条目化需求管理带来的瀑布式敏捷

•需求评审之• 版中，定义了5类评审审计（Audits）在CMM3/CMMI3中，同级评审（也 评审或者同级互•）是其要•传统的基于文档和文档评审的方法在2001年起的敏捷动中被视 繁琐、繁文缛需求评审的定观察软件运行与测试有部 ，但并不是测5大关键方面，分别是：1，组织2，时机；3，侧重；4，评审者；5，评审对象。组织形式分

需求评审组织形说 说结对评审双人在可全程实时口头交流的情况下，包括面对面、语音或，进行需求评审潜在的人际。

会议形式，参会人数多于2人，评审者在会前预审，作者和评审者在会议流探讨。优点：业界已经积累了许多评审流程[10]，会前会中会后都有相当成指导，各方交无预审的会议审

非即 评审的新情 非即 评审的例时时 说需求完稿后，关键各方参加评审，一旦通过，就进入下一阶段工作。

高频按需评按照需要，频繁的开展，比如针对指定功能的桌查，每天或每几天 需求评审的侧重分侧 说 需求评审的评审者分评审 说严格同级也称，这样的评审不直接影响作者和评审者，可以让作者无作者上评审者中没有作者的上级，评审者之间可能存在上下级， CMMIfor DEVV1.3中没有采用严格同级来实施同级评审，只说明了由作者的同级或称同级人员来实施同级评审[23]，而在实践中不少的同级评审包括有作者的下级，含作者上评审者中包括作者的上级。评审表现可能被上级用于评价人员绩效。下 需求评审的对对 说档 各类需求文档，比如需求规格说明书，用例分析，用户故事等等，在CMMI，工产是适地现规的确“确做。优点：能够较早的开缺点：不够直观，尤其难以判断交互 优点：直观展现实现的需求，可以更好的判断需求，尤其是交互易用性缺点：得到可运行软常见情组织常见情组织式评审严格同级、同级（评审者不含上级），常见需求评审情情况情况情况情况情况常见称需求里程碑会需求分评需求结需求分段同级互需求管组织形有预审的会非即结对即非即有预审的会时里程完定分里程侧技技技管评审含上同同同含上对需求文需求文需求文需求文需求文标准评

瀑布模型下需求评需求评审框架分析说 需求里程碑评 有预审的会议形式，里程碑，技术和管理方面，非同级需求文档评 分段需求同级评 有预审的会议形式，分段，技术方面，同级需求文档评CMMI给需求评审带来的变新需求评审框架对传统瀑布模型的启 IEEE标准需求评标准评 需求评审框架分析说 技术评 有预审的会议形式，里程碑，技术方面，非同级需求文档评有预审的会议形式，完稿，技术方面，同级需求文档评走 有预审的双人或者会议，定期或者高频，技术方面，同级需求文档评敏捷开发下常见需求评审相关实践情 Scrum中产品待办列表细无预审的会议，定期，技术方面，同级需求文档评审Scrum中计划会议第一部无预审的会议，定期的里程碑，管理方面，同级需求文档评审Scrum每日站会和燃尽图无预审的会议，每日高频，管理方面，同级需求文档评审 敏捷带来的启示敏捷带来的启示 需求条目化管理下的需求评有些工具中条目称为工作项(workitem)1，状态流转实现工作流2，条目属性字段可定全程的需 评需求条目的流程定需求条目流程关键点的评状态流 关键点的评从草稿到已分析需求分析人员内部评审（比如同级互查），通过后状态流转到“已分析”，显从已分析到已评审由对产品需求负责的人员担当，常见有产品经理、项目经理或者产品，如果工具有并行功能，可让多人参与此，这相当于需求里程碑评审的从已评审到已设计由开发人员需求得到设计的覆盖，这仍然是基于文档的现由从已实现到已核 由需求分析人员来验证实现是否符合当初的需求，这是基于软件运行的评审从已核对到已测试由测试人员根据测试来校对需求是否得到正确实现，这也是基于软件运行的评审，这里与测试有所，但这里是对需求本身的，与测试对于测试用例的执行是不一样的，当然可以根据需求对应测试用例的执行结果来需求。需求测试缺陷双向追条目话管理下的需