《软件工程-理论、方法与实践》课件第4章

第4章需求工程4.1软件需求4.2需求工程过程4.3可行性研究4.4需求获取和分析4.5需求定义4.6需求验证4.7案例本章小结习题

4.1软件需求

IEEE给出了如下关于软件需求的定义：

(1)用户解决问题或达到目标所需的条件或能力。

(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。

(3)一种反映(1)或(2)所描述的条件或能力的说明。一般来说，站在不同的角度对需求的理解会有一定的偏差，客户方和开发者对需求概念的范围和定义的要求也会有所不同，IanSommerville根据需求文档服务的对象将需求分成两类：用户需求和系统需求。如果从系统应解决的问题和达到的目标来分，软件需求又可分为功能性需求、非功能性需求和业务需求。4.1.1用户需求和系统需求

软件开发过程中，需求需要以文档的形式被描述出来，文档化的需求既是开发者与用户之间沟通和达成协议的需要，也是开发人员进行后期软件设计、验证活动的基础。由于用户和开发者角色、知识背景以及期望目标的差别，仅一种需求描述形式难以兼顾各方的需要。因此可以将需求文档分为用户需求(UserRequirements)和系统需求(SystemRequirements)。

表4.1是一个示例，反映了用户需求和系统需求的区别。

4.1.2功能性需求和非功能性需求

从软件需求的定义就可以看出，任何软件系统都应具备一定的功能和服务，在提供服务的同时也需要遵守一定的限制，这就是功能性需求和非功能性需求的本质。

功能性需求反映了系统应该提供的功能(服务)，包括系统对特定输入行为的响应、系统的输出、异常处理等。表4.2是一个采用自然语言描述的银行ATM系统的功能性需求的示例，从该需求描述中，可以看出目标软件系统应具有的功能和行为。软件需求定义除了要建立软件系统应提供的功能外还应对系统的内在质量、特性、性能等方面作出明确的要求，非功能性需求即是关注软件系统这方面的需求。

非功能性需求是定义系统提供功能时所受到的约束和限制，例如响应时间的限制、开发过程的规范、法律法规的约束等。表4.3列出了非功能性需求的类型，主要分为三类：产品需求、过程需求和外部需求。从表4.3可以看出，软件的非功能性需求可理解，但验证却不容易，究竟怎样才是可用性好？效率高？直接度量这些非功能性需求往往较为困难，这会导致系统交付时难以验证，所以通常使用一些度量指标间接描述，以便系统开发和交付时确认系统是否符合相关的要求。表4.4列出了一些非功能性需求的度量指标。

4.2需求工程过程

需求工程过程活动是对需求的收集、分析、定义和验证的过程，主要包括可行性研究、需求获取和分析、需求定义和需求验证等，见图4.1。需求工程活动将产生有效的需求模型和需求文档，为以后的设计、测试、交付和维护提供支持。图4.1需求工程过程可行性研究活动将评估软件项目的风险，决策其是否可行，最终形成可行性报告；需求获取和分析则是收集、整理需求并建立需求模型的活动；需求定义则要形成正式的用户需求和系统需求文档；需求验证活动对形成需求文档进行评审，通过评审的文档正式成为需求定义文档。

IanSommerville则将需求工程过程划分成由三个阶段构成的迭代过程，即需求获取和分析、需求定义和需求验证。过程的早期，主要进行理解高层业务、非功能性需求和用户需求，后期活动则聚焦于系统需求和系统模型的定义。

结构化分析方法(SA)和面向对象的分析方法(OOA)是需求工程中常用的需求分析方法，它们各自拥有一套分析系统、构建图形化分析模型的方法和规则，用于描述系统的功能、行为及其他相关特性，如结构化方法中的数据流图、面向对象的Use-case模型和协作图等。本书将在面向对象的分析一章中详细讨论面向对象的分析和建模方法。

4.3可 行 性 研 究

可行性研究是每个需求工程过程最先开始的活动。一般来说，软件开发过程会受到时间、资金、软硬件、技术、人员等资源的一定限制，因此项目开始前需进行可行性研究，以降低项目的风险，最终将形成的可行性研究报告用于决定是否要开展进一步的需求工程和系统开发过程。可行性研究主要集中在经济可行性、技术可行性、法律可行性和方案决策几个部分。可行性研究阶段最终应形成可行性研究报告，并提交给项目管理部门进行评审。报告的主要内容包括：

(1)项目背景：问题描述、实现环境、限制条件等。

(2)管理说明与建议：重要的研究结果、说明、建议和影响。

(3)候选方案：候选系统的配置、选择最终方案的原则。

(4)系统描述：简略的范围描述、分配元素的可行性。

(5)经济可行性：成本-效益分析、经费概算、预期的经济效益。

(6)技术可行性：技术实力、已有工作基础、设备条件。

(7)法律可行性：系统开发可能导致的侵权、责任问题。

(8)用户使用可行性：用户单位的行政管理、工作制度、用户素质问题。

(9)其他与项目有关的问题：其他方案介绍、未来可能的变化。

4.4需求获取和分析

需求获取和分析活动要求软件开发人员和客户及最终用户共同找出应用域问题，包括系统应提供的服务、系统需要的性能、硬件和软件的限制等。软件开发机构的需求分析人员必须具有一定需求获取、需求建模、问题抽象与分解技术，这样方可有效地完成本阶段的任务。一般来说主要包含以下一些活动：

(1)应用问题理解：分析人员必须对系统应用领域进行充分理解。

(2)需求收集：与相关人员充分交流以发现需求。

(3)分类：对收集到的需求信息进行整理和归类。

(4)冲突避免：原始的需求信息之间不可避免地会存在冲突问题，活动致力于发现和解决冲突。

(5)优先级确立：分清需求的层次和重要性，据此确定需求的优先级。

(6)需求检验：对需求的完整性、一致性以及是否反映用户的真实期望进行检验。需求获取时可以将需求分成三种类型：

(1)必须满足的需求。

(2)期望有的需求但不是必须的。

(3)可能需要但可以去除的需求。

图4.2示意出需求可能的来源，可以以多种方式获得。图4.2需求来源需求获取的目的是通过一系列与用户的交流充分挖掘需求，获取用户对软件系统要求的第一手资料，并理解这些需求，得到什么是用户想要的。与系统需求有直接或间接关系的最终用户、事务管理人员、应用领域专家、系统开发人员都应参与需求获取和分析工作。需求获取可以通过评审当前的工作模式、与用户共同讨论、理解问题、通过已有的相关文档挖掘、制作系统工作的视频、观察相似系统、制作原型系统等方式展开。4.4.1用户交流

需求获取的主要途径是与用户充分地交流以获取需求相关信息，主要包括用户访谈、问卷调查、联合会议、用户业务观察、定期交流等活动。

用户访谈是需求获取不可缺少的活动，需求分析人员一般应预先准备一些问题，记录并整理用户对问题的回答，获取用户对目标软件的需求。表4.5列出了访谈应关注的问题和关键部分。4.4.2基于用例的需求获取

1．确定参与者

与ATM系统存在交互的参与者包括银行客户、ATM管理者、银行数据库系统。银行客户与ATM之间存在着服务请求和服务结果的反馈；ATM管理者需要借助与ATM的交互完成相应的管理活动，如加入现金、诊断系统等；ATM则在处理与用户的交易时与银行的数据库系统产生交互，包括验证用户、记录交易信息等。确定参与者还应区分主要的和次要的参与者。

2．确定用例

Jacobson建议通过提出如下的问题确定用例：

(1)参与者的目标是什么？

(2)系统事件开始前有什么前提条件？

(3)参与者完成的主要工作或功能是什么？

(4)还需要考虑什么异常？

(5)参与者的交互中有什么可能的变化？

(6)参与者将获得、产生或改变哪些系统信息？

(7)参与者必须通知系统外部环境的改变吗？

(8)参与者希望从系统获取什么信息？

(9)参与者希望得知意料之外的变更吗？

3．构建用例模型

将参与者和用例之间的交互关系在用例图上标识出来，并可进一步标识这些元素之间的结构关系，如泛化关系等。图4.3是ATM机的用例模型图。图4.3ATM机的用例模型图

4．用例描述

一种采用脚本形式的ATM取款用例描述：

●用例任务：允许银行客户通过ATM系统取款；

●用例启动：当合法银行用户对ATM机发出取款请求后，用例启动；

●基本事件流：系统请求用户输入取款金额，系统验证金额是否符合一次可存取限额，系统验证用户账户余额是否足够支取，满足支取条件，控制ATM吐出现金，打印交易单，提示进一步取款或退出的操作信息；●不满足支取条件事件流：系统显示提示不能支取的信息和退出取款流程的信息；

●结束用例：用户发出取消的请求。

基于用例的需求获取方法是建立在UML的基础上的，因此它为面向对象的分析与设计提供了良好的基础，在后面的章节中，我们将介绍基于用例模型的对象分析和设计。4.4.3原型化方法

在前面已介绍过演化式开发模式，我们也可以将快速原型的的思想用于需求的发现。原型方法的核心思想是：根据用户对需求的概要性描述，快速建立一个目标系统原型，让用户可以尽早接触到软件系统的面貌，对其进行评价，引导用户挖掘更多的需求，通过对用户意见的修改，确定最后的需求目标。例如对于一个有着众多人机交互的办公系统，用户无使用相似系统的经验，项目之初对人机交互的方式并不能提出具体的要求，则可以通过原型化方法，帮助挖掘出令用户满意的需求。

原型方法的关键是借助系统原型启发用户发现需求，是一种重要的需求获取手段。4.4.4需求分析

需求分析要对收集到的需求进行提炼、分析和认真审查，以确保所有的项目相关人员都明白其含义，并找出其中的错误、遗漏或其他不足的地方，形成完整的分析模型。需求分析的核心在于建立分析模型。分析模型应详细、准确地定义系统的需求，通常采用数据流图、实体关系图、状态转换图、用例图、顺序图、协作图、类图等来定义需求。

图4.4是ATM系统用户取款的顺序图。图4.4ATM系统“取款”用例时序图

4.5需求定义

需求定义阶段的工作就是以分析模型为基础，形成完整的需求定义文档(即需求规格说明)，为设计提供基础，也为软件测试和确认及维护提供依据。4.5.1需求描述方式

1．自然语言

自然语言具有易理解的特点，但描述软件需求一般不够准确，可能造成理解上的出入，这将给软件开发过程后期的活动带来麻烦，长篇的文字也会导致结构不清晰，可读性差。一种良好的改善方法是采用需求定义模板，这种描述采用标准形式和模板表达需求，使得需求的描述更加清晰、可读。

下面是一个无人值守气象站向中心气象站发送气象数据的需求描述。表4.6列出了需求定义模板所描述的需求文档。例4.1一个气象站系统需要管理各类气象数据检测仪器，根据气象中心的要求，通过远程通信设备Modem将数据汇总发送到气象中心主机数据收集子系统，以形成报表和地图。数据来自气象监测仪，每5分钟监测一次，包括气温、气压、风力、风速、雨量的最大值、最小值和平均值。数据的汇总和上传每小时一次，但今后可以修改。

2．结构化语言

结构化语言用带有抽象性质的类程序设计语言描述需求，结合了自然语言的易理解性和程序设计语言的语法。例如：

Validation()

{

Inputcash_amountfrompanel

Ifaccount_balance>=cash_amount+10

{outputcash}

Else

{Display"Notenoughmoney"}

}

3．可视化模型语言

可视化模型通常用图形直观地描述需求，作为文本描述的补充工具，一般用于更好地理解需求。常见的可视化模型如数据流模型、实体关系模型、类图等。目前主要采用UML来建立面向对象系统的需求模型。如图4.5为ATM系统的状态转移模型。图4.5ATM系统的状态转移模型

4．形式语言

形式语言是基于数学定义的方法，如有限状态机、图论等。这是一种不会引起歧义的定义方法，用于精确描述系统的属性，常用的形式化描述方法有Petri网、Z语言等，将在以后的章节详细讨论。形式化描述方法具有精确、严谨的特点，但不易被理解，对软件人员有较高的要求，通常在一些可靠性和安全性要求较高的系统中使用。4.5.2软件需求规格说明

一般来说，需求规格说明应该包括用户需求和系统需求，某些情况下也可以合二为一。用户需求采用用户可理解的自然语言和图来描述(requirementdefinition)，系统需求则是更为精确，详细的需求规格说明(requirementspecification)是开发人员设计的基础。软件需求规格说明应包含功能性行为需求描述以及非功能性行为需求描述，Heninger(1980)提出软件需求文档应满足以下内容：

●定义外部系统行为

●定义实现时的限制

●易于修改

●可以作为系统维护的参考

●提出对系统生存期的预想

●指明对不期望的事件可接受的响应通常需求规格说明要包含以下一些项目：

●物理环境：功能所需要的设备处于何处，是否只在一个位置，环境是否有限制，例如温度、湿度等。

●接口：输入是否来自一个或多个其他系统； 输出是否到一个或多个系统；数据是否有规定的格式；数据是否要使用规定的介质。

●用户和人的因素：谁使用系统；是否有多种类型的用户；每一类用户的技能水平；用户需要什么样的训练；对用户来讲理解和使用用户的难易程度。●功能：系统应该做什么？何时做？ 系统操作是否需要多种模式；系统怎样可以改变或扩展； 在执行速度、响应时间、吞吐量上有何要求。

●文档：需要什么文档？文档的形式，在线阅读、书的形式，还是两者皆有；文档的阅读对象是谁？

●数据：什么是数据的输入和输出的格式；发送或接收数据的频率；数据的精确度；通过系统的数据流；数据保留的时间。

●资源：构建、使用和维护系统需要的物资、人员和其他资源；开发者必须具有的技能； 系统占有的物理空间；是否需要动力、空调和加热设备；是否有开发时间限制；是否有成本、软硬件的限制。●安全性：是否必须控制对系统和信息的访问；用户之间的数据是否必须隔离；用户程序是否必须与其他程序和操作系统隔离；系统备份的时间；是否需要在不同地点备份；是否需要考虑意外灾害，比如水、火灾等。

●质量保证：可靠性、有效性、可维护性、安全性和其他质量属性的要求；故障间隔的要求；系统是否必须检测和隔离错误；系统失效后最大重启时间；系统如何适应设计的变化；维护仅需考虑纠正错误还是需考虑改善系统；对资源使用和有效响应、时间的度量；系统可移植性要求。以下是IEEE建议的需求文档结构。其中特定需求是文档中最核心内容，由于各个软件组织的软件活动各有不同，因此很难定义标准的结构。但系统的功能、性能、逻辑数据库需求、设计限制、质量特性以及应急机制都应包含其中。

4.6需求验证

需求验证也称为需求评审，是检验需求规格说明是否满足用户实际需求的活动。在将需求规格说明书提交之前，必须进行需求评审。若需求文档中的错误在后期的开发中被发现，将会带来额外的重新开发的代价，除了会增加系统的成本，也会给软件质量和按时交付带来压力。正确性检验。检验需求规格说明对系统功能、行为、性能及其他属性的描述是否满足用户的期望。不同的用户对需求有不同的要求，通过检验可以和用户达成共识，并有助于发现用户的其他所需的功能。

●完整性检验：需求规格说明应包含用户所需的所有功能、行为和性能约束，不能有遗漏。

●一致性检验：检验系统各个需求的描述是否存在互相矛盾的地方，功能需求、非功能需求、行为特征、术语、时序定义都不应存在冲突。●无歧义性：对于用户和软件人员而言，需求规格说明中的任何表达只能有唯一的语义。确保无歧义性的有效方法是使用标准化术语和模型，并对它们有统一、明确的解释。

●可理解性：对于用户和软件人员而言，需求规格说明的表达易于理解。对于非专业的用户来说，不宜在用户需求中使用过多的专业化术语。

●可修改性：需求规格说明的格式和组织应能易于后期需求变化时的修改，使修改后的说明书可较好地保持原有特性。

●实现性检验：确认运用已有的技术和知识是否能确保系统顺利实现。●可追踪性：需求规格说明中定义的每项需求都能与原始需求的来源有着清晰的关联，便于追踪。例如，ATM的诊断功能需求最初来自与银行系统管理员的一次面谈记录。

●可验证性：需求的定义应是可验证的，并且可以避免客户和开发者之间产生争议。应该具有检查手段来说明交付的系统可以满足用户需求。评审可以围绕以下问题进行展开：

(1)软件说明的目标和对象与系统的目标和对象是否一致?

(2)所有系统元素的重要接口是否已经给出?

(3)信息流和信息结构是否满足所定义的问题域?

(4)图示是否清晰？如果每一个图示没有辅助说明，能独立使用吗?

(5)每一个包含在工作域内的主要功能描述是否充分?

(6)软件的行为是否与其必须处理的信息和必须完成的功能相一致?

(7)设计限制是否实际？

(8)开发的技术风险是什么?

(9)是否已经考虑了另一个可供选择的软件需求?

(10)是否已经详细说明了确认准则？它们能满足一个成功的系统所要求的描述吗?

(11)是否存在不一致性(inconsistencies)、遗漏(omissions)和冗余(redundancy)?

(12)是否完成了与用户的沟通?

(13)用户已经评审了初步的用户手册吗?

(14)对软件项目计划中所建立的各种估算有影响吗?

4.7案例

本节将结合一个理财管理系统的实例，讨论基于用例的需求获取方法。这里采用以下步骤实现该系统的需求获取和用例建模：

(1)确定系统的参与者。

(2)确定用例。

(3)构建用例模型。

(4)用例描述。下面是关于“理财管理系统iricher”的问题描述：

用户在“理财管理系统iricher”注册后，系统通过注册的Email给用户发送一个密码。注册用户可以使用自己的用户名和密码登录；登录后可以使用此系统记录日常的收支、管理自己的每个银行卡账户信息、输入理财预算、管理个人信息。该系统应该在Internet环境下运行，用户通过浏览器浏览。要求用户界面友好、响应速度快，具有良好的可扩展性。

(1)确定参与者。在“理财管理系统iricher”例子中，可以确定任何一个网络“用户”是该系统的主动参与者，他使用系统的主要功能；另外用户注册后需要使用外部的“邮件系统”通知注册用户的密码，如图4.6所示。图4.6iricher系统的参与者

(2)确定用例。如果基本系统的所有功能都提供给注册用户使用，那么与注册用户有关的用例是登录、日常的收支、管理银行账户、输入理财预算、管理个人信息、管理家庭成员信息；与普通用户有关的用例是注册；与邮件系统有关的用例是注册。

(3)构建用例模型。确定iricher系统的用户和用例之间的关系，如图4.7所示。图4.7iricher系统用例图

(4)用例描述。此处我们给出采用脚本形式的iricher系统“记录