kt-event-marketing/reference/유저스토리작성방법.md

# 유저스토리 작성 방법 

## 개요
이 가이드는 마이크로서비스 기반 시스템 개발을 위한 유저스토리 작성 표준을 제공합니다.  
표준화된 형식을 통해 일관성 있고 완전한 요구사항을 정의할 수 있습니다.

## 작성 구성 요소

### 1. 서비스
마이크로서비스명을 명시합니다.
- **형식**: 서비스 도메인명
- **예시**: 홈페이지, 가입설계, 주문관리, 결제처리

### 2. ID
User Story ID로서 표준화된 식별자입니다. 
- **형식**: `<유저스토리 유형 코드>-<서비스약어>-<일련번호>`
  - 유저스토리 유형 코드
    - UFR(User Functional Requirements): 사용자 기능 요구사항  
    - AFR(Admin Functional Requirements): 어드민 기능 요구사항 
    - NFR(Non Functiional Requirements): 비기능 요구사항(확장성, 회복성, 유연성, 성능, 보안, 운영성)
  - 서비스약어: 3~4자로 작성
  - 일련번호: 3자리로 하고 010부터 시작하여 10개씩 증가 예) UFR-HOME-010, UFR-HOME-020
- **예시**: 
  - `UFR-HOME-010`: 홈페이지 서비스의 첫 번째 유저스토리
  - `UFR-PAY-020`: 결제 서비스의 다섯 번째 유저스토리

### 3. Epic
유저스토리의 상위 카테고리를 분류합니다.
- **용도**: 관련 유저스토리들을 그룹화
- **예시**: 사용자 관리, 상품 관리, 주문 처리

### 4. 유저스토리
표준 형식에 따라 작성합니다. 각 파트는 파이프로 구분합니다. 
- **형식**: `[유저스토리 제목] <유저유형>으로서 | 나는, <비즈니스 목적>을 위해 | <작업/기능>을(를) 원합니다.`
- **예시**: 
  - [상품검색] 쇼핑몰 고객으로서 | 나는, 상품을 쉽게 찾기 위해 | 카테고리별 상품 검색 기능을 원합니다.
  - [주문현황] 관리자로서 | 나는, 주문 상태를 파악하기 위해 | 실시간 주문 현황 대시보드를 원합니다.

중요) 유저유형은 사람 뿐 아니라 시스템, API 등으로 정의할 수도 있음
- 이벤트 스토밍은 사용자 중심으로 수행하기 위해 사람만 Actor로 허용 
- 유저스토리는 충분한 요구사항 전달을 위해 사람이 아닌 유저유형도 허용함 

### 5. Biz중요도 (MoSCoW 분류)
우선순위에 따른 분류입니다.

| 분류 | 의미 | 설명 |
|------|------|------|
| **M (Must)** | 반드시 필요 | 핵심 비즈니스 기능, 없으면 서비스 불가능 |
| **S (Should)** | 매우 필요하나 대체할 방법은 있음 | 중요하지만 우회 방법이 존재 |
| **C (Could)** | 있으면 좋으나 우선 순위는 떨어짐 (Nice to have) | 사용자 편의성 향상 기능 |
| **W (Won't)** | 가장 우선순위가 떨어지므로 보류해도 됨 | 향후 개발 고려 기능 |

### 6. 인수테스트 시나리오
기능 완성도를 검증하기 위한 테스트 시나리오입니다.

#### 시나리오명
- 테스트할 기능이나 상황을 명확히 표현
- **예시**: "정상적인 회원 가입 처리", "중복 이메일 가입 시도"

#### 인수기준 (Given-When-Then 형식) 
- **형식**: `<Given> | <When> | <Then>`
  - **Given (사전 조건/상황)**: 테스트 실행 전 준비사항
  - **When (Action)**: 사용자가 수행하는 액션
  - **Then (결과)**: 기대되는 결과 또는 시스템 반응

- **예시**
```
미 로그인 상태로 서비스에 접근하여 | ID와 암호를 입력하여 로그인 요청을 하면 | 대시보드 페이지가 표시된다. 
```

#### 체크리스트
세부 테스트 항목을 최대한 자세히 작성합니다.
- 기능/비기능 요구사항 검증 항목
- 예외 상황 처리 검증
- 통합 테스트 항목

### 7. Score
구현 난이도를 피보나치 수열을 이용하여 표현합니다.
- **수열**: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...
- **기준**:

| 점수 | 난이도 | 설명 | 세부 기준 | 예시 |
|------|--------|------|-----------|------|
| **1-2** | **매우 간단** | 기본적인 CRUD 작업 | • 단일 파일 수정<br>• 간단한 설정 변경<br>• 단순 명령어 실행 | • README 작성<br>• 간단한 스크립트 실행<br>• 환경변수 설정 |
| **3-5** | **간단** | 기본 비즈니스 로직 포함 | • 여러 파일 수정<br>• 간단한 테스트 작성<br>• 기본 에러 처리 | • 설정 파일 파싱<br>• 간단한 데이터 변환<br>• 기본 유효성 검사 |
| **8-13** | **보통** | 복잡한 비즈니스 로직 | • API 연동<br>• 데이터베이스 처리<br>• 복잡한 알고리즘<br>• 외부 도구 통합 | • MCP 서버 연동<br>• 파일 시스템 조작<br>• CLI 인터페이스 개발 |
| **21-34** | **복잡** | 다중 시스템 연동 | • 여러 서비스 통합<br>• 복잡한 상태 관리<br>• 성능 최적화 필요<br>• 보안 고려사항 | • GitHub API 통합<br>• 실시간 모니터링<br>• 복잡한 워크플로우 |
| **55+** | **매우 복잡** | 새로운 기술/패러다임 | • 신규 아키텍처 설계<br>• 혁신적 기능 개발<br>• 대규모 리팩토링<br>• 연구개발 요소 | • 새로운 플러그인 아키텍처<br>• AI 모델 통합<br>• 분산 시스템 설계 |

## 결과 형식 
- 코드블록 내에 작성함 
- 구성
```
{서비스 일련번호}. {서비스명}
{Epic 일련번호}. {Epic}
{유저스토리 ID}: [{유저스토리 제목}]: {유저스토리}
- 시나리오: {시나리오}
  {인수기준}
  - {체크 리스트}
- {Biz중요도}/{Score}
```
작성예시
```
1. User 서비스
1) 사용자 인증 및 관리
RQ-USER-010: [회원가입] 사용자로서 | 나는, 여행 계획을 관리하기 위해 | 간편하게 회원가입하고 싶다.
- 시나리오: 회원가입 
  미 로그인 상태로 서비스에 접근한 상황에서 | 사용자 기본정보(이름, 이메일, 연락처), ID, 암호를 입력하여 회원가입 요청하면 | 회원가입이 된다.
  - [ ] 이름, 이메일, 연락처 등록 체크   
  - [ ] ID는 5자 이상의 영숫자 
  - [ ] 암호는 8자 이상의 영숫자와 특수문자가 최소 1개 이상 포함 
- M/5 
```

## 추가 항목 
추가 항목은 필요 시 추가 가능합니다. 
예를 들어 '기술 태스크'와 같은 기술적 내용을 추가할 수 있습니다. 
예시)
```
UFR-AI-010: [AI일정생성] 여행자로서 | 나는 맞춤형 여행 일정을 받기 위해 | AI가 내 여행 정보와 이동수단 선호도를 기반으로 최적화된 일정을 생성하기를 원한다.
- 시나리오: AI 일정 생성 결과 확인
  여행 기본정보와 여행지를 설정하고 AI 일정 생성을 요청한 상황에서 | 5초 이내에 생성이 완료되면 | 선호 이동수단을 기반으로 한 시간대별 상세 일정이 생성되어 확인할 수 있다.
  
  [생성 결과 검증]
  - 모든 여행지에 대한 일정 존재
  - 각 일자별 시작/종료 시간 일치
  - ...
- M/8
- 기술 태스크
  - AI 서비스 API 구현
    - POST /ai/schedules/generate (일정 생성 요청)
    - GET /ai/schedules/{id}/status (진행 상태 조회)
    - GET /ai/schedules/{id} (생성된 일정 조회)
  - AI 모델 통합
    - Claude API 연동
    - 프롬프트 엔지니어링
    - 응답 파싱 및 구조화
```

## 참고 자료
- [유저스토리 작성 샘플](https://raw.githubusercontent.com/cna-bootcamp/clauding-guide/refs/heads/main/samples/Userstory.pdf)

## 결과 파일
작성된 유저스토리는 다음 위치에 저장됩니다:
- **파일 경로**: `design/Userstory.md`
- **형식**: 마크다운 형식으로 모든 유저스토리를 포함

## 작성 시 주의사항

1. **명확성**: 모호한 표현 대신 구체적이고 측정 가능한 표현 사용
2. **완전성**: 모든 필수 구성 요소를 빠짐없이 작성
3. **추적성**: ID를 통해 설계 문서와 연결 가능하도록 작성
4. **테스트 가능성**: 인수테스트 시나리오가 실제 테스트로 실행 가능하도록 구체적으로 작성
5. **우선순위**: MoSCoW 분류를 통해 개발 우선순위 명확화