분석단계 - 요구사항

프로젝트 초기, 분석단계가 시작되면 'ASIS 분석' 후 제일 처음 만나는 TOBE Task가 ‘요구사항 분석(또는 정의)’ Task이다. 고객으로부터 요구사항을 듣고, 수집해서 TOBE 요구사항으로 정리하는 것이다. 고객이 친절하게 명시적으로 설명해주면 좋겠지만 그렇지 않은 경우도 많다. ASIS 분석 결과를 바탕으로 여러가지 문서도 참고하고 관련팀과 몇차례에 걸처 회의도한다. 그렇게 요구사항을 정의하면 파트별로 분석설계자 개인별로 담당하게 될 요구사항을 목록으로 나열해서 관리한다.

프로젝트 규모에 따라, 인력구성에 따라 다르겠지만 대략 한사람이 몇 개의 요구사항을 맡게될까? 수십개는 담당하지 않을까? 많으면 100개 넘기도 할 것이다.

예를들어 ‘코드관리’라는 단순한 요구사항 하나를 맡았다고 보면 그 요구사항으로부터 단순하게 생각해도 코드등록, 수정, 삭제, 조회 등 4개의 기능과 최소 2개 이상의 화면, (레거시 코드와의) 인터페이스, (동기화) 배치 등의 프로그램이 떠오를 수 있다.

이와 같이 하나의 요구사항이 여러 기능으로 분해되고, 분석/설계를 진행함에 따라 UI, Report, API, Table, Interface, Batch 등 여러 프로그램으로 세분화되고 매핑된다. 그런데 이러한 요구사항 하나 하나가 코드관리처럼 단순하지도 않고 본인이 수십 또는 백여개의 요구사항을 담당해야 한다면…

이게 가능할까?

하나 하나 정성드릴 시간이 없을 것 같다. 각 Task별로 제출할 산출물을 적당히 칸만 채워 제출하고 진지하게 논의하고 ASIS 개선을 위한 효율적인 방법 찾는데 시간 쏟기가 어려워 보인다. (사실 저도 과거에 그랬다)

하나의 요구사항에 대해 워드형태로 명세서를 작성하면 대략 아래와 같은 항목에 대해 서술해야할 것이다.
* 요구사항 등록일, 요구사항 최종 변경일
* 도출단계(분석, 설계, 개발)
* 변경유형(신규(추가), 변경, 삭제, ASIS유지)
* 유형(기능, 비기능(보안, 성능, 호환성, 인터페이스, 유지보수))
* 진행상태(접수, 검토중, 수용, 기각, 이관)
* 중요도(상, 중, 하)
* 난이도(상, 중, 하)
* 관련부서
* 요청부서/요청자
* 고객 현업 담당자, 고객 IT 담당자
* 수행사 담당 파트, 수행사 담당자
* 출처(제안요청서, 제안서, 사업수행계획서, 회의록 등)
* 관련 요구사항 ID
* 요구사항 내용 (HOW가 아닌 무엇을 중심으로)
* 전제조건(사용자, 개발자, 운영자 측면의 제약사항 및 고려사항)
* Baseline 이후 추가, 변경, 삭제
* Baseline 이후 승인일, 변경요청 ID
위의 항목 하나 설명하지 않아도 많이 보아왔던 요구사항 항목들이다. 자주 봐서 뻔한 것 같지만 어디 중요하지 않은 항목이 있단 말인가? ASIS 문서든, TOBE 제안서든, 회의든 어떤 형태로든 위의 내용을 찾아 충실히 기록 관리(변경이력포함)해야 할 것이다. 그리고 변경유형, 진행상태 등 특정 항목별로 필터링 해 가면서 확정율도 관리하고 그렇지 못한 건에 대해서는 추가 논의도 해야한다.

하나의 요구사항으로부터 파생되는 여러 분석설계 요소나 프로그램을 생각해보면 요구사항 하나 하나 정성을 들여야한다. 그럴 수 없다면 범위를 줄이든 사람을 더 뽑든 해야한다. 그것도 안된다면 ASIS를 배끼듯이 대충 TOBE를 만들어야 하는 유혹에 맞닥뜨리게 될 것이다.

어떻게 할 것인가?