第5章 信息系统工程-需求分析

5.1.2 需求分析

    软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据 IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

    1.需求的层次

    简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。质量功能部署 (Quality Function Deployment，QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD 将软件需求分为三类，分别是常规需求、期望需求和意外需求。

    2.需求过程

    需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

    1)需求获取

    需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是一件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有与用户的有效合作才能成功。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。

    2)需求分析

    在需求获取阶段获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计基础的。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

    需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。需求分析的关键在于对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。

    使用结构化分析(Structured Analysis，SA)方法进行需求分析，其建立的模型的核心是数据字典。围绕这个核心，有三个层次的模型，分别是数据模型，功能模型和行为模型(也称为状态模型)。在实际工作中，一般使用实体关系图(E-R 图)表示数据模型，用数据流图 (Data Flow Diagram，DFD)表示功能模型，用状态转换图 (State Transform Diagram，STD)表示行为模型。E-R图主要描述实体、属性，以及实体之间的关系；DFD从数据传递和加工的角度利用图形符号通过逐层细分描述系统内各个部件的功魔和数据在它们之间传递的情况，来说明系统所完成的功能；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为指出作为特定事件的结果将执行哪些动作（例如，处理数据等）。

    面向对象的分析(Object-Oriented Analysis，OOA)的基本任务是运用面向对象的(Object-Oriented，OO)方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题城和系统功能的OOA模型及其详细说明。OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模:分析模型描述系茨的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为(动态模型)。

    3)求规格说明书编制

    软件需求规格说明书(Software Requirement Specification，SRS)是需求开发活动的产物编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软性项目都不应该缺少。

    在国家标准GB/T 8567《计算机软件文档编制规范》中，提供了一个SRS 的文档模板和编写指南，其中规定 SRS 应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。

    另外，国家标准GB/T 9385《计算机软件需求说明编制指南》也给出了一个详细的 SRS写作大纲，由于该标准年代久远，一些情况已经与现实不符，可以考虑作为SRS 写作的参考之用。

    4)需求验证与确认

    资深软件工程师都知道，当以 SRS 为基础进行后续开发工作，如果在开发后期或在交付系统之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。相对而言，在系统分析阶段，检测 SRS中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS 的正确性进行验证，以确保需求符合良好特征。需求验证与确认活动内容包括：

• SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；

• SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；

• 需求是完整的和高质量的；

• 需求的表示在所有地方都是一致的；

• 需求为继续进行系统设计、实现和测试提供了足够的基础。

 

    在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS 进行技术评审，SRS 的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐敲性，仅仅通过阅读 SRS，通常很难想象在特定环境下系统的行为。只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

    3.UML

    统一建模语言(Unified Modeling Language，UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持 00A 和0OD (Object-Oriented Design，面向对象设计)，还支持从需求分析开始的软件开发的全过程。从总体上来看，UML 的结构包括构造块、规则和公共机制三个部分，如表 5-1所示。

 

    2)UML中的关系

UML 用关系把事物结合在一起，主要有四种关系，分别为：

• 依赖(Dependency)：依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

• 关联(Association)：关联描述一组对象之间连接的结构关系。

• 泛化(Generalization)：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。

• 实现(Realization)：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

• 3)UML2.0中的图

UML2.0 包括14 种图，如表5-3 所示

 

 

    4)UML视图

UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息，包括 5 个系统视图：

• 逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。

• 进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。

• 实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。

• 部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

• 用例视图：用例视图是最基本的需求分析模型。另外，UML 还允许在一定的阶段隐藏模型的某些元素，遗漏某些元素，可不保证模型的完整性，但模型逐步地要达到完整和一致。

 

   4.面向对象分析

    OOA 的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的 OOA 模型及其详细说明。O0A模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA 和OOD 的区别之所在。OOA 的任务是“做什么”，OOD 的任务是“怎么做”。面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。

    1)用例模型

    结构化分析(Structured Analysis，SA)方法采用功能分解的方式来描述系统功能，在这种表达方式中，系统功能被分解到各个功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的。采用SA 方法来描述系统需求，很容易混淆需求和设计的界限，这样的描述实际上已经包含了部分的设计在内。因此，系统分析师常常感到迷惑，不知道系统需求应该详细到何种程度。一个极端的做法就是将需求详细到概要设计，因为这样的需求描述既包含了外部需求也包含了内部设计。SA 方法的另一个缺点是分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能项如何相互关联来实现一个完整的系统服务。

    从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。用例方法是一种需求合成技术，先获取需求并记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。在 OOA 方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，如表5-4 所示。其中前三个阶段是必须的。

 

 

    2)分析模型

    前文从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

    为了使模型独立于具体的开发语言，系统分析师需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起点就是领域模型。领域模型又称为概念模型或简称为域模型.也就是找到那些代表事物与概念的对象，即概念类。概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。每一个用例对应一个类图，描述参与这个用例实现的所有概念类，而用例的实现主要通过交互图来表示。例如，用例的事件流会对应产生一个顺序图，描述相关对象如何通过合作来完成整个事件流，复杂的备选事件流也可以产生一个或多个顺序图。所有这些图的集合就构成了系统的分析模型。

    建立分析模型的过程大致包括定义概念类，确定类之间的关系，为类添加职责，建立交互图等，其中有学者将前三个步骤统称为类-责任-协作者(Class-Responsibility-Collaborator，CRC)建模。类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等，它们在 UML 中的表示方式，如表5-5 所示。