😤 100% 완벽한 요구사항 정의서는 없다 최근 맡고 있는 프로젝트의 요구사항 정의서를 작성하는 와중에 요구사항 정의서 작성라는 타이틀에 눈이 가서 읽어보았다. 해당 글은 프로젝트를 수주하기 위해서 제안 요청서를 받고 개발에 들어가기 전에 요구사항 정의서를 만든다는 내용이었다. 나는 자사 서비스를 개발하는 입장이지만 비딩을 하는 과정에서 받게된다는 RFP(Request For Proposal)와 비슷한 문서를 작성해서 팀에 공유한 후에 요구사항 정의서를 작성해나간다. (사내에서 Proposal Doc이라는 명칭을 사용 중) 아직 프로젝트 및 개발 경력이 짧은 멤버의 경우 왜이렇게 문서화가 중요한지 잘 모르는 경우가 있다. 나 또한 경험이 적었을 때는 개발을 진행하면서 완성하면 되겠지 했지만 초기에 개발 목적, 달성 목표, 서비스 정책 등이 확실하지 않는 상황에서 프로젝트가 진행되니 뒤로 갈수로 나는 멘붕이고 함께하는 동료들을 힘들게 했던 기억이 난다. 그 경험이 나를 완전히 바꾸었는데 사내 문서화 가이드라인부터 각 개발 단계별 필요한 문서의 템플릿까지 준비하여 누가 작성하더라도 최소한의 구성은 지켜질 수 있도록 사내에 전파하고자 노력했다. (문서화도 중요하지만 다들 쉽게 문서를 찾고 작성할 수 있는 툴 도입도 나름 신경 써서 업계보다 빠르게 4년 전부터 노션을 도입) 각 업계마다 작성하는 구성과 내용이 다르겠지만 작성 목적은 같을 것이라고 생각한다. 완벽한 것은 없다는 전제하에 초안을 작성하고 리뷰하고 다듬어가면서 개발이 종료되는 시점에 완성된 문서가 함께 준비되는 것을 상상해보며 노력해보는 것도 좋을 것 같다. 📝 이하 아티클 메모 1. 100% 완벽한 요구사항 정의는 없습니다. 이미 협의된 사항이라 하더라도 번복될 수 있기에 확정된 요구사항이라고 단정 짓지 말고 모든 개발이 완료될 때까지 지속적으로 관리하는 작업이 필요합니다. 2. 처음부터 완벽한 요구사항 정의서는 없기에 프로젝트 끝까지 고객 요청 사항을 보다 효율적으로 관리하고, 추후 논쟁 시에 그때 당시 히스토리를 추적하기 위해서 작성하고 있습니다. 3. 요구사항 정의서 작성하는 방법 a. 요구사항 구분: 프로젝트 규모가 크면 클수록 확인해야 할 요구사항이 많습니다. EX) [웹], [앱], [사용자], [관리자] b. 요구사항 ID: 화면 설계서를 작성할 때 화면 별 화면 ID를 부여하는 것처럼 요구사항들을 관리하기 위한 [요구사항 ID]를 부여합니다. EX) [REQ-001] c. 요구사항 명: 말 그대로 해당 요구사항이 어떤 요구사항인지 요약하여 기재 EX) [일반회원 회원가입] d. 요구사항 상세 설명: 요구사항에 대한 상세한 내용에 대해 기재합니다. EX) [일반회원의 경우 아이디와 비밀번호로 로그인할 수 있도록 함] e. 요청자: 요구사항을 요청한 요청자 정보를 기재합니다. 추후 요구사항에 대하여 더 자세히 논의가 필요한 상황이 생길 수 있기 때문에, [요청자] 칼럼은 꼭 작성하시기를 권장