功能规范: [FEATURE NAME]

功能分支: [###-feature-name] 创建时间: [DATE] 状态: 草稿 输入: 用户描述: "$ARGUMENTS"

用户场景与测试 (必填)

<!-- 重要说明: 用户故事应按重要性排序, 作为用户旅程进行优先级划分. 每个用户故事/旅程必须能够独立测试——这意味着即使只实现其中一个, 你仍然应该有一个可行的 MVP(最小可行产品)来交付价值. 为每个故事分配优先级(P1、P2、P3 等), 其中 P1 是最关键的. 将每个故事视为独立的功能切片, 可以: - 独立开发 - 独立测试 - 独立部署 - 独立向用户演示 -->

用户故事 1 - [简要标题] (优先级: P1)

[用通俗语言描述这个用户旅程]

优先级原因: [解释价值以及为什么具有此优先级]

独立测试: [描述如何独立测试 - 例如: "可以通过 [具体操作] 完全测试并交付 [具体价值]"]

验收场景:

1. 给定 [初始状态], 当 [操作时], 那么 [预期结果]
2. 给定 [初始状态], 当 [操作时], 那么 [预期结果]

---

用户故事 2 - [简要标题] (优先级: P2)

[用通俗语言描述这个用户旅程]

优先级原因: [解释价值以及为什么具有此优先级]

独立测试: [描述如何独立测试]

验收场景:

1. 给定 [初始状态], 当 [操作时], 那么 [预期结果]

---

用户故事 3 - [简要标题] (优先级: P3)

[用通俗语言描述这个用户旅程]

优先级原因: [解释价值以及为什么具有此优先级]

独立测试: [描述如何独立测试]

验收场景:

1. 给定 [初始状态], 当 [操作时], 那么 [预期结果]

---

[根据需要添加更多用户故事, 每个都分配优先级]

边界情况

<!-- 需要操作: 本节内容表示占位符. 请用正确的边界情况填写. -->

• 当 [边界条件] 时会发生什么？
• 系统如何处理 [错误场景]？

需求 (必填)

<!-- 需要操作: 本节内容表示占位符. 请用正确的功能需求填写. -->

功能需求

• FR-001: 系统必须 [具体能力, 例如: "允许用户创建账户"]
• FR-002: 系统必须 [具体能力, 例如: "验证电子邮件地址"]
• FR-003: 用户必须能够 [关键交互, 例如: "重置密码"]
• FR-004: 系统必须 [数据需求, 例如: "持久化用户偏好设置"]
• FR-005: 系统必须 [行为, 例如: "记录所有安全事件"]

*标记不明确需求的示例: *

• FR-006: 系统必须通过 [NEEDS CLARIFICATION: 未指定认证方法 - 电子邮件/密码、SSO、OAuth？] 认证用户
• FR-007: 系统必须保留用户数据 [NEEDS CLARIFICATION: 未指定保留期限]

测试需求 (符合章程原则I)

• TR-001: 每个功能必须有对应的集成测试验证完整用户场景
• TR-002: 单元测试覆盖率必须达到60%以上
• TR-003: 所有测试必须在实现前编写（TDD）

文档需求 (符合章程原则II)

• DR-001: 所有公共类和方法必须有中文XML文档注释
• DR-002: 复杂算法必须有中文说明文档
• DR-003: README和Wiki必须更新以反映新功能

跨平台需求 (符合章程原则IV)

• PR-001: 功能必须在Windows、Linux、macOS上正常工作
• PR-002: 必须支持.NET 8.0和.NET Framework 4.6
• PR-003: 文件路径和编码处理必须跨平台兼容

关键实体 (如果功能涉及数据则包含)

• [实体 1]: [它代表什么, 关键属性(不含实现细节)]
• [实体 2]: [它代表什么, 与其他实体的关系]

成功标准 (必填)

<!-- 需要操作: 定义可衡量的成功标准. 这些标准必须与技术无关且可衡量. -->

可衡量的结果

• SC-001: [可衡量的指标, 例如: "用户可以在 2 分钟内完成账户创建"]
• SC-002: [可衡量的指标, 例如: "系统处理 1000 个并发用户而不降低性能"]
• SC-003: [用户满意度指标, 例如: "90% 的用户在首次尝试时成功完成主要任务"]
• SC-004: [业务指标, 例如: "将与 [X] 相关的支持工单减少 50%"]