第3章需求工程与需求分析全解.ppt

第3章 需求工程与需求分析 3.1 基本的软件需求 基本的软件需求 软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。 基本的软件需求 在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。 3.1.1 软件需求的定义 ⑴ 用户解决问题或达到目标所需的条件或权能（Capability）。 ⑵ 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 ⑶ 一种反映上面⑴或⑵所描述的条件或权能的文档说明。 3.1.1 软件需求的定义 1. 一些关于“需求”的解释 需求的关键的问题是一定要编写需求文档。 如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺欺人。 许多的需求分析专家给出了不同形式的需求定义，但从这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence 1998）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。 3.1.1 软件需求的定义 2．需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。 软件需求包括三个不同的层次——业务需求、用户需求和功能需求（包括非功能需求）。 ⑴ 业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 ⑵ 用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。 ⑶ 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。 3.1.1 软件需求的定义 3.1.2 需求的开发和管理 需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作者把整个需求范围称之为“需求工程”，另一些则称之为“需求管理”。 软件专家认为可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适： 3.1.2 需求的开发和管理 需求开发可进一步分为：需求获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段。 需求开发活动包括以下几个方面： ⑴ 确定产品所期望的用户类。 ⑵ 获取每个用户类的需求。 ⑶了解实际用户任务和目标以及这些任务所支持的业务需求。 ⑷ 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 3.1.2 需求的开发和管理 ⑸ 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 ⑹ 了解相关质量属性的重要性。 ⑺ 商讨实施优先级的划分。 ⑻ 将所收集的用户需求编写成规格说明和模型。 ⑼ 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 3.1.2 需求的开发和管理 需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI 1995)。这种契约都包含在编写的需求规格说明与模型中。 通常的需求管理活动包括： ⑴ 定义需求基线（迅速制定需求文档的主体）。 ⑵ 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 ⑶ 以一种可控制的方式将需求变更融入到项目中。 ⑷ 使当前的项目计划与需求一致。 ⑸ 估计变更需求所产生影响并在此基础