bmalph 실전 가이드 4편 - 요구사항 문서와 화면 흐름 정리하기

요약#

참고 자료#

• BMAD Method - Commands - create-prd, create-ux
• BMAD Method - Workflow Map - 분석 다음에 기획이 오는 이유
• bmalph README 원문 - planning 산출물이 implement로 넘어가는 구조

지금 todo-demo는 어디까지 왔을까요?#

4편에서는 todo-demo-prd.md에 무엇을 넣어야 implement 단계에서 흔들리지 않는지, 그리고 필요한 만큼의 화면 흐름을 어떻게 남길지 정리합니다.
즉 제품 아이디어를 구현 기준 문서로 바꾸는 편입니다.

바로 이때 필요한 문서가 PRD입니다.
여기서 말하는 PRD는 거창한 회사 문서가 아니라, 구현 기준을 남기는 요구사항 문서라고 보면 됩니다.

제품 개요와 PRD는 무엇이 다를까요?#

제품 개요는 방향을 짧게 잡는 문서입니다.
PRD는 그 방향을 구현 기준으로 바꾸는 문서입니다.

쉽게 말하면 아래 차이입니다.

• 제품 개요: 무엇을 만들지 정합니다
• PRD: 무엇이 끝난 상태인지 정합니다

그래서 제품 개요가 “우선순위와 상태 필터가 있는 작은 할 일 앱”이라면, PRD는 아래처럼 더 구체적이어야 합니다.

• 우선순위 값은 무엇인가
• 상태 필터는 어떤 값을 가지는가
• 실패 조건은 어떻게 처리할 것인가
• 테스트는 무엇을 통과해야 하는가

실제로 어떤 섹션이 필요할까요?#

이 부분은 추측으로 쓰면 안 됩니다.
실제로 todo-demo 최소 예제로 bmalph implement를 돌려 보니, 아래 섹션이 없을 때 경고가 났습니다.

• Executive Summary 또는 Vision
• Functional Requirements
• Non-Functional Requirements
• Scope

즉 작은 예제라도 이 네 가지는 넣는 편이 안전합니다.
이번 시리즈에서는 아래처럼 정리하겠습니다.

1
# Todo Demo PRD
2

3
## Executive Summary
4

5
## Vision
6

7
## Scope
8
### In Scope
9
### Out of Scope
10

11
## Functional Requirements
12

13
## Non-Functional Requirements

이 구조를 맞춰 두면, 6편에서 implement가 PROJECT_CONTEXT.md를 더 안정적으로 생성합니다.

todo-demo-prd.md는 이렇게 쓰면 됩니다#

이번 예제 기준으로는 아래 정도면 충분합니다.

1
# Todo Demo PRD
2

3
## Executive Summary
4
Todo Demo는 작은 할 일 관리 예제를 BMAD 문서와 Ralph 반복 구현까지
5
연결해 보는 학습용 프로젝트다.
6

7
## Vision
8
혼자 쓰는 사용자가 할 일을 추가하고, 완료 처리하고,
9
우선순위를 정하고, 상태 기준으로 목록을 걸러 볼 수 있게 한다.
10

11
## Scope
12
### In Scope
13
- 할 일 추가
14
- 완료/미완료 전환
15
- 우선순위 설정
16
- 상태 필터
17

18
### Out of Scope
19
- 로그인
20
- 데이터베이스 저장
21
- 여러 사용자 지원
22

23
## Functional Requirements
24
- 할 일은 제목을 받아 생성되어야 한다
25
- 완료 상태는 id 기준으로 전환되어야 한다
26
- 우선순위는 low, medium, high만 허용한다
27
- 필터는 all, active, completed를 지원한다
28

29
## Non-Functional Requirements
30
- `npm test`가 통과해야 한다
31
- 구현은 학습용으로 읽기 쉬워야 한다
32
- 잘못된 입력은 명확히 실패를 알려야 한다

핵심은 글을 길게 쓰는 것이 아닙니다.
뒤에서 구현 판단에 필요한 기준을 빠뜨리지 않는 것입니다.

화면 흐름 문서는 꼭 필요할까요?#

이 질문도 자주 나옵니다.
답은 “UI가 중요한 프로젝트라면 짧게라도 있는 편이 좋다”입니다.

todo-demo는 화면이 복잡하지 않으므로 긴 UX 문서는 필요 없습니다.
하지만 최소한 아래 정도의 흐름은 적어 두면 좋습니다.

• 상단 입력 영역에서 새 할 일을 추가한다
• 각 항목에서 완료 상태를 바꾼다
• 각 항목에서 우선순위를 바꾼다
• 상단 또는 목록 위에서 상태 필터를 바꾼다

즉 이번 예제에서는 UX 문서가 “화면 설계서”라기보다 “화면 흐름 메모”에 가깝습니다.
UI가 주요 기능인 프로젝트라면 create-ux 계열 흐름을 더 적극적으로 쓰면 됩니다.

다음 편 설계 문서로 넘기려면 무엇이 필요할까요?#

5편으로 넘어가기 전에 아래 기준만 만족하면 됩니다.

• PRD에 목표와 범위가 있다
• 포함 기능과 제외 기능이 분명하다
• 기능 요구사항이 동작 기준으로 적혀 있다
• 비기능 요구사항에 최소 테스트 기준이 있다
• 화면 흐름 메모가 너무 복잡하지 않다

이 기준이 만족되면 다음 편에서 설계 문서와 세부 작업을 만들 수 있습니다.

4편에서 꼭 가져가야 할 기준#

• 제품 개요는 방향이고, PRD는 구현 기준입니다
• 작은 예제라도 Vision, Scope, 기능 요구사항, 비기능 요구사항은 필요합니다
• implement 경고를 줄이려면 PRD 섹션이 분명해야 합니다
• todo-demo의 UX 문서는 길지 않아도 됩니다
• 다음 편에서는 이 PRD를 기술 결정과 세부 작업으로 쪼갭니다

5편에서는 이제 todo-demo-architecture.md, todo-demo-epics-stories.md, todo-demo-readiness.md를 만들어 implement 직전 상태까지 끌고 가겠습니다.