1. 요구사항 관리의 중요성
가. 요구사항의 변경 가능성
최초에 작성된 요구사항은 다양한 이유로 변경이 될 수 있음.
나. 요구사항의 변경 원인 추적
베이스라인으로 설정된 요구사항 명세서는 지속적인 변경 가능성을 모니터링하고 변경되고 있는 과정을 추적하는 것이 필요
다. 요구사항의 변경 영향 평가
요구사항을 변경할 경우 향후 시스템 개발에 미칠 다양한 요소, 즉 비용, 일정, 품질 등에 대해서 다양한 영향을 평가해야 함.
라. 요구사항의 변경 최종결정
요청된 모든 변경이 받아들여지는 것은 아니며 영향평가 결과에 따라서 기각될 수 있는 가능성이 있음.
2. 요구사항 관리 단계
가. 요구사항 관리 단계 개요
요구사항 추적 -> 변경 요청 -> 변경 영향 분석 -> 변경 승인 / 기각
1) 추적
요구사항은 설계와 구현과정을 통해 점진적으로 소프트웨어의 모습으로 완성되게 되며, 단계적 과정을 통해 전체의 진행경과를 추적할 수 있음.
요구사항 추적 매트릭스
요구사항 추적 매트릭스는 고객이나 사용자가 요구한 내역이 시스템에 어느 부분에 구현되어 있는지 정의하는 표 형식의 문서
2) 변경요청
고객이나 사용자가 SW에 대하여 새로운 이해를 함으로써 발생하기도 하고, 외부환경의 원인에 의해 발생하기도 함.
요구사항 변경원인
요구사항의 오류, 충돌
요구사항 간의 불일치
기술적, 시간적, 비용 상의 문제
사용자 혹은 고객의 우선순위 변경요청
법/제도, 경제상황 등 환경의 변화
조직의 비즈니스측면에 의한 변경
기술의 발전 등
요구사항 변경요청서 작성
기존의 정의된 요구사항에서 변경이 필요
요구사항은 행정적인 절차에 따라 요구사항 변경요청서 작성에 의해 관리가 되어져야 함.
변경이 필요한 담당자는 변경요청서에 의해 공식적으로 변경을 요청해야 함.
변경요청번호, 변경제목, 변경내용, 변경처리 기한, 변경요청 유형(단순, 일반, 긴급 등) 등을 포함
3) 변경 영향분석
요구사항의 변경사안별 영향도 분석
변경이 요청된 요구사항이 수행해야 할 업무범위, 일정, 예산 등의 관점에서 어느 정도의 파급효과를 나타낼 것인지 추정해야 함.
UI, 데이터베이스, 타 시스템과 인터페이스, 문서산출물 등의 변경 항목에 따라 영향도를 분석
요구사항 변경 영향분석서는 관련된 개발자 혹은 전문가가 프로젝트관리자와 함께 영향 내역을 분석하여 프로젝트 전체에 미치는 영향 정도를 문서화 함.
변경 영향분석서에는 일정, 예산, 위험, 심각도, 해결방안 등을 기술
4) 변경 승인 / 기각
변경통제위원회(CCB)의 결정
요청된 모든 변경요청서가 받아 들여지는 것은 아니며, 프로젝트에 미치는 영향의 평가결과에 따라 기각될 수 있음.
상위의사결정위원회(Steering Committee)의 결정
발주자 측 사업담당자와 수주자 측 프로젝트 관리자가 함께 협의에 의하여 변경사항에 대한 수용여부를 협의하고 최종 결정함.
서로 의견이 일치하지 않는 경우 상위 의사결정 위원회에 상정하고 결정을 받음.
※ 상위의사결정위원회: 양사의 경영층으로 구성된 최고의사결정 기구
3. 요구사항 명세서
가. 인터뷰 결과서 작성
1) 사용자 탐색
향후 개발된 소프트웨어를 사용할 것으로 예상하는 사용자를 선택
2) 요구사항 인터뷰
어떤 소프트웨어를 원하는지 인터뷰 진행
3) 결과작성
인터뷰에 대한 결과를 문서로 정리
나. 요구사항 명세서 작성 단계
1) 개발목표
무엇을 개발할 것인지 요약
완성된 결과가 무엇을 위한 것인지 설명
2) 개발항목
개발해야 할 범위를 구체화하여 구현될 항목을 구조적으로 정의
3) 요구사항 목록
개발될 시스템의 요구사항 목록을 항목별로 설명
4) 상세 요구사항
기능적 요구사항, 비기능적 요구사항을 필수적으로 기술
5) 팀별 검토 및 확정
요구사항 명세서 확정 및 제출
