谈需求

1. 提出新需求时应以书面形式进行记录，由需求方盖章确认或我方领导签字；
2. 对原有需求进行变更或删除时，必须以书面形式进行记录，由需求方盖章确认或我方领导签字；
3. 需求描述只负责解释“要做什么”的问题，至于“如何去做”以及“能不能做得到”应该留给架构师单独分析；
4. 书面形式的文档应复印分发给项目研发团队全体成员，人手一份，交叉检查需求描述是否出现模棱两可或自相矛盾的内容。如果开发人员发现需求文档中存在有歧义或含糊不清的描述，随时反馈给需求文档的编写者，间隔每1～2周汇总一次打印，及时将改进意见随副需求文档一起提交给项目经理去沟通解决；

程序员陪同上级领导或甲方进行需求分析的过程中，必须时刻牢记以下4条法则：

1. 提出新需求时应以书面形式进行记录归档，由需求方签字盖章确认；

• 对原有需求进行变更或删除时应以书面形式进行记录归档，由需求方签字盖章确认；
• 需求分析文档只负责解释要做什么，而非如何去做，也不需要分析能不能实现；
• 项目的研发团队要阅读上述需求文档，理解每条需求包含的内容。如果开发人员发现需求文档中存在有歧义或含糊不清的描述，应尽早反馈给需求文档的编写者进行修改（参照法则2）。如果没人理你，那么尝试自己细化补充测试用例以消除歧义；

对应功能性需求和性能需求，可分别制定可操作的功能测试方案和性能测试方案

例一：含糊不清的需求描述

• “设备必须快速启动”

建议改为“设备必须在10秒以内启动并进入能够处理数据的状态”

存在歧义的需求描述

• “支持手机设备与台式电脑联网进行游戏”

建议指明“联网”是连接家庭局域网即可进行游戏，还是必须连接互联网才能

例二：几个相互冲突的需求同时存在

• “设备必须能够存储1万条语音留言”
• “设备只能配备不超过64MB的闪存”

建议改为“由设备实际配备的闪存容量决定至少可以存储多少条语音留言”，例如需求文档中可以规定：

• 单条语音留言的时长上限不低于60秒
• 用户可以选择不同的录音质量（高清/标准）

然后根据音频每秒是多少KB，估算64MB闪存可以存储多少秒语音文件

图片发自简书App

图片发自简书App