user-stories

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

유저스토리 작성

用户故事编写

목적

目的

선정된 솔루션과 Event Storming 결과를 기반으로 체계적인 유저스토리를 작성합니다.
基于选定的解决方案和Event Storming结果,编写系统化的用户故事。

사용 시점

使用时机

  • Event Storming이 완료된 후
  • UI/UX 디자인 전
  • 개발 우선순위를 정의해야 할 때
  • 사용자가 "유저스토리", "User Story", "백로그"를 언급할 때
  • Event Storming完成后
  • UI/UX设计前
  • 需要定义开发优先级时
  • 用户提及“用户故事(User Story)”“产品待办列表(Backlog)”时

필수 입력

必要输入

  • 선정된 솔루션:
    think/핵심솔루션.md
    (solution-selection 결과)
  • 타겟 고객 정의:
    define/고객분석.md
    (customer-analysis 결과)
  • Event Storming 결과 (event-storming 결과):
    • think/es/userflow.puml
    • think/es/{순번}-{유저플로우명}.puml
  • 유저스토리 샘플 참고:
    reference/sample_유저스토리.md

  • 选定的解决方案:
    think/핵심솔루션.md
    (solution-selection结果)
  • 目标客户定义:
    define/고객분석.md
    (customer-analysis结果)
  • Event Storming结果 (event-storming结果):
    • think/es/userflow.puml
    • think/es/{序号}-{用户流名称}.puml
  • 用户故事示例参考:
    reference/sample_用户故事.md

이벤트스토밍 → 유저스토리 연결 가이드

Event Storming → 用户故事转换指南

Event Storming 결과에서 유저스토리를 도출하는 가이드입니다.
本指南介绍如何从Event Storming结果中推导用户故事。

1. 매핑 기본 원칙

1. 映射基本原则

Event Storming 요소User Story 요소설명
유저플로우(제목)Epic주요 비즈니스 기능 단위
이벤트 [이벤트]Story (I want to...)사용자가 달성하고 싶은 결과
커맨드 [커맨드]시나리오/Task결과를 달성하기 위한 구체적 행동
정책/규칙 [정책/규칙]Acceptance Criteria비즈니스 규칙 및 제약사항
데이터 [데이터]입력/출력 요구사항필요한 데이터 정의
참여자 (Actor)Persona (As a...)스토리의 주체
핵심 원칙: 사용자는 "버튼을 클릭하고 싶은 것"이 아니라 "결과를 달성하고 싶은 것"입니다.
  • 커맨드(Command): How (방법) - 시스템에 요청하는 행동
  • 이벤트(Event): What (목표) - 달성하고 싶은 결과/상태변화
Event Storming要素User Story要素说明
用户流(标题)Epic主要业务功能单元
事件 [Event]Story (I want to...)用户想要达成的结果
命令 [Command]场景/Task达成结果的具体行动
政策/规则 [Policy/Rule]Acceptance Criteria业务规则及约束条件
数据 [Data]输入/输出需求所需数据的定义
参与者 (Actor)Persona (As a...)故事的主体
核心原则: 用户想要的不是“点击按钮”,而是“达成结果”。
  • 命令(Command): How(方法)- 向系统发起的操作
  • 事件(Event): What(目标)- 想要达成的结果/状态变化

2. 유저플로우 → Epic 변환

2. 用户流 → Epic转换

각 유저플로우 파일이 하나의 Epic이 됩니다. 예시)
| 파일명 | Epic |
|--------|------|
| `01-회원가입.puml` | Epic 1: 사용자 인증 |
| `02-차량등록및AI검증.puml` | Epic 2: 차량 등록 및 검증 |
每个用户流文件对应一个Epic。 示例)
| 文件名 | Epic |
|--------|------|
| `01-会员注册.puml` | Epic 1: 用户认证 |
| `02-车辆注册及AI验证.puml` | Epic 2: 车辆注册及验证 |

3. 이벤트 → User Story 변환

3. 事件 → User Story转换

변환 공식:
{사용자 유형}으로서 | 나는, {목적}을 위해 | {이벤트/결과}를 원한다.
예시 (01-회원가입.puml 기준):
이벤트User Story
[이벤트] 카카오 인증 완료됨
사용자로서 | 나는, 복잡한 입력 없이 빠르게 가입하기 위해 | 카카오 계정으로 인증을 완료하고 싶다.
[이벤트] 이메일 인증 완료됨
사용자로서 | 나는, SNS 없이 가입하기 위해 | 이메일 인증을 완료하고 싶다.
[이벤트] 본인인증 완료됨
사용자로서 | 나는, 안전한 거래 환경에 참여하기 위해 | 본인인증을 완료하고 싶다.
[이벤트] 회원가입 완료됨
사용자로서 | 나는, 서비스를 이용하기 위해 | 회원가입을 완료하고 싶다.
转换公式:
{用户类型}作为 | 我为了{目的} | 想要达成{事件/结果}。
示例(基于01-会员注册.puml):
事件User Story
[Event]  Kakao认证完成
作为用户
[Event] 邮箱认证完成
作为用户
[Event] 实名认证完成
作为用户
[Event] 会员注册完成
作为用户

4. 커맨드 → 시나리오/Task 변환

4. 命令 → 场景/Task转换

커맨드는 User Story의 시나리오 또는 구현 Task로 변환됩니다.
예시:
markdown
undefined
命令会转换为User Story的场景实现Task
示例:
markdown
undefined

UFR-USER-010: [회원가입] 사용자로서 | 나는, 서비스를 이용하기 위해 | 회원가입을 완료하고 싶다.

UFR-USER-010: [会员注册] 作为用户 | 我为了使用服务 | 想要完成会员注册。

  • 시나리오 1: 카카오 간편가입 회원가입 화면에서 | [커맨드] 카카오 로그인 버튼을 클릭하면 | 카카오 인증 후 가입이 완료된다.
  • 시나리오 2: 이메일 가입 회원가입 화면에서 | [커맨드] 이메일/비밀번호를 입력하고 인증하면 | 이메일 인증 후 가입이 완료된다.
undefined
  • 场景1: Kakao快捷注册 在会员注册页面 | 点击[Command] Kakao登录按钮后 | 完成Kakao认证即注册成功。
  • 场景2: 邮箱注册 在会员注册页面 | 输入邮箱/密码并完成认证后 | 完成邮箱认证即注册成功。
undefined

5. 정책/규칙 → Acceptance Criteria 변환

5. 政策/规则 → Acceptance Criteria转换

시퀀스 다이어그램의
[정책/규칙]
노트가 Acceptance Criteria(인수조건)가 됩니다.
序列图中的
[政策/规则]
注释将成为Acceptance Criteria(验收条件)。

6. 외부 시스템 연동 스토리 분리

6. 外部系统集成故事分离

(E)
로 표시된 외부 시스템 연동은 별도 Technical Story로 분리합니다.

标记为
(E)
的外部系统集成将分离为独立的Technical Story。

마이크로서비스 정의 가이드

微服务定义指南

Event Storming 결과에서 마이크로서비스를 도출하는 5단계 프로세스입니다.
从Event Storming结果中推导微服务的5步流程。

1. 이벤트 클러스터링

1. 事件聚类

유저플로우별 이벤트를 비즈니스 개념 기준으로 그룹화합니다.
[방법]
1. 각 .puml 파일에서 [이벤트] 추출
2. 동일 비즈니스 개념 이벤트 묶기
3. 동일 액터가 주로 사용하는 이벤트 확인

[예시]
인증 클러스터: 회원가입 완료됨, 로그인 완료됨, 인증 완료됨
주문 클러스터: 주문 생성됨, 주문 취소됨, 주문 완료됨
按业务概念对各用户流的事件进行分组。
[方法]
1. 从每个.puml文件中提取[Event]
2. 将同一业务概念的事件归为一组
3. 确认同一参与者主要使用的事件

[示例]
认证聚类: 会员注册完成、登录完成、认证完成
订单聚类: 订单创建、订单取消、订单完成

2. Aggregate 식별

2. 聚合(Aggregate)识别

이벤트가 변경하는 엔티티와 생명주기를 파악합니다.
분석 항목질문
상태 변경이 이벤트가 어떤 엔티티의 상태를 변경하는가?
생명주기생성-수정-삭제 사이클이 같은 엔티티는?
불변식항상 함께 검증되어야 하는 규칙은?
[예시]
주문 Aggregate: Order(Root), OrderItem, OrderStatus
회원 Aggregate: Member(Root), Profile, Address
分析事件所改变的实体及其生命周期。
分析项问题
状态变更该事件会改变哪个实体的状态?
生命周期具有相同创建-修改-删除周期的实体是哪些?
不变量必须始终一起验证的规则是什么?
[示例]
订单Aggregate: Order(Root), OrderItem, OrderStatus
会员Aggregate: Member(Root), Profile, Address

3. 바운디드 컨텍스트 정의

3. 限界上下文(Bound Context)定义

Aggregate와 정책/규칙을 묶어 컨텍스트 경계를 설정합니다.
[경계 설정 기준]
- 유비쿼터스 언어: 같은 용어가 같은 의미로 사용되는 범위
- 정책 귀속: [정책/규칙]이 적용되는 범위
- 팀 책임: 단일 팀이 책임질 수 있는 범위
将聚合(Aggregate)与政策/规则组合,设定上下文边界。
[边界设定标准]
- 通用语言(Ubiquitous Language): 同一术语具有相同含义的范围
- 政策归属: [政策/规则]适用的范围
- 团队职责: 单个团队可负责的范围

4. 컨텍스트 맵핑

4. 上下文映射

컨텍스트 간 관계와 통신 패턴을 정의합니다.
관계 유형설명통신 패턴
Customer-Supplier요청-응답 관계동기 호출
Conformist상위 서비스 모델 따름동기 호출
Published Language표준 이벤트 공유비동기 이벤트
Anti-Corruption Layer모델 변환 계층 필요어댑터 패턴
定义上下文之间的关系和通信模式。
关系类型说明通信模式
Customer-Supplier请求-响应关系同步调用
Conformist遵循上游服务模型同步调用
Published Language共享标准事件异步事件
Anti-Corruption Layer需要模型转换层适配器模式

5. 분할/병합 결정

5. 拆分/合并决策

아래 기준을 적용하여 최종 마이크로서비스를 도출합니다.
应用以下标准推导出最终的微服务。

분할 기준 (하나 이상 해당 시 분리)

拆分标准(满足任意一项则拆分)

기준설명
차별화 핵심비즈니스 경쟁력 원천 기능
부하 변동스케일링 패턴이 다름
변경 빈도배포 주기가 다름
데이터 소유별도 Aggregate Root 소유
标准说明
差异化核心业务竞争力来源的功能
负载波动扩容模式不同
变更频率发布周期不同
数据所有权归属于独立的Aggregate Root

병합 기준 (해당 시 통합 고려)

合并标准(满足则考虑整合)

기준지표
트랜잭션 경계강한 일관성 필요
서비스 크기코드 5,000줄 미만
호출 빈도동기 호출 90% 이상
운영 복잡도팀당 3-5개 서비스 적정
标准指标
事务边界需要强一致性
服务规模代码量少于5000行
调用频率同步调用占比90%以上
运维复杂度每个团队负责3-5个服务为最佳

MVP 단계 병합 전략

MVP阶段合并策略

초기에는 운영 복잡도를 낮추기 위해 관련 컨텍스트를 병합하고, 트래픽/복잡도 증가 시 분리합니다.
[병합 예시]
회원 + 알림 → 회원서비스 (분리 트리거: 알림 처리량 > 10,000건/시간)
주문 + 결제 → 거래서비스 (분리 트리거: 결제 기능 복잡화)
初期为降低运维复杂度,可合并相关上下文,当流量/复杂度增加时再拆分。
[合并示例]
会员 + 通知 → 会员服务(拆分触发条件: 通知处理量 > 10,000条/小时)
订单 + 支付 → 交易服务(拆分触发条件: 支付功能复杂化)

서비스 정의 체크리스트

服务定义检查清单

  • 모든 유저플로우 이벤트가 서비스에 매핑됨
  • 각 서비스가 단일 Aggregate만 소유함
  • 트랜잭션 경계가 서비스 경계 내에 있음
  • 이벤트 기반 통신 패턴이 정의됨

  • 所有用户流事件均已映射到服务
  • 每个服务仅拥有单个Aggregate
  • 事务边界在服务边界内
  • 已定义基于事件的通信模式

유저스토리 프레임워크

用户故事框架

1. 마이크로서비스

1. 微服务

유저스토리는 마이크로서비스 단위로 구성합니다: 마이크로서비스는 '마이크로서비스 정의 가이드'에 따라 정의합니다.
'MVP 단계 병합 전략'에 따라 운영 복잡도를 낮추기 위해 관련 컨텍스트는 병합합니다.
用户故事按微服务单元组织: 微服务根据“微服务定义指南”进行定义。
根据“MVP阶段合并策略”,为降低运维复杂度,可合并相关上下文。

서비스 조직 예시

服务组织示例

  • User Service: 사용자 관리 (회원가입, 로그인, 프로필)
  • [Core] Service: 핵심 비즈니스 기능
  • [AI] Service: AI 기반 기능
  • [Integration] Service: 외부 연동 기능
  • User Service: 用户管理(会员注册、登录、个人资料)
  • [Core] Service: 核心业务功能
  • [AI] Service: 基于AI的功能
  • [Integration] Service: 外部集成功能

2. UFR (User Functional Requirement) 포맷

2. UFR (User Functional Requirement) 格式

각 유저스토리는 다음 형식을 따릅니다:
每个用户故事遵循以下格式:

UFR-{서비스약어}-{번호}: [{유저스토리 제목}] {사용자유형}로서 | 나는, {목적}을 위해 | {액션}을 하고 싶다.

UFR-{服务缩写}-{编号}: [{用户故事标题}] {用户类型}作为 | 我为了{目的} | 想要执行{操作}。

예시:
  • UFR-USER-010: [회원가입] 구매자로서 | 나는, 서비스를 이용하기 위해 | 간편하게 회원가입하고 싶다.
  • UFR-CORE-020: [주문하기] 구매자로서 | 나는, 상품을 구매하기 위해 | 쉽게 주문하고 싶다.
示例:
  • UFR-USER-010: [会员注册] 作为买家 | 我为了使用服务 | 想要便捷完成会员注册。
  • UFR-CORE-020: [下单] 作为买家 | 我为了购买商品 | 想要轻松完成下单。

3. 시나리오 기반 상세 요구사항

3. 基于场景的详细需求

각 UFR은 다음 구조로 상세화합니다:
每个UFR按以下结构细化:

- 시나리오: {시나리오명}

- 场景: {场景名称}

{상황 설명} | {조건} | {결과}
[입력 요구사항]
  • 기본 정보
    • {필드명}: {검증 조건}
    • {필드명}: {검증 조건}
  • 추가 정보
    • {필드명}: {검증 조건}
[검증 요구사항]
  • {검증 항목}: {검증 내용}
  • {검증 항목}: {검증 내용}
[처리 결과]
  • 성공 시
    • {결과 항목}
    • {결과 항목}
  • 실패 시
    • {실패 조건}: {처리 방법}
{情境描述} | {条件} | {结果}
[输入需求]
  • 基础信息
    • {字段名}: {验证条件}
    • {字段名}: {验证条件}
  • 附加信息
    • {字段名}: {验证条件}
[验证需求]
  • {验证项}: {验证内容}
  • {验证项}: {验证内容}
[处理结果]
  • 成功时
    • {结果项}
    • {结果项}
  • 失败时
    • {失败条件}: {处理方式}

- M/{포인트}, S/{포인트}, C/{포인트}

- M/{分值}, S/{分值}, C/{分值}

우선순위 표기법:
  • M (Must Have): 필수 구현 기능
  • S (Should Have): 중요 구현 기능
  • C (Could Have): 선택 구현 기능
  • 숫자: Story Points (피보나치: 1, 2, 3, 5, 8, 13, 21)
예시:
M/13
→ Must Have, 13 포인트
优先级标记法:
  • M (Must Have): 必须实现的功能
  • S (Should Have): 重要的实现功能
  • C (Could Have): 可选实现的功能
  • 数字: Story Points(斐波那契数列: 1, 2, 3, 5, 8, 13, 21)
示例:
M/13
→ Must Have,13个故事点

4. 기술 태스크 (복잡한 스토리)

4. 技术任务(复杂故事)

복잡한 구현이 필요한 스토리는 기술 태스크를 분리합니다:
对于需要复杂实现的故事,需拆分技术任务:

[기술 태스크]

[技术任务]

  • Frontend
    • {구현 내용}
    • {구현 내용}
  • Backend
    • API Endpoint: {엔드포인트}
    • Service Layer: {서비스 로직}
    • Repository: {데이터 접근}
  • Infrastructure
    • {인프라 요구사항}
  • Frontend
    • {实现内容}
    • {实现内容}
  • Backend
    • API Endpoint: {端点}
    • Service Layer: {服务逻辑}
    • Repository: {数据访问}
  • Infrastructure
    • {基础设施需求}

5. 사용자 역할

5. 用户角色

각 역할 정의:
  • 설명
  • 권한
  • 목표
各角色定义:
  • 说明
  • 权限
  • 目标

6. Feature Story Map

6. Feature Story Map

계층 구조 생성:
User Service
├── UFR-USER-010: 회원가입
├── UFR-USER-020: 로그인
└── UFR-USER-030: 프로필 관리

Core Service
├── UFR-CORE-010: [기능 1]
├── UFR-CORE-020: [기능 2]
└── UFR-CORE-030: [기능 3]
生成层级结构:
User Service
├── UFR-USER-010: 会员注册
├── UFR-USER-020: 登录
└── UFR-USER-030: 个人资料管理

Core Service
├── UFR-CORE-010: [功能1]
├── UFR-CORE-020: [功能2]
└── UFR-CORE-030: [功能3]

7. 우선순위 매트릭스

7. 优先级矩阵

Must Have (P0)

Must Have (P0)

  1. [UFR-XXX-###] - [스토리 제목]
  1. [UFR-XXX-###] - [故事标题]

Should Have (P1)

Should Have (P1)

  1. [UFR-XXX-###] - [스토리 제목]
  1. [UFR-XXX-###] - [故事标题]

Could Have (P2)

Could Have (P2)

  1. [UFR-XXX-###] - [스토리 제목]
  1. [UFR-XXX-###] - [故事标题]

Won't Have (이번 버전에서는)

Won't Have (本版本不包含)

  1. [UFR-XXX-###] - [스토리 제목]
  1. [UFR-XXX-###] - [故事标题]

8. 스프린트 계획 (MVP 기준)

8. Sprint计划(基于MVP)

Sprint 1 (1-2주차)

Sprint 1 (第1-2周)

  • UFR-USER-010: [제목] (M/5)
  • UFR-CORE-020: [제목] (M/3)
  • Sprint 목표: [스프린트 목표]
  • 총 SP: 8
[이후 스프린트 계속]
  • UFR-USER-010: [标题] (M/5)
  • UFR-CORE-020: [标题] (M/3)
  • Sprint目标: [Sprint目标]
  • 总SP: 8
[后续Sprint以此类推]

9. 비기능적 요구사항

9. 非功能性需求

성능

性能

  • 페이지 로드: 3G에서 <3초, WiFi에서 <1초
  • API 응답: <200ms
  • 동시 사용자: 1000명
  • 页面加载: 3G网络下<3秒,WiFi下<1秒
  • API响应: <200ms
  • 并发用户: 1000人

보안

安全

  • HTTPS 적용
  • 인증/권한 관리
  • 데이터 암호화
  • 启用HTTPS
  • 认证/权限管理
  • 数据加密

사용성

易用性

  • 모바일 반응형
  • WCAG 2.1 접근성 준수
  • 다국어 지원
  • 移动端响应式
  • 符合WCAG 2.1可访问性标准
  • 多语言支持

확장성

扩展性

  • 수평 확장 가능
  • 클라우드 네이티브
  • 마이크로서비스 아키텍처
  • 支持水平扩容
  • 云原生
  • 微服务架构

10. Definition of Done

10. Definition of Done

체크리스트:
  • 코드 리뷰 완료
  • 단위 테스트 작성 및 통과
  • 통합 테스트 통과
  • 문서화 완료
  • QA 테스트 통과
  • 스테이징 배포 및 검증
  • 프로덕션 배포
检查清单:
  • 代码评审完成
  • 单元测试编写并通过
  • 集成测试通过
  • 文档完成
  • QA测试通过
  • 预发布环境部署并验证
  • 生产环境部署

11. 리스크 및 의존성

11. 风险与依赖

UFR ID리스크/이슈영향도완화 전략
UFR-XXX-###[리스크]높음[전략]
UFR ID风险/问题影响程度缓解策略
UFR-XXX-###[风险][策略]

INVEST 원칙

INVEST原则

유저스토리는 반드시 INVEST를 따라야 함:
  • Independent (독립적): 독립적으로 개발 가능
  • Negotiable (협상 가능): 세부사항 논의 가능
  • Valuable (가치 있음): 사용자에게 가치 제공
  • Estimable (추정 가능): 추정 가능
  • Small (작음): 한 스프린트 내 완료 가능
  • Testable (테스트 가능): 명확한 인수 기준

用户故事必须遵循INVEST原则:
  • Independent (独立性): 可独立开发
  • Negotiable (可协商性): 可讨论细节
  • Valuable (价值性): 为用户提供价值
  • Estimable (可估算性): 可估算工作量
  • Small (小型化): 可在一个Sprint内完成
  • Testable (可测试性): 具备明确的验收标准

작성 형식

编写格式

유저스토리 예시
markdown
undefined
用户故事示例
markdown
undefined

유저스토리

用户故事

User Service

User Service

UFR-USER-010: [회원가입] 사용자로서 | 나는 서비스를 이용하기 위해 | 간편하게 회원가입하고 싶다.

UFR-USER-010: [会员注册] 作为用户 | 我为了使用服务 | 想要便捷完成会员注册。

  • 시나리오: 신규 회원가입 미로그인 상태에서 회원가입 화면에 접근한 상황에서 | 필수 정보를 모두 입력하고 회원가입 버튼을 클릭하면 | 가입이 완료되고 로그인 화면으로 이동한다.
    [입력 요구사항]
    • 기본 정보
      • 이름: 2자 이상 (한글/영문)
      • 이메일: 유효한 이메일 형식
      • 비밀번호: 8자 이상, 영문+숫자+특수문자
    • 추가 정보
      • 닉네임: 2-10자 (선택)
      • 프로필 이미지: JPG/PNG, 최대 5MB (선택)
    [검증 요구사항]
    • 이메일 중복 확인: 기존 회원과 중복 불가
    • 비밀번호 강도: 보안 정책 준수
    • 필수 입력: 이름, 이메일, 비밀번호
    [처리 결과]
    • 성공 시
      • 회원 정보 DB 저장
      • 환영 이메일 발송
      • 로그인 화면으로 리디렉션
    • 실패 시
      • 이메일 중복: "이미 사용 중인 이메일입니다" 메시지
      • 유효성 오류: 해당 필드에 오류 메시지 표시
  • M/13

(다음 스토리 반복)
  • 场景: 新用户注册 在未登录状态下进入会员注册页面 | 输入所有必填信息并点击注册按钮后 | 注册成功并跳转到登录页面。
    [输入需求]
    • 基础信息
      • 姓名: 2字以上(韩文/英文)
      • 邮箱: 符合有效邮箱格式
      • 密码: 8字以上,包含英文+数字+特殊字符
    • 附加信息
      • 昵称: 2-10字(可选)
      • 头像: JPG/PNG格式,最大5MB(可选)
    [验证需求]
    • 邮箱重复检查: 不可与现有会员重复
    • 密码强度: 符合安全政策
    • 必填项: 姓名、邮箱、密码
    [处理结果]
    • 成功时
      • 会员信息保存到DB
      • 发送欢迎邮件
      • 跳转到登录页面
    • 失败时
      • 邮箱重复: 显示“该邮箱已被使用”提示
      • 有效性错误: 在对应字段显示错误提示
  • M/13

(后续故事以此类推)

사용자 역할

用户角色

역할 1: {역할명}

角色1: {角色名}

  • 설명: {역할 설명}
  • 권한: {권한 목록}
  • 목표: {역할의 주요 목표}
  • 说明: {角色描述}
  • 权限: {权限列表}
  • 目标: {角色的主要目标}

역할 2: {역할명}

角色2: {角色名}

  • 설명: {역할 설명}
  • 권한: {권한 목록}
  • 목표: {역할의 주요 목표}
  • 说明: {角色描述}
  • 权限: {权限列表}
  • 目标: {角色的主要目标}

Feature Story Map

Feature Story Map

``` User Service ├── UFR-USER-010: 회원가입 ├── UFR-USER-020: 로그인 └── UFR-USER-030: 프로필 관리
Core Service ├── UFR-CORE-010: {스토리 제목} ├── UFR-CORE-020: {스토리 제목} └── UFR-CORE-030: {스토리 제목} ```
User Service
├── UFR-USER-010: 会员注册
├── UFR-USER-020: 登录
└── UFR-USER-030: 个人资料管理

Core Service
├── UFR-CORE-010: {故事标题}
├── UFR-CORE-020: {故事标题}
└── UFR-CORE-030: {故事标题}

우선순위 매트릭스

优先级矩阵

Must Have (P0) - 필수

Must Have (P0) - 必备

  1. UFR-USER-010: 회원가입 - 서비스 이용을 위한 필수 기능
  2. UFR-CORE-020: {제목} - {설명}
  1. UFR-USER-010: 会员注册 - 服务使用的必备功能
  2. UFR-CORE-020: {标题} - {说明}

Should Have (P1) - 중요

Should Have (P1) - 重要

  1. UFR-USER-030: {제목} - {설명}
  2. UFR-CORE-030: {제목} - {설명}
  1. UFR-USER-030: {标题} - {说明}
  2. UFR-CORE-030: {标题} - {说明}

Could Have (P2) - 선택

Could Have (P2) - 可选

  1. UFR-XXX-###: {제목} - {설명}
  1. UFR-XXX-###: {标题} - {说明}

Won't Have - 향후 고려

Won't Have - 后续考虑

  1. UFR-XXX-###: {제목} - {설명}
  1. UFR-XXX-###: {标题} - {说明}

스프린트 계획 (MVP 기준)

Sprint计划(基于MVP)

Sprint 1 (1-2주차)

Sprint 1 (第1-2周)

Sprint 목표: {스프린트의 핵심 목표}
  • UFR-USER-010: 회원가입 (M/5)
  • UFR-USER-020: 로그인 (M/3)
  • UFR-CORE-010: {제목} (S/2)
총 Story Points: 10 예상 완료일: {날짜}
Sprint目标: {Sprint的核心目标}
  • UFR-USER-010: 会员注册 (M/5)
  • UFR-USER-020: 登录 (M/3)
  • UFR-CORE-010: {标题} (S/2)
总Story Points: 10 预计完成日期: {日期}

Sprint 2 (3-4주차)

Sprint 2 (第3-4周)

Sprint 목표: {스프린트의 핵심 목표}
  • UFR-CORE-020: {제목} (M/8)
  • UFR-USER-030: {제목} (S/5)
총 Story Points: 13 예상 완료일: {날짜}
(이후 스프린트 계속)
Sprint目标: {Sprint的核心目标}
  • UFR-CORE-020: {标题} (M/8)
  • UFR-USER-030: {标题} (S/5)
总Story Points: 13 预计完成日期: {日期}
(后续Sprint以此类推)

비기능적 요구사항

非功能性需求

성능 요구사항

性能需求

  • 페이지 로드 시간: 3G 네트워크에서 3초 이내, WiFi에서 1초 이내
  • API 응답 시간: 200ms 이내
  • 동시 사용자 처리: 1000명 이상
  • 트랜잭션 처리량: 초당 100건 이상
  • 页面加载时间: 3G网络下3秒以内,WiFi下1秒以内
  • API响应时间: 200ms以内
  • 并发用户处理: 1000人以上
  • 事务处理量: 每秒100笔以上

보안 요구사항

安全需求

  • HTTPS 적용: 모든 통신 암호화
  • 인증/권한 관리: JWT 또는 OAuth 기반
  • 데이터 암호화: 민감 데이터 암호화 저장
  • 보안 감사: 정기적인 보안 점검
  • HTTPS启用: 所有通信加密
  • 认证/权限管理: 基于JWT或OAuth
  • 数据加密: 敏感数据加密存储
  • 安全审计: 定期安全检查

사용성 요구사항

易用性需求

  • 모바일 반응형: 모든 기기에서 최적화된 화면
  • 접근성: WCAG 2.1 AA 이상 준수
  • 다국어 지원: 최소 2개 언어 지원
  • 브라우저 호환성: Chrome, Safari, Firefox, Edge 최신 2개 버전
  • 移动端响应式: 适配所有设备的优化界面
  • 可访问性: 符合WCAG 2.1 AA以上标准
  • 多语言支持: 至少支持2种语言
  • 浏览器兼容性: Chrome、Safari、Firefox、Edge最新2个版本

확장성 요구사항

扩展性需求

  • 수평 확장: 트래픽 증가 시 서버 추가 가능
  • 클라우드 네이티브: 클라우드 환경 최적화
  • 마이크로서비스: 서비스 독립 배포 가능
  • 캐싱 전략: Redis 기반 캐싱
  • 水平扩容: 流量增加时可添加服务器
  • 云原生: 云环境优化
  • 微服务: 服务可独立部署
  • 缓存策略: 基于Redis的缓存

Definition of Done

Definition of Done

각 스토리 완료 기준:
每个故事的完成标准:

개발 완료

开发完成

  • 코드 작성 완료
  • 코드 리뷰 완료 (최소 1명)
  • 코딩 스타일 가이드 준수
  • 기술 부채 최소화
  • 代码编写完成
  • 代码评审完成(至少1人参与)
  • 符合编码风格指南
  • 最小化技术债务

테스트 완료

测试完成

  • 단위 테스트 작성 및 통과 (커버리지 80% 이상)
  • 통합 테스트 통과
  • E2E 테스트 통과 (주요 플로우)
  • 성능 테스트 통과
  • 单元测试编写并通过(覆盖率80%以上)
  • 集成测试通过
  • E2E测试通过(主要流程)
  • 性能测试通过

문서화 완료

文档完成

  • 코드 주석 작성
  • API 문서 업데이트
  • 사용자 가이드 업데이트
  • 변경 사항 로그 작성
  • 代码注释编写完成
  • API文档更新
  • 用户指南更新
  • 变更日志编写

배포 완료

部署完成

  • 스테이징 환경 배포
  • QA 검증 완료
  • 프로덕션 배포 승인
  • 프로덕션 배포 완료
  • 预发布环境部署
  • QA验证完成
  • 生产环境部署审批通过
  • 生产环境部署完成

리스크 및 의존성

风险与依赖

리스크 관리

风险管理

UFR ID리스크/이슈영향도발생 가능성완화 전략담당자
UFR-USER-010{리스크 설명}높음중간{완화 전략}{담당자}
UFR-CORE-020{리스크 설명}중간높음{완화 전략}{담당자}
UFR ID风险/问题影响程度发生可能性缓解策略负责人
UFR-USER-010{风险描述}{缓解策略}{负责人}
UFR-CORE-020{风险描述}{缓解策略}{负责人}

의존성 관리

依赖管理

UFR ID의존하는 스토리의존성 타입해결 방법
UFR-CORE-020UFR-USER-010기술적 의존성{해결 방법}
UFR-XXX-###UFR-CORE-020비즈니스 의존성{해결 방법}

---
UFR ID依赖的故事依赖类型解决方法
UFR-CORE-020UFR-USER-010技术依赖{解决方法}
UFR-XXX-###UFR-CORE-020业务依赖{解决方法}

---

도구 활용

工具使用

Sequential MCP 사용

使用Sequential MCP

복잡한 유저스토리 분석과 우선순위 결정이 필요할 때 Sequential MCP를 활용하여 체계적으로 백로그를 구성하세요.
当需要分析复杂用户故事并确定优先级时,可使用Sequential MCP系统化构建待办列表。

결과 파일

结果文件

  • 유저스토리.md:
    design/userstory.md
  • 用户故事.md:
    design/userstory.md

주의사항

注意事项

  • UFR 포맷 준수:
    UFR-{서비스}-{일련번호}
    형식 엄격히 사용
  • 일련번호: 각 서비스별로 '010'부터 시작하여 10씩 증가시킴
  • 시나리오 구조 필수: [입력 요구사항], [검증 요구사항], [처리 결과] 모두 작성
  • 우선순위 표기: M/S/C + Story Points (피보나치) 형식 사용
  • 최소 20개 이상: 충분한 UFR로 MVP 범위 정의
  • Event Storming 연계: ES 결과를 UFR로 체계적 변환
  • 마이크로서비스 구조: 서비스별로 명확히 그룹화
  • 기술 태스크: 복잡한 스토리는 Frontend/Backend/Infrastructure 분리
  • INVEST 원칙: 독립성, 협상가능성, 가치, 추정가능성, 작은 크기, 테스트가능성
  • 비기능적 요구사항: 성능, 보안, 사용성, 확장성 필수 포함
  • Definition of Done: 모든 완료 기준 충족 필요
  • 遵循UFR格式: 严格使用
    UFR-{服务}-{序列号}
    格式
  • 序列号: 每个服务从'010'开始,每次递增10
  • 必须包含场景结构: [输入需求]、[验证需求]、[处理结果]需全部编写
  • 优先级标记: 使用M/S/C + Story Points(斐波那契数列)格式
  • 至少20个以上: 需有足够的UFR来定义MVP范围
  • 关联Event Storming: 将ES结果系统化转换为UFR
  • 微服务结构: 按服务明确分组
  • 技术任务: 复杂故事需拆分Frontend/Backend/Infrastructure任务
  • INVEST原则: 确保独立性、可协商性、价值性、可估算性、小型化、可测试性
  • 非功能性需求: 必须包含性能、安全、易用性、扩展性
  • Definition of Done: 需满足所有完成标准

다음 단계

后续步骤

유저스토리 작성 완료 후:
  1. UI/UX 디자인 (와이어프레임, 디자인 시스템)
  2. 프로토타입 개발 (기술 스택, 구현)
  3. 스프린트 실행 및 개발
完成用户故事编写后:
  1. UI/UX设计(线框图、设计系统)
  2. 原型开发(技术栈、实现)
  3. 执行Sprint并开发