第15章--需求确认.pptVIP

第15章 需 求 确 认 需求确认是需求开发过程的第4个阶段，前3个阶段分别为需求获取、需求分析和编写需求规格说明(Abran和Moore 2001)。 需求确认活动应力图确保以下几点： 软件需求规格说明正确描述了预期的满足各方涉众需要的系统能力和特征。 从系统需求、业务规则或其他来源中正确地推导出软件需求。 需求是完整的和高质量的。 需求的表示在所有地方都是一致的。 需求为继续进行产品设计和构造提供充分的基础。 15.1 需 求 评 审 需求文档的评审是一项功能很强的技术，通过它可以发现具有二义性的或无法验证的需求、那些定义不够明确而无法开始设计的需求以及其他问题。 非正式评审方法包括： 同级桌面检查(peer deskcheck) 轮查(passaround) 走查(walkthrough) 正式评审会生成一份报告，报告中指明具体材料、评审人员以及评审团队认为产品是否可以接受，主要提交对发现的错误和提出的问题的总结。 15.1.1 审查过程 审查是一个定义明确的分多个阶段完成的过程，由一小组受过培训的参与者完成，他们仔细检查工作产品的缺陷和是否可能对其进行改进。 文档必须通过审查这一质量关卡后，才能被纳入基线。 1. 参与者 审查参与者应该代表4种人的观点(Wiegers 2002a)： 工作产品的作者，也可能是作者的同级伙伴 先前所有的其中有条目正在接受审查的工作产品或规格说明的作者 需要根据正在接受审查的条目来开展工作的人 负责工作产品与正在接受审查的条目的接口工作的人 15.1.1 审查过程 2. 审查中每个成员所扮演的角色 作者(author) 作者创建或维护正在接受审查的工作产品。 仲裁者(moderator) 仲裁者，或者说审查组长(inspection leader)，负责与作者一起制定审查计划，协调审查活动，并且促成审查会议的召开。 读者(reader) 要由一名审查员来担当读者的角色。 记录员(recorder) 记录员，或者叫抄写员(scribe)，负责用标准化的形式对审查会中提出的问题和发现的缺陷进行记录编档。 15.1.1 审查过程 3. 审查的开始标准 审查的开始标准为作者清楚地设定了在审查准备期间应该遵循的标准。 下面列出了一些对需求文档开始审查的建议标准： 文档遵循标准模板。 文档已经进行过拼写检查。 作者已经检查了文档在版面布局上所存在的错误。 已经获得了审查员检查文档所需要的先前文档或参考文档。 在文档中标上了行序号，这样可以便于在审查会上对特定位置的内容进行查阅。 所有未解决的问题都要标记为TBD(待确定)。 仲裁者对具有代表性的需求范例检查10分钟后，找不出3个以上的重大缺陷。 15.1.1 审查过程 4. 审查阶段 审查过程需要分多个步骤来完成 如图15.2所示。 根据下面几个因素来调整审查速度： 审查小组以前的审查数据。 每一页的文字量。 规格说明的复杂性。 仍有错误未被检测出来对项目会有多大的风险。 待审查的材料对项目成 功的重要程度。 软件需求规格说明编写人员的经验水平。 15.1.1 审查过程 5. 审查的结束标准 在仲裁者宣布审查结束之前，审查过程应该定义结束审查必须满足的标准。下面列出一些对需求文档结束审查的标准： 审查期间审查员提出的所有问题都已解决。 文档中和相关的工作产品中的所有更改都已正确完成。 修订过的文档已经进行了拼写检查。 所有标识为TBD(待确定)的问题已经全部解决，或者已经对每个待确定问题的解决过程、计划解决的目标日期和由谁来解决等编制了文档。 文档已经在项目的配置管理系统中作了登记。 15.1.1 审查过程 6. 缺陷检查清单 为了帮助审查员查找出待审查产品中存在的典型的错误类型，应该为公司创建的每一类需求文档开发一个缺陷检查清单。 这些检查清单提醒审查员应该关注过去频繁出现的需求问题。 图15.5展示了审查软件需求规格说明所用的检查清单。 组织和完整性 正确性 质量属性 可跟踪性 特殊问题 15.1.2 需求评审面临的困难 下面列出软件组织评审其需求文档时必须面对的一些常见困难，并提供了解决方案(Wiegers 1998a，Wiegers 2002a)。 见长的需求文档 找出风险高的地方，并进行仔细审查，而风险较小的部分则可以采用非正式评审。 庞大的审查小组 尝试用以下的方法处理庞大的审查小组： 确保每个参与者都是为了查找缺陷。 理解每一位审查员所代表的观点，并且委婉地拒绝具有相同的观点的多个人都参与审查。 把审查组分成若干小组并行地审查软件需求规格说明，发现的缺陷