Plane-base 개발의 경우, 개발 중간에 다시 requirement로 돌아가기 매우 어려우므로, 신중히 requirement를 도출하여야 한다. 반면에, Agile 방법에서는 버전이 계속 업그레이드 되는 방식이므로, 비교적 자유롭다.

Requirements engineering and processes

Requirement engineering은 고객의 시스템에 대한 요구사항과 제한 사항을 도출하는 과정이다. System requirement는 시스템 서비스와 제약 사항들에 대한 설명이다.

What is requirement?

시스템의 서비스와 제한 사항에 대한 추상적인 정보부터 구체적 기능 명세까지를 어우른다. 특히 requirement자체가 계약서가 되는 경우도 존재한다. 또한 requirement는 plan-based의 시발점이 되므로 매우 중요하다.! SI회사들(LG CNC, SK C&C 등)은 사용자에게 서비스를 제공하는 회사들로, requirements를 매우 중요하게 생각한다.

< Types of requirements >

"User requirement을 어떻게 잘 추출하여 System requirement로 바꿀 것인가?"

• user requirements : 자연어로 되어 있으며, 사용자가 시스템에서 필요한 내용들과 그에 대한 제한사항등을 말한다.

• System requirements : 보통 User requirement이후 생성되며, detail한 시스템 기능, 서비스, 연산 제약사항등을 나타낸다. 개발자에게 전달되어야 하므로, 서비스와 운영에 대해서 구체적이며 구조적이여야 한다.

< System stakeholders >

시스템 이해관계자(Stakeholders)들로는 Users, System managers, System Owners, External Stakeholders이 있다.

< Agile methods and requirements >

애자일 방식이 incremental하므로, requirements가 중간에 변하여도 flexible하게 시스템에 반영할 수 있다.

Functional and Non-Functional requirements

Functional requirements

SW의 기능적 관점을 말한다. 즉, 시스템이 제공해야하는 서비스들에 대한 설명이며, 특정 inputs에 대해 어떠한 행동을 취해야하는지 기술한다. 시스템이 하지 말아야 할 일도 기술할 수 있다. Functional requirements는 추상적인 사용자의 요구사항을 detail하게 시스템 서비스를 기술해야 한다.

< Requirements imprecision >
functional requirements가 제대로 도출이 안되면, 문제가 발생한다. 모호한 requirements는 개발자와 사용자간의 다른 해석(의도)을 낳을 수가 있다.

< Requirements completeness and consistency >

• Complete : 가능한 detail하게 해서 오해의 여지를 없애는 것이다.
• Consistent : 시스템 기능들간 충돌이 없어야 한다.

Non-functional requirements

기능 외적으로 신뢰성, 보안성, 개발 프로세스의 제약, 법률 등 시스템에서 요구되는 것들과 제한 사항을 나타낸다. 심지어 functional한 것보다 더욱 중요할 수 있다.

< Non-functional Requirements implementation >
Non-functional Requirements는 시스템 전반에 영향을 끼칠 수 있다. 예를 들어 보안성이라는 요구사항은, functional한 requirements의 추가들로 연결될 수 있다.

< Non-functional Requirements classifications >

• Product requirements : 신뢰성, 실행 속도 등이 있다
• Organisational requirements : 회사 조직 내의 정책들과 절차에 맞춘 요구사항들
• External requirements : 규정, 법규, 인증 등 시스템과 개발 외적인 요구사항들

< Goal and requirements >
비기능적 요구사항들은 도출하기도 어렵고, 검증하기도 어렵다. 이것의 목표(Goal)은 사용자의 일반적인 의도이며, 이러한 goals은 개발자들에게 사용자의 의도를 전달하므로써 도움을 준다.

Requirements elicitation

Requirements specification

Requirements validation

Requirements change