软件需求工程20110418.pptVIP

* 收集需求 客户需求可能已经定义好，并提供给了软件项目组 如果在软件项目开始之前没有定义好需求，那么确定需求就变成了首要的工作 识别需求的不同技巧： 面谈 原型设计 会议 需求必须写在“需求规范”文档中 定义客户需求 * 客户需求的评审 必须评审需求规范，并确保： 是充分定义的 是没有歧义的 评审人员包括： 项目经理 开发人员 SCM人员 SQA人员 客户 将需求定义为基线 * 需求的关键特征 完整性 对软件设计来说是十分重要的 如果没有必须的信息，就无法正确地实现需求 可测试性 直接影响对系统的验收 验收测试的方法依靠： 需求的类型 依据客户需求，其他需求特征能否被充分的描述 正确性 如果需求不正确，软件就无法按照客户的需求去开发 将需求定义为基线 * 客户需求的批准 必须有书面的签字 要么在专门的地方签字，要么在“产品审批表”上签字 被批准的客户需求规范应置于配置管理之下 这就建立了客户需求的基线 将需求定义为基线 * 需求的可追溯性 需求最终必须能够从系统级追溯到每一行代码 追溯可通过以下两种途径： 需求---设计---编码 需求---测试计划---测试结果 在产品的开发过程中，开发人员必须保持需求的可追溯性 项目必须能够证明： 实施了所有客户需求 满足了所有客户需求 建立追溯 * 三、基线变更控制 目标 确定变更的批准人和实施人 保持配置的稳定性和一致性 确保变更控制的有效性 定义变更控制批准人 控制变更 管理问题报告 * 五、 评审、批准和发布 目标： 确保置于配置控制之下的配置项满足质量要求 发布和使用之前确保基线的一致性 保证基线的发布是受控的 质量检查点 配置审计 基线发布 * 审计基线 在每次重要发布之前实施配置审计，检查软件的一致性 在SCMP中详细描述审计的实施步骤和审计的时间安排 参与审计人员： 不能是被审对象 有相关技术资格 配置审计 * 配置审计是质量检查点的补充 审计应该识别： 所有经批准的变更并入基线 相关项已得到更新 没有未经批准的变更并入基线 制定了适当的状态统计条目 每项新的变更项完成了质量检查 可交付项与软件需求和设计相符 实行了评审（审查）并核查，发布的基线满足了客户的详细需求 所有的软件问题已经由变更授权批准人评审过了 已经准备了一份版本描述文档 配置审计 * 功能性需求 简单理解： 功能性需求指明了产品必须做的事情。例如：“产品将确定通过区域的哪些路段预计会结冰。” 它描述了一个产品必须执行的动作，如果产品要完成期望的工作，就必须执行该动作。 * 功能性需求 归纳总结： 功能性需求是： 产品功能的规格说明； 产品必须执行的动作---检查、计算、记录、取回数据等等； 源自于产品的基本目标； 不是质量要求---例如：“快速”是质量要求，因此它是一项非功能的需求。 需求规格说明将成为构建产品的合同。因此功能性需求必须完整地描述期望的产品能够执行的动作。所以对需求规格说明的一个要求是，产品的开发者能使用它来构建客户所期望的产品。 * 非功能性需求 非功能性需求是产品必须具备的属性。这些属性可以看作是一些特征或属性，他们使产品有吸引力、易用、快速或可靠。例如：用户可能希望产品在指定的时间内做出响应，或者在计算时达到指定的精度。 这些属性的存在并不是因为它们是产品的基本活动---诸如计算、操作数据等等活动---而是因为用户希望这些功能性活动以某种方式表现或者执行。 非功能性需求并不改变产品的功能。也就是说，不管增加多少属性，功能性需求会保持不变。 非功能性需求增加了产品的功能---它增加了一些处理，使产品更易于使用、更安全或者交互性更强。但是让这种功能性成为产品一部分的原因是为了让它具有期望的特征，所以我们可以把功能性需求看作是那些完成工作的需求，而非功能性需求是为工作赋予特征的。 * 非功能性需求 八类主要的非功能性需求： 观感需求---产品的外观精神实质。 易用性需求---产品的易用程度，以及特殊使用性考虑； 性能需求---功能的实现必须多快、多可靠、能处理多少处理量、多精确； 可操作性需求---产品的操作环境，以及对该操作环境必须考虑的问题； 可维护性和可移植性需求---期望的改变，以及完成改变允许的时间； 安全性需求---产品的安全保密性； 文化和政策需求---由产品的开发者和使用者所带来的特别需求。 法律需求---哪些法律和标准适用于该产品。 * 对用户重要的属性-4 完整性（或安全性）主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。 例如：“只有拥有查账员访问特权的用户才可以查看客户交易历史。” * 对用户重要的属性-5 互操作性表明了产品与其它系统交换数据和服务的难易程度。 例如：“化学制品跟踪系统应该能够从 C h e m i D r