Fully Dressed Use Case 작성 가이드
01-use-case-writing의 Fully Dressed 형식을 실제로 작성할 때 참고하는 가이드.
템플릿
## Use Case: [동사 + 목적어]
**Primary Actor:** ???
**Stakeholders and Interests:**
- [이해관계자1]: [뭘 원하는지]
- [이해관계자2]: [뭘 원하는지]
**Preconditions:** ???
**Success Guarantee:** ???
**Main Success Scenario:**
1. [액터]가 ??? 한다
2. 시스템이 ??? 한다
3. ...
**Extensions:**
3a. [조건]:
1. 시스템이 ??? 한다
각 섹션 설명
Primary Actor
이 Use Case를 시작하는 사람. "시스템아, 이거 해줘"라고 요청하는 주체.
Stakeholders and Interests
이 Use Case의 결과에 이해관계가 있는 모든 주체와, 각각이 뭘 원하는지.
시스템이 해야 할 일의 범위를 결정한다. Primary Actor만 생각하면 놓치는 요구사항이 여기서 드러난다. 예를 들어 POS 시스템에서 Salesperson의 "커미션 기록" 관심사를 빠뜨리면 커미션 기능 자체를 놓친다.
판단 기준: "이 Use Case가 끝났을 때 결과에 신경 쓰는 사람/시스템이 또 있나?"
없으면 Primary Actor만 써도 된다. 억지로 만들 필요 없다.
Preconditions
시나리오가 시작되기 전에 이미 참이어야 하는 조건. 시나리오 안에서 검사하지 않는다.
판단 기준: "이게 안 되어 있으면 이 시나리오를 시작할 수조차 없다"는 것만 쓴다.
예시:
- "학생이 시스템에 로그인되어 있다" — 로그인은 별도 Use Case
- "학생의 학사 정보가 시스템에 등록되어 있다" — 데이터 없으면 시작 불가
Success Guarantee (Postconditions)
Use Case가 성공적으로 끝났을 때 반드시 참이어야 하는 상태. "이게 달성되면 모든 이해관계자가 만족한다"는 보장.
작성법: Stakeholders and Interests에 적은 관심사가 전부 충족되었는지 확인한다.
Main Success Scenario
가장 일반적인 해피 패스. 아무 문제 없이 순조롭게 진행되는 시나리오. 조건 분기나 에러 처리는 넣지 않는다 — 전부 Extensions로 뺀다.
각 스텝은 세 종류 중 하나:
- 액터가 뭔가를 한다 — "학생이 졸업 목표 연도를 입력한다"
- 시스템이 검증한다 — "시스템이 이수 과목을 확인한다"
- 시스템이 상태를 바꾼다 — "시스템이 추천 결과를 저장한다"
블랙박스 스타일로 쓴다:
✅ "시스템이 이수 과목을 확인한다" ❌ "시스템이 DB에서 이수 과목을 쿼리한다"
Extensions
Main Success Scenario에서 뭔가가 달라지는 모든 경우. 에러뿐 아니라 대안적 성공 경로도 포함.
표기법: 메인 시나리오의 스텝 번호 기준.
3a. [3번 스텝에서 이런 조건이면]:
1. 시스템이 이렇게 한다
3b. [3번 스텝에서 저런 조건이면]:
1. ...
3-5a. [3~5번 스텝 어디서든 이런 조건이면]:
1. ...
*a. [어느 스텝에서든 이런 조건이면]:
1. ...
조건은 시스템이 감지할 수 있는 것으로 쓴다:
✅ "시스템이 외부 서비스 통신 실패를 감지한다" ❌ "외부 서비스가 죽어있다"
처음부터 다 채울 필요 없다. 떠오르는 것만 쓰고, iteration 돌면서 추가한다.
흔한 실수
- "어떻게"를 쓴다 → "LLM이 분석한다", "DB에서 조회한다" 같은 구현 방법은 빼야 한다
- 스텝이 너무 크다 → "시스템이 추천한다"보다 "시스템이 이수 과목을 확인한다 → 졸업요건을 비교한다 → 추천 과목을 제시한다"로 쪼갠다
- Extensions를 Main에 섞는다 → "만약 ~이면"은 전부 Extensions로 뺀다
- Stakeholder를 빠뜨린다 → 숨겨진 요구사항을 놓치게 된다