需求评审流程V1.0

产品需求评审(V1.0)产品需求评审的目的、目标、范围1、目的产品需求是软件开发最重要的一个输入，需求的质量很大程度上决定了项目质量或产品质量。并且需求风险常常是软件开发过程中最大的一个风险，要降低需求阶段带来的风险。而产品需求评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。2、目标需求已经文档化并且完整地描述了产品需求期望；业务问题已经解决了；系统要求的性能价格比已经经过讨论研究并证实是合理的；已经明确了控制需求的方向（“控制”在这里的意思是包括所有的机制、方法及应用程序中用于保证其功能与期望相一致的过程。）；确定需求阶段所有解决问题的方法和途径是有效和正确的。3、范围对需求规格说明的正确性进行评审对需求规格说明的实践性进行评审对需求规格说明的完整性进行评审对需求方案的可行性和成本预算进行评审对需求的质量属性进行评审对需求的可实施性进行评审对需求包含的用例文档进行评审需求评审会的过程和结束标准具体执行操作流程具体角色及职责关系准备阶段（P）需求负责人：争取上层决策者的支持与谅解，在正式评审之前，将相关的需求记录（文档或其他形式）发布给每个参与评审的人员手中。收集相关评审人员的各项需求评审建议和意见，对存在争议和疑惑的需求说明必须做好讨论的安排。管理层：筹备相关的资源，包括人力、时间计划，评审场地。开发负责人、测试负责人：做好评审前的相关质疑与确认记录。实施阶段（D）与会人就某具体的问题进行讨论，讨论的优先级如下所列最重要的业务内容，一般是按流程、功能、细节来排定争议或疑问较多的地方部分有争议的地方对于没有提出疑义的地方，可以快速流过最后，要注意一定要回顾已提出问题和有结论的地方由需求负责人整理会议的纲要，记录各与会人员的相关意见，并在会后递交纪要检查再实施阶段（C）需求负责人：对评审得出结论的问题进行再次确认和修正补充并确定下次评审的时间按照第一阶段的流程再次进行组织，并确认结果总结阶段（A）就以上内容做最后的确认，需求定稿，各方签字确认。今后的变更转入需求变更流程，其后产生的评审为小范围内评审。具体检查手段在评审会议过程中，通过评审表（附录一）对需求说明书进行考核。报告反馈机制注：评审会议结束后，将会议纪要及评审表在一个工作日内交至上级审阅,阅后将会议纪要及评审表发放至各与会人员。附录一：编号项目实际案例或说明评审结果1与需求相关的数据定义数据流向，可以有数据流图2功能需求是否覆盖了所有的异常情况的处理对涉及到流程类的操作进行头脑风暴，画出流程图，找出所有的异常情况3是否标识了将来可能变化的需求可扩展性的考虑或是可维护性。测试中需要注意和跟踪的地方。4是否说明了系统输入的来源输入的数据是什么样的5是否说明了系统输入输出的类型输入输出等价类的划分6是否说明了系统输入输出的值域，单位，格式7是否说明了系统输入，输出的精度有效位数8是否说明了如何进行系统输入合法性的验证输入合法性的验证。9时间因素时间精度，跨度，使用的时间控件的情况。10需求项的编号，需求唯一，并可标识需求管理和跟踪11与需求相关的维护性系统上线后是怎么被维护的？维护的工作量是怎样的，由谁来维护，维护的频度是多大的。12需求定义系统的外部接口与内部接口划定测试范围，模块集成测试的依据。从不同的入口准备数据。13需求之间是否有冲突和矛盾14是否对每个需求给出设计理由，理由是否充分。比如，按id倒序排序，为什么要按id，为什么要倒序排序，按别的是不是更好？15是否冗余同一个需求被定义多次16系统应用的环境，如浏览器，应用语言，分辨率等等。17需求形式化语言的运用对于数学公式的描述，或是复杂流程，尽量用形式化语言进行描述。18需求是否可以验证需求的可测试性，是否需要开发打上logo。19对于异常数据产生的结果是否有描述垃圾数据的处理20所有页面控件的默认状态是否明确的标明21是否有关于权限控制的说明22对于提示信息的文案说明是否有详细的描述23Demo列表，demo是否加入了版本控制24是否对界面需求有所描述25需求中是否包含模糊性词语举例，如：依需要，顺利完成，正确完成，可以，可能，等等26需求描述中应有优先级别和重要程度的描述27

软件需求文档和用户需求文档是否有对应的跟踪关系全选和反选详细说明，反选是取反还是全部不选2