用途
需求工程用于将原始需求转化为结构化、可测试的规格说明，指导开发团队工作。它适用于以下场景：创建功能需求文档；编写带验收标准的用户故事；定义业务规则与约束；记录流程流；对功能进行优先级排序（MoSCoW、RICE）；分析干系人需求。
需求文档结构
一份完整的需求文档包含：功能概述（业务背景与成功指标）、用户故事（谁、做什么、为什么格式）、验收标准（Given/When/Then 场景）、数据模型（字段、类型、约束）、业务规则（BR-XXX 格式）、权限要求（基于角色的访问）、待澄清问题。
核心模板
用户故事格式
US-[XXX]: [标题]
作为 [角色]， 我想要 [动作]， 以便 [收益]。
验收标准：
- [ ] 给定 [上下文]，当 [动作]，则 [预期结果]
- [ ] 给定 [上下文]，当 [动作]，则 [预期结果]
- [ ] 给定 [上下文]，当 [动作]，则 [预期结果]
优先级：必须有 | 应该有 | 可以有 | 不会有 工作量：S（1-2 天）| M（3-5 天）| L（1-2 周）| XL（2 周以上） 依赖：列出任何依赖的故事
验收标准模式
正常路径：
给定已登录的 [角色] 当他们使用有效 [输入] [执行动作] 则 [预期成功结果] 并且 [副作用（如有）]
校验错误：
给定已登录的 [角色] 当他们使用无效 [输入类型] [执行动作] 则系统显示“[错误消息]” 并且 [操作未完成]
授权：
给定没有 [权限] 的用户 当他们尝试 [执行动作] 则系统返回 403 Forbidden 并且 [记录未授权尝试]
边界情况：
给定 [边界条件存在] 当 [执行动作] 则 [发生优雅处理]
业务规则格式
完整格式：参见 domain-modeling 技能获取详细模式与分类。
需求中的快速格式：
ID | 规则 | 执行 | 影响 BR-{CAT}-001 | [规则描述] | [创建/更新/删除] | [拒绝并报错]
数据模型模板
完整实体建模：参见 domain-modeling 技能获取包含关系、状态转换与 API 访问的完整实体定义。
需求中的快速格式：
字段 | 类型 | 必填 | 约束 | 描述 Id | Guid | 是 | 主键 | 唯一标识符 Name | string | 是 | 最多 100 字符 | 显示名称 Email | string | 是 | 有效邮箱，唯一 | 联系邮箱 Status | enum | 是 | 启用/停用 | 当前状态
流程流模板
流程：[流程名称]
参与者
| 参与者 | 角色 | 职责 |
|---|---|---|
| [角色 1] | [职位] | [他们做什么] |
| [角色 2] | [职位] | [他们做什么] |
流程
- [参与者] 发起 [动作]
- 系统 校验 [条件]
- 如果有效： a. [成功步骤 1] b. [成功步骤 2] c. [通知/确认]
- 如果无效： a. [错误处理] b. [用户反馈]
应用的业务规则
- BR-001：[在步骤 X 应用的规则]
- BR-002：[在步骤 Y 应用的规则]
优先级排序方法
MoSCoW 方法
优先级 | 含义 | 指导 必须有 | 发布关键 | 约 60% 工作量 应该有 | 重要但不关键 | 约 20% 工作量 可以有 | 锦上添花 | 约 20% 工作量 不会有 | 本次发布范围外 | 为未来记录
RICE 评分
RICE 分数 =（触达 × 影响 × 信心）/ 工作量
触达：每季度受影响的用户数（数字） 影响：对每个用户的影响（3=巨大，2=高，1=中，0.5=低，0.25=极小） 信心：我们有多确定（100%=高，80%=中，50%=低） 工作量：完成所需人月数（数字）
质量检查清单
在最终确定需求之前：
- 至少定义 3 个用户故事
- 每个故事有 2 个以上验收标准
- 验收标准可测试（Given/When/Then）
- 数据模型包含所有字段及类型
- 业务规则已编号并记录
- 权限与现有角色一致
- 待澄清问题已捕获
- 每个故事已分配优先级
- 依赖已识别
与领域建模的集成
创建需求时，始终考虑领域影响：
- 编写需求前：查看 docs/domain/ 中的现有领域
- 分析期间：识别新增/修改的实体、规则、权限
- 需求完成后：使用 domain-modeling 技能创建影响分析
business-analyst 智能体结合 requirements-engineering 与 domain-modeling 进行完整分析。
参考资料
- references/user-story-examples.md - 真实世界示例
- references/acceptance-criteria-patterns.md - 常见模式