요구 공학 프로세스

1. 타당성 조사
1) 타당성 조사(Feasibility studies)란?
- 새로운 시스템의 경우, 요구 공학 프로세스의 출발점
- 입력: 시스템의 개요나 어떻게 사용되는지에 대한 기술
- 결과: 요구 공학이나 시스템 개발 프로세스를 진행할 지에 대한 보고서
- 다음과 같은 질문들의 답을 구하는 것이다.
□ 시스템이 기관(organization)의 전체적인 목적(objectives)에 부합하는가?
□  시스템이 현재의 기술과 비용을 가지고, 스케줄대로 진행될 수 있는가?
□  기존의 다른 시스템과 통합(integration)될 수 있는가?

시스템이 비즈니스(business)의 목적(objectives)에 부합하는지의 여부는 상당히 중요한 문제 이다. 그럼에도 불구하고, 정치적 간섭을 피하기 위해 이를 명확히 하지 않아서 쓸모없는 시스템을 만드는 경우가 발생하기도 한다.

2) 타당성 조사의 세부 작업들
① 정보 평가(information assessment) : 앞의 3개 질문들을 답하는데 필요한 정보들을 식별 하는 것.  정보 평가를 중심으로 정보 수집과,  보고서 작성이 이루어진다.
② 정보 수집(information collection) : 질문들에 대한 답변에 필요한 정보를 수집하는 것으로 시스템을 사용할 부서 관리자, 소프트웨어 엔지니어, 기술 전문가, 최종 사용자에 문의 할 수 있다.
③ 보고서 작성(report writing) : 타당성의 조사 과정 및 결과를 정리 개발 범위,  예산 또는 스케쥴 조정의 제안을 포함할 수 있다.


2. 요구사항 추출, 분석 및 확인
1) 요구사항 추출 및 분석(Requirements elicitation and analysis)
- 타당성 조사를 마친 후, 기술자가 고객 및 사용자와 함께 응용 도메인(application domain) 과 시스템이 제공해야 할 서비스(services), 시스템의 성능, 시스템의 조작상의 제약사항 (constraints)들을 찾아내는 작업이다.

2) 요구사항 추출 및 분석의 문제점
① 컴퓨터 시스템으로부터 원하는 것을 정확히 표현하지 못하거나 비현실적 요구를 하는 관련자들(stakeholders)이 많다.
② 관련자들(stakeholders)은 각자의 환경에서 익숙한 표현을 사용한다.
③ 다양한 관점들 때문에 서로 다른 요구사항을 가지는 경우가 발생하기도 하며, 동일한 내용이 다르게 표현되기도 한다.
④ 정치적인 이유 때문에 특정 기능을 요구하는 경우도 있다.
⑤ 관련한 환경이 동적이기   문에, 요구사항이 바뀌거나 새롭게 추가될 수 있다.

* 관련자들(stakeholders)이란?
직간접적으로 시스템 요구사항에 영향을 기치는 사람들로 최종사용자뿐만 아니라 조직의 비즈니스 관리자, 관련 시스템 기술자, 도메인 전문가, 노조 대표 등도 포함된다.

3) 요구사항 추출 및 분석 과정

P.125 그림 6.2 The requirements elicitation and analysis process

- 도메인 이해(Domain understanding)
분석가(Analyst)가 특정 도메인에 대해서 이해하는 과정으로, 예를 들어 슈퍼마켓에 대한 시스템이 필요할 경우,  분석가는 슈퍼마켓이 어떤 식으로 운영되는지 알아야한다.

 

- 요구사항 수집(Requirements collection)
요구사항을 발견하기 위해 관련자들과 접촉하는 과정이며, 이 단계를 진행하는 동안 도메인 의 이해도가 더욱 증가하게 된다.

 

- 분류(Classification)
특별한 규칙없이 모여있는 요구사항들을 특정 기준에 맞추어 분류하고 조직화한다.

 

- 충돌 해결(Conflict resolution)
다양한 다수의 관련자가 참여했기 때문에 요구사항들끼리 모순이 되는 등 충돌이 일어날 수 있다. 이러한 충돌을 찾고 해결하는 과정이다.

 

- 우선순위 결정(Prioritization)
요구사항들 중에서 다른 것들보다 우선되야하는 중요한 내용들이 존재하는데, 이 단계를 통 해 가장 중요한 것들부터 그렇지 않은 것들까지 우선순위를 결정한다.

 

- 요구사항 검사(Requirements checking)
요구사항이 완전한지(complete), 일관성이 있는지(consistent), 실제로 관련자들이 시스템으로부 터 원하는 것인지 등을 검사한다.

4) 요구사항 확인(Requirements validation)
- 요구사항이 고객이 원하는 시스템과 정말로 일치하는가를 보여주는 과정이다.
- 요구사항에서의 문제점을 찾는다는 점에서는 요구사항 분석단계와 유사하지만, 분석 단계는 불완전한(incomplete) 요구사항으로 작업을 한다는 점에서 완전한(complete) 요구사항 문서를 가지고 작업을 진행하는 확인(validation) 과정과는 차이가 있다.

요구사항 문서(requirements document)에서의 오류(errors)가 개발(development)단계나 이미 동작하고 있는 상태(in service)에서 발견된다면 엄청난 재작업의 비용(extensive rework costs)을 필요로 하게 된다.

5) 요구사항 확인에서 필요한 검사
- 타당성 검사(Validity checks)
시스템이 사용자들의 요구사항에 가장 적합한 기능을 제공하는가?

 

- 일관성 검사(Consistency checks)
충돌이 생기는 요구사항은 없는가?

 

- 완전성 검사(Completeness checks)
고객이 요구하는 모든 기능과 제약 사항이 포함되었는가?

 

- 현실성 검사(Realism checks)
주어진 예산과 기술로 요구사항을 구현할 수 있겠는가?

 

- 검증가능성(Verifiability)
요구사항이 체크리스트에 의해 검사될 수 있는 형태인가?


6) 요구사항 확인 기술(Requirements validation technique)
- 요구사항 검토(Requirements review)
검토 담당 팀이 요구사항을 수작업을 통해 체계적으로 분석한다.

 

- 프로토타이핑(Prototyping)
시스템의 실행 가능한 모델을 가지고 사용자(end-users)나 고객(customers)을 대상으로 데모 (demonstration)를 실시한다. 모델을 이용한 경험을 통해 고객들은 자기가 요구하는 바를 명 확하게 확인할 수 있게 된다.

 

- 테스트-케이스 생성(Test-case generation)
요구사항은 테스트가 가능하도록 작성된다. 확인 과정에서 테스트케이스를 만들어 문제점 을 밝힌다.

 

- 자동화된 일관성 분석(Automated consistency analysis)
CASE 등을 이용해서 구조화된 요구사항 기술에 대해서는 일관성을 검사할 수 있다.

7) 요구사항 검토(Requirements reviews)시 체크 사항
① 검증가능성(Verifiability)
요구사항이 현실적으로 테스트 가능하게 작성되었는가?

 

② 이해가능성(Comprehensibility)
시스템 사용자(end-users)가 요구사항을 명확하게 이해할 수 있는가?

 

③ 추적가능성(Traceability)
요구사항의 출처(origin)을 명확히 기술하였는가?
- 추적가능성을 통해 요구사항 변화가 미치는 영향을 평가할 수 있기 때문에 중요.

 

④ 적응가능성(Adaptability)
요구사항이 적응 가능한가? 즉, 시스템의 다른 요구 사항들에 큰 영향을 미치지 않고 특정 요구사항을 변경할 수 있는가?


3. 요구사항 관리(Requirements management)
1) 요구사항 관리(Requirements management)란?
- 요구 공학 프로세스나 시스템 개발 과정에서 발생하는 요구사항의 변화를 이해하고,  
통제하는 프로세스를 의미한다.

• 요구사항은 불완전(incomplete)하며, 불일치(inconsistency)가 존재할 수밖에 없다.
- 비즈니스 자체가 변화할 뿐 아니라, 점차적으로 시스템의 이해도가 높아지기 때문에 새로 운 요구사항이 추가될 수 있다.
- 서로 다른 관점 때문에 다양한 요구사항이 발생할 수 있고, 이 때문에 모순이 발생하기도 한다.
Tip: 복잡한 대규모 시스템은 해결하고자 하는 문제 자체가 본질적으로 사악(wicked)하다고 합니다. 초기에 명확히 문제를 정의하기는 불가능하며 솔루션을 개발해 나감에 따라 문제의 본질이 드러난다고 할 수 있습니다.

 

3) 요구사항이 바뀌는 이유
① 큰 규모의 시스템은 대부분 다양한 사용자 집단을 가지고 있기 때문에, 이에 따른 요구 사항이나 우선순위의 관점이 각양각색으로 나타날 수 있다.
② 시스템 비용을 지급하는 사람과 시스템 사용자가 다른 경우가 많기 때문에, 조직이나 예산 제약에 따른 요구사항이 추가되는 경우가 있다.
③ 비즈니스 및 기술적인 환경이 변화한다.


4) 진화(evolution) 관점에서의 요구사항의 분류
- 영구적 요구사항(Enduring requirements)
조직의 핵심 활동으로부터 얻어지는 것으로 시스템 도메인에 직접적으로 관련 있는 요구 사항이며 비교적 안정적(stable)이다. 예를 들어, 병원의 경우 환자나 의사, 간호사, 처치 등과 관련한 요구사항들은 도메인 모델로부터 도출될 수 있는 것들이다.

- 휘발성 요구사항(Volatile requirements)
시스템의 개발 중 또는 사용되면서도 충분히 요구사항에 대한 변경이 발생할 수 있는 부 이다.

□  변하기 쉬운 요구사항(Mutable requirements)
(예: 의료 정책이 바뀌어서 기존과 다른 정보가 필요한 경우)
□  새로 나타나는 요구사항(Emergent requirements)
(예: 고객의 시스템 이해도가 진전 됨에 따라 새로운 요구사항이 나타나는 경우)
□  결과로 일어나는 요구사항(Consequential requirements)
(예: 컴퓨터 시스템의 도입으로 인해 새로운 작업방식이 가능한 경우)
□  호환 요구사항(Compatibility requirements)
(예: 다른 시스템이나 비즈니스 프로세스의 변화로 인해 호환이 필요한 경우)

5) 요구사항 관리 계획(Requirements management planning)
- 요구사항 식별(Requirements identification)
각각의 요구사항은 유일하게 구별되어야 한다.

 

- 변화 관리 프로세스(A change management process)
변화의 영향(impact)과 비용(cost)에 대해 평가하는 활동이다.

 

- 추적가능성 정책(Traceability policies)
요구사항들간 또는 요구사항과 시스템 설계간의 관계를 정의하고 기록하며, 어떻게 이러한 정보들을 유지할지 방법을 정의한다.

- CASE도구 지원(CAE tool support)
요구사항 관리를 위해서는 요구사항에 대한 많은 양의 정보를 처리할 수 있어야 하므로 도 구를 사용하도록 한다.

6) 추적가능성(Traceability)
- 요구사항들끼리 또는 요구사항과 시스템 설계 사이에는 다양한 관계가 존재하며, 각 요구사 항들은 제안된 이유가 있다. 만약 요구사항이 변경될 경우, 그에 따른 영향을 받는 관련 요 구사항(또는 설계)을 파악할 수 있어야 한다.

• 추적가능성의 종류
- 소스 추적가능성 정보(Source traceability information) : 요구사항과 그것을 제안한 관련자 들 및 제안 이유에 대한 정보이다. 만약 요구사항의 변화가 필요할 경우, 담당자를 찾아 변화에 대해 상담을 하기 위해서 필요한 정보이다.

 

- 요구사항 추적가능성 정보(Requirements traceability information) : 특정 요구사항에 대해 관련된 요구사항들에 대한 정보이다. 만약 요구사항이 변경될 경우, 이에 영향을 받는 다 른 요구사항들과 그 정도를 파악하기 위해서 필요한 정보이다.

 

- 설계 추적가능성 정보(Design traceability information) : 해당 요구사항에 해당하는 설계에 대한 정보이다. 만약 요구사항이 변경될 경우, 이에 영향을 받는 시스템 설계 및 구현들 을 파악하기 위해서 필요한 정보이다.

p.143 Figure 6.18 A traceability matrix

위의 추적가능성 메트릭은 요구사항들간의 관계를 파악하게 해준다. 큰 규모의 시스템의 경우는 이러한 메트릭을 사용하는 것 보다는 CASE등의 도구의 지원을 받는 것이 유리하다.  

U : 행(row)에 해당하는 요구사항이 열(column)에 해당하는 요구사항을 사용함(uses)을 의미.

예: 1.1 uses 1.2 / 1.2 uses 1.3 / ...
R : 행(row)에 해당하는 요구사항과 열(column)에 해당하는 요구사항간에는 약한 관계(weaker relationship)이 존재함을 의미한다.
예: 1.2는 2.3  과 약한 관계 가짐 / 3.2는 3.1과 약한 관계 가짐


7) CASE 도구의 지원
- 요구사항 저장(Requirements storage) : 안전하게 관리되는 저장소에 보관
- 변경 관리(Change management) : 각 단계 및 단계간의 정보 흐름을 관리
- 추적가능성 관리(Traceability management) : 요구사항을 자동으로 추적

문제인식 

□  문제분석과 변경 제안(문제를 분석하고 타당한지를 판단하며 상세한 변경, 제안) 

□   변경 분석과 비용 추정(추적 가능성 정보를 이용하여 영향을 분석하고 비용을 추정 하고 변경할 것인지를 결정) 

□  변경 구현(요구사항 문서나 설계 또는 구현 사항 변경)


[정리하기]
요구 공학은 타당성 검사(feasibility study), 요구사항 추출 및 분석(requirements elicitation and analysis), 요구사항 명세(requirements specification)와 요구사항 관리(requirements management)를 포함하는 프로세스이다.

요구사항 분석은 도메인 이해(domain understanding), 요구사항 수집(requirements collection), 분류(classification), 구조화(structuring), 우선순위 정하기(prioritisation)와 확인(validation)과 관련한 반복적인(iterative) 작업이다. 

시스템과 관련한 담당자들은 다양한 관점을 가지고 있으며, 이로 인해 다양한 요구사항들이 발생하게 된다. 사회적이거나 조직적인 요소들도 시스템 요구사항 에 영향을 미친다. 

 

요구사항 관리(requirements management)는 계획(planning)과 변경 관리(change management)를 포함한다.
 
[참고하기]
Requirements Engineering
by Elizabeth Hull, Ken Jackson, Jeremy Dick
http://www.amazon.com/exec/obidos/tg/detail/-/1852335777/qid=1078490922/sr=1- 3/ref=sr_1_3/103-7583756-7029449?v=glance&s=books
200 쪽 정도의 분량으로 최신의 요구 공학 기술을 간단 명료하게 설명한 책이다. 요구사항 추출, 검증 및 확인, 변경 관리 등에 관한 일반적 방법과 구체적 방법을 예를 들어 설명하고 있다.