「做完了，但不是我要的」——这个问题几乎都发生在需求阶段。 而且它通常不是因为对方不用心，是因为需求本身只写了功能名，没写使用场景。
功能清单缺了什么
一份典型的功能清单长这样：「订单管理、会员管理、库存查询、报表统计」。每一行都成立，但每一行都不够开发。
因为它只回答了「有哪些东西」，没回答「谁在什么情况下怎么用」。 而后者才是决定系统长什么样的东西。
五段式：把功能写成场景
同一条功能，换成这样的写法就清楚了：
- 角色：谁在用（店员 / 店长 / 总部运营 / 供应商）
- 触发：什么条件下进入这个流程（扫码、点击、定时任务）
- 动作：他要做什么（填什么、选什么、确认什么）
- 结果：系统怎么响应，数据变成什么（订单状态变了、库存扣了、通知发给谁）
- 异常：做不成时怎么办（库存不足、权限不够、网络断了）
一个例子
「库存查询」这四个字不够。「店员在顾客问到货时按商品名搜索，显示本店库存、邻店库存和建议调货门店；如果本店无货，允许一键发起调货申请」——这才够开发。
三个最常被漏掉的部分
权限： 谁能看、谁能改、谁能删。这一项不写清楚，开发会默认「都能看」，上线后再加权限就是重构。
边界： 数量上限、字符长度、文件大小、并发人数。不写这些，系统在小数据量时正常，一上量就崩。
异常： 所有人都只写正常流程，但系统真正的体验在异常路径上：提交失败怎么办、数据冲突怎么办、超时怎么办。
不需要写什么
- 技术实现：用什么框架、什么数据库，那是开发方的事
- 界面细节：按钮放左还是放右，那是设计阶段的事
- 未来的可能性：「以后可能要做多语言」——先不做，别写进本期范围
怎么验证需求写好了
找一个没参与讨论的同事，把需求文档给他读。 读完让他复述「这个系统是给谁做什么的」。如果他说得和你理解的一样，文档就合格了；如果他说不清楚，开发也一定不清楚。
最后
需求文档不是给开发看的任务单，是双方对「做完了」的共同定义。 写它的时间通常只占项目总时长的百分之几，但它决定了后面百分之九十的工作会不会白做。