软件工程-需求工程-UML_《软件工程与uml》需求管理内容

一、概述

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

二、需求分类

1. 需求的层次分类

   业务需求：是指反应企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定了基础。

   用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。

   系统需求：是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

   功能需求也称为行为需求，它规定了开发人员必须在系统种实现的软件功能，用户利用这些功能来完成任务，满足业务要求。

   性能需求（非功能需求） 是指系统必须具备的属性或品质，又可细分为软件质量属性和其他非功能需求。

   设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明。

2. 需求的 QFD 分类

   质量功能部署 QFD 是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。QFD 将软件需求分为三类：

   常规需求（基本需求）：用户认为系统应该做到的功能或性能，实现越多用户会越满意。

   期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

   兴奋需求（意外需求）：是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

三、需求获取方法

1. 用户访谈：1 对 1-3，有代表性的用户。用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过 1 对 1（或 1 对 2，1 对 3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

2. 问卷调查：用户多，无法一一访谈。与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。问卷调查最大的不足就是缺乏灵活性。

3. 现场观摩：针对较为复杂的流程和操作。想获取系统某些较为复杂的流程和操作过程，则现场观摩方法比较合适。对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。

4. 联合需求计划（JRP）：高度组织的群体会议，各方参与，成本较高。为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。

5. 情节串联板：一系列图片，通过这些图片来讲故事。

6. 收集资料：把与系统有关的、对系统开发有益的信息收集起来。

7. 参加业务实践：有效地发现问题的本质和寻找解决问题的办法。

8. 阅读历史文档：对收集数据性的信息较为有用。

9. 抽样调查：降低成本。采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。抽样能够提高需求获取效率，但抽样往往是由系统分析师来抽的，所以会受到他的主观因素影响。

四、需求分析

1. 结构化需求分析（SA） ⭐⭐
   
   数据流图 DFD

状态转换图 STD

数据分析-E-R

五、面向对象需求分析 - UML 图概念 ⭐⭐⭐⭐⭐

UML 包括两组公共分类，分别是类与对象（类表示概念，而对象表示具体的实体）、接口与实现（接口用来定义契约，而实现就是具体的内容）

结构事物：结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。UML 有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点。类是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口；接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作；协作定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大；用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的；活动类的对象有一个或多个进程或线程。活动类和类很相似，只是它的对象代表的事物的行为和其他事物是同时存在的；构件是物理上或可替换的系统部分，它实现了一个接口集合；节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。

行为事物：行为事物是 UML 模型中的动态部分，代表时间和空间上的动作。UML 有两种主要的行为事物。第一种是交互（内部活动），交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作）、连接（对象之间的连接）；第二种是状态机，状态机由一系列对象的状态组成。

分组事物：分组事物是 UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。 UML 只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段。注释事物：注释事物是 UML 模型的解释部分。

在初步的业务需求描述已经形成的前提下，基于UML的需求分析过程大致可分为以下步骤：

1. 利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象，形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。
2. 利用包图和类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。

六、面向对象需求分析 - UML 图分类

静态图

1. 类图（class diagram）:类图描述一组类、接口、协作和它们之间的关系。

2. 对象图（object diagram）:对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。

3. 构件图（component diagram）。构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。一个封装的类和它的接口

4. 部署图（deployment diagram）。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。软硬件之间映射

5. 制品图：系统的物理结构

6. 包图：由模型本身分解而成的组织单元，以及他们之间的依赖关系

动态图

1. 用例图：系统与外部参与者的交互

2. 顺序图（sequence diagram，序列图）：顺序图是一种交互图（interaction diagram），它强调对象之间消息发送的顺序，同时显示对象之间的交互。强调按时间顺序。

3. 通信图（communication diagram）。协作图。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。

4. 定时图：强调实际时间

5. 状态图（state diagram）。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。状态转换变迁

6. 活动图（activity diagram）。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。类似程序流程图，并行行为，和流程图类似。

六、面向对象需求分析 - UML 图关系

1. 用例关系

   包含关系(使用关系)：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例系：当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。（每次都要使用）

   扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。（可选择使用）

   泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。（父子关系、一般与特殊的关系）

2. 类图/对象图关系

   依赖关系：一个事物发生变化影响另一个事物。 （虚线加实体黑色三角）
   实现关系：接口与类之间的关系（虚线加空心三角）

   泛化关系：特殊/一般关系 （实线加空心三角）
   关联关系：描述了一组链，链是对象之间的连接，分为聚合关系和组合关系。（实线连接）
   关联关系-聚合关系：整体与部分生命周期不同（汽车和轮胎）。（实线线加空心菱形）
   关联关系-组合关系：整体与部分生命周期相同 （公司与部门）。（实线加实体菱形）

七、面向对象需求分析 - UML “4+1”视图 ⭐⭐

UML 采用 4+1 视图来描述软件和软件开发过程：

逻辑视图：以问题域的语汇组成的类和对象集合（系统功能）。

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

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

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

用例视图：最基本的需求分析模型。

八、需求建模

用例模型：用例图
分析模型：类图

九、需求定义

十、需求验证

十一、需求管理⭐⭐⭐

1. 定义需求基线
   
   2.需求跟踪

3. 变更控制

   带有风险的做法：无足够用户参与，忽略了用户分类，用户需求的不断增加，模棱两可的需求，不必要的特性，过于精简的 SRS，不准确的估算。

4. 版本控制
5. 需求状态跟踪

十二、扩展

1. 图与开发阶段的对应关系为：
1、需求分析阶段：数据流图。
2、概要设计阶段：模块结构图、层次图和HIPO图。
3、详细设计阶段：程序流程图、伪代码、盒图。

2. 软件架构需求

软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。