젝트 웹 서비스의 PM을 맡으며 어드민 페이지 신규 기획 및 일정 산출이라는 첫 임무를 받았습니다.
우선은 파편화된 요구사항들을 하나로 묶어 정리하는 과정이 필요할 것 같아, '요구사항 정의서' 작성부터 차근차근 시작해보려 합니다. 돌이켜보면 이전까지는 작업 전에 정의서를 제대로 갖추고 시작한 적이 별로 없었는데요.
이번 프로젝트를 계기로 제대로 된 작성법을 공부하고 기록해 두려 합니다. 처음 해보는 과정인 만큼, 시행착오까지 포함해 뜻깊은 경험이 될 것 같습니다.
※ 요구사항 정의서의 필요성
- 요구사항 정의서는 프로젝트 범위를 명확하게 정의합니다. 어디까지 만들어야 하는지 정해지지 않으면 끝없이 기능이 추가되고 프로젝트는 완료되지 않습니다. 문서로 범위를 고정하면 추가 요청이 들어와도 합리적으로 판단할 수 있습니다.
- 의사소통 비용이 크게 줄어듭니다. 개발자가 기획자에게 매번 같은 질문을 반복하지 않아도 됩니다. 디자이너는 문서를 보고 어떤 화면을 만들어야 할지 파악합니다. 테스트 담당자는 문서를 기준으로 검증 시나리오를 작성합니다.
- 계약 분쟁을 예방하는 법적 근거가 됩니다. 고객과 개발사 간에 인식 차이가 생겼을 때 요구사항 정의서는 합의된 내용을 증명합니다. 추가 비용이 발생할 때도 문서를 근거로 협의할 수 있습니다.
1. 요구사항 수집
- 이 단계에서 가장 중요한 것은 각 이해관계자의 요구와 기대를 명확히 이해하는 것입니다. 개인의 의견이 중요할 수 있지만, 여기서 중요한 것은, 프로젝트의 관점에서, 프로젝트가 성공적으로 완수되기 위한 요건만을 도출하는 게 중요합니다.
- 개개인이 말하는 내용이 결국, 프로젝트와 관여도가 있는 내용인지, 정말 프로젝트에 중요한 내용인가를 판단하며 수집할 필요가 있습니다.
2. 요구사항 분석
- 수집된 요구사항을 분석하여 중복된 부분을 제거하고, 우선순위를 설정하는 과정입니다. 이를 통해 프로젝트의 핵심 요구사항을 도출할 수 있습니다.
3. 요구사항 구분
- 분석된 요구사항을 기능적 요구사항과 비기능적 요구사항으로 구분합니다. 기능적 요구사항은 시스템이 수행해야 할 기능을 의미하며, 비기능적 요구사항은 시스템의 성능, 보안, 유지 보수성 등 사람이 해결해야 하는 영역이거나 운영 과정에서 생길 수 있는 예상치 못한 이슈들을 의미합니다.
▼ 비기능 요구사항 주요 항목
- 성능: 응답 시간과 처리량과 동시 사용자 수를 명시합니다.
- 보안: 데이터 암호화와 접근 권한과 인증 방식을 정의합니다.
- 호환성: 지원할 브라우저와 운영체제와 기기를 나열합니다.
- 확장성: 향후 사용자 증가에 대응할 수 있는 구조를 계획합니다.
- 유지보수성: 코드 문서화와 모듈화 기준을 설정합니다.
4. 요구사항 정의서 작성
- 구분된 요구사항을 문서화하여 요구사항 정의서에 작성합니다.
이때, 각 요구사항은 명확하고 구체적으로 기술해야 합니다.
※ 유의사항
1. 명확한 표현
모든 요구사항은 간결하고 구체적으로 작성되어야 합니다.
예를 들어 ‘사용자는 로그인을 할 수 있어야 한다’보다 ‘사용자는 이메일과 비밀번호를 사용하여 로그인을 할 수 있어야 한다’처럼 명확한 표현이 되어야 하고 동일한 개념이나 기능은 일관된 용어를 사용해야 합니다.
그리고 정량적 기준을 명시할 수 있어야 합니다. 예를 들어 ‘응답시간은 빠르게’ 보다는 ‘응답시간은 2초 이내로’처럼 정량적인 숫자가 명시되는게 좋습니다.
2. 일관된 형식으로 작성
모든 요구사항은 동일한 템플릿인 요구사항 정의서에 기재되어야 하고 Depth, 설명, 우선순위, 상태 등 템플릿화하여 요구사항을 기재할 수 있어야 합니다.
또 요구사항 별로 일련번호 형식의 인식 코드를 부여하는 것이 좋을 수 있고 글꼴, 폰트 크기, 색상, 문단 스타일, 강조 서식 등의 스타일도 일관되게 작성하는 것이 좋습니다.
3. 변경 기록을 통한 버전 관리
요구사항이 변경되는 내용을 기록하며 버전을 관리하고 전반적인 진행 상황이나 이슈 등을 추적 관리하는 것은 필수입니다.
그리고 매일, 주 단위 등 정기적인 최신화를 통해 전반의 담당자들에게 공유되고 활용될 수 있게 해야 하며, 검토 및 승인 절차 등을 정립하며 아무나 수정할 수 없도록 규정짓는 것이 좋을 수 있습니다.
※ 기능명세서와 차이점
요구사항 정의서는 고객의 니즈와 비즈니스 관점을 반영합니다. 무엇을 만들 것인지에 초점을 맞춥니다. 프로젝트 초기에 작성하며 고객과 개발팀이 함께 검토합니다. 기능 명세서는 요구사항 정의서를 바탕으로 어떻게 구현할 것인지 상세하게 기술합니다. 화면 설계와 데이터베이스 구조와 API 명세가 포함됩니다. 개발자가 직접 참고하여 코드를 작성하는 문서입니다.
요구사항 정의서를 먼저 작성하고 승인받은 후 기능 명세서를 작성하는 것이 일반적인 순서입니다. 요구사항이 변경되면 기능 명세서도 함께 수정해야 합니다. 두 문서는 항상 동기화되어야 합니다.
출처 : https://www.elancer.co.kr/blog/detail/283
https://www.alchera.ai/resource/blog/requirements-definition-documentation