需求评审流程V1.0

肈产品需求评审膆(V1.0)一、二、螂产品需求评审的目的、目标、范围薀1、目的袇产品需求是软件开发最重要的一个输入，需求的质量很大程度上决定了项目质量或产品质量。并且需求风险常常是软件开发过程中最大的一个风险，要降低需求阶段带来的风险。而产品需求评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。芆膃2、目标1)2)节需求已经文档化并且完整地描述了产品需求期望；3)4)袀业务问题已经解决了；5)6)莅系统要求的性能价格比已经经过讨论研究并证实是合理的；7)8)薄已经明确了控制需求的方向（“控制”在这里的意思是包括所有的机制、方法及应用程序中用于保证其功能与期望相一致的过程。）；9)10)螀确定需求阶段所有解决问题的方法和途径是有效和正确的。虿蒅3、范围1)2)羅对需求规格说明的正确性进行评审3)4)蒂对需求规格说明的实践性进行评审5)6)蒈对需求规格说明的完整性进行评审7)8)薅对需求方案的可行性和成本预算进行评审9)10)膂对需求的质量属性进行评审11)12)袀对需求的可实施性进行评审13)14)膇对需求包含的用例文档进行评审15)16)薅需求评审会的过程和结束标准薃三、四、蚂具体执行操作流程芀测试负责人管理层开发负责人需求负责人开始需求设想合理性评定完成NONO需求评审流程图需求评审筹划YES可行性评定评审表需求修改YES需求评审修改需求说明书YES项目筹划NO五、六、蚅具体角色及职责关系羄准备阶段（P）聿需求负责人：争取上层决策者的支持与谅解，在正式评审之前，将相关的需求记录（文档或其他形式）发布给每个参与评审的人员手中。收集相关评审人员的各项需求评审建议和意见，对存在争议和疑惑的需求说明必须做好讨论的安排。罿管理层：筹备相关的资源，包括人力、时间计划，评审场地。螅开发负责人、测试负责人：做好评审前的相关质疑与确认记录。莄实施阶段（D）1)2)螁与会人就某具体的问题进行讨论，讨论的优先级如下所列螇最重要的业务内容，一般是按流程、功能、细节来排定袅争议或疑问较多的地方螅部分有争议的地方艿对于没有提出疑义的地方，可以快速流过3)4)螀最后，要注意一定要回顾已提出问题和有结论的地方5)6)羅由需求负责人整理会议的纲要，记录各与会人员的相关意见，并在会后递交纪要袂检查再实施阶段（C）1)2)羁需求负责人：对评审得出结论的问题进行再次确认和修正补充并确定下次评审的时间3)4)蕿按照第一阶段的流程再次进行组织，并确认结果肄总结阶段（A）1)2)芃就以上内容做最后的确认，需求定稿，各方签字确认。3)4)蚃今后的变更转入需求变更流程，其后产生的评审为小范围内评审。5)6)莈七、八、膄具体检查手段蚄在评审会议过程中，通过评审表（附录一）对需求说明书进行考核。膁九、十、肇报告反馈机制测试负责人管理层开发负责人需求负责人开始需求评审会议结束审核会议纪要评审上报流程图NO产品架构设计评审表修改需求并再次评审YES审核NO整理上报YES编制项目计划YESNO完成膄注：评审会议结束后，将会议纪要及评审表在一个工作日内交至上级审阅,阅后将会议纪要及评审表发放至各与会人员。肅袃膀芄附录一：节编号芁项目实际案例或说明评审结果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软件需求文档和用户需求文档是否有对应的跟踪关系全选和反选详细说明，反选是取反还是全部不选28是否有真实数据作为需求的输入29业务的业务操作流程是什么，页面使用频度是否可定义。30需求是否定义了哪些是应用现有的框架，哪些是全新实现的部分。31需求文档中使用的图表是否正确，是否更新。