4. Requirement engineering

Requirement of system이란, 시스템이 제공해야하는 service와 그것의 operation의 제약사항을 의미한다. 이러한 요구사항을 찾고, 분석하고, 문서화하고 검토하는 프로세스를 Requirement engineering이라고 한다. 이러한 프로세스는 보통 Software Engineer의 첫번째 단계로 여겨진다. 여기서는 Agile방식이 아닌 클래식한 Plan-driven방식에서의 Requirement engineering을 다룬다.

 

이러한 요구사항은, Description level에 따라 두가지 유형으로 나눌 수 있고 각기다른 이해관계자를 위한 서술이다.

1) User requirement : diagram과 natural language 들로 구성된 추상화된 기술

2) System requirement : 시스템의 functions, services, operational constraints에 대한 자세한 기술

 

4.1 Functional and non-functional requirement

 

Requirement는 크게 두가지로 분류된다.

1) Functional requirement : 어떤 서비스를 시스템을 제공해야하는지

2) Non-functional requirement : 시스템이 제공하는 서비스나 기능에 대한 제약사항이 어떤 것인지

 

하지만, 요구사항들은 명백히 두가지 타입중 하나로 분류되지 않으며, 요구사항들은 서로 종속되어있기도 하며, 하나의 요구사항이 다른 요구사항을 생성하기도 한다.

 

4.1.1 Functional requirements

Functional requirements는 시스템이 무엇을 해야하는지를 설명한다. 이것은 completeness와 consistency를 만족해야 한다. completeness란, 모든 서비스와 사용자에 의해 요구되는 정보들이 빠짐없이 기술되어야 한다는 뜻이고, consistency란, 요구사항간에 충돌이 존재해서는 안된다는 것이다. 이러한 것들이 만족되지 않고, 애매모호하게 작성된 functional requirement의 경우, 고객과 개발자 사이의 논쟁을 불러일으킨다.

 

4.1.2 Non-functional requirements

Non-functional requirements는 시스템 전체에 대한 특징들을 설명한다. 이것은 종종 개별적 기능 요구사항보다 중요하다. 예를 들어, reliability 요구사항이 보장되지 않은 항공기 컨트롤 시스템의 경우, 판매가 불가능하다. 기능적 요구사항은 각각을 어떤 소프트웨어 컴포넌트로 구현할지 결정하기 쉽지만, non-functional requirement의 경우 그렇지 않다. 왜냐하면, 이러한 비기능적 요구사항은 전체 시스템 아키텍처에 영향을 받고, 종종 새로운 functional requirement를 생성하기도 하고 기존의 요구사항에 제약사항을 가하기도 하기 때문이다.

Non-functional requirements는 다음과 같이 크게 분류될 수도 있다.

1) Product requirements, 2) Organizational requirements, 3) External requirements

이러한 non-functional requirements는 가능하면 quantative하게 작성하는것이 좋고, functional requirement와 충돌하는지, 다른 non-functional requirements와 충돌하는지에 대한 검토가 필요하다.

 

4.2 Requirements engineering processes

 

Requirements engineering process는 크게 1) elicitation and analysis, 2) specification, 3) validation의 단계로 진행된다. 하지만, 이러한 과정은 interleaved될 수 있고, 비즈니스, 사용자, 시스템 요구사항에 따라 각각 수행된다. 최종결과물은  requirement document가 되어야 한다.

 

4.3 Requirements elicitation 

 

요구사항 도출과정은 크게 다음과 같고, interleaved될 수 있다.

1) Requirements discovery and understanding

2) Requirements classification and oragnization

3) Requirements prioritization and negotiation

4) Requirements documentation

 

하지만, 요구사항 도출을 어렵게 만드는 요인이 있다.  

1) 이해관계자들(Stakeholders)이 실제로 컴퓨터 시스템에게 기대하는 바를 정확하게 말하지 못한다.

2) 이해관계자들은 그들의 용어로 요구사항을 표현하여, 도메인 경험이 없다면 이해하기 어렵다.

3) 여러 다른 이해관계자들은 각각 다른 방식으로 요구사항을 표현한다.

4) 요구사항에 그들의 영향력을 확장하기 위한 정치적인 것이 포함되어 있을 수 있다.

5) 실제 비즈니스 환경은 동적이므로, 수시로 요구사항이 변할 수 있다.

Documentation단계에서 간단한 언어와 다이어그램을 이용하여 묘사함으로서, 이해관계자가 이해하도록하고 피드백 받는 것이 필요하다.

 

4.3.1 Requirements elicitataion techniques

크게 두가지 방법이 존재한다.

1) Interviewing 

인터뷰는 미리 질문이 정해진 Closed Interview와 미리 정해진것이 없는 Open Interview로 나뉜다. 실제로는 두가지 방법을 혼합해서 사용한다. 인터뷰에서 도메인 전문가가 아니라면 그들이 말하는 것을 이해하기 어려울 수 있다. 또한, 당연하다고 생각하는 것을 설명하지 않을 수 있고, 외부의 사람에게 실제로 조직적인 이해관계 때문에 발생하는 것들을 말하기 꺼려할 수 있다. 사실, 인터뷰는 단독으로 사용되는 것이 아닌 다른 technique과 함께 사용해야 한다.

2) Observation or ethnography

소프트웨어 시스템은 실제로 혼자서 동작하지 않고, 사회적이고 조직적인 환경에서 동작하고 그에 따라 제한되기도 한다. 공식적인 프로세스보다는 실제로 운영되는 환경과, 실제적인 일들을 관찰함으로서 사람들이 실제로 일하는 방법을 반영하는 암묵적인 요구사항을 발견할 수 있다. 객관적인 제 3자에 의해 조직내의 다른 일들과의 관계를 이해할 수 있다. 

또한, Ethonography기법을 통해 사용자를 둘러싼 환경을 더 잘 이해할 수 있다.

 

4.3.2 Stories and scenarios

사람들은 추상화된 묘사보다 실제로 사용되는 예시를 보여주었을 때 더 이해하기 쉬워한다. Story, Scenario는 인터뷰 과정 등에 활용되어 이해관계자들과의 커뮤니케이션에 도움을 줄 수 있다. Story는 실제 시스템의 사용방식에 대해 스토리형식으로 서술하고, Scenario는 입력 및 출력과 같은 조금 더 구조화된 서술방식을 따른다. 하지만, 이 둘 모두 특정한 task에 대해 실제로 어떻게 시스템이 사용되는지를 설명할 수 있다는 측면에서 같다.

 

4.4 Requirements specification

 

요구사항 명세는 User/System Requirements를 Requirement document에 실제로 작성하는 프로세스를 말한다.

이상적으로 작성된 명세는 명확하고, 완전하고, 일관성이 있어야 하지만, 이것은 실질적으로 불가능하다.

 

1) User requirement : natural language로 작성, functional/non-functional requirement 포함, 기술적인 지식이 없더라도 이해할 수 있어야 하며 이상적으로는 시스템 외부의 행위만을 묘사해야하고 시스템 아키텍처나 디자인에 대한 묘사를 포함해서는 안된다. 

 

2) System requirement : natural language 및 수학적 모델과 시각적 요소들을 포함하여 작성, functional/non-functional requirement 포함, user requirement의 실제 엔지니어를 위한 버전이며 디자인의 시작점이다. 실제로 계약의 일부분으로 사용될 수 있으며, 시스템 전체에 대한 자세하고 완전한 서술을 포함해야 한다. 디자인 이전단계이므로, 이상적으로는 아키텍처나 디자인 정보가 포함되면 안되지만, 실질적인 이유때문에 불가능하다.

 

4.4.1 Natural language specification 

Natural language는 가장 일반적인 서술방식이지만, 모든 사람들이 동일하게 이해하지 못하게 하는 측면이 있다. 이를 보완하기 위한 몇가지 가이드라인이 있다. 1) 표준 형식 도입, 2) 필수 요구사항과, 그렇지 않은 요구사항 분리, 3) 텍스트 강조, 4) 읽는 사람이 기술적인 엔지니어링 용어를 모른다고 가정, 5) 요구사항에 대한 근거를 관계시키려는 시도

 

4.4.2 Structured specifiations

구조화된 템플릿이 제공된 채로 기술된 요구사항 명세는 free-form형태의 natural language 서술방식보다 정확한 이해를 할 수 있도록 돕는다. 이러한 템플릿에는 function, input, output, description 정보 등이 포함된다.

 

4.4.3 Use cases

Use cases란 grapical model, structured text를 가지고 사용자들과 시스템간에 발생하는 상호작용을 설명하는 방식이다.

하지만, 보통은 modeling단계에서 사용된다.

 

4.4.4 Software requirements document

Software requirements document는 개발자가 구현해야하는 것에 대한 공식적인 명세이다. 시스템 개발이 다른 팀에 의해 아웃소싱될 때 필수적으로 필요하며, 시스템에 따라 Detail의 정도가 달라진다. Critical System의 경우 다른 시스템보다 더 많은 세부적인 요구사항이 필요하다. Agile method의 경우, document를 따로 작성하지 않고, user story와 같은 형태로 incrematally하게 요구사항을 수집한다. IEEE 요구사항 문서표준에서는, 문서에 어떤 내용이 포함되어야 하는지를 명시하고 있으며, predicted system evolution에 대한 정보를 포함하기도 한다.

 

4.5 Requirements validation

 

요구사항이 고객이 원하는것을 정확하게 정의하고 있는지를 검사하는 프로세스. Requirment document의 에러는 막대한 재작업 비용을 발생시키기 때문에 매우 중요하다. 체크항목은 다음과 같은 것들이 있다.

1) Validity check, 2) Consistency check, 3) Completeness checks, 4) Realism checks, 5) Vefiability

이러한 validation process는 다음과 같은 기술들과 함께 쓰일 수 있다.

1) Requirements reviews, 2) Prototyping, 3) Test-case generation

실제적으로, 모든 요구사항에서 문제를 찾는 것은 어렵고 이후 요구사항의 변경은 필수적으로 발생하게 된다.

 

4.6 Requirments change

 

개발과정이 진행됨에 따라, 이해관계자의 문제에 대한 이해도가 높아지면서 이에 따른 요구사항의 변화는 반드시 일어나게 된다. 대부분의 요구사항의 변화는 비즈니스 환경의 변화때문에 발생하고, 시스템 개발에 참여하는 사람과 End-User이 같지 않으며, 다양한 이해관계자가 요구사항을 다른 방식으로 이해하기 때문에 발생한다.

요구사항의 변화는 요구사항간의 연관관계를 유지하며 추적할 수 있어야 한다. 또한, 변화간의 우선순위를 정하여 우선순위가 낮은 것은 다음 iteration에 반영될 수 있도록 하여야 한다.

 

4.6.1 Requirements management planning

요구사항 관리 계획은 변화하는 요구사항을 어떻게 관리할 것인가를 결정하는 것이다. 다음과 같은 것들을 결정해야 한다.

1) Requirement identification, 2) A change management process, 3) Traceability policies, 4) Tool support 

필요하다면 자동화된 tool을 사용하여 관리하는 것도 좋다.

 

4.6.2 Requirement change management

요구사항 변화 관리 프로세스는 크게 다음과 같은 단계를 따른다.

1) Problem analysis and change specification, 2) Change analysis and costing, 3) Change implementation