# 需求定义与验收

本规范用于把一个产品想法转成团队可以实现和验收的需求。它是通用起点；具体项目的用户研究、合规要求和业务规则仍以该项目的证据与约定为准。

## 先说明要解决的问题

每项需求至少写清：谁遇到了什么问题、问题出现在哪个场景、现在如何处理，以及改善后希望发生什么。将已观察到的事实、用户反馈和团队推测分开记录；没有证据的假设要标明待验证。

## 定义用户结果

用用户能够完成的任务描述目标，例如“用户可以查看某订单的退款进度”。避免只写“增加一个页面”“接入某接口”或“优化体验”。这些是可能的实现方式，不能替代用户结果。

为目标选择一个可观察的验证方式：任务完成情况、错误率、完成时间、人工验收，或当前阶段真正能够取得的其他证据。不要为了填指标而编造基线或承诺尚未测量的提升。

## 收紧范围

写出本次必须完成的主流程、必要的异常处理，以及明确延期的情形。范围变化要更新需求和验收条件，不能只在讨论中达成口头共识。依赖其他团队、外部服务或授权的事项应标明负责人和前置条件。

## 写可验证的验收条件

验收条件应描述输入、操作和可见结果，覆盖成功、失败、权限不足、空数据等与当前任务相关的状态。对有写入或外部副作用的操作，还要说明重复提交、处理中断和重试后的预期结果。

验收条件不要绑定无必要的布局细节或实现技术。界面体验另参照 [界面基础规范](../../ui/foundations/interface-foundations.md)；涉及业务事实与权限时参照 [业务规则与数据边界](../../business/rules/business-rules-and-data.md)。

## 交付时核对

实现完成后，使用实际用户路径验证验收条件，并记录已完成、未完成和无法验证的部分。需求文档应反映当前产品行为；发现实现与原决策不同，要更新决策记录或明确留下待处理项。