Requirement Engineering(요구공학)이란?


Requirements engineering(요구공학) 고객이 시스템에 요구하는 서비스가 무엇인지 확립하고 시스템을 개발하고 운영하는 동안 충족해야하는 제약사항(constraint) 무엇인가를 정립하는 과정이다.

 

실질적인 개발 과정에서 가장 먼저 진행되는 작업이다. 이 작업의 결과를 바탕으로 이후의 설계(design), 구현(implementation), 테스트(test)가 진행되기 때문에 굉장히 중요한 단계라고 볼 수 있다.

 

요구사항(requirements)으로서 정립되는 것에는 개발하고자 하는 시스템이 제공하는 기능, 서비스, 시스템이 반드시 충족해야하는 제약사항(constraint) 등이 있다. 이러한 요구사항을 도출, 정리, 분석, 검증해나가는 일련의 과정을 Requirement Engineering이라고 한다.

 

시스템에 대한 요구사항을 완전하게(complete), 그리고 요구사항 간의 충돌이 없도록 일관성 있게(consistent) 정립하는 것을 추구한다.

 

 

 

 

 

User and System Requirements


User requirements

시스템이 제공하는 서비스와 운영에 있어서의 제약사항들을 우리가 쓰는 언어인 자연어(natural language)와 추가적으로 이해를 높이기 위한 그림이나 표와 같은 diagram을 통해 보완하여 서술한다. 기술적 배경지식이 없어도 이해하기 쉽도록 하며, 주로 고객을 위해 쓰여진다. 

 

 

 

System requirements

User requirements보다 더 상세하며, 구조화된 기술적인 정보를 포함하는 문서이다. 무엇이 구현되어야 하는지 정의한다. 주로 클라이언트(client)와 계약자(contractor) 사이의 계약 또는 개발자를 위해서 쓰여진다. 

 

 

 

 

 

Functional, non-functional and domain requirements


functional requirements

시스템이 제공해야하는 서비스에 대한 기능, 시스템이 특정 입력값(input)에 대해서 어떻게 반응해야 하는지, 특정 상황에서 어떻게 동작해야 하는지 기능적인 요구사항을 기술한다. 이에 추가하여 시스템이 하지 말하야 하는 것에 대해서도 기술할 수 있다.

 

non-functional requirements

시스템에 의해 제공되어지는 서비스 및 기능들에 대한 각종 제약사항들(constraints)과 시스템 전체로서의 특성 및 안정성(safety), 성능(performance)에 대한 System Properties(+ emergent property) 대해 기술한다.

process requirements(개발 환경 - IDE, Programming Language, Framework, Development Method)도 이에 포함된다.

전반적인 시스템 구조에 치명적인 영향을 줄 수 있으므로 중요하다. 또한, 하나의 non-functional requirements로부터 여러 개의 functional requirements가 파생될 수 있다. (ex. security -> 각종 보안을 위한 functional requirements)

 

domain requirements

시스템의 운영 환경에서 사용되는 도메인의 여러 가지 속성들, 주제, 방법, 절차들에 대해 기술한 것으로, 개발자가 해당 시스템의 도메인에 대해 학습하고 내재되어있는 해당 requirements를 도출하도록 노력해야 한다. 전문성이 요구된다.

 

 

 

 

Requirement Imprecision


요구사항에 대한 유저의 이해와 개발자의 해석은 다를 수 있다.

고객은 보다 크게 생각하고, 개발자는 이를 작게 나누어 생각한다는 특성이 있다.

이러한 부분을 명확히 하지 않으면 갈등의 소지가 존재하게 된다.

 

 

 

 

Software Requirement Document


소프트웨어 개발자를 위해서 시스템이 무엇을 해야하는지 기술한 공식 문서이다.

User Requirements의 정의와 System Requirements의 명세를 모두 포함해야 한다.

Design Document가 아니기 때문에 How(How System should do)가 아닌 What(What System should do)에 초점을 둔다.

 

 

 

 

Agile Methods and requirements


많은 애자일 방법론에서 요구 문서(requirements document)를 작성하는 것은 시간 낭비라고 여기기도 한다. requirements는 끊임없이 변화하기 때문이다. 따라서 XP(Extreme Programming)와 같은 메소드에선 incremental requirement engineering 또는 requirements를 user stories로써 기술하기도 한다.

 

이러한 관점은 실질적인 비즈니스 시스템에서 충분히 제기될 수 있는 관점이지만, 여러 팀에서 함께 개발하는 대규모 시스템 또는 충분한 사전 분석이 필요한 핵심적인 시스템을 개발할 때는 문제가 될 수 있다.

+ Recent posts