[21년 5월 칼럼] PMI Requirements Management – A Practice Guide vs. IREB CPRE

1. Eliciting Requirements – 요구사항 도출

  요구사항 도출은 요구공학에서 핵심적인 활동으로 요구사항 소스(source)로부터 필요한 정보를 추출하는 과정이다. 요구사항 소스로는 이해관계자, 법적 표준이나 규제 관련 문서, 기존 시스템 또는 경쟁시스템 등이 될 수 있다. 요구사항은 행위에 대한 기능적 사항, 품질과 같은 비기능적 사항 및 제한조건으로 분류할 수 있으며, 해당 요구사항 도출을 위한 방법은 다음과 같다.

 1) Survey Techniques

   – 인터뷰와 질의 등을 통한 요구사항 도출 방법

   – 명시적으로 요구사항 도메인에 대한 지식을 알고 있을 때는 직접 도출 가능

 2) Creativity Techniques

   – 브레인 스토밍, 브레인 스토밍 패러독스, 관점을 변경하는 방법 등을 사용한 요구사항 도출 (예, Six Thinking Hats[Debono 2006])

 3) Document-centric Techniques

   – 기존 시스템이나 경쟁 시스템으로부터 요구사항 도출(코드나 문서로부터)

   – 많은 양의 세밀한 요구사항을 얻을 수 있음

   – 기존 요구사항의 재활용

 4) Observation Techniques

   – 도메인 전문가가 자신의 경험과 지식을 공유할 시간이 부족할 때 유용

   – Requirements Engineer가 관찰한 모든 것을 문서화(실수, 리스크, 질문 포함)

   – 상세요구 사항과 기존 시스템 불만족자에 대한 요구사항을 도출 할 수 있음

 5) Support Techniques

   – 워크샵, 프로토타이핑 등의 방법을 활용한 요구사항 도출

2. Documenting Requirements – 요구사항 문서화

  품질 좋은 요구사항 문서는 프로젝트 전반적인 설계, 구현, 테스트에 모두 영향을 주기 때문에, 해당 문서의 품질은 전체 프로젝트의 성공 품질에 영향을 미친다.  요구사항 문서화 기법은 다음과 같이 크게 두 가지 형태로 나눠진다.

 1) Requirements Documentation using Natural language (일상어를 통한 요구사항 문서화)

   – 이해관계자가 새로운 언어를 배울 필요가 없으므로, 일반적으로 많이 사용되며, 어떤 종류의 요구사항도 표현가능한 장점이 있음

   – 요구사항의 애매모함이 존재할 수 있으며, 서로 다른 관점에서의 요구사항이 섞일 수 있는 단점이 있음

 2) Requirements documentation using Conceptual Models (모델 기반 요구사항 문서화)

   – 프로젝트를 수행할 훈련 받은 사람들이 읽고 이해하기기 쉬우며, 요구사항의 애매모호함을 제거할 수 있는 장점이 있음

   – Use case diagram, Class diagram, Activity diagram, State diagram 등이 있음

  소프트웨어 프로젝트에서는 위와 같은 구조로 SRS(Software Requirements Specification)를 도출하며, 해당 문서는 ISO/IEC/IEEE standard 29148:2011 과 유사하다.

3. Requirements Validation and Negotiation – 요구사항 검증과 협의

  Requirements Validation (요구사항 검증)은 가능한 조기에 오류를 발견하고 수정하기 위해 해당 요구사항들이 정의된 품질 기준의 만족 여부를 검증하는 것이다. 요구사항 문서에 담긴 오류는 이후 진행되는 모든 개발 활동의 기본 역할을 하기 때문에, 요구사항 문서에 담긴 오류는 모든 개발활동에 영향을 미친다. 검증에 대한 품질 측면은 다음과 같다.

 * 요구사항 문서의 완전성

 * 개별 요구사항의 완전성

 * 추적성

 * 정확성 및 적합성

 * 일관성

 * 충분한 자료가 뒷받침되지 않은 설계 결정 금지

 * 검증 가능성

 * 필요성

  요구사항 문서는 사전 정의된 문서의 양식 및 구조를 따라야 한다. 또한, 이해가능성, 명료성, 문서화 규칙을 준수해야한다. 이해관계자와의 합의 측면에서는 합의됨, 변경 후 합의 됨, 충돌이 해소됨의 세 가지 기준을 고려해야한다. 또한, 검증적 측면에서는 올바른 이해관계자의 참여, 오류 진단과 오류 수정의 분리, 다양한 시각을 통한 검증, 요구사항에 기반한 개발 산출물 작성과 반복적인 검증이 필요하다.

  요구사항 검증 기법으로는 코멘팅(Commenting), 인스펙션(Inspection), 워크스루(Walkthroughs) 등이 있다.

  Requirements Negotiation(요구사항 협의)란 개발 대상 시스템과 관련된 요구사항을 모든 이해관계자가 동일하게 이해하도록 하는 과정이다. 협의 과정은 다음과 같다.

 * 충돌 사항 식별

 * 충돌 사항 분석

 * 충돌 사항 해소

 * 충돌 사항 해소 결과 문서화

4. Requirements Management – 요구사항 관리

  요구사항은 프로젝트 전주기에 걸쳐 관리하기 위해서는 요구사항 정보를 가능한 구조화된 속성의 형태로 수집해야한다. 속성의 예는 다음과 같다.