요구사항 관리 4단계 개요
요구사항 관리 4단계 개요
1. 요구사항 추적
요구사항에 어떤 변경요소가 발견되었는가?를 추적한다.
2. 변경 요청
변경을 염두에 두고 변경을 요청한다.
3. 변경 영향 분석
변경이 향후 시스템에 어떤 영향을 미칠 것인가를 상세하고 고차원적인 분석을 한다.
4. 변경 승인/기각
영향 분석을 바탕으로 해서 변경을 승인할 것인가, 기각할 것인가를 선택한다.
이런 과정이 한번으로 끝나는 것이 아니라 다시 한번 고려를 해서 이런 과정이 사이클로 반복될 수 있다.
처음 변경이 기각이 된다라고해도 의사결정 과정, 다양한 환경에 의해서 다시 한번 고려할 필요가 있다고 한다면
다시 한번 추적으로 돌아가서 요청, 분석, 승인/기각 단계를 거칠 수 있다.
1. 요구사항 추적
요구사항은 설계와 구현과정을 통해 점진적으로 소프트웨어의 모습으로 완성되게 되며, 단계적 과정을 통해 전체의 진행결과를 추적할 수 있다.
요구사항 추적 매트릭스를 이용하게 되는데 ,
1. 요구사항 추적 매트릭스는 추적하는 일반적인 방법, 수단, 도구이다. 말로 진행하는 것이 아니라 도구, 방법을 통해서 진행된다.
2. 요구사항 추적 매트릭스는 고객이나 사용자가 요구한 내역, 즉 요구사항이 기능과 비기능적으로 분류해 추적을 하는 공식적인 수단이다.
예) 요구사항 추적 매트릭스
4가지의 단계를 이용하게 되는데 각각의 단계마다 고유한 ID를 붙인다.
요구사항, 기능, 프로그램, 테스트 케이스로 분류해 다양한 요구사항을 추적하고 기록한다.
그 결과물이 요구사항 추적 매트릭스이다.
요구사항 추적 매트릭스에 기록하기 위해서 그전에 어떤 활동이 이루어져야 되는가?
-요구사항 변경요청해야 함
-요구사항 추적해야 한다.
-요구사항 변경항목을 관리해야 한다.
이것이 서로 유기적으로 돌아가야 한다.
요구사항 저장소라는
예) 스프레드 시트를 이용해 간단히 기록해 놓을 수 있는 것.
저장과 관리를 통해서 형식 된 문서로 표현된 것이 요구사항 추적 매트릭스라고 불린다.
2. 변경요청
고객이나 사용자가 SW에 대하여 새로운 이해를 함으로써 발생하기도 하고, 외부환경의 원인에 의해 발생하기도 한다.
예) 경쟁제품으로 더 좋은 제품이 나타났다.
그러면 개발하고 있던 제품을 출시하게 되면 안 팔리니깐 어떻게 성능을 개선하는가? 가 발생할 수 있다.
예) 사용 중이던 개발툴이 유지보수를 중단했다.
다른 개발툴을 구입하면 요구사항이 틀려질 수밖에 없는 상황이 발생된다.
요구사항 변경원인
1. 요구사항의 오류, 충돌
일상적으로 발생할 수 있다. 주로 보면 오류, 충돌이라는 것은 성능과 편리성(보안) 항상 반대가 된다.
예) 차의 성능을 좋게 하기 위해서 다양한 옵션을 넣으면
비용, 휘발유가 많이 든다. 성능을 높이면 보안문제가 허술할 수 있고, 비용이 높아질 수 있다.
2. 요구사항의 불일치
변경을 가능하게 하는 요인이 될 수 있다.
3. 기술적, 시간적, 비용 상의 문제
하다 보니 숙련된 기술자가 빠지게 될 때 대체인력으로 새로운 사람이 왔는데 그 직원이 숙련되기까지 상당한 시간이 필요해 정해진 일정에 납품을 하기에는 문제가 발생될 수 있다. 그럴 경우에 당연히 요구사항을 변경해야 한다.
4. 사용자 혹은 고객의 우선순위 변경요청
처음에 A, B, C로 우선순위를 정했는데 나중에 고객이 C, B, A로 해달라 하면 요구사항이 변경될 수 있다.
5. 법/제도, 경제상황 등 환경의 변화
예) 웹사이트를 개발할 때는 아무 문제가 없었는데 시간이 지나고 중간에 개인정보법의 강화로 인해서 다양한 제약이 가해졌을 경우 요구사항에 대해서도 변경이 가해질 수 있다.
6. 조직의 비즈니스측면에 의한 변경
회사가 갑자기 어려워져서 개발 인원이 줄어들어 10명이 개발했던 것을 5명이 개발해야 되면 개발범위가 축소되어야 한다.
개발범위의 축소는 요구사항에 대해서도 당연히 변경을 요구해야 한다.
7. 기술의 발전 등
새로운 기술, 새로운 패러다임이 등장하면 이것을 맞춰주기 위해서 요구사항도 따라서 덩달아 변경될 수밖에 없다.
요구사항 변경요청서 작성
- 기존의 정의된 요구사항에서 변경이 필요할 경우 작성된다.
- 요구사항은 행정적인 절차(공식적인 승인)에 따라 요구사항 변경요청서 작성에 의해 관리(문서화)가 되어야 한다.
- 변경이 필요한 담당자는 변경요청서에 의해 공식적으로 변경을 요청해야 한다.
| 변경요청서 항목 | 내용 |
| 변경 요청번호 | 일종의 일련번호이다. 프로젝트 관리 기준에 따른다. |
| 변경 제목 | 무엇에 관한 변경 요청사항인가? 를 나타내는 이름 |
| 변경 내용 | 변경이 필요하게 된 이유와 근거 문서 등 변경이 필요한 부분에 대해 자세히 기술한다. (변경 요구사항) |
| 변경 처리 기한 | 요청자가 기대하는 처리 완료일을 지정한다. |
| 변경 요청 유형 | 단순, 일반, 긴급 등 변경관리 회의 소집여부를 표시한다. (소위말하는 우선순위를 어떻게 둘것인가. 여러가지 변경이 발생되었을 경우 어느것부터 처리하고, 어떤 방식으로 처리할 것인지. ) |
3. 변경 영향 분석
요구사항의 변경 사안별 영향도 분석한다.
변경을 우리가 받아들이면 프로젝트를 수행함에 있어 어떠한 영향을 미치는가. 영향 분석을 할 수밖에 없다.
변경이 요청된 요구사항이 수행해야 할 업무범위, 일정, 예산 등의 관점에서 어느 정도의 파급효과를 나타낼 것인지 추정해야 한다.
업무범위, 일정, 예산
이 3가지가 소프트웨어 성패를 짓는 요인이다. 이 3가지 중 어느 한 가지라도 만약 문제를 발생시키면 얼마 큼의 영향을 발생시키고, 그 영향이 얼마큼 심각한지에 대해서 조사하는 것이 영향 분석이다.
요구사항의 변경사안별 영향도 분석
다양한 측면에서 분석이 필요하다.
1. UI > 화면이나 보고서의 신규개발 혹은 변경
- 얼마만큼 사용자 인터페이스에 영향을 미치는가?
- 사용자 인터페이스는 변경하는 데에 있어서 심각도, 영향도가 높지는 않다.
2. 데이터베이스 > UI의 변경에 따른 DB의 수정, 혹은 새로운 DB 생성
- 데이터베이스의 얼마 큼의 수정과 새로운 데이터베이스를 변경이 일어났을 때 반영이 되는가 중요한 부분이다.
- 성능과 기능에 핵심이 된다.
3. 타 시스템과 인터페이스 > 데이터의 전송을 위한 새로운 인터페이스의 필요
- 데이터를 주고받는 전송을 위해서 어떤 인터페이스를 이용할 것인가.
- 변경으로 인해서 새로운 인터페이스가 필요할 수밖에 없다.
4. 문서산출물 > 미리 정의되지 않았던 문서의 생성요청 및 수정
- 변경이 발생이 되면 당연히 새로 정의할 문서가 발생될 수 있다.
- 이미 만들어진 문서도 수정이 가해져야 되는 상황이 발생될 수 있다.
5. 기타 > 새로운 HW, SW, 기술자 등의 추가투입 여부
- 추가투입이 요구될 수 있다.
요구사항 변경 영향분석서는
관련된 개발자 혹은 전문가가 프로젝트관리자와 함께 더불어 영향 내역을 분석하여 프로젝트 전체에 미치는 영향 정도를 철저하게 문서화할 필요가 있다.
영향 분석서에 있어 몇 가지 기준되는 게 있다.
일정, 예산, 위험, 심각도, 해결방안 이 5가지 하나하나가 분석에 있어서 고려해야 하는 요소이다.
| 영향분석 | 내용 |
| 일정 | 기존 일정의 변경 및 새로운 일정의 필요 여부 (변경됨으로써 일정에 영향을 준다. 특히 일정을 상당부분 늦춰야하면 끼치는 영향이 굉장히 심각하다고 볼 수 있다. ) |
| 예산 | 주어진 예산 내에서 처리여부 및 새로운 비용 가능성 (주어진 예산을 벗어나면 영향이 심각하다고 볼 수 있다.) |
| 위험 | 전체 프로젝트의 성공에 미치는 위험분석 (예기치 못한 위험일경우 이 변경을 받아들이는것은 신중하게 결정해야한다.) |
| 심각도 | 변경 사안의 심각도와 계약관련 이슈사항 검토 (고객과의 신뢰문제라던가, 회사에 있어서 신용도에 영향을 미칠 수 있다. 그러면 심각도가 클 수 밖에 없다.) |
| 해결방안 | 영향분석 결과, 가능한 해결방안의 모색한다. |
4. 변경 승인/기각
요구사항에 대한 변경요청에 대한 승인과 기각은
- 대단히 신중한 판단에 근거하여 결정되어야 하며 일정, 예산, 위험, 심각도, 해결방안 등 다양한 영향분석을 통해 최종적 으로 결정되어야 한다.
- 이 두 가지를 고려해서 마지막 단계에서 승인을 하거나 기각을 한다.
1. 정량적(수치화 : 비용, 일정 ),
2. 정성적(고객과의 신뢰도에 영향을 미친다던가, 회사 전체 신용도에 영향을 미치는 등의 수치화할 수 없지만 굉장히 심각하게 받아들여지는 )
승인과 기각은 변경통제위원회(CCB)의 결정
요청된 모든 변경요청서가 받아들여지는 것은 아니며, 프로젝트에 미치는 영향의 평가결과에 따라 기각될 수 있다.
상위의사결정위원회 (Steering Committee)
양사(고객과 개발자)의 경영층으로 구성된 최고의사결정 기구
상위의사결정위원회 (Steering Committee)의 결정
- 1차적으로 걸러진 결정 내용을 가지고 상위에 있는 의사결정위원회에서 마지막 최종적으로 결정을 내린다.
- 마지막이기 때문에 굉장히 신중하고 조심스럽게 결정을 내려야 된다.
- 발주자 측 사업담당자와 수주자 측 프로젝트 관리자가 함께 협의에 의하여 변경사항에 대한 수용여부를 협의하고 최종 결정한다.
- 만약 서로 의견이 일치하지 않는 경우 상위 의사결정위원회에 상정(화해와 서로 간의 일치화를 시킨다.)하고 결정을 받는다.
- 결정 내린 것은 번복하기 힘들지만, 요구사항 관리 단계 개요 사이클을 다시 돌 수 있다.
재판도 1심과 2심이 있는 것처럼 마찬가지로 승인과기각이 끝난다고 해서 완전히 종료가 되는 것이 아니라 또 다른 변수들이 결정 내린 후 발생될 수 있기 때문에 여러 번 사이클을 돌 수 있다.
참고사이트 - 메가존아이티평생교육원 | 소프트웨어 공학 | 전우천