requirements

要求

创建或更新根目录中的 REQUIREMENTS.md。描述产品、产品的作用及其关键功能。将其维护为长期有效的产品文档。 使用 /spec 编写单项功能的规范，使用 /architecture 记录系统技术决策。

流程

1. 阅读请求、仓库说明、现有要求和相关依据。沿用已有决策。
2. 识别用户、问题、期望结果、范围和约束。区分明确提出的需求与假设。检查仓库以确认事实；对于可能改变结果的产品决策，向用户询问缺失信息。
3. 按照下方结构编写要求。为每条要求分配稳定的 REQ-n ID。不得重复使用或重新编号已有 ID。
4. 检查要求是否相互一致、是否涵盖相关故障行为，以及是否可测试。记录尚未解决的决策，并说明这些问题是否会阻碍架构设计或交付。
5. 完成文档，供人工审核。不要设计实现方案、规划任务或编写代码。

文档结构

• 目的与用户： 问题是什么、哪些人遇到了该问题，以及他们需要什么结果。
• 用户旅程： 当多个功能需要衔接时，展示一条从问题到期望结果的真实路径。
• 依据与假设： 链接所提供的研究、反馈或支持该问题的现有行为。标明影响重大的假设以及验证方式。不得编造依据。
• 关键功能与范围： 主要功能、其价值以及明确排除的目标。
• 要求： 可观察的行为、业务规则、权限，以及用户可见的失败与恢复方式。必要时定义领域概念。
• 约束： 必须满足的兼容性、安全、隐私、运维和性能限制。已知时使用可衡量的阈值；未知目标应标记为待决事项。
• 验收： 系统功能的可观察条件。详细的功能场景和检查留给对应的规范。
• 成功指标： 有依据时，说明交付后如何衡量价值。将其与实现验收标准分开。
• 待决事项： 列出每个待确认的问题、理由充分时建议采用的默认选项，以及它对后续工作的影响。

只使用有助于定义产品的章节。合并相关内容，省略没有实际帮助的章节。

当产品、关键功能、范围或业务规则发生变化时，更新此文档。保持内容与现状一致；在规范中保留功能决策的历史记录。功能实现细节应放在规范中。

不要在要求中写入实现方案。只有被强制要求的技术，才能作为明确约束写入。不得编造用户研究、目标或业务规则。

返回内容

报告文档路径、已做出的决策，以及任何阻碍进展的问题。