1. 요구공학 (Requirement Engineering)
요구사항이란, 시스템이 제공해야하는 서비스와 작동에서의 제약사항을 의미한다.
요구공학은 이러한 요구사항을 추출하고, 분석하고, 문서화하고, 확인하는 것을 의미한다.
전체적인 소프트웨어공학 프로세스에서 가장 첫번째 단계라고 할 수 있다. (실제 현업에서는 Feasibility Study, 즉 기술의 실현가능성이나 타당성을 조사하는 것을 첫 단계로 하기도 함)
2. User and System Requirements
1) User Requirements
서비스와 제약사항에 대한 추상적인 언급
ex) 정신문제가 있는 사람을 치료하는 MENTCARE 시스템에서의 유저 요구사항 ; 약의 양, 비용 등
2) System Requirements
시스템의 기능에 대한 디테일하고 형식적인 정의
이 두가지 요구사항이 모두 중요한 이유는, 요구사항을 읽는 독자마다 다른 방식으로 요구사항을 읽기 때문이다.
클라이언트 매니저의 경우는 User Requirement에 주로 관심이 있다면, 소프트웨어 개발자는 System Requirement에 주로 관심이 있다.
ex) 정신문제가 있는 사람을 치료하는 MENTCARE 시스템에서의 시스템요구사항 = 보다 구체적
달의 마지막 일한 날 이후 5시반이 지난 후 리포트, 투약량, 처방횟수 등 보다 구체적으로. 시스템 접근자에 대한 제약
3. Functional and Non-functional Requirements
시스템 요구사항은 Functional and Non-functional Requirements로 나누어 볼 수 있다.
1) Functional Requirements
- 시스템이 제공해야 하는 기능과, 시스템이 해서는 안되는 부분에 대한 것
- 함수별 input과 output을 기술하며, 각 함수에 대해서 요구사항이 존재함
- 아주 general한 요구사항부터 specific한 요구사항까지 다양할 수 있는데, 만약 요구사항이 불명확할 경우 고객과 개발자 간의 오해의 소지가 생겨서 시간과 비용이 늘어날 위험이 존재한다.
- 따라서 요구사항을 완벽하게, 전부 작성하고 그 요구사항들 간의 모순이 없는지 확인하는 것이 이상적이다. 그렇지만 현실적으로는 큰 시스템 안에서 다양한 이해관계자가 있기 때문에 완벽하게 요구사항을 작성하는 것은 어렵다.
2) Non-functional Requirements
- 기능이 아니라, 시스템이 제공하는 '제약조건'에 대해 관심이 있음
- 메모리 사용량, 시간 제한 등 전체적인 시스템에 대한 요구사항임
- 일반적으로 전체 단위에 대한 요구사항인 Non-functional Requirements가 individual functional requirements보다 중요하다.
- 이해관계자들이 요구사항을 general하게 제시하기 떄문에, 평가 가능하고 측정 가능하게 바꾸는 작업이 필요하다. 즉 요구사항을 테스팅이 가능한 지표로 바꾸는데, speed는 processed transactions per second로, robustness는 percentage of events causing failure 등으로 바꿀 수 있다.
- 유저의 니즈를 반영하여 생기는 요구사항이다.
(1) Product Requirements
- 소프트웨어의 runtime behavior을 명세하는 것.
- 실행 속도, 메모리 사용량, 수용가능 실패율 등
(2) Organizational Requirements
- 고객 조직이나 개발자 조직의 정책으로 생긴 요구사항
- 특정 언어로 구현해야 한다거나, 사용되어야 하는 프로세스 스탠다드 등
(3) External Requirements
- 시스템 외부적 요인
- 원자력 시스템에 대한 법적 규제, 제약사항 등
4. Requirements engineering process
요구 공학에는 3가지 핵심적인 key activity가 있다. 아래 activity들은 폭포수 과정이 아니라, interleaving하게 진행된다.
1) Elicitation and Analysis
(1) 이해관계자들이 하는 일을 이해하고, 그들이 어떻게 새로운 시스템을 사용할지 파악하는 단계를 의미한다.
(2) 관련 문제
- 이해관계자들 자신이 무엇을 원하는지 모를 수도 있고, 그들만의 용어로 요구사항을 표현할 수 있다는 문제가 있다. 더불어 다른 이해관계자는 각각 다른 요구사항을 표현하며, 정치적 요소가 시스템 요구사항에 영향을 미칠수도 있다. 더불어 요구사항은 분석과정에서 다이나믹하게 변화할 수 있다는 문제가 존재한다.
(3) Elicitation and Analysis 프로세스
- 요구사항을 발견하고, 이해한다. 이해관계자들과 상호작용하며 요구사항을 파악한다.
- 요구사항을 분류하고, 조직화한다. 관련된 요구사항을 그룹화하는 과정이다.
- 요구사항의 우선순위를 정하고, 타협한다.
- 요구사항을 문서화하여 초안을 작성한다.
(4) Elicitation 기술
- 직접 대화하고 인터뷰하면서 이해관계자들이 무엇을 원하는지 알아낼 수 있다. predefined된 질문을 갖고 하는 closed interview 형식과, predefined된 주제 없이 진행하는 open interview가 있다.
- 직접 이해관계자들의 업무 현장을 보고 관찰하여 파악하는 방식도 있다.
(5) Stories and Scenarios를 통해 요구사항을 추출할 수 있다.
- 시스템이 특정 task에 어떻게 이용될지 묘사하고 인터뷰에 참여함으로써 customer와의 토론 과정에서 요구사항을 보다 잘 파악할 수 있다.
- story는 하이 레벨의 narrative한 묘사라면, scenario는 input과 output이 포함된 보다 formal하고 specific한 형식이다. 시스템의 기대사항, 플로우, 잘못될 수 있는 부분들, 상태들을 담고 있다.
2) Specificaton
(1) 유저와 시스템 요구사항을 작성, 문서화하는 과정
(2) Notation 방식
유저 요구사항은 주로 최종 사용자에게 이해될 수 있도록 자연어로 쓰이지만, 시스템 요구사항은 요저 요구사항의 확장된 버전으로서 시스템 구현 계약사항의 일부이기 때문에 다른 방식으로 쓰일 수 있다. 자연어뿐 아니라 좀더 구조화된 자연어 템플릿을 이용할 수 있고, Graphical Notation이나 수학적 개념을 활용하여 작성할 수 있다.
(3) Software Requirements Specification(=SRS)
시스템 개발자가 구현해야 하는 공식적 문서를 의미한다. 유저와 시스템 요구사항을 모두 포함하며, 고객/매니저/엔지니어 등 다양한 사람들이 읽게 된다. 그리고 이 문서는 각각의 독자에 따라 다른 관점으로 읽히게 된다.
(4) SRS의 구조
- Preface : 해당 버전에 대해서 어떠한 변화가 이뤄졌는지 요약
- Introduction : 해당 시스템의 필요성과 기능을 묘사
- Glossary : 기술적인 용어 명시
- User Requirements Definition : 유저의 요구사항을 정의
- System Architecture : 기대되는 시스템 아키텍쳐에 대한 하이레벨의 overview
- System Requirements Specification : 시스템 요구사항을 디테일하게 명세
- System Models : 해당 시스템 컴포넌트와 환경에 대한 모델
- System Evolution : 기대되는 변화 명시
- Appendices : 부록으로서 디테일하고 구체적인 어플리케이션 관련 정보
- Index : 인덱스
3) Validation
(1) 요구사항이 고객이 정말로 원하는 것을 잘 반영한 내용인지 확인하는 과정
- 요구공학에서 중요한 프로세스로서, 여기에서 오류가 발생하면 이후 상당한 양의 재작업 비용이 발생할 수 있다.
(2) 요구사항 검증에서 체크해야 하는 부분들
- Validity : 요구사항이 정말 실제 니즈를 잘 반영하는지
- Consistency : 서로 충돌되는 요구사항은 없는지
- Completeness : 모든 기능과 제약사항을 잘 반영하고 있는지
- Realism Check : 현실적 예산 안에서 실행 가능한지
- Verifiability : 테스팅이 가능하도록 쓰여져 있는지
(3) 큰 시스템에서의 요구사항은 계속해서 바뀌게 된다.
새로운 법적 규제가 생길 수도 있고, 다른 시스템의 영향을 받을 수도 있기 때문이다.
