需求工程

需求的分类

需求的层次

业务需求：反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- 功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
- 非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
- 设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

质量功能部署

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

常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性),实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

PIECES框架

PIECES框架是系统非功能性需求分类的技术。

	概念	示例
性能 ( Performance)	描述企业当前的运行效率，业务的处理速度。	响应时间，吞吐量
信息 (Information)	描述业务数据的输入、输出以及处理方面存在的各种问题。	无法捕获数据，或数据不精准
经济 ( Economics)	从成本和收益的角度分析企业当前存在的问题。	订单数减少
控制 ( Control)	提高信息系统的安全和控制水平。	身份鉴别
效率 ( Efficiency)	提高企业的人、财、物等的使用效率。	浪费时间/材料/资源
服务 ( Service)	提高企业对客户、供应商、合作伙伴、顾客等的服务质量。	系统结果不准、使用困难、与其它系统不兼容

需求获取

用户访谈

形式包括结构化和非结构化两种。

结构化是指事先准备好一系列问题，有针对性地进行。
而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。

为了进行有效的用户访谈，系统分析师需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作。


准备访谈	步骤： 1、确定访谈目的。 2、确定访谈哪些用户。 3、准备一些详细的访谈问题【开放式和封闭式相结合】。 4、作出最终的访谈安排。此外：领域知识培训，充分阅读相关材料。
访谈过程	注意事项： 1、限制访谈时间。 2、寻找异常和错误情况。 3、深入调查细节。 4、认真作好记录。
访谈的后续工作	1、后续工作的首要任务是吸收、理解和记录访谈所获得的信息。 2、当次错过的问题，记录下来，下次再访谈。

优缺点

总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围。

但是，也存在着许多困难，

用户经常较忙，难以安排时间；
面谈时信息量大，记录较为困难；
沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。
在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。
这看似简洁的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

问卷调查

三个重要活动

确定问题及其类型。开放式和封闭式结合问题。问卷调查表的问题必须非常清楚，组织顺序必须有说服力能预见用户可能的回答。
编写问题。在具体问题的编写中，要注意使用“用户的语言”，不要使用含糊的词语，但也要避免过度明确的问题，保持问题的简短，避免措辞上的偏向。
设计问卷调查表的格式。对用户重要的问题放在最前面，内容相似的问题放在一起

优点：

与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据

问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；

问卷调查的结果比较好整理和统计

缺点： （不灵活）

双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
调查表不利于对问题进行展开的回答，无法了解一些细节问题。
回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。

提升问卷返还率

1、向所有的工作人员解释问卷的目的，以及如何填。

2、强调这份问卷哪些人员必须填写。

3、拜托相关领导督促填写并及时返还。

4、合理设计，尽量减少回答问卷所花费的时间。

5、设置一些奖品或奖励，激励大家及时返还问卷。

采样

采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。

样本大小

样本大小 = α×(可信度系数/可接受的错误)2

其中，α称为启发式因子，一般取值为0.25; 可信度系数表示希望“种群数据包括了样本中的各种情况”有多大的可信度

例如，如果希望订单样本集包含的所有情况具有90 %的可信度，那么样本大小计算如下：

样本大小 = 0.25×(1.65/(l-0.90))2= 68.0625

优点：

通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。
采样技术使用了数理统计原理，能减少数据收集的偏差。

缺点：

由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。

情节串联板

情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。通过以图片辅助讲故事的方式叙述需求，有助于畚效和准确地沟通。

简单地说，情节串联板技术就是使用工具向用户说明（或演示）系统如何适合企业的需要，并表明系统将如何运转。系统分析师将初始的情节串联板展示给讨论小组，小组成员提供意见。

情节串联板应该易于创建和修改，系统分析师不要企图将情节串联板制作得太好，因为情节串联板既不是原型，也不是真实事物的演示。

情节串联板的类型

被动式（草图、图片、屏幕截图、幻灯片）、主动式（自动播放）和交互式

制作工具

大致可以分为两大类：静态工具和动态工具。静态工具主要有纸和铅笔、白板、即时贴和PPT等，动态工具主要有Flash、Macromedia Director和其他动画工具

优缺点

由于情节串联板给用户一个直观的演示，因此它是最生动的需求获取技术，其优点是用户友好、交互性强，对用户界面提供了早期的评审。
情节串联板的缺点是花费的时间很多，使需求获取的速度大大降低。

联合需求计划

联合需求计划（JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（JAD）的一部分。用小组工作会议来代替大量独立的访谈。

主要原则

JRP 的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP 时应把握以下主要原则：

( 1 ) 在 JRP 实施之前，应制订详细的议程，并严格遵照议程进行。

( 2 ) 按照既定的时间安排进行。

( 3 ) 尽量完整地记录会议期间的内容。

( 4 ) 在讨论期间尽量避免使用专业术语。

( 5 ) 充分运用解决冲突的技能。

( 6 ) 会议期间应设置充分的间歇时间。

( 7 ) 鼓励团队取得一致意见。

( 8 ) 保证参加JRP的所有人员能够遵守事先约定的规则。

优缺点：

JRP 是一种相对来说成本较高的需求获取方法
用户参与度高
，要做到言之有物，气氛开放。否则，将难以达到预想的效果
当各方对需求不明确，有严重的分歧的时候。JRP 将会消除分歧，起到群策群力的效果，

速记表

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

需求分析

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

需求分析的任务

绘制系统上下文范围关系图：这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围
创建用户界面原型
分析需求的可行性
确定需求的优先级
为需求建立模型：例如，面向对象分析中的用例模型和领域模型，SA中的DFD 和 E-R图等。
创建数据字典
使用QFD（质量功能部署）

结构化分析

SA 方法的基本思想是自顶向下，逐层分解

SA 方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中一般使用E-R图表示数据模型，用 DFD 表示功能模型，用状态转换图（STD）表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。

数据流图

DFD是SA 方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD 还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD 作为需求规格说明书的一个组成部分。

DFD的主要作用

DFD 从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD 的主要作用如下：

DFD 是理解和表达用户需求的工具，是需求分析的手段。由于DFD 简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD 与用户进行交流。
DFD 概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
DFD 作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

DFD 的基本符号

如何画DFD

重点关注，数据流图的平衡原则，如下所示。

父图 ( 上层数据流图 ) 与子图 ( 下层数据流图 ) 平衡。个数一致：两层数据流图中的数据流个数一致。方向一致：两层数据流图中的数据流方向一致。
子图内部的平衡。黑洞：加工只有输入没有输出。奇迹：加工只有输出没有输入。灰洞：加工中输入不足以产生输出。每个数据存储必须既有读的数据流，又有写的数据流。但是在某张子图中，可能只有读没有写，或者只有写没有读。

常见错误：

1、不满足数据流图的平衡原则

2、数据流未经加工从数据存储指向外部实体

3、在 DFD中，需按层给加工编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。

0 层图的编号 1、2、3
1 层图的编号 1.1、2.1、3.1 …….

状态转换图

数据字典

数据字典是在DFD 的基础上，对 DFD 中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

数据字典的条目

数据字典中一般有6 类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体

面向对象分析

面向对象的概念

封装：是一种信息隐蔽技术，它的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。

消息：对象之间进行通信的一种构造叫做消息

类：一个类定义一组大体上相似的对象，一个类所包含的方法和数据描述 一组对象的共同行为和属性 。类是对象之上的抽象，对象是类的具体化，是类的实例。

多态：不同对象收到同一消息可以产生完全不同的结果

对象：在面向对象的系统中，对象是基本的运行实体，它既包括数据（属性），也包括作用于数据的操作（行为），所以一个对象把属性和行为封装为一个整体

抽象：通过特定的实例抽取共同特征以后形成概念的过程

继承：子类复用父类数据和方法的一种机制。

覆盖：在子类中重定义一个与父类同名同参的方法。

函数重载：一个类可以拥有多个同名但不同参数的函数。

建模

用例模型

建立流程

第一步：识别参与者【参与者：用户、组织、外部系统、时间】
第二步：合并需求获得用例
第三步：细化用例描述
第四步：调整用例模型(可选步骤) 【关系包括：包含关系、扩展关系、泛化关系】

用例的描述

用例描述通常包括以下几个部分：

用例名称
简要说明
事件流。事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动
非功能性需求
前置条件和后置条件
扩展点
优先级

用例关系

包含关系【使用关系】：从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例。

扩展关系：一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。

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

分析模型

建立流程

第一步：定义概念类
第二步：确定类之间的关系
第三步：为类添加职责
第四步：建立交互图
第五步：分析模型的详细程度问题

概念类

发现类的方法有很多种，其中应用最广泛的是名词短语法。它的主要规则是先识别有关问题域文本描述中的名词或名词短语，然后将它们作为候选的概念类或属性

发现类的步骤：

阅读和理解需求文档或用例描述。
筛选出名词或名词短语，建立初始类清单(候选类)。
将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
舍弃明显无意义的类。
- 去除相同含义的
- 去除不属于系统范围内的
- 去除没有特定独立行为的
- 去除含义解释不清楚的
- 去除属于另一个类属性或行为的
小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。

类之间的关系

依赖关系：一个事物发生变化影响另一个事物。（类A 使用了类 B的方法，他们就是依赖关系）

泛化关系：特殊/一般关系。

关联关系：描述了一组链，链是对象之间的连接。

聚合关系：整体与部分生命周期不同。
组合关系：整体与部分生命周期相同。

实现关系：接口与类之间的关系。

需求定义

系统分析师在获取了用户的需求，并进行了详细分析之后，接下来的工作就需要把这些需求形成文档 （需求规格说明书 SRS），作为系统后续开发的基础，这就是需求定义。

需求定义的方法

严格定义方法：需求的严格定义建立在以下的基本假设之上：
- 所有需求都能够被预先定义。
- 开发人员与用户之间能够准确而清晰地交流。
- 采用图形(或文字)可以充分体现最终系统。
原型方法，迭代的循环型开发方式，需要注意的问题
- 并非所有的需求都能在系统开发前被准确地说明。
- 项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。
- 需要实际的、可供用户参与的系统模型。有合适的系统开发环境。
- 有合适的系统开发环境
- 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

SRS 的内容和格式

范围
- 简述SRS 适用的系统和软件的用途，描述系统和软件的一般特性
- 概述系统开发、运行和维护的历史；
- 标识项目的投资方、需求方、用户、承建方和支持机构；
- 标识当前和计划的运行现场；
- 列出其他有关的文档；
- 概述 SRS 的用途和内容，并描述与其使用有关的保密性和私密性的要求；
- 说明编写SRS 所依据的基线
引用文件
需求
- 这一部分是SRS 的主体部分，详细描述软件需求
合格性规定
- 采取措施，以确保需求得到满足
需求可追踪性
尚未解决的问题
注解
附录

需求验证

其活动是为了确定以下几个方面的内容：

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

需求评审

也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SAS进行评审和测试，包括两个步骤：

需求评审
- 技术评审：评审（一次正式的会议）、检查（非作者本人详细检查工作产品）、走查（评审的过程）
需求测试（设计概念测试用例）。

需求测试

实际上，需求幵发阶段不可能有真正意义上的测试进行，因为还没有可执行的系统, 需求测试仅仅是基于文本需求进行“概念”上的测试

以功能需求为基础（ SA 方法）或者从用例派生出来（OO方法）的测试用例。可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例。

基于概念测试用例进行需求测试的基本过程如下：

需求测试人员根据概念测试用例所描述的若千可能的过程，进行 “概念上”的执行，期望发现遗漏的、错误的和不必要的需求。
根据测试结果快速修改对应的需求文档，完成一轮完整的需求测试过程。

作用：

发现S R S 中的错误、二义性和遗漏，
进行模型分析，
作为用户验收测试的基础

需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

需求变更管理

需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS, 以及相关的分析模型。经评审批准，这些文档就定义了幵发工作的需求基线

需求的状态

需求变更流程

需求风险管理

风险管理的目的就是希望让项目管理人员能够“掌控”风险，风险事件一旦发生，能够按照预先制订的应对计划有条不紊地处理风险。有关项目风险管理的过程。

带有风险的做法

无足够用户参与
忽略了用户分类
用户需求的不断增加
模棱两可的需求
不必要的特性
过于精简的SRS
不准确地估算

需求跟踪

需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统架构和构件、源代码、测试用例，以及帮助文件等。

正向跟踪是指检查SRS 中的每个需求是否都能在后继工作成果中找到对应点；

反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS 中找到出处

统一建模语言 UML

UML的结构

从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

构造块

构造块。UML有三种基本的构造块，分别是：事物(thing)、关系(relationship)和**图(**diagram)。

事物是UML的重要组成部分，
-关系把事物紧密联系在一起，
图是多个相互关联的事物的集合。（用例图、例图、活动图等）

事物

结构事物：名词、静态部分，用于描述概念或物理元素。结构事物包括类(Class)、接口(Interface)、协作(Collaboration)、用例(UseCase)、主动类(Active Class)、构件(Component)、制品(Artifact)和节点(Node),

行为事物：动词，描述了跨越时间和空间的行为。行为事物包括交互(Interaction)、状态机(State Machine)和活动(Activity)

分组事物：包是最常用的分组事物，结构事物、行为事物甚至其他分组事物都可以放进包内

注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。

关系

ML中有4种关系：依赖、关联、泛化和实现。

公共机制

公共机制。公共机制是指达到特定目标的公共UML方法。
- 规格说明：事物语义的细节描述，它是模型真正的核心
- 修饰：通过修饰来表达更多的信息
- 公共分类：类与对象、接口与实现
- 扩展机制：允许添加新的规则

规则

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

类图

类图(class diagram):类图描述一组类、接口、协作和它们之间的关系。

对象图

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

对象图 VS 类图

类图	对象图

类具有3个分栏，自上而下依次为名称、属性和操作	对象只有两个分栏，自上而下依次为名称、属性
在类的名称分栏中只有类名	对象的名称形式为“对象名:类名“，匿名对象的名称形式为”:类名”
类的属性分栏定义了所有属性的特征	对象则只定义了属性的当前值，以便用于测试用例或例子中
类中列出了操作	对象图中不包括操作，因为对于同属于同一个类的对象而言，其操作是相同的
类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义类代表的是对对象的分类，所以必须说明可以参与关联的对象的数目	对象使用链连接、链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重