요구사항 검증 (Requirements Verification)
📌 요구사항 검증은 이터페이스의 설계 및 구현 전에 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술되었는지 검토하고 개발 범위의 베이스라인을 설정하는 것이다.
- 인터페이스의 설계 및 구현 중에 요구사항 명세서의 오류가 발견되어 이를 수정할 경우 많은 비용이 소요되므로 프로젝트에서 요구사항 검증은 매우 중요하다.
- 인터페이스 요구사항 검증은 '요구사항 검토 계획 수립 > 검토 및 오류 수정 > 베이스라인 설정' 순으로 수행한다.
인터페이스 요구사항 검토 계획 수립
📌 프로젝트 이해 관계자들이 프로젝트 품질 관리 계획을 참조하여 다음과 같이 인터페이스 요구사항 검토 계획을 수립한다.
| 검토 기준 및 방법 |
프로젝트의 규모와 참여 인력, 검토 기간 등을 고려하여 검토 기준 및 방법을 정한다. |
| 참여자 |
프로젝트 규모에 따라 이해관계자들을 파악하여 프로젝트 관리자, 품질 관리자, 인터페이스 분석가, 소프트웨어 아키텍트, 시스템 사용자 테스트 관리자 등 요구사항 검토 참여자를 선장한다. |
| 체크리스트 |
완전성, 일관성, 명확성 등의 항목을 점검할 수 있는 요구사항 검토 체크리스를 작성한다. |
| 관련 자료 |
인터페이스 요구사항 목록, 인터페이스 요구상 명세서, 현행 및 표준 시스템 구성도 등 인터페이스 요구사항 검토에 필요한 자료들을 준비한다. |
| 일정 |
인터페이스 요구사항 검토 일정을 정한다. |
- 검토 계획이 수립되면 인터페이스 요구사항 검토 참여자에게 검토 관련 자료와 일정 등을 전달한다.
- 프로젝트 이해 관계자에는 품질 관리자, 프로젝트 관리자 기술 아키텍처 전문가, 인터페이스 전문가 등이 있다.
- 소프트웨어 아키텍트(Software Architect)는 아키텍처를 설계 및 구축하는 사항으로 TA, SA등이 있다.
- TA(Technical Architect) : 기술 아키텍처의 설계 및 구축을 담당하는 아키텍트
- SA(Solution Architect) : 소프트웨어 아키텍처의 설계 및 구축을 담당하는 아키텍트
인터페이스 요구사항 검토 및 오류 수중
📌 인터페이스 요구사항 검토는 검토 체크리스트의 항목에 따라 인터페이스 요구사항 명세서를 검토하는 것이다.
- 요구사항 검토 시 오류가 발견되면 오류를 수정할 수 있도록 오류 목록과 시정 조치서를 작성한다.
- 오류 수정과 요구사항 승인 절차를 진행할 수 있도록 요구사항 검토 결과를 검토 관련자들에게 전달한다.
- 시정 조치서를 작성한 경우 시정 조치가 완료되었는지 확인하여 시정 조치가 완료되면 인터페이스 요구사항 검토 작업을 완료한다.
인터페이스 요구사항 베이스라인 설정
📌 인터페이스 요구사항 검토를 통해 검증된 인터페이스 요구사항은 프로젝트 관리자와 주요 의사 결정자에게 공식적으로 승인 받는다.
- 소프트웨어 설계 및 구현을 위해 요구사항 명세서의 베이스라인을 설정한다.
- 도출된 요구사항에 대해 베이스라인을 세우는 것은 중요한데 베이스라인이란 고객이 원하는 모든 요구사항을 도출해서 명세서에 모두 기록했다는 것을 의미한다. 따라서 추가로 발생하거나 변경되는 요구사항에 대해서는 엄격한 절차를 통해서만 수용여부가 결정된다.
요구사항 검증 방법
📌 인터페이스 요구사항 검증은 다음과 같은 검증 방법을 적절하게 이용한다.
- 요구사항 검토(Requirements Review) : 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함여부를 검토 담당자들이 수작업으로 분석하는 방법으로, 동료검토, 워크스루, 인스펙션 등이 있다.
동료검토
(Peer Review) |
요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발션 하는 형태의 검토 방법이다. |
워크스루
(Walk Through) |
검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 검토 회의를 통해 결함을 발견하는 형태의 검토 방법이다. |
인스펙션
(Inspection) |
요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견하는 형태의 검토 방법이다. 아울러 정적 테스트 시에만 활용하는 기법이다. |
동료검토는 개발자가 동료 개발자들과 코드를 검토라는 것이고, 워크스루는 개발자가 동료 개발자들에게 자신이 개발한 코드를 설명하면서 검토하는 것이며, 인스펙션은 개발자가 제외된 상태에서 전문가가 검토하는 방법이다.
동료 검토와 워크스루가 비공식적인 검토 방법인테 인스펙션은 공식적인 검토 방법이다.
- 프로토타이핑(Prototyping) : 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측한다.
- 테스트 설계 : 요구사항은 테스트할 수 있도록 작성되어야 하며, 이를 위해 테스트 케이스(Test case)를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토한다.
- CASE(Computer Aided Software Enginnering) 도구 활용 : 일관성 분석(Consistency Analysis)을 통해 요구사항 변경사항의 추적 및 분석, 관리하고, 표준 준수 여부를 확인한다.
인터페이스 요구사항 검증의 주요 항목
📌 인터페이스 요구사항 검증은 다음과 같은 항목들을 중심으로 수행한다.
- 완전성(Completeness) : 사용자의 모든 요구사항이 누락되지 않고 완전하게 방영되어 있는가?
- 일관성(Consistency) : 요구사항이 모순되거나 충돌되는 점 없이 일관성을 유지하고 있는가?
- 명확성(Unambiguity) : 모든 참여자가 요구사항을 명확히 이해할 수 있는가?
- 기능성(Functionality) : 요구사항이 '어떻게(How to)' 보다 '무엇을(What)'에 중점을 두고 있는가?
- 검증 가능성(Verifiability) : 요구사항이 사용자의 요구를 모두 만족하고, 개발된 소프트웨어가 사용자의 요구 내용과 일치하는지를 검증할 수 있는가?
- 추적 가능성(Traceability) : 요구사항 명세서와 설계서를 추적할 수 있는가?
- 변경 용이성(Easily Changeable) : 요구사항 명세서의 변경이 쉽도록 작성되었는가?
정형 기술 검토 (FTR)
📌 소프트웨어 개발 산출물 대상 요구사항 확인 및 검증을 수행하는 방법이다. 동료검토, 워크스루, 인스펙션 등이 여기에 속한다.
- 제품 검토에만 집중하라.
- 의제를 제한하여 진행하라.
- 논쟁과 반박을 제한하라.
- 문제영역을 정확히 표현하라.
- 해결책이나 개선책에 대해서는 논하지 말라.
- 참가자 수를 제한하고 사전 준비를 강요하라.
- 자원과 시간 일정을 할당하라.
- 모든 검토자들을 위해 의미 있는 훈련을 시행하라.
- 검토자들은 사전에 작성한 메모들을 공유하라.
- 검토의 과정과 결과를 재검토하라.