需求工程

1 需求工程概述

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。

需求工程（Requirement Engineering，RE） 是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。

需求工程由需求获取、需求分析、形成需求规格（或称为需求文档化）、需求确认与验证、需求管理5个阶段，如图：

软件需求规格说明书（Software Requirement Specification，SRS）
SRS具体包括功能需求、非功能需求和约束。约束包括设计约束和过程约束。批准的SRS是需求开发和需求管理之间的桥梁。

需求管理
需求管理是一个对系统需求变更、了解和控制的过程，包括变更控制、版本控制、需求跟踪等活动

2 需求开发(主线、目标)

2.1 需求分类

需求分类
（1）业务需求：业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。

（2）用户需求：用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求

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

质量功能部署QFD
它是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

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

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

（3）意外需求：意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

2.2 需求获取

方法	特点
收集资料	把与系统有关的、对系统开发有益的信息收集起来。
阅读历史文档	对收集数据性的信息较为有用。
用户访谈	1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑
问卷调查	用户多，无法一一访谈，成本低。
现场观摩	针对较为复杂的流程和操作。
参加业务实践	有效地发现问题的本质和寻找解决问题的办法。
联合需求计划(JRP)	高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。
情节串联板(原型法)	一系列图片，通过这些图片来讲故事。
抽样调查/采样	基于数理统计，降低成本，快速获取。 样本大小=a*(可信度系数/可接受的错误)2 注:a一般取0.25

2.3 需求分析

需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

需求分析的任务：
（1）绘制系统上下文范围关系图
（2）创建用户界面原型
（3）分析需求的可行性
（4）确定需求的优先级
（5）为需求建立模型
（6）创建数据字典
（7）使用QFD（质量功能部署)

2.3.1 结构化分析方法-SA

结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型，分别是数据模型，功能模型，行为模型（状态模型）。

结构化分析的步骤，如下：
（1）分析业务情况，做出反映当前物理模型的数据流图（Data Flow DiagramDFD）。
（2）推导出等价的逻辑模型的DFD。
（3）设计新的逻辑系统，生成数据字典和基元描述。
（3）建立人机接口，提出可供选择的目标系统物理模型的DFD。
（5）确定各种方案的成本和风险等级，据此对各种方案进行分析。
（6）选择一种方案。
（7）建立完整的需求规约。

结构化分析方法SA是数据流和控制流，常用手段是数据流图（DFD）和数据字典。

2.3.1.1 数据字典DD

数据字典是需求分析建立模型的核心。是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。

数据字典有4类条目：数据流、数据项、数据存储和基本加工。包括了数据元素，数据结构，数据流，加工逻辑和外部实体。

2.3.1.2 数据流图DFD

数据流图DFD是用数据流图表示功能模型，DFD说明系统所完成功能，从数据传递和加工的角度，利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况，来说明系统所完成的功能。如下图：

其中，DFD还会有“顶层DFD图”和“0层DFD图”。如下图，有如下几种“图元”描述：

另附一个错误的DFD图，如下：

如上图错误：加工3.1.2有输入但是没有输出，称之为“黑洞”。加工3.1.3有输出但没有输入。称之为“奇迹”。加工3.1.1中输入不足以产生输出，我们称之为“灰洞”。

2.3.1.3 状态转换图STD

用状态转换图表示行为模型，STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出做为特定事件的结果将执行哪些动作。如下图：

2.3.1.4 E-R图/实体联系图

ER图主要描述实体属性，以及实体之间的关系。另外，ER模型是结构化时代的模型与产物，在面向对象和UML中是没有的。如下图：

什么是弱实体？
举例说明：在人事管理系统中，职工子女的信息就是以职工的存在为前提的，子女实体是弱实体，子女与职工的联系是一种依赖联系。所以，职工是实体，也可以成为强实体。强实体与弱实体的联系只能是1：1或1：N。

2.3.2 面向对象的分析方法-OOA

对象	属性[数据]+方法[操作]+对象ID/标识ID
类【详细见下】	实体类/控制类/边界类 实体类：往往和数据库有对应的关系，是不是数据类型 控制类：衔接实体类和边界类的类 边界类：在一个系统的边界上和外部进行沟通的类 这三个类似于MVC模型之间的关系，它们的思想是一样的
继承和泛化	复用机制，它是一种紧耦合。因为当父类变的时候子类不得不变。继承是对已有实例
封装	隐藏对象的属性和实现细节仅对外公开接口
多态	不同对象收到同样的信息产生不同的结果
接口	一种特殊的类，它只有方法定义没有对方法的实现
重载	一个类可以有多个同名的参数类型不同的方法，函数同名但参数不一样是其特点
消息和消息通信	消息是异步通信的
覆盖和重写	子类的同名方法覆盖父类的同名方法
组合与聚合	聚合关系：汽车部件和整车的关系（整体与部分生命周期不同） 组合关系：部门与公司的关系。公司倒闭的话部门也完完（整体与部分生命周期相同）

OOA大致上遵循如下5个基本步骤：

（1）确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
（2）确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
（3）确定主题：主题是指事物的总体概貌和总体分析模型。
（4）确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
（5）确定方法：方法是在收到消息后必须进行的一些处理方法:方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

2.3.2.1 UML

OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。

UML基本构造块之事物【重要组成部分】

事务	描述
结构事务	最静态的部分，包括类，接口，协作用例，活动类，构件和节点
行为事务	代表时间和空间上的动作，包括消息，动作次序，连接
分组事务	看成是个盒子，如包和构件
注释事务	UML模型的解释部分。描述，说明，和标注模型的元素

UML基本构造块之关系【把事物紧密联系在一起】

关系	描述
依赖关系	一个事物发生变化影响另一个事物，包含关系和扩展关系都属于依赖
泛化关系	特殊一般关系，特殊元素的对象可替换一般元素的对象
关联关系	描述了一个链，链是对象之间的连接
实现关系	接口与类之间的关系，一个类指定了由另一个类保证执行的契约

UML基本构造块之图【多个相互关联的事物的集合】

图	描述
静态图	结构图
类图	描述一组类，接口协作和它们之间的关系
对象图	描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。
构件图	也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。
部署图	表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。
制品图	描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。
包图	将某些类放入“包”中，通过包图来组织业务概念图。
组合结构图	展示该部分内容“内部”参与者的配置情况。这个图不常用。
动态图	行为图
用例图	系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。
顺序图	强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程
通信图	也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。
定时图	消息跨越不同对象或角色的实际时间。交互图的一种。
交互概览图	活动图与顺序图的结合。这个图不常用。
活动图	类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。
状态图	从某个物品的状态是如何变化的角度来展示流程。

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

1. 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
2. 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
3. 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
4. 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
5. 用例：是描述一系列的动作，产生有价值的结果。
6. 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
7. 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.3.2.2 UML 4+1视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织[软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.3.2.3 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.4 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

1. 需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

2. 需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

3 需求管理（支持、保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

3.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

3.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

3.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

3.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

（1）所有需求变更必须遵循变更控制过程。
（2）对于未获得批准的变更，不应该做设计和实现工作。
（3）变更应该由项目变更控制委员会决定实现哪些变更。
（4）项目风险承担者应该能够了解变更的内容。
（5）绝不能从项目配置库中删除或者修改变更请求的原始文档。
（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。

3.5 需求风险

带有风险的做法有：①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。

变更产生的原因：①外部环境的变化。②需求和设计做的不够完整。③新技术的出现。④公司机构重组造成业务流程的变化。

3.6 需求跟踪

SRS中的每个软件配置项的需求到其涉及的系统（或子系统）需求都要具有双向可追踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。