第3章需求工程与需求分析

1第3章需求工程与需求分析第3章需求工程与需求分析23.1基本的软件需求第3章需求工程与需求分析3基本的软件需求软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。第3章需求工程与需求分析4基本的软件需求在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。第3章需求工程与需求分析53.1.1软件需求的定义⑴用户解决问题或达到目标所需的条件或权能（Capability）。⑵系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。⑶一种反映上面⑴或⑵所描述的条件或权能的文档说明。第3章需求工程与需求分析63.1.1软件需求的定义1.一些关于“需求”的解释需求的关键的问题是一定要编写需求文档。如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺欺人。许多的需求分析专家给出了不同形式的需求定义，但从这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence1998）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。第3章需求工程与需求分析73.1.1软件需求的定义2．需求的层次下面这些定义是需求工程领域中常见术语的定义说明。软件需求包括三个不同的层次——业务需求、用户需求和功能需求（包括非功能需求）。⑴业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。⑵用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本（scenario）说明中予以说明。⑶功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。第3章需求工程与需求分析83.1.1软件需求的定义业务需求项目视图与范围文档用户需求使用实例文档质量属性系统需求功能需求其它非功能需求约束条件软件需求规格说明第3章需求工程与需求分析93.1.2需求的开发和管理需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作者把整个需求范围称之为“需求工程”，另一些则称之为“需求管理”。软件专家认为可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适：需求工程需求开发需求管理需求获取需求分析编写规格说明验证第3章需求工程与需求分析103.1.2需求的开发和管理需求开发可进一步分为：需求获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段。需求开发活动包括以下几个方面：⑴确定产品所期望的用户类。⑵获取每个用户类的需求。⑶了解实际用户任务和目标以及这些任务所支持的业务需求。⑷分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。第3章需求工程与需求分析113.1.2需求的开发和管理⑸将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。⑹了解相关质量属性的重要性。⑺商讨实施优先级的划分。⑻将所收集的用户需求编写成规格说明和模型。⑼评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。第3章需求工程与需求分析123.1.2需求的开发和管理需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI1995)。这种契约都包含在编写的需求规格说明与模型中。通常的需求管理活动包括：⑴定义需求基线（迅速制定需求文档的主体）。⑵评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。⑶以一种可控制的方式将需求变更融入到项目中。⑷使当前的项目计划与需求一致。⑸估计变更需求所产生影响并在此基础上协商新的承诺(约定)。⑹让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。⑺在整个项目过程中跟踪需求状态及其变更情况。第3章需求工程与需求分析133.1.2需求的开发和管理需求开发和需求管理之间的区别基准需求说明分析编写文档评审,商议需求市场客户管理需求变更过程需求开发需求管理当前基线修正后基线项目变更需求变更市场客户管理项目环境第3章需求工程与需求分析143.1.3需求工程的作用1．支持项目的开发。需求工程过程是软件开发阶段的前提和基础。2．支持测试和验证需求规格说明书将为项目测试和验证提供基准，可以用来检查设计和验证系统。3．支持维护维护阶段的工作同以下几个方面紧密联系：⑴修改在测试阶段中尚未检查出来的少量残留编码错误。⑵软件运行一段时间后，因环境因素的改变而产生的软件的适应性维护。⑶用户在软件交付使用后又重新提出扩充功能的需求时的软件维护。4．支持项目承包商需求的证实过程为拟构造系统的正确性提供了进一步的根据。5．支持管理为了保证项目的顺利进行，项目管理者必须有一个完备的项目计划，包括开销、交付日期、可用资源、交付条件等等。第3章需求工程与需求分析153.2需求获取第3章需求工程与需求分析163.2.1需求获取过程需求获取时期的主要工作：⑴归纳和整理用户提出的各种问题和要求；⑵弄清用户企图通过软件达到的目的；⑶借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。第3章需求工程与需求分析173.2.2需求获取方法需求获取方法包括两个方面：⑴指导开发小组获取用户需求的方法框架。⑵支持控制此项活动进展的过程控制机制。获取需求从用户处引导原始需求陈述反馈同意用户的需求陈述反复沟通图3.2.1需求获取方法第3章需求工程与需求分析183.2.3当前状况⑴误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了用户潜在的隐含假设。⑵交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。⑶缺乏共同语言：由于需求分析员和系统用户的经历和教育背景不同，他们之间通常缺乏足够的沟通。⑷“完整性”问题：软件工程师希望提出系统需求的用户领域专家能清晰、简明和完备地描述出确实可行的系统需求，然而，所要的需求知识在其最初阶段可能是模糊、不完备甚至是不正确的。⑸需求永远不会稳定：用户对软件的需求常常会发生变化，并且是不可预测的。⑹用户意见不统一：大系统往往有各种不同的用户，他们往往有互相冲突的需求和不同的需求优先次序，寻求折衷是不容易的。⑺错误的要求：系统的定购者（付钱的人）和系统的使用者经常不是一个人，定购者由于受到组织或经费的限制，提出的需求会与最终用户的需求相冲突。⑻认识混淆：有时系统的目标和系统的需求会发生混淆。目标是系统应达到的更为一般的特征，而需求应是可测试的。第3章需求工程与需求分析19解决问题的建议1.了解系统需求2.市场调查3.访问用户和用户领域专家4.考察现场第3章需求工程与需求分析20调查的方式1.调查提纲或调查表2.小型调查会议3.个别访问4.现场调查5.资料6.调查工具第3章需求工程与需求分析21调查中应注意的事项1.不要用计算机专业术语与用户或用户领域专家交谈2.不要使用“你应该…”这样的字眼3.始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息4.要善于把用户中职位高的人和职位低的人的谈话结合起来分析第3章需求工程与需求分析223.3需求分析任务第3章需求工程与需求分析233.3需求分析任务需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。第3章需求工程与需求分析243.3需求分析任务⑴正确地确定对系统综合要求，充分理解和表达用户的需求。也就是详细定义开发软件的功能、性能、外部接口、设计限制、数据库需求、确定硬件和软件支持环境、辅助软件以及将来可能提出的要求。⑵通过结构分析的方法对系统进行分解，以确定软件系统的主要成分或软件系统的构成。当前系统目标系统物理模型逻辑模型物理模型逻辑模型模型化抽象化具体化实例化导出理解需求表达需求图3.3.1参考当前系统建立目标系统第3章需求工程与需求分析253.3需求分析任务⑶是对以上已进行的两项工作进行描述，以形成需求文档，也就是编制“需求规格说明书”。它应明确地定义要开发软件的需求；系统的构成及有关接口。需求规格说明书的作用在于：①提供一个用户和开发者对开发软件的共同的理解；②相当于用户和开发单位之间的一份技术合同；③是今后各阶段设计的基本依据；④是今后验收测试阶段对软件进行确认和验收的基准。第3章需求工程与需求分析263.3需求分析任务⑷编写用户手册概要，迫使分析员从用户的角度看待软件，及早考虑用户界面工作，此时编写的重点在系统输入和输出。把整个软件系统分解为若干个子系统或软件成分(如软件包)，把整个软件的外部功能分配给软件系统的各功能成分，并详细地定义每个软件成分的外部功能以及它们间的接口。⑸编写验收计划，作为今后验收测试的依据。⑹修正可行性研究阶段所制订的软件项目开发计划。由于在需求分析过程中对将要开发的系统有了更深入的了解，所以可以更准确地估计开发成本、进度和资源需求。有必要对原计划作出适当修正。第3章需求工程与需求分析273.4需求分析过程第3章需求工程与需求分析283.4.1功能性需求功能性需求包括：1．功能需求例举出开发软件在职能上应做什么，这是最主要的需求。2．性能需求给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。3．环境需求软件系统运行时多所处的环境要求。4．可靠性需求各种软件在运行时，失败的影响各不相同，在需求分析时，应对所开发的软件在投入运行后不发生故障的概率，按实际的运行环境提出的要求。第3章需求工程与需求分析293.4.1功能性需求5．安全保密要求把软件运行的安全需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全保密方面的性能得到必要的保证。6．用户界面需求软件与用户界面的友好性是用户能够方便有效、愉快地使用该软件的关键之一。7．资源使用需求开发软件运行时所需的数据、软件、内存空间等各项资源。8．软件成本消耗与开发进度需求软件项目立项后，要根据合同规定，对软件开发的进度和各项步骤的费用提出要求，作为开发管理的依据。9．预先估计系统可能达到的目标在开发过程中可对系统将来可能的扩充与修改做准备。第3章需求工程与需求分析30【例1】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以下功能：⑴有四个按钮输入，分别称为B1，B2，B3和B4；⑵有两个灯泡作为输出，分别称为L1和L2；⑶B1是打开电源的按钮；⑷B4是关闭电源的按钮；⑸B2和B3是操作按钮；⑹在B1被按下后及B4被按下前，系统应称为电源打开状态；⑺在B4被按下后及B1被按下前，系统应称为电源关闭状态；⑻在电源关闭状态下，B2和B3按钮不起作用；⑼在电源关闭状态下，灯应不亮；⑽从最