개발 문서 RFP, RFI, Project Charter, SRS, RTM, STD...

1. 제안 PM이 작성

RFP (제안요청서, request for proposal) : 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시해 도움을 주기 위한 문서. (영업)

RFI (사전정보요청, request for information) : 제품, 서비스, 시장 동향, 경쟁사 정보 등을 제공받아 진행하고자 하는 업무에 대한 정보를 미리 수집하고 비교분석하는 문서로 프로젝트에 대한 개요, 목적, 기간 정도 까지만 요약하고 대부분의 RFI에는 많은 요구사항을 담지 않는다.

 

참고 : 제안 PM은 기술영업을 하고, 수행 PM은 개발 프로젝트 구현을 이끈다.

 

2. 개발 진행 과정

Project Charter : 프로젝트의 범위, 목표, 참가자에 대한 설명. (but, 우리나라는... 작성 안 한다... )

SRS (소프트웨어 요구사항명세서, Software Requirement Specification) : 고객과 어떤 것을 어떻게 개발하고, 어떤 것은 개발하지 않는지를 결정하여 문서화한 계약서 -> 프로젝트에 대해 법적인 보호를 받을 수 있는 일종의 보험. 대부분의 버그는 SRS가 충실하지 않아서 발생한다. (but, 외국에서는 SRS를 오래 작성하고 정말 중요하다. 하지만 우리나라는 기간을 짧게 주고 고객도 뭘 원하는지도 모르고 프로젝트를 요청해서 SRS도 없고 분석도 없이 대충 개발에 들어간다. 우리나라는 SRS ID 번호가 중요하다.)

SDS (Software Design Standards)

SCS (Software Code Standards)

RTM (요구사항 추적표, Requirement Traceability Matrix) : 요구사항 변동을 엑셀 등으로 추적할 수 있게 작성한다.

UML (통합 모델링 언어, Unified Modeling Language) : '구현 문서'다. 클래스 다이어그램으로 작성한다.???

STD (테스트 문서, Software Test Description) : 테스트 문서.

 

우리나라는 Project Charter, SRS, RTM 등... 아무것도 안 쓰고 개발 시작한다... 그래서 기본적으로 '회의록'과 '녹취', 그리고 자체적으로 요구사항을 정리하고 변화를 기록해서 형상관리를 한다. 이 때 필요한 것은

1 ) 요구사항을 '기능/비기능'으로 구분한다.
2 ) 최종 결과 테스트를 기준으로 '기능'적인 것인지, '수치'적인 것인지 구분한다.
3 ) 이것을 요구사항과 변동사항을 기록해 형상관리를 한다.