프로젝트를 진행할 때 관계자들(클라이언트, 기획자, 엔지니어, 개발자, 경영진 등) 간 커뮤니케이션의 시작이 되는 요구사항정의서(Requirements Specification)에 대해 알아보겠습니다. 개인적으로는 프로젝트를 진행할 때 고객을 이해하는 첫 단계라 생각합니다.
요구사항 : 프로젝트의 고객을 이해하는 첫 단계
고객의 요구사항을 얼마나 잘 파악하여 수행하는지에 따라 프로젝트 전반적인 품질(Quality)과 기간(Period), 비용(Cost)이 달라지게 됩니다. 따라서 요구사항정의서는 프로젝트를 기획한 기획자, 수행하는 엔지니어, 경영자 모두에게 프로젝트의 완성도를 가늠해볼 수 있는 척도(barometer)가 될 수 있습니다.
업무를 하며 솔루션의 모니터링 시스템을 고객사에 제공하기 위해 웹페이지로 만들어야할 상황이 있었습니다. 솔루션 내 자체 모니터링 화면이 있었지만 관리자 페이지가 아닌 고객 제공용으로 커스텀된 UI 화면이 필요하여 단기간 내에 개발이 필요해 웹개발자에게 요청해야했습니다.
이때가 처음 고객이 되어 요구사항정의서를 작성하여 개발자와 커뮤니케이션 해본 경험이었습니다. 당시에 기획자의 업무라고만 생각했던 요구사항정의서를 작성해보니 때때로는 맡은 업무에서 누구나 기획자가 될 수도 있다는 생각이 들었고 직접 필요한 기능에 대해 상세히 작성하다보니 엔지니어로서 담당하는 솔루션에 대해 좀 더 파악해볼 수 있었습니다.
요구사항정의서를 작성하며 개발자와 커뮤니케이션을 하다보니 요구사항별 분류를 나누고 각 분류별로 요구사항을 명확하고 상세하게 적는 것이 중요하다는 것을 알게되었습니다. 해당 솔루션을 한번도 사용해보지 않은 웹개발자분을 이해시키는 것은 생각보다 쉽지 않았습니다. 다행히 경험이 많은 웹개발자분께서 요구사항정의서를 보고 기간 내에 개발하기 쉬운 방향을 잡고 서로 필요 요구(기능)들을 정리해가며 프로젝트가 순차적으로 진행되었습니다.
내게 필요한 것을 때때로 나도 모를 때…
보통 고객의 경우 해당 프로젝트에 대한 경험이 프로젝트 수행 주체(기획자, 엔지니어, 개발자) 보다 적을 확률이 큽니다. 따라서 프로젝트 수행 주체가 고객의 필요(Pain Point)를 먼저 찾아서 제시해주는 것이 중요합니다. 프로젝트가 진행된 이후 고려하지 못했던 문제가 발견되어 프로젝트 진행에 차질이 발생할 수 있기 때문입니다.
일반적으로 요구사항정의서는 요구사항정의서는 다음 문서를 기준으로 작성됩니다.
- RFP 기반 제안서
- 협상과정 변경된 안건
- 사업수행계획서
- 고객 요구사항
- 현행시스템 분석서
만일 표준화된 요구사항서를 이용하려면 조직에서의 Best Practice가 반영되어야합니다. 존재하는 요구사항서를 조사해서 공통 특징을 가지는 요구사항서를 찾아야합니다. 요구사항서에서 생략되어질 부분은 어떤 것이 있는지 추가해야 할 부분은 어떤 것이 있는지 등을 파악해야 합니다.
프로젝트마다 요구하는 항목들이 다르기 때문에 문서를 표준화 하는 것은 생각처럼 쉽지 않습니다. 존재하는 문서를 분석하고 이해하기 위해 표준화를 만들기까지 오랜 시간이 걸립니다. 특히 큰 조직에서는 표준화가 만들어지기 전까지 오랜 협상 기간이 소요되기 때문에 일단 표준화가 확정되면 정기적으로 검토되어져야 하고 필요시에는 변경되어져야 합니다.
구체적인 요구사항 작성법에 대해서는 다음을 참고하시기 바랍니다:)
[참고] 요구사항 명세서 (Requirements Specification)
[요구사항 정의서] 작성하는 법
요구사항 정의서 작성하는 법을 간단한 예시와 함께 알아보자.
velog.io
blog migration project
written in 2022.11.19
https://medium.com/techblog-hayleyshim/project-requirements-specification-40f753e95709
'IT > ETC' 카테고리의 다른 글
| [env] Setting MAC+Window OS with Logitech Flow (1) | 2023.10.28 |
|---|---|
| [env] Warning when applying k8s cli in WSL (0) | 2023.10.28 |