요구 정의 · 양식
용어사전 양식
핵심 개념의 뜻을 요구사항보다 먼저 정의해 팀이 같은 말을 쓰게 한다. 전사 공유용.
이럴 때 써요
- 기획서마다 같은 개념을 다른 이름으로 부를 때
- 새 표면(화면·서비스)을 기획하기 전에 기존 개념을 확인할 때
- 개발자가 아닌 사람도 봐야 하는, 팀 전체가 같이 보는 용어 기준이 필요할 때
양식 구성
4개 절로 이루어져 있습니다.
- 문서 정보
- 버전 · 서비스 · 작성자 · 검토자 · 승인자 · 최종 수정일
- 1 핵심 용어
- 팀이 같은 말을 다르게 쓰는 걸 막는 게 목적입니다. 화면·기획서·코드에서 실제로 쓰는 이름을 그대로 적습니다.
- 2 헷갈리기 쉬운 용어 구분
- 팀이 실제로 헷갈렸던 짝만 적는다. 실수 사례를 같이 적으면 왜 구분해야 하는지 바로 전해진다.
- 3 변경 이력
- 용어의 뜻이 바뀌면 반드시 남긴다. 뜻이 조용히 바뀌면 옛 문서 전체가 틀린 말이 된다.
바로 써 보기
로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.
요구 정의 단계의 다른 양식
- 제품 요구사항 정의서 (PRD) — 무엇을 왜 만드는지, 성공을 무엇으로 판단할지 정의한다.
- 기능 기획서 (Feature Spec) — 단일 기능의 동작, 화면 흐름, 예외 처리를 상세히 규정한다.
- 유저 스토리 백로그 — 요구사항을 사용자 문장과 수용 기준으로 쪼개 스프린트에 붙인다.
- 릴리즈 계획 — MVP 범위와 버전별 단계, 출시 판단 기준을 미리 정한다.
- 요구사항 명세서 (SRS) — 계약 기준이 되는 기능·비기능 요구사항을 항목별로 명세한다.