一份需求文档被开发退回4次，理由依次是：逻辑不清、边界没写、异常没处理、验收标准缺失。补上6项后，第5版一次通过。
第1项：正常流程写步骤。用编号列主流程，5到8步，每步写清输入、操作、输出。避免「用户登录后进入首页」这种一句话带过，登录失败怎么办、首页加载多久，都要有说法。
第2项：异常情况列清单。至少列5类：网络失败、数据为空、权限不足、并发冲突、超时。每类写清系统怎么提示、用户能做什么。开发最怕的是「这个情况没说过」。
第3项：边界条件给数字。输入框限多少字、列表一页多少条、文件最大多少兆、超时多少秒。写「合理限制」等于没写，给具体数字，比如「标题最多30字，超出截断并提示」。
第4项：权限写清角色。哪些角色能看到、能编辑、能删除，用表格列，3列5行。常见错误是只写「管理员可操作」，其他角色怎么办，没写。
第5项：验收标准可测。不写「体验流畅」，写「首页加载不超过2秒」「提交后3秒内出结果」。每条标准能被测试人员直接验证，否则验收时扯皮。
第6项：变更记录留痕。每次修改写清：改了什么、为什么改、谁确认的、日期。4次退回的经历里，有2次是改了A处、漏了关联的B处，有记录就能对照。
常见错误：图和文字对不上。原型图改了3版，文档还是第1版描述，开发和设计各按各的理解做。定稿前对一遍图和文。
一个细节：文档开头放一页「一图看懂」，用流程图加5行说明，把主流程和关键规则画出来。开发和测试先看这一页，能少问一半问题。
需求文档不是写给自己看的，是写给要动手做的人看的。6项补齐，退回次数会明显下降。
