requirements

要求

编写关于结果和可观察行为的要求。明确保留用户的选择；不要擅自换成你偏好的解决方案。

工作

• 从简报或运行中的产品中提取用户目标、触发事件、允许执行操作的参与者、输入、结果和失败行为。
• 仅在有助于追溯时为要求分配稳定 ID。优先采用“编辑者可以重命名项目；查看者不可以”，避免法律条文式的空话。
• 对每项写入操作，明确服务器授权、验证、持久化、重复提交行为，以及超时后结果未知时的处理方式。
• 根据适用情况，注明质量约束及其条件：目标设备、输入方式、内容大小、延迟测量方式、支持的语言、隐私和可用性。将拟议目标标记为提案。
• 列出依赖项、尚未解决的契约问题和不在范围内的内容。不要臆造 API，也不要暗示它们已经存在。
• 重新审视实现时，根据证据报告哪些要求已满足、已更改、未满足或尚未验证。

交付

采用 要求 → 验收示例 → 依赖项/未知事项。示例只需足以区分正确行为与看似合理的实现。

按以下格式编写每项要求：

FR-01: [参与者 + 行为]。验收：[可观察的示例]。依赖项/未知事项：[...]

NFR-01: [约束 + 条件]。验证：[限定范围的检查]

结尾注明范围外事项、假设、待解问题和下一步。

为重要行为添加失败或边界案例。“无障碍”“快速”和“安全”都需要明确范围的验证标准。当分支顺序尚未确定时，使用 $flow；当需要为可复用交互制定契约时，使用 $component。

示例

FR-01: 编辑者可以重命名项目；查看者不可以。验收：查看者直接提交重命名请求时，服务器会拒绝，且存储的名称保持不变。依赖项：每个组织的角色数据。 FR-02: 重命名操作超时后，不会重复生效。验收：超时后重新提交，最终只存储一个名称，并且只有一条审计记录。未知事项：API 是否支持幂等键。 FR-03: 项目列表会将状态筛选条件保留在 URL 中。验收：打开复制的链接时，会显示相同的筛选列表。依赖项：无。 NFR-01: 只用键盘也能完成重命名。验证：不使用指针即可完成重命名；焦点会返回项目名称。 NFR-02（拟议，尚未达成一致）：在使用限速移动网络配置的客户端现场手机上，项目列表应在 2 s 内显示可用内容。验证：客户端确认目标设备后，在该设备配置上测量。 范围外：批量重命名、重命名历史视图。 假设：项目名称在每个组织内唯一。 待解问题：编辑者重命名项目时，已打开该项目的查看者会看到什么。 下一步：使用 $flow 梳理重命名路径，包括两名编辑者同时重命名的情况。

注意事项

• 仅验证权限检查是否隐藏按钮，会让允许任何人调用 API 的构建通过；应加入直接请求的测试案例。
• 写入操作还可能以第三种方式失败：服务器已保存，但请求超时。因此，重要写入操作需要明确重试要求。
• 直接在要求中指定组件（“添加一个下拉菜单”）会在设计开始前锁定解决方案。
• 没有条件和检查标准的“快速”“安全”和“无障碍”无法通过测试判定。
• 写入要求的端点名称会被视为现有契约；将未记录的 API 列为未知事项。

范围边界

• 如果想法仍然模糊（面向谁、要实现什么结果），请勿使用；改用 $intent。
• 如果待解问题是导航或页面构成，请勿使用；改用 $sitemap。
• 如果要梳理任务的逐步路径，请勿使用；改用 $flow。