요구사항 확인

요구사항 프로세스

도출

- 어떻게 수집할 것인가?

- 다양한 이해관계자와 효율적인 의사소통이 중요

 

분석

- 요구사항들간 상충되는 것을 해결하고

- 소프트웨어의 범위파악

- 개념 모델링

 

명세

- 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것

- 시스템 정의서

- 시스템 요구사항 명세서

- 소프트웨어 요구사항 명세서

 

확인

- 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증

- 분석가가 요구사항을 이해했는지 확인

 

요구사항 분석 기법

1. 요구사항 분류(Requirement Classification)

- 요구사항이 기능인지 비기능(시스템의 속성들과 제약사항들을 정의하는 요구사항)인지

- 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나 다른 원천(Source)으로부터 직접

  발생한 것인지

- 요구사항이 제품에 권한 것인지 프로세스에 관한 것인지

- 우선순위 범위(요구사항이 소프트웨어에 미치는 영향의 범위)

- 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부

 

2. 개념 모델링(Coceptual Modeling)

- 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심

- 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명

- 개념 모델은 문제 도메인의 엔티티(entity)들과 그들의 관계 및 종속성을 반영

- 대부분의 모델링 표기법 UML(Unified Modeling Language)을 사용

- 시나리오로 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있음

 

3. 요구사항 할당(Requirement Allocation)

(1) 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것

(2) 다른 구성 요소와 어떻게 상호 작용하는지 분석을 통하여 추가적인 요구사항을 발견할 수 있음

 

4. 요구사항 협상(Requirement Neogotiation)

(1) 두 명의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항과 리소스, 기능과 비기능 요구사항들이 서로 상충되는 경우, 어느 한 쪽을 지지하기보다는 적절한 트레이드 오프 지점에서 합의가 중요

(2) 요구사항에 우선순위를 부여하는 것은 중요한 요구사항을 필터링할 수 있으며, 요구사항들간 상충되는 문제를 해결하는데 사용

 

5. 정형 분석(Formal Analysis)

(1) 형식적으로 정의된 시멘틱(Sementic)을 지닌 언어로 요구사항을 표현

(2) 정확하고 명확하게 표현하여 오해를 최소화

(3) 정형 분석(Formal Analysis)은 요구사항 분석의 마지막 단계에서 이루어짐

 

요구사항 확인

기법	내용
요구사항 검토	여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 등을 찾아내는 직업. 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자가 1명 이상 포함 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점 등에서 이루어짐
프로토타이핑	시제품, 견본품 새로운 요구사항을 도출하기 위한 수단 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단
모델 검증	분석단게에서 개발된 모델의 품질 검증 필요
인수 테스트	최종 제품이 요구사항을 만족시키는지 확인 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 세워야 함