요구 정의 · 양식
요구사항 명세서 (SRS) 양식
계약 기준이 되는 기능·비기능 요구사항을 항목별로 명세한다.
이럴 때 써요
- 계약 기준이 되는 요구사항을 항목별로 확정할 때
- 검수에서 다툼이 없도록 근거를 남겨야 할 때
양식 구성
7개 절로 이루어져 있습니다.
- 문서 정보
- 버전 · 프로젝트명 · 상태 · 작성자 · 검토자 · 승인자 · 작성일
- 1 시스템 개요
- 시스템이 무엇을 하는지, 어디까지가 이 시스템인지 적는다. 고객사와 합의할 첫 문단이다.
- 2 기능적 요구사항
- 계약 기준이 되는 항목입니다. ID는 변경하지 않고 유지합니다.
- 3 비기능적 요구사항
- 성능·보안·가용성처럼 "얼마나" 에 해당하는 요구를 숫자로 적는다. 숫자가 없으면 검수 때 다툰다.
- 4 인터페이스 요구사항
- 주고받는 상대와 방식·주기를 적는다. 연동 상대가 정해지지 않았으면 그 사실을 적어 둔다.
- 5 제약 사항 및 가정
- 바꿀 수 없는 조건과, 참이라고 가정하고 진행하는 것을 나눠 적는다. 가정이 깨지면 일정이 흔들린다.
- 6 변경 이력
- 문서를 고칠 때마다 한 줄 남긴다. 승인 뒤에 바뀐 것은 특히 빠짐없이 적는다.
바로 써 보기
로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.
요구 정의 단계의 다른 양식
- 용어사전 — 핵심 개념의 뜻을 요구사항보다 먼저 정의해 팀이 같은 말을 쓰게 한다. 전사 공유용.
- 제품 요구사항 정의서 (PRD) — 무엇을 왜 만드는지, 성공을 무엇으로 판단할지 정의한다.
- 기능 기획서 (Feature Spec) — 단일 기능의 동작, 화면 흐름, 예외 처리를 상세히 규정한다.
- 유저 스토리 백로그 — 요구사항을 사용자 문장과 수용 기준으로 쪼개 스프린트에 붙인다.
- 릴리즈 계획 — MVP 범위와 버전별 단계, 출시 판단 기준을 미리 정한다.