答案

业务分析师应为每个需求正式化验收标准（acceptance criteria），使其对项目所有参与者，包括客户、开发人员和测试人员，清晰且明确。为此，应用了规范化技术，比如使用Gherkin（Given-When-Then）符号的标准表述、检查清单和使用案例（use cases）。分析师将标准记录在需求文档中，并确保每个需求都有一组客观条件，通过这些条件可以明确确认任务的完成。

关键特点：

• 使用商业和技术术语清晰、可测量地表述标准。
• 在开发开始前，客户需参与确认标准。
• 将标准包含在用户故事、规范和测试用例中。

误导性问题。

可以仅使用用户故事来描述需求，而不需要额外的验收标准吗？

不可以，仅有用户故事没有明确的验收标准太过于抽象，可能会被不同解读。标准是理解需求是否正确实现的必要条件。

需要将非功能性需求（例如性能）包括在验收标准中吗？

是的，非功能性需求也应在标准中正式化，否则会存在被遗忘或未完全实现的风险。

验收标准应由谁批准：只有业务分析师吗？

不，可以，必须与客户及开发团队协商标准，以最大限度地减少误解。

常见错误与反模式

• 忽视与客户的标准协商。
• 将标准留给开发团队自行决定。
• 在工作开始后再晚些时候添加标准。

生活中的例子

负面案例： 业务分析师没有与客户确认验收标准，开发人员按自己的理解实现需求。 优点：快速开发，没用任何会议来拖延进程。 缺点：发布后70%的功能与真实期望不符，产生了冲突。

正面案例： 分析师详细列出了正式的验收标准，得到了双方的确认，并附在用户故事中。 优点：客户和团队之间的理解，发布后错误最少。 缺点：起初花费了更多时间进行确认。