需求文档checklist

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其中一个更新，存在互相矛盾不一致的地方