요구사항 정의
요구공학 개요
요구공학(Requirements Engineering)? 요구사항을 정의하고, 문서화하고, 관리하는 프로세스를 의미
[ 요구사항 개발 프로세스 ]
요구사항 분석 기법
- 요구사항 분류(Requirement Classification)
- 개념 모델링(Conceptual Modeling)
- 요구사항 할당(Requirement Allocation)
- 요구사항 협상(Requirement Negotiation)
- 정형 분석(Formal Analysis)
1. 요구사항 분류(Requirement Classification)
[ 분류 기준 ]
- 기능/비기능
- 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나 다른 원천(source)으로부터 직접 발생한 것인지
- 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지
- 우선순위가 더 높은 것인지 여부
- 요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위)
- 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부
2. 개념 모델링(Conceptual Modeling)
[ 개념 모델의 역할 ]
- 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심
모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명함 - 개념 모델은 문제 도메인의 엔터티(entity)들과 그들의 관계 및 종속성을 반영함
[ 개념 모델의 종류와 표기법 ]
- 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표 기반 모델(Goal-Based Model), 사용자 인터액션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등
- 대부분의 모델링 표기법; UML(Unified Modeling Language)을 사용
3. 요구사항 할당(Requirement Allocation)
- 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것
- 다른 구성 요소와 어떻게 상호 작용하는지 분석을 통하여 추가적인 요구사항을 발견할 수 있음
요구사항 확인
- 분석가가 요구사항을 이해했는지 확인(Validation)하는 것이 필요
- 요구사항 문서가 회사의 표준에 적합하고 이해 가능하고, 일관성이 있고, 완전한지 검증(Verification)하는 것이 중요
[ 요구사항 확인 기법 ]
1. 요구사항 검토(Reviews)
요구사항 검증의 가장 일반적인 방법으로, 여러 검토자들이 에러, 잘못된 과정, 불명확성, 표준과의 차이를 찾아내는 작업을 수행하며 검토자 그룹을 어떻게 구성하느냐가 중요함
- 검토는 시스템 정의서(System Definition Document), 시스템 사양서(System Specification), 소프트웨어 요구사항 명세서(SRS: Software Requirements Specification Document)를 완성한 시점 등에서 이루어짐
2. 프로토타이핑(Prototyping)
새로운 요구사항을 도출하기 위한 수단으로, 또한 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 많이 사용됨
- 장점
: 분석가의 가정을 파악하고 잘못된 경우 유용한 피드백을 제공한다는 점,
사용자 인터페이스(User Interface)의 동적인 행위가 문서나 그래픽 모델보다 프로토타입으로 이해하기 쉬운 점, 요구사항의 가변성이 프로토타이핑 이후에 급격히 감소하는 점 - 단점
: 사용자의 관심이 핵심 기능에서 멀어지고 프로토타입의 디자인이나 품질 문제로 집중될 수 있으며, 프로토타입 수행 비용이 발생함
- 잘못된 요구사항을 만족시키기 위해 자원을 낭비하는 것을 방지할 수 있다는 점에서 프로토타이핑을 긍정적으로 검토할 수 있음
3. 모델 검증(Model Verification)
4. 인수 테스트
- 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인이 가능해야 한다는 것
- 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 세워야 함
요구사항의 시스템화 타당성 분석
요구사항의 기술적 타당성 검토
1. 성능 및 용량산정의 적정성
- 목표 시스템의 용량이 산정되면, 과거 유사 프로젝트 경험치를 적용하여 필요시 재조정한 후에 성능 관련 비기능 요구사항과 비교하여 적정성 여부를 판단
2. 시스템 간 상호 운용성
- 상호 운용성? 다른 목적을 지닌 2개 이상 시스템들이 상호 간 정보 및 서비스를 교환하면서 효과적으로 운용될 수 있는 시스템의 능력을 의미
- 요구사항 중에서 목표 시스템이 조직 내외 타 시스템과의 연동을 요구할 경우, 상호 운용이 가능한지 여부를 판단해야 함
3. IT 시장 성숙도 및 트렌드 부합석
- 시스템 구축 시 요구되는 영역별 정보 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 부합하는지 판단
- 시장 성숙도가 낮거나, 발전 방향에 부합되지 않는 기술들은 향후 더 이상 사용되지 않을 가능성이 높아 시스템의 유지보수가 어려운 상황이 발생할 수 있음
4. 기술적 위험 분석
요구사항을 만족시키기 위해 적용한 기술의 복잡성, 검증 여부, 의존성 등에 대해 위험 발생 가능성 영향도를 파악
※ 게시물에 사용된 개념도와 도표 등의 출처 : 교육부의 NCS 학습모듈 자료