- 提出新需求时应以书面形式进行记录,由需求方盖章确认或我方领导签字;
- 对原有需求进行变更或删除时,必须以书面形式进行记录,由需求方盖章确认或我方领导签字;
- 需求描述只负责解释“要做什么”的问题,至于“如何去做”以及“能不能做得到”应该留给架构师单独分析;
- 书面形式的文档应复印分发给项目研发团队全体成员,人手一份,交叉检查需求描述是否出现模棱两可或自相矛盾的内容。如果开发人员发现需求文档中存在有歧义或含糊不清的描述,随时反馈给需求文档的编写者,间隔每1~2周汇总一次打印,及时将改进意见随副需求文档一起提交给项目经理去沟通解决;
![1458798-707de410b850f0f9.jpeg](https://i-blog.csdnimg.cn/blog_migrate/88a3b079225fa88e0f979955e5789c59.webp?x-image-process=image/format,png)
程序员陪同上级领导或甲方进行需求分析的过程中,必须时刻牢记以下4条法则:
- 提出新需求时应以书面形式进行记录归档,由需求方签字盖章确认;
- 对原有需求进行变更或删除时应以书面形式进行记录归档,由需求方签字盖章确认;
- 需求分析文档只负责解释要做什么,而非如何去做,也不需要分析能不能实现;
- 项目的研发团队要阅读上述需求文档,理解每条需求包含的内容。如果开发人员发现需求文档中存在有歧义或含糊不清的描述,应尽早反馈给需求文档的编写者进行修改(参照法则2)。如果没人理你,那么尝试自己细化补充测试用例以消除歧义;
对应功能性需求和性能需求,可分别制定可操作的功能测试方案和性能测试方案
例一:含糊不清的需求描述
- “设备必须快速启动”
建议改为“设备必须在10秒以内启动并进入能够处理数据的状态”
存在歧义的需求描述
- “支持手机设备与台式电脑联网进行游戏”
建议指明“联网”是连接家庭局域网即可进行游戏,还是必须连接互联网才能
例二:几个相互冲突的需求同时存在
- “设备必须能够存储1万条语音留言”
- “设备只能配备不超过64MB的闪存”
建议改为“由设备实际配备的闪存容量决定至少可以存储多少条语音留言”,例如需求文档中可以规定:
- 单条语音留言的时长上限不低于60秒
- 用户可以选择不同的录音质量(高清/标准)
然后根据音频每秒是多少KB,估算64MB闪存可以存储多少秒语音文件
![1458798-1698422a0c1fb0d9.jpg](https://i-blog.csdnimg.cn/blog_migrate/961f86385eceb7dfec10aad759f3ac86.webp?x-image-process=image/format,png)
图片发自简书App
![1458798-53b0ef024f65ac6a.jpg](https://i-blog.csdnimg.cn/blog_migrate/d7eeec5af0cb9741570d728858fda955.webp?x-image-process=image/format,png)
图片发自简书App