3.2 需求分析

在技术层面上，软件工程从一系列的建模工作开始，最终生成待开发软件的需求规格说明和设计表示。需求模型实际上是一组模型，是系统的第一个技术表示。而需求建模的目标是创建各种表现形式，用其描述和定义一组可被确认的客户需求，建立生成软件设计的基础。需求模型是系统级表示层和软件设计之间构造的桥梁。系统表示层描述整个系统和业务功能，软件设计描述软件应用的架构、用户接口和组件级的结构。

需求分析产生所开发软件的规格说明，指明软件和其他系统元素的接口，规定软件必须满足的约束，并且让软件工程师（有时也称软件分析师或软件架构师）细化在前期需求工程的起始、导出和谈判任务中建立的基础需求。

需求建模活动产生以下一种或多种模型类型。

●场景模型：出自各种系统“参与者”观点的需求。

●数据模型：描述问题信息域的模型。

●面向类的模型：表示面向对象类（属性和操作）的模型，其方式为通过类的协作获得系统需求。

●面向流程的模型：表示系统的功能元素并且描述当功能元素在系统中运行时怎样进行数据变换的模型。

●行为模型：描述如何将软件行为看做是外部“事件”后续的模型。

其中，基于场景的建模技术在软件工程界迅速发展；数据建模是较为特殊的技术，适用于当一个应用问题必须生成或处理一个复杂的信息空间时；面向类建模表示面向对象类和允许的系统功能间的有效协作。

这些模型为软件设计者提供信息，并可以转化为结构、接口和构件级的设计。最终，在软件开发完成后，需求模型（和需求规格说明）为开发人员和客户提供了评估软件质量的手段。

3.2.1 总体目标和原理

在需求建模过程中，软件工程师主要关注“做什么”而不是“怎么做”。包括：在特定环境下发生哪些用户交互？系统处理什么对象？系统必须执行什么功能？系统展示什么行为？定义什么接口？有什么约束？

由于在初期就得到完整的需求规格说明几乎是不可能的，因此，分析师将为已经知道的内容建模，并将该模型作为软件进一步扩展的设计基础。

需求模型必须实现下列3个主要目标。

1）描述客户需要什么。

2）为软件设计奠定基础。

3）定义在软件完成后可以被确认的一组需求。

分析模型联系系统级描述和软件设计。系统级描述给出了在软件、硬件、数据、人员和其他系统元素共同作用下的整个系统功能，而软件设计给出了软件的应用程序结构、用户接口及构件级的结构，其关系如图3-5所示。

图3-5 分析模型在系统描述和设计模型之间建立桥梁

要注意需求模型的所有元素都可以直接跟踪到设计模型。通常很难清楚地区分这两个重要的建模活动之间的设计和分析工作，有些设计会作为分析的一部分进行，而有些分析将在设计中进行。

在建立分析模型时应该遵循的下列一些原则。

●模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。“不要陷入细节”，即不要试图解释系统将如何工作。

●需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。

●关于基础结构和其他非功能的模型应推迟到设计阶段再考虑。例如，可能需要一个数据库，但是只有在已经完成问题域分析之后，才考虑实现数据库所必需的类、访问数据库所需的功能，以及使用时所表现出的行为。

●最小化整个系统内的关联。表现类和功能之间的联系非常重要，但是，如果“互联”的层次非常高，应该想办法减少互联。

●确认需求模型为所有干系人都带来价值。对模型来说，每个客户都有自己的使用目的。例如，利益相关的业务人员将使用模型确认需求，设计人员将使用模型作为设计的基础，质量管理人员将使用模型帮助规划验收测试。

●尽可能保持模型简洁。如果一个简单列表够用，就不要使用复杂的表示方法。

3.2.2 域分析

分析模式通常在特定业务领域内的很多应用系统中重复发生。如果用一种方式对这些模式加以定义和分类，让软件工程师或分析师识别并复用这些模式，将促进分析模型的创建。更重要的是，应用可复用的设计模式和可执行的软件构件的可能性将显著增加，这将有可能使产品投放市场的时间提前，并减少开发费用。

软件域分析是识别、分析和详细说明某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的需求。面向对象的域分析是在某个特定应用领域内，根据通用的对象、类、部件和框架，识别、分析和详细说明公共的、可复用的能力。域分析的目标很简单，就是查找或创建那些广泛应用的分析类和（或）分析模式，使其能够复用。

域分析被看做是软件过程的一个普适性活动，而不与任何一个软件项目相关。域分析师发现和定义可复用的分析模式、分析类和相关的信息，以便用于类似但不一定完全相同的应用。图3-6说明了域分析过程的关键输入和输出。

图3-6 域分析的输入和输出

3.2.3 需求建模的方法

所谓结构化分析，是一种考虑数据和处理的需求建模方法，其中的处理将数据作为独立实体加以转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时如何转换数据。需求建模的第二种方法称为面向对象的分析，这种方法关注定义类和影响客户需求的类之间的协作方式。UML和统一过程是主要的面向对象分析方法。

如图3-7所示，需求模型的每个元素表示源自不同观点的问题。基于场景的元素表述用户如何与系统和使用软件时出现的特定活动序列进行交互。基于类的元素表述系统操作的对象，应用在这些对象间影响操作和对象间关系（某层级）的操作，以及定义的类间发生的协作。行为元素描述了外部事件如何改变系统或驻留在系统里的类的状态。最后，面向流的元素表示信息转换的系统，描述了数据对象在流过各种系统功能时是如何转换的。

图3-7 需求模型的元素

需求建模导出每个建模元素的派生类。然而，每个元素的特定内容可能因项目而异。软件团队必须想办法保持模型的简单性，只使用那些为模型增加价值的建模元素。

3.2.4 需求建模策略

需求建模有很多不同的维度。对于某种类型的软件，用例可能是唯一可行的需求建模表示方法，而其他类型的软件，则需要选择面向对象的方法开发基于类的模型。但在另外一些情形下，复杂应用需求甚至必须做一个检测，查看当数据对象在系统中移动时是如何转换的；查看作为外部事件的后一个应用系统是如何工作的；查看现存知识领域能否解决当前问题；或者在基于Web的系统和应用中，如何将内容和功能融合在一起，并提供给最终用户成功导向一个Web应用的能力，以便达到适用目标。