요구사항 확인 #1

1. 요구공학

- 요구사항을 정의하고, 문서화하고, 관리하는 프로세스를 연구하는 학문

 

2. 요구사항 분류

1) 기술하는 내용에 따른 분류

- 기능적 요구사항 : 시스템이 무엇을 하여야하는지 (ex. 로그인 기능)

- 비기능적 요구사항 : 개발 과정에서 지켜져야 할 제약조건 (ex. 사용자가 많은 피크시간에도 3초 이내에 로그인이 되어야한다)

 

2) 관점에 따른 분류

- 사용자 요구사항 : 사용자 관점, 이해가 쉽게 표현

- 시스템 요구사항 : 개발자 관점(소프트웨어 요구사항), 기술적인 용어로 표현

 

 

3. 요구사항 개발 프로세스

1) 요구사항 도출

- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로서 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련.

- 이해관계자가 식별되고, 개발 팀과 고객 사이의 관계가 만들어진다.

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

- 요구사항 도출 기법 : 인터뷰, 설문, 브레인 스토밍(3인 이상이 자유롭게 의견을 교환하여 아이디어 산출), 워크샵, 유스케이스(요구사항을 기능 단위로 표현), 프로토타입(견본품) 등

 

2) 요구사항 분석

- 요구 사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호작용하는지 이해한다.

 

3) 요구사항 명세

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

- 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.

- 기능 요구사항은 빠짐없이 기술하고, 비기능 요구사항은 필요한 것만 기술한다.

 

4) 요구사항 확인

- 분석가가 요구사항 명세서를 이해했는지 확인하고 요구사항 문서가 회사의 표준에 적합하고 이해가능하며, 일관성이 있고, 완전한지 검증한다.

- 이해관계자들이 문서를 검토해야하고, 요구사항 정의 문서들에 대해 형상관리를 해야한다.

- 리소스(자원)이 요구사항에 실제로 할당되기 전에 문제를 파악하기 위해 검증을 수행한다.

 

---

※ 요구사항 분석 기법

 

1) 요구사항 분류

 

- 기능 요구사항 /비기능 요구사항

- 간접 생성 / 직접 생성

ㄴ (고수준 요구사항으로 인해) / (이해관계자나 다른 원천)

- 제품 요구사항 / 프로세스 요구사항

- 우선순위

- 요구사항의 범위

- 요구사항의 소프트웨어 생명 주기 동안 변경 여부

 

2) 개념 모델링

- 개념 모델의 역할 : 문제 발생에 대한 이해 증진과 해결책 설명, 문제 도메인의 개체들과 그들의 관계 및 종속성 반영

 

- 개념 모델의 종류

ㄴ 유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터액션, 객체 모델, 데이터 모델 등..

ㄴ 대부분의 모델링 표기법은 UML을 사용한다.

 

- UML 다이어그램의 사용

ㄴ 구조다이어그램 : 시스템의 정적 구조와 다양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계

ㄴ 행위다이어그램 : 시스템 내 객체의 동적인 행위를 보여주며, 시간의 변화에 따른 시스템의 연속된 변경

 

 

3) 요구사항 할당

- 요구사항을 만족시키기 위한 아키텍쳐 구성 요소를 식별하는 것

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

 

 

4) 요구사항 협상

- 두 명의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항과 리소스, 기능과 비기능 요구사항들이 서로 상충되는 경우, 어느 한쪽을 지지하기 보다는 적절한 합의를 하는 것.

- 요구사항에 우선순위를 부여하여 중요한 요구사항을 우선시하고 요구사항들간 상충되는 문제를 해결한다.

 

 

5) 정형분석

- 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현한다 == 수학적 기호로 표현

- 정확하고 명확하게 표현하여 오해를 방지한다.

- 요구사항 분석의 마지막 단계에서 실행된다.

 

---

 

※ 요구사항 확인 기법

 

1) 요구사항 검토

- 요구사항 검증의 가장 일반적인 방법으로 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이를 찾아낸다.

- 각종 정의, 명세서 들의 작성이 완료된 이후에 시행된다.

 

2) 프로토타이핑

- 소프트웨어 엔지니어가 해석한 요구사항을 견봄품으로 만들어 피드백을 받는다.

- 장점 : 잘못 해석된 요구사항에 대해 파악이 쉽다, 요구사항의 가변성이 감소하여 자원소모가 줄어든다, 잘못된 요구사항 제작에 드는 자원 낭비가 사라진다.

- 단점 : 사용자의 관심이 핵심 기능이 아닌 프로토타입의 디자인이나 품질 쪽에 집중될 수 있다, 프로토타입 제작비용이 든다.

 

3) 모델 검증

- 요구사항 분석 단계에서 개발된 모델의 품질을 검증한다.

 

4) 인수 테스트

- 최종 제품이 요구사항을 만족하는지 확인

- 각각의 요구사항을 어떻게 확인할지에 대한 계획을 세운다.

 

- 테스트 종류

ㄴ 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부 확인

ㄴ 운영상 인수 테스트 : 시스템 관리자가 시스템의 백업/보안/보안취약성 등을 확인

ㄴ 계약 인수 테스트 : 계약 조건 준수 여부 확인

ㄴ 규정 인수 테스트 : 정부 지침, 법규, 규정 준수 여부 확인

ㄴ 알파 검사 : 개발자의 장소에서 사용자가 시험하고 개발자가 지켜보는 검사

ㄴ 베타 검사 : 실 업무를 가지고 사용자가 직접 시험하는 검사