【系统分析师】软件需求工程——第11章学习笔记（上）

软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程。

可分为两大工作：

需求开发
- 需求获取
- 需求分析
- 需求定义（编写需求规格说明书）
- 需求验证
需求管理
- 定义需求基线
- 处理需求变更
- 需求跟踪

在需求开发阶段需要确定软件所期望的用户类型，获取每种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务需求。同时还包括分析源于用户的信息，对需求进行优先级分类，将所收集的需求编写成需求规格说明书和需求分析模型，以及对需求进行评审等工作。

11.1 软件需求概述

11.1.1 需求的层次

简单地说，软件需求就是系统必须完成的事以及必须具备的品质。

需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

业务需求
- 反映企业或客户对系统高层次的目标要求，通常来自项目投资人，购买产品的客户，客户的管理人员，市场营销部门或产品策划部门等
用户需求
- 描述用户的具体目标，或用户要求系统必须能完成的任务
系统需求
- 从系统的交付说明软件的需求，包括功能需求（行为需求），非功能需求，设计约束等

11.1.2 质量功能部署

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

为了达到这个目标，QFD将软件需求分为三类:常规需求、期望需求和意外需求。

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

11.1.3 软件需求

软件包含以下方面的内容：

用户解决问题或达到目标所需条件或权能。
系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
一种反映上面(1)或(2)所述条件或权能的文档说明，即需求规格说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求、质量标准或者设计限制。

在统一过程(UP)中，需求按照“FURPS+”模型进行分类。“FURPS+”中的“FURPS具体指以下需求:

功能性(Functional):特性、功能、安全性
可用性(Usability):人性化因素、帮助、文档。
可靠性(Reliability):故障频率、可恢复性、可预测性。
性能(Performance):响应时间吞吐量、准确性、有效性、资源利用率。
可支持(Sptability):适应性、可维护性、国际化、可配置性。

“FURPS+”中的“+”是指一些辅助性的和次要的因素，用来强调各种不同的属性。比如:

实现(Implementation):资源限制、语言和工具、硬件等。
接口(Interface):强加于外部系统接口之上的约束。
操作(Operation):对其操作设置的系统管理。
包装(Packaging):例如物理的包装盒。
授权(Legal):许可证或其他方式。

11.1.4 需求工程

人们逐渐意识到需求分析活动不仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

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

主要被划分为以下几个阶段：

需求获取
需求分析
形成需求规格（需求文档化）
需求确认与验证
需求管理

11.2 需求获取

11.2.1 用户访谈

最基本的一种需求获取手段。其形式包括结构化和非结构化两种。

结构化是指事先准备好一系列问题，有针对地进行
非结构化是列出一个粗略的想法，根据访谈的具体情况发挥。

系统分析师需要再三个方面进行组织：准备访谈，主持访谈，访谈的后续工作

准备访谈
- 确定访谈的目的
- 确定包括哪些用户
- 准备一些详细的问题
  - 开放式
  - 封闭式
- 作出最终的访谈安排，并通知所有参与者
主持访谈
- 限制访谈时间
- 寻找异常和错误情况
- 深入调查细节
- 认真记录
访谈的后续工作
- 吸收，理解，记录访谈所获得的信息

11.2.2 问卷调查

可以收集到大量的信息，以低廉的代价短时间内收集到大量的回答，但缺乏灵活性

最好的做法事先问卷调查，进行仔细整理和分析，针对结果进行小范围用户访谈。

11.2.3 采样

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

选择样本的方式有随机采样，分层采样，聚类采样，系统采样等

采样不仅可以用于收集数据，还可以采集访谈用户或者采集观察用户。

11.2.4 情节串联板

很多用户对信息系统没有直观认识，这样也很容易产生盲区，这时候，需要系统分析师用情节串联版技术来帮助用户消除盲区

情节串联版通常是一些列图片，系统分析师通过图片来讲故事。比如流程图，交互图，报表等

类型包括被动式，主动式，交互式，其复杂程度依次递增

被动式
- 草图，图片，PPT，系统分析师简述场景
主动式
- 看到类似“电影”内容，自动播放，自动简述
交互式
- 用户亲自体验，比如仿真器，实物模型，抛弃式原型。

优点：直观，生动，用户友好，交互性强

缺点：花费的时间很多，需求获取速度大大降低

11.2.5 联合需求计划

联合需求计划(Joint Requirement Planning，JRP)是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发(JointApplicationDevelopment，JAD)的一部分。

联合应用开发

JAD是以小组形式定义和建立系统的，它是由企业主管部门经理、会议主持人、用户、协调人员、IT 人员、秘书等共同组成的专题讨论组。由这个专题讨论组来定义并详细说明系统的需求和可选的技术方案。JAD的过程大致如下:

确定JAD项目，主要指确定系统的范围和规范。
在JAD 专题预备会上，会议主持人向参与者介绍项目和JAD专题讨论内容
准备JAD专题讨论材料。
进行JAD专题讨论会，其目的是要达成对需求的一致意见，并对各种可选的技术方案加以过论从由研究出几有可供选择的方案

JRP会议

联合需求计划(Joint Requirement Planning，JRP)是一种相对来说成本较高的需求获取方法，但也是一种十分有效的方法。

它通过联合各个关键用户代表、系统分析师、开发团队代表，通过有组织的会议来讨论需求。通常该会议的参与人数为6~18人，召开时间为1~5h。

在会议之前，应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后，按照以下步骤进行:

应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议开始时，针对所列举的问题进行逐项专题讨论。
对现有系统和类似系统的不足进行开放性交流。鼓励与会者在短时间内说出尽量多的想法，在这一过程中不对这些想法发表任何评论。
大家在此基础上对新的解决方案进行一番设想，在这个过程中，需要把这些想法、问题、不足记录下来，形成一个要点清单。
针对这个要点清单进行整理，明确优先级，并进行评审

主要原则

JRP的主要意图是收集需求，而不是对需求进行分析和验证。

实施IP时应把握以下主要原则:

在JRP实施之前，应制定详细的议程，并严格遵照议程进行。
按照既定的时间安排进行。
尽量完整地记录会议期间的内容。
在讨论期间尽量避免使用专业术语。
充分运用解决冲突的技能。
会议期间应设置充分的间歇时间。
鼓励团队取得一致意见。
保证参加 JRP的所有人员能够遵守事先约定的规则。

JRP将会起到群策群力的效果，对于一些最有歧义的问题、需求最不清晰的领域都是十分有用的一种方法。

这种方法最大的难度是会议的组织和相关人员的能力，要做到言之有物，氛开放，否则，将难以达到预想的效果。

11.2.6 需求记录技术

在开发过程中，有时候进行需求获取的人员和进行需求分析的人员不是同一个人（部门），因此，需要统一需求记录工具，以便所有人的获取结果是统一口径的。

任务卡片

各个项目的内容及解释如图11-1：

任务卡片还有一个增强版，如图11-2，增加问题点描述和解决方案提示

场景说明

有时候，很难总结出子任务和任务变体，因为需要对任务执行过程进行抽象，这时候可以用场景说明来对用户的描述进行整理。

场景说明就是用户对其工作场景和过程的详细描述。

用户故事

描述对用户有价值的功能，包含书面描述（用于计划和备忘），交谈（细化故事）和测试用例（验证故事实现）。在任何项目中，需要用户团队根据故事的重要性来安排开发工作，回答所有开发问题，编写所有的故事。在编写故事之前应该建立用户角色模型，必须包含对项目成功至关重要的角色，尽量保证所有用户对系统完全满意。
用户故事具有6个基本属性:独立性、可协商性、对用户有价值、可预测性、短小精悍和可测试性。

独立性。
- 尽可能避免故事之间存在依赖关系，因为依赖关系会产生优先级和规划问题
可协商性。
- 故事是可协商的，不是必须实现的书面合同或者需求。
对用户有价值。
- 确保每个故事对用户有价值的最好方式是让用户编写故事。
可预测性。
- 系统分析师应该能够预测(至少大致猜测)故事的规模，以及实现所需要的工作量。
短小精悍。
- 故事规模对实现有影响，哪种故事规模最合适，取决于开发团队的规模和能力，以及技术实现等方面。
可测试性。
- 所编写的故事必须是可测试的。

Volere白卡

一种类似于任务卡片的需求记录工具

用户故事和白卡定位的是最小的需求项，因此在实际应用中会导致量比较大，一般在敏捷方法中使用。

11.3 需求分析

将杂乱的用户需求整理成好的需求（具有二义性，完整性，一致性，可测试性，确定性，可跟踪性，正确性，必要性等特性）

11.3.1 需求分析的任务

把用户对开发软件提出的要求进行分析整理，确认后形成描述完整，清晰与规范的文档。

11.3.2 需求分析的方法

分析的方法有很多比如

结构化分析(Structured Analysis，SA)方法
面向对象的分析(Object-Oriented Analysis，OOA)方法
面向问题域的分析(Problem Domain Oriented Analysis，PDOA)方法。

PDOA

与 SA 方法和 OOA方法相比，PDOA方法更多地强调描述，而较少强调建模。它的描述大致分为以下两个部分:

关注问题域。用一个文档对含有的问题域进行相关的描述，并列出需要在该域中求解的问题列表，也就是需求列表。只有这个文档是在分析时产生的。
关注解系统(即系统实现)的待求行为。用一个文档对解系统的待求行为进行描述该文档将在需求定义阶段完成。

在 PDOA方法中，对整个过程有着清晰的定义:

收集基本的信息并开发问题框架，以建立问题域的类型。
在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述。
基于以上两点，收集并用文档说明新系统的需求。

从上面的描述中可以看出，问题框架是PDOA的核心元素，是将问题域分为一系列相互关联的子域，而一个子域可以是那些可能算是精选出来的问题域的一部分。

也可以把问题框架看作是开发上下文范围关系图，但不同的是，上下文范围关系图的建模对象是针对解系统，而问题框架则是针对问题域。

也就是说，问题框架的目标就是大量地获取更多有关问题域的信息。

方法的对比

SA 方法关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到可解决的思考方式。

SA方法本身隐含着几个基本假设，即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。SA方法应用的是科学方法中的因果律、归纳法和逻辑法，通过对现实世界中的问题域进行不断的“测量”和“分解”，直到得到问题域的逻辑模型。

OOA 方法则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA方法首先对问题域的事物的“外在表象”进行观测，然后在逻辑世界中模拟出一个对应的逻辑对象,“断定”该对象和现实事物是一致的。随后，观测到的对象被记录入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模型。OOA方法建立的对象彼此之间通过接口来相互沟通，每传递一个消息即触发一个事件，并引起内部方法的执行。只有观测对象内部的时候，才能看到具体的属性和方法。否则，只能看到对象对外部开放的接口。

SA方法假定系统分析师理解问题域的全部，并且有能力正确地识别和分解问题。

而OOA方法既不假定系统分析师理解问题域的全部，也不假定其能够建立正确的抽象对象，它只承诺一种可以持续“观测并理解”的方法，以及“观测后建立”的对象和现实世界的外在表象是一致的。

11.4 结构化分析方法

基本思想：自顶向下，逐层分解，把大问题分解成一个个小问题

SA方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。

在实际工作中，一般使用E-R图表示数据模型，用DFD表示功能模型，用状态转换图(State Transform Diagram，STD)表示行为模型。

这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。

11.4.1 数据流图

DFD是SA方法中的重要工具。可以被认为是一个系统模型。

DFD的主要作用

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

DFD的基本符号

数据流
- 有名字的箭头
加工
- 对数据流的变换，一般用圆圈
数据存储
- 一般用直线段表示
外部实体（数据源以及数据终点）
- 系统之外的生产者或消费者，不能由计算机处理的部分

DFD的层次

SA方法的思路是依赖于DFD进行自顶向下的分析。

顶层图：

系统最高层结构的DFD。将整个待开发的系统表示为一个加工，将所有的外部实体和进出系统的数据流放在一张图中。

逐层分解

加工的编号，将以1,2,3为序列展开。对0层图上的加工进行再分解，称之为1层图，其编号规则是：1. 1, 1.2, 1.3.......

如何画DFD

DFD的绘制是一个自顶向下、由外到里的过程，通常按照以下几个步骤进行:

画系统的输入和输出:
1. 在图的边缘标出系统的输入数据流和输出数据流。这一步其实是决定研究的内容和系统的范围。
画 DFD的内部:
1. 将系统的输入、输出用一系列的处理连接起来，可以从输入数据流画向输出数据流，也可以从中间画出去。
为每一个数据流命名:
1. 命名的好坏与DFD的可理解性密切相关，应避免使用空洞的名字。
为加工命名:
1. 使用动宾短语为每个加工命名。

每画好一张 DFD，就需要进行检查和修改，检查和修改的原则如下:

DFD中的所有图形符号只限于前述4种基本图形元素，图上每个元素都必须有名字。
每个加工至少有一个输入数据流和一个输出数据流，而且要保持数据守恒。也就是，一个加工的所有输出数据流中的数据必须能从该加工的输入流中直接获得，或者通过该加工能产生的数据。一个加工的输出数据流不应与输入数据流同名，即使它们的组成完全相同。
在 DFD中，须按层给加工编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。
规定任何一个 DFD 子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。
- 这就是父图与子图的平衡。也就是说，父图中的某加工的输入/输出数据流必须与它的所有子图的输入/输出数据流在数量上和名字上相同。值得注意的是，如果父图中的一个输入/输出数据流对应于子图中的几个输入/输出数据流，而子图中组成这些数据流的数据项的全体正好是父图中的这一个数据流，那么它们仍然算是平衡的。
在整套DFD中，每个数据存储必须既有读的数据流，又有写的数据流。但是在某张子图中，可能只有读没有写，或者只有写没有读。
可以在 DFD 中加入物质流，帮助用户理解DFD，但不可夹带控制流。