요구사항 정의서(RD): 합의의 중심
요구사항 정의서(RD): 합의의 중심
서론
의견은 다를 수 있어도, 문서는 하나여야 한다.
As-Is/To-Be로 현행과 목표를 정리했다면, 다음 단계는 요구사항 정의서(RD)입니다. RD는 범위, 기능, 정책, 비기능, 데이터, 수용 기준을 한 문서로 묶어 팀의 기준을 만듭니다. 이 글은 실무에서 바로 쓰는 RD 표준 구조와 작성 규칙을 정리했습니다.
📚 목차
본론
1) RD의 목적과 원칙
- 목적: 합의의 기준, 개발·QA·운영의 참조 문서.
- 원칙: 모호어 금지, 측정 가능, 단일 의미의 용어.
- 범위: 포함/제외를 함께 명시해 해석 여지를 줄임.
2) RD 표준 구조
- 개요: 배경, 문제, 목표, 성공 지표
- 용어 사전
- 범위/제외 범위
- 기능 요구사항
- 비기능 요구사항
- 정책/규칙/예외
- 데이터 사전·도메인 모델
- 시나리오·유스케이스·수용 기준
- 우선순위·릴리즈 전략
- 추적성 매트릭스
- 오픈 이슈·리스크
- 부록(참고 링크, 샘플 JSON)
3) 기능 요구사항 작성법
- 문장 규격: “누가 언제 무엇을 한다.”
- 예: “회원은 이메일과 비밀번호로 가입한다.”
- 반패턴: “최대한 편하게” 같은 모호어 사용 금지.
- 상태: 정상/오류/빈 상태를 각각 정의.
기능은 화면ID·플로우ID와 연결해 추적 가능하게 만듭니다.
4) 비기능 요구사항 작성법
- 성능: “P95 응답 ≤ 1.0초, 오류율 ≤ 0.3%”.
- 보안: 암호 정책, 개인정보 보관·마스킹 규칙.
- 가용성: “월간 가용성 ≥ 99.9%”.
- 접근성: 키보드 포커스, 대체 텍스트, 명도 대비.
5) 정책·예외·경계값
- 정책 문장: “항상/반드시/예외” 키워드로 서술.
- 경계값: 길이, 금액, 수량, 시간의 최소/최대.
- 예: “비밀번호는 10~32자. 특수문자 1개 이상 필수.”
6) 데이터 사전·도메인 모델
- 필드: 이름, 타입, 길이, 제약, 기본값, 예시값.
- 관계: 엔터티 관계도(ER), 식별자 규칙.
- 호환: 외부 시스템과의 키 매핑, 코드 테이블.
7) 시나리오·유스케이스·수용 기준
- 유스케이스: 기본 흐름과 대안 흐름 분리.
- 수용 기준: “주어·조건·기대결과” 형식.
- 예: “주어진 9자 비밀번호, 언제 가입 버튼 클릭, 그러면 버튼 비활성 유지.”
8) 우선순위와 범위 관리
- 우선순위: Must/Should/Could/Won’t.
- 릴리즈: v1 범위와 후속 백로그를 분리.
- 의존성: 앞선 요구사항이 필요한 항목 표시.
9) 변경관리·버전·이력
- 버전 규칙: v0.9 초안 → v1.0 확정 → 소수점 패치.
- 이력: 날짜, 변경자, 변경 요지, 근거 링크.
- 승인: 결재·승인자 서명 또는 전자 기록.
10) 추적성 매트릭스(RD↔화면↔API↔TC)
- 열: 요구사항ID, 화면ID, API, 데이터, TC ID, 상태.
- 일관성: 이름·코드·라벨을 동일하게 사용.
- 상태: Open/In Progress/Resolved/Verified/Closed.
11) RD 품질 체크리스트
- 모든 요구는 수용 기준이 있다.
- 모든 정책에는 예외·경계값이 있다.
- 모든 화면·API는 요구사항ID와 연결된다.
- 모든 비기능은 측정 기준이 있다.
- 버전·이력이 최신이다.
결론
요구사항 정의서(RD)는 팀의 합의를 한곳에 모으는 문서입니다. 기능과 정책, 비기능, 데이터, 수용 기준을 한 구조로 정리하면 개발과 QA가 흔들리지 않습니다. 위의 구조와 체크리스트를 기준으로 RD v0.9를 만들고, 코멘트를 받아 v1.0으로 확정하세요.
FAQ
Q RD와 화면 설계서는 무엇을 먼저 작성하나요?
A RD에서 범위·정책·비기능을 먼저 확정하고, 이후 화면 설계서로 인터랙션을 구체화합니다.
Q RD의 분량은 어느 정도가 적당한가요?
A 프로젝트 규모에 따라 다르지만 10~25페이지 내에서 핵심을 담고, 상세는 부록과 링크로 분리합니다.
Q 모호한 요구를 줄이려면 어떻게 하나요?
A “누가·언제·무엇을”과 수용 기준을 함께 작성하고, 경계값과 예외를 명시하세요.
Q 비기능 요구는 어디까지 적나요?
A 성능, 보안, 가용성, 접근성, 로그·모니터링 기준까지 수치와 방법을 포함해 적습니다.
Q 변경 요구가 자주 생깁니다. 어떻게 관리하나요?
A 변경 요청서를 별도로 관리하고, RD 버전 이력에 근거와 결정자를 남깁니다. 추적성 매트릭스로 영향 범위를 확인하세요.