03. 요구사항 확인하기
요구사항 정의
- 소프트웨어 공학기술의 요구사항 분석 기법을 활용하여 업무 분석가가 정의한 응용소프트웨어의 요구사항을 확인할 수 있다.
- 업무 분석가가 분석한 요구사항에 대해 정의된 검증기준과 절차에 따라서 요구사항을 확인할 수 있다.
요구공학 개요
요구공학(Requirements Engineering)이란 요구사항을 정의하고, 문서화하고, 관리하는 프로세스를 의미한다. (https://en.wikipedia.org/wiki/Requirements_engineering)
1. 요구사항 개발 프로세스
소프트웨어공학 지식체계(SWEBOK: SoftWare Engineering Body of Knowledge)에서는 이 프로세스를 요구사항 도출(Elicitation), 분석(Analsysis), 명세(Specification), 확인(Validation)으로 구분하고 있다. (http://www.computer.org/web/swebok)
(1) 요구사항 도출(Requirement Elicitation)
(가) 요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로서요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다.
(나) 이 단계에서 이해관계자(Stakeholder)가 식별되고, 개발 팀과 고객 사이의 관계가 만들어진다.
(다) 이 단계에서는 다양한 이해관계자와 효율적인 의사소통이 중요하다.
(2) 요구사항 분석(Requirement Analysis)
(가) 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해한다.
(나) 시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출한다.
(3) 요구사항 명세(Requirement Specification)
(가) 요구사항 명세란 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것을 의미한다.
(나) 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.
(4) 요구사항 확인(Requirement Validation)
(가) 분석가가 요구사항을 이해했는지 확인(Validation)이 필요하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)하는 것이 중요하다.
(나) 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리를 해야 하는데, 일반적으로 요구사항 관리 툴을 이용한다.
(다) 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행한다.
위와 같은 요구사항 개발 프로세스 중에서 요구사항 확인하기와 관련된 단계는 분석 및검증 단계이므로, 필요 지식에서는 도출 및 명세 단계를 생략한 분석 및 검증 단계에 대해서만 기술하기로 한다.
요구사항 분석 기법
요구사항 분석을 통해 요구사항을 기술할 때에는 아래의 작업들이 가능하도록 충분하고정확하게 기술하여야 한다.
- 요구사항의 확인(Validation)
- 요구사항 구현의 검증(Verification)
- 비용 추정
분석기법으로 요구사항 분류((Requirement Classification), 개념 모델링(Conceptual Modeling), 요구사항 할당((Requirement Allocation), 요구사항 협상((Requirement Negotiation), 정형 분석(Formal Analysis) 등이 있다.
1. 요구사항 분류(Requirement Classification)
요구사항을 다음과 같은 기준으로 분류한다.
- 요구사항이 기능인지 비기능인지
- 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나다른 원천(Source)으로부터 직접 발생한 것인지
- 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지
- 우선순위가 더 높은 것인지 여부
- 요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위) - 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부
2. 개념 모델링(Conceptual Modeling)
(1) 개념 모델의 역할
(가) 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문 제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다. (나) 따라서 개념 모델은 문제 도메인의 엔터티(entity)들과 그들의 관계 및 종속성을 반영한다.
(2) 개념 모델의 종류와 표기법
(가) 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model),상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터액션(UserInteractions), 객체 모델(Object Model), 데이터 모델(Data Model) 등과 같은 다양한 모델을 작성할 수 있다.
(나) 대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용한다.
(3) UML 다이어그램의 사용
(가) 사용 시나리오를 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있다.
(나) 구조 다이어그램(Structure Diagram)은 시스템의 정적 구조(Static Structure)와 다양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계를 보여 준다.
(다) 행위 다이어그램(Behavior Diagram)은 시스템 내의 객체들의 동적인 행위(DynamicBehavior)를 보여 주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해 준다.
3. 요구사항 할당(Requirement Allocation)
(1) 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것을 요구사항 할당이라 한다.
(2) 다른 구성 요소와 어떻게 상호 작용하는지 분석을 통하여 추가적인 요구사항을 발견할 수 있다.
4. 요구사항 협상(Requirement Negotiation)
(1) 두 명의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항과 리소스, 기능과 비기능 요구사항들이 서로 상충되는 경우, 어느 한 쪽을 지지하기보다는 적절한 트레이드 오프 지점에서 합의가 중요하다.
(2) 요구사항에 우선순위를 부여하는 것은 중요한 요구사항을 필터링할 수 있으며, 요구사항들 간 상충되는 문제를 해결하는 데 사용될 수 있다.
5. 정형 분석(Formal Analysis)
(1) 형식적으로 정의된 시맨틱(Semantics)을 지닌 언어로 요구사항을 표현한다.
(2) 정확하고 명확하게 표현하여 오해를 최소화시킬 수 있다.
(3) 정형 분석(Formal Analysis)은 요구사항 분석의 마지막 단계에서 이루어진다.
요구사항 확인
분석가가 요구사항을 이해했는지 확인(Validation)하는 것이 필요하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하고, 일관성이 있고, 완전한지 검증(Verification)하는 것이 중요하다. 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리를 해야 하는데 일반적으로 요구사항 관리 툴을 이용한다. 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행한다.
1. 요구사항 확인 기법
(1) 요구사항 검토(Requirement Reviews)
(가) 요구사항 검증의 가장 일반적인 방법으로, 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 등을 찾아내는 작업을 수행하며, 검토자 그룹을 어떻게구성하느냐가 중요하다.
(나) 예를 들어, 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자가 1명 이상 포함되어야 한다.
(다) 검토는 시스템 정의서(System Definition Document), 시스템 사양서(System Specification), 소프트웨어 요구사항 명세서(SRS: Software Requirements Specification Document)를 완성한 시점 등에서 이루어진다.
