概述
| 1 | 输入：是否所有输入都有约束描述，包括输入框、日期控件等控件，需要统一的输入校验规则和提示规范 | 需求没有写明约束，导致前端或后端开发的时候要不就是完全没做约束，要不就是前后端约束不一致，测试同学也根据自己的理解验证约束。 | |
| 2 | 输出：每项操作的输出内容格式内容清楚 | ||
| 3 | 权限定义：哪些操作由谁来执行，明确清晰 | ||
| 4 | 是否用用户语言,站在用户角度上来写需求？用户这样认为吗？ | 因为和用户需求不一致引起的需求变更过多，会导致开发延期，影响产品上线质量。 | |
| 5 | 是否所有的需求都避免与其它的需求发生冲突？ | ||
| 6 | 是否所有的需求都是名副其实的需求而不是设计或实现方案， 需求是否足够清晰，以至可以转交给一个独立小组来实现，并能够被理解？ | 需求如果不够清晰，需要反复询问才能理解，沟通成本增加，而且在不同项目成员间容易引起理解不一致。 比如如果新同学来了开始一个项目，还需要先去理解其他项目的需求才能看明白这个项目的需求，那么成本会很高。 | |
| 7 | 如果有错误输入或错误操作，响应是什么 | 目前基本是开发自己定义，不一定符合实际需求 | |
| 8 | 功能需求是否覆盖了所有非正式情况的处理，除了主流程，对所有分支流程同样有清晰描述 | ||
| 9 | 消息：哪些地方有消息，谁能收到，消息内容有清晰描述 | ||
| 10 | 待办：哪些地方有待办，谁能收到，待办内容有清晰描述 | ||
| 11 | 流转日志：日志需要记录的内容有清晰描述 | ||
| 12 | 是否每个需求都具有惟一性并且可以正确地识别它，是否每一个需求都只有一种解释 | ||
| 13 | 需求变更：是否都有记录并知会所有相关人 | ||
| 14 | 本项目数据统计需求需要说明，方便提前设计 | ||
| 15 | 运营查询需求需要说明 | 目前都是临时需要加的 | |
| 16 | 对第三方下游用户的影响，需要说明 | ||
| 17 | 前端需求：支持浏览器版本和种类,分辨率 | ||
| 18 | 提供有交互稿或是（完整详细流程图） | ||
| 19 | UED图有相关标注规范（颜色，边距） | ||
| 20 | PRD，UED图等需求设计文档统一放置在项目文件管理服务器上 | ||
| 21 | UED图输出格式为HTML格式 | ||
| 22 | 需求UED设计是否与现有规范冲突（统一设计风格） | ||
| 23 | 相关接口设计符合规范（是否存在相关接口规范，尽量避免前端二次计算和转化） | ||
| 24 | PRD和UED更新一致 | 很多时候只有PRD和UED其中一个更新，存在互相矛盾不一致的地方 |
最后
以上就是霸气煎饼为你收集整理的需求文档checklist的全部内容，希望文章能够帮你解决需求文档checklist所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复