从用户问题到验收标准：把“好用一点”写具体

朋友说：“这个知识库不太好用，给我加个收藏吧。”你马上开始写按钮，结果他真正想要的是快速找回上周读到一半的文章。收藏也许有用，但还没证明它就是合适的办法。本章先练习把模糊的话变成可以讨论、可以验证的需求。

1. 先问发生过什么

比起问“你要什么功能”，先请对方复述最近一次经历：当时想做什么，在哪里卡住，最后怎样解决。如果他说“我只能翻浏览器历史”，你就知道问题是找回文章。如果他说“我想把资料发给同学”，那可能需要分享，而不是私人收藏。

把事实与自己的猜测分开记录。事实是“上次找文章花了十分钟”；猜测是“收藏功能一定能解决”。随后用纸面草图或小原型检验猜测，不要先投入几天开发来证明自己最初的想法。

2. 用一句话保留使用目的

可以这样写：“作为已登录读者，我希望保存稍后阅读的文章，以便下次直接找回。”这类句子常叫用户故事，它帮助团队记住使用者、行为与目的。但一句话还不能代替完整讨论。

例如“下次”是同一个浏览器，还是另一台电脑？其他人能否看到？文章下线后，收藏列表显示什么？故事不需要塞满全部细节，却应链接到这些规则。否则开发者和验收者可能各自脑补出不同产品。

3. 用例子定义完成的样子

先从最普通的一次操作写起：小林已经登录，文章 A 已发布；点击收藏；刷新后 A 仍出现在自己的收藏列表。接着补重复点击、取消、无权限和网络失败。

Text复制
场景：重复保存同一篇文章
前提：小林已登录，文章 A 已在他的收藏中
操作：小林再次请求保存 A
结果：列表仍只有一条 A，接口返回已保存的结果

“前提、操作、结果”对应常见的 Given、When、Then 表达。它首先是沟通方式，不要求立刻安装自动化工具。结果应能被外部观察，例如列表条数，而不是“调用了内部 save 方法三次”。实现方式变了，用户承诺仍可能不变。

4. 正常流程之外还要写什么

下面这张表把容易遗漏的地方摆到台面上：

最后一行是一种产品选择，不是所有网站的通用标准。也可以决定隐藏失效收藏，只要与相关人员约定清楚，并保证不会因此绕过文章权限。

5. 把质量要求也变成可检查的句子

“响应要快”“系统要稳定”很难验收。可以先给出示例目标：“在约定的测试环境、100 个并发读者和 1 万条收藏数据下，收藏列表请求的 95% 在 500 毫秒内完成。”这些数字只是练习用，不是行业统一合格线；真正目标要依据用户期望、成本和测量边界协商。

描述性能时还要说明是否包含网络时间、如何采样、错误请求怎样统计。不然前端量到 1 秒，后端日志只有 100 毫秒，双方都可能以为对方错了。常把功能之外的性能、安全、可访问性等称为质量属性；它们同样影响功能是否可用。

6. 给需求一个能追踪的名字

把上面的规则编号为 FAV-01、FAV-02，测试和改动说明引用相同编号。以后“为什么要加唯一约束”就能追到重复保存的规则。这种对应关系叫可追踪性，简单表格就可以实现，不必先采购复杂工具。

练习与参考答案

改写“收藏列表要正常”。参考答案：“已登录且有三条有效收藏时，打开列表应看到三篇对应文章；取消其中一篇并刷新后只剩两篇；另一账号看不到这些记录。”比原句更长，但大家终于能用同一套动作判断结果。

阅读依据

• Cucumber：行为驱动开发
• Cucumber：Gherkin 参考