기획자가 이건 할 줄 알아야지?-요구사항정의서

01. 요구사항정의서

프로젝트 개발의 단계에서 기업이나 업체가 요구해온 사항을 정리하는 작업

Why?

클라이언트와 외주사의 약속의 증거물

기능의 구현에 대한 개발자의 관점에서의 이해도를 높이기 위함

요청한 기능이 정상적으로 구현이 됐는지에 대한 추적 자료(요구사항 추적표의 기준)

How?

최대한 상세하게 서술

요청하지 않은 기능의 경우 협의 필요

사실대로 작성해야 함

요구사항정의서 샘플

작성요령

1) 요구사항ID

- 요구사항의 건 수 별로 공수를 책정하는 경우 추가, 삭제 시 중복되지 않게 작성해야 하므로 각각의 요구사항에 ID를 부여해야 함

- 추 후 요구사항 추적에 대한 증거가 됨

- 한 개의 요구사항은 한 개의 고유 ID를 가짐

- Ex: CS001, CS002, BO001, BO001 -> 앞 요구사항이 속해 있는 메뉴의 알파벳 + 번호를 표기(Customer Service + 001 등)

2) Depth 분류

- 문서를 보는 모든 이가 쉽게 어느 메뉴의 요구사항인지 볼 수 있도록 분류가 필요함

- Depth가 깊지 않은 경우 생략 가능

3) 요구사항 명

- 요구하는 기능의 이름을 서술

- 문어체 사용 권고

4) 요구사항 상세 내용

- 기능에 대해 상세하게 서술

- Ex: 파일 첨부의 경우 용량 제한, 업로드 가능한 개수, 확장자명 등 작은 부분까지 고려하여 서술

- 문어체 사용을 권고하나 이해관계자의 문서 이해능력에 따라 구어체 활용 가능

5) 전제/검토사항

- 해당 요구사항을 구현하기 위해 필요한 고객사의 환경, 조건 등이 있을 경우 서술

6) 수용 여부

- 수용 여부에 대해 수용, 보류, 기각, 제외 등의 분류를 기준에 따라 기재

- 기각, 제외 처리가 되더라도 요구사항ID는 변동되지 않음

7) 유형

- 요구사항의 성격을 기능/비기능의 분류에 따라 기재

- 개발사항의 여부에 따라 기능/비기능 분류

(1) 기능 - 로그인, 글 작성, 삭제, 수정 등의 개발이 필요한 기술
(2) 비기능 - 가용성, 성능, 보안성, 사용성 등의 개발이 불필요한 기술

8) 구분

- 기능의 신규, 개선, 유지, 삭제 여부 판단

- 삭제 처리가 되더라도 요구사항ID는 변동되지 않음

9) 난이도

- 구현의 난이도에 따라 분류

- 난이도에 따라 해당 요구사항의 작업 시간을 파악할 수 있어 프로젝트 일정 변동 시 참고가 가능

 

10) 고객사 검토의견/협의사항

- 작성된 요구사항에 대해 고객사의 이견이 있을 경우 서술

- 요구사항의 변경으로 다르게 구현된 기능의 출처에 대한 증거가 될 수 있음

 

11) 요청자

- 고객사 담당자 기재

12) 접수일

- 해당 요구사항이 최초 합의된 날짜 기재

 

13) 출처/근거

- RFP, 이메일 전화, 회의 등 요구사항이 발생된 수단 기재

---

100% 완벽한 요구사항정의서는 있을 수 없지만 고객사와 외주사, 그리고 개발자에게 있어 서비스를 이해할 수 있는 첫 문서이기 때문에 신중하고 꼼꼼하게 작성해야 한다.