第3章需求分析

6. 约束
设计约束或实现约束描述在设计或实现应用系统时应遵守
的限制条件。常见的约束有：精度；工具和语言约束；设 计约束；应该使用的标准；应该使用的硬件平台。
7
3.1.1 确定对系统的综合要求

7. 逆向需求
逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求，我们应该仅选取能澄清
输入/输出都要与原来相同 (2) 数据流图何时分解到头： 分解后使人考虑需写出程序代码时，就不应再分解了

24
细化数据流图

随着分析过程的进展，经过反复循环，分析员最终 得到对系统数据和功能要求的满意了解。 图3.1粗略地概括了上述分析过程。
图3.1 面向数据流自顶向下求精过程
25
性能需求指定系统必须满足的定时约束或容量约束，通常
包括速度(响应时间)、信息量速率、主存容量、磁盘容量、 安全性等方面的需求。
5
3.1.1 确定对系统的综合要求

3. 可靠性和可用性需求
可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可以使用系统的
程度。

4. 出错处理需求
30
3.3.2 软件需求规格说明



通过需求分析除了创建分析模型之外，还应该写出 软件需求规格说明书，它是需求分析阶段得出的最 主要的文档。 通常用自然语言完整、准确、具体地描述系统的数 据要求、功能需求、性能需求、可靠性和可用性要 求、出错处理需求、接口需求、约束、逆向需求以 及将来可能提出的要求。 自然语言的规格说明具有容易书写、容易理解的优 点，为大多数人所欢迎和采用。
3
3.1需求分析的任务

1.确定对系统的综合要求 2.分析系统的数据要求 3.导出系统的逻辑模型 4.修正系统开发计划 5.开发原型系统
4
3.1.1 确定对系统的综合要求

1. 功能需求
这方面的需求指定系统必须提供的服务。通过需求分析应
该划分出系统必须完成的所有功能。

2. 性能需求
构建原型的要点是，它应该实现用户看得见的功能(例如，
屏幕显示或打印报表)，省略目标系统的“隐含”功能(例 如，修改文件)。
14
3.1.5 开发原型系统

快速原型应该具备的第一个特性是“快速”。
快速原型的目的是尽快向用户提供一个可在计算机上运行
的目标系统的模型，以便使用户和开发者在目标系统应该 “做什么”这个问题上尽可能快地达成共识。因此，原型 的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原 型的功能，不会使用户对产品的行为产生误解，就不必管 它们。
真实需求且可消除可能发生的误解的那些逆向需求。

8. 将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但是
据分析将来很可能会提出来的要求。 这样做的目的是，在设计过程中对系统将来可能的扩 充和修改预做准备，以便一旦确实需要时能比较容易 地进行这种扩充和修改。
8
3.1.2 分析系统的数据要求
3.4节将介绍的实体-联系图，描绘数据对象及数据对象之
间的关系，是用于建立数据模型的图形。 2.4节讲过的数据流图，描绘当数据在软件系统中移动时 被变换的逻辑过程，指明系统具有的变换数据的功能，因 此，数据流图是建立功能模型的基础。 3.6节将介绍的状态转换图(简称为状态图)，指明了作为外 部事件结果的系统行为。 为此，状态转换图描绘了系统的各种行为模式(称为 “状态”)和在不同状态间转换的方式。状态转换图是 行为建模的基础。
17
3.1.5 开发原型系统
(3) 形式化规格说明和原型环境
在过去的20多年中，人们已经研究出许多形式化规格
说明语言和工具(参见第4章)，用于替代自然语言规格 说明技术。 今天，形式化语言的倡导者正在开发交互式环境，以 便可以调用自动工具把基于形式语言的规格说明翻译 成可执行的程序代码，用户能够使用可执行的原型代 码去进一步精化形式化的规格说明。

为了快速地构建和修改原型，通常使用下述3种方法 和工具：
(1) 第四代技术（即用软件直接生成需要的代码程序 ）
第四代技术包括众多数据库查询和报表语言、程序和
应用系统生成器以及其他非常高级的非过程语言。 第四代技术使得软件工程师能够快速地生成可执行的 代码，它们是较理想的快速原型工具。
16

必须请用户对上述分析过程中得出的结果仔细地复 查。
数据流图是帮助复查的极好工具。 复查过程验证了已知的元素，补充了未知的元素，填补了
文档中的空白。
23
细化数据流图

为了追踪更详细的数据流，分析员应该把数据流图 扩展到更低的层次。通过功能分解可以完成数据流 图的细化。
新的数据流图使系统元素之间的关系变得更清楚。 对新数据流图的分析追踪可能产生新的问题。 (1)细化时要保持信息连续性
系统对环境错误应该怎样响应 应用系统发现它自己犯下一个错误时所采取的行动。
应该有选择地提出这类出错处理需求。对应用系统本
身错误的检测应该仅限于系统的关键部分，而且应该 尽可能少。
6
3.1.1 确定对系统的综合要求

5. 接口需求
接口需求描述应用系统与它的环境通信的格式。常见的接
口需求有：用户接口需求；硬件接口需求；软件接口需求； 通信接口需求。
31
3.3.2 软件需求规格说明

为了消除用自然语言书写的软件需求规格说明书中 可能存在的不一致、歧义、含糊、不完整及抽象层 次混乱等问题，有些人主张用形式化方法描述用户 对软件系统的需求，第4章将简要地介绍形式化说明 技术。

快速原型应该具备的第二个特性是“容易修改”。
如果原型的第一版不是用户所需要的，就必须根据用户的
意见迅速地修改它，构建出原型的第二版，以更好地满足 用户需求。在实际开发软件产品时，原型的“修改—试 用—反馈”过程可能重复多遍，如果修改耗时过多，势必 延误软件开发时间。
15
3.1.5 开发原型系统
26
修正开发计划
数据要求
数据字典 (描述数据结构的)层次方框图或Warnier图 对存储信息(文件/数据库)分解结果 用户系统描述(从用户角度描述) 功能、性能、使用方法/步骤、用户的责任(消除“子 系统分析员”与“用户”之间的误解) 修正开发计划(成本、资源使用、进度)


技术审查和管理复审
27
3.3 分析建模与规格说明

为了更好地理解复杂事物，人们常常采用建立事物 模型的方法。
所谓模型，就是为了理解事物而对事物做出的一种抽象，
是对事物的一种无歧义的书面描述。 通常，模型由一组图形符号和组织这些符号的规则组成。
28
3.3 分析建模与规格说明

结构化分析实质上是一种创建模型的活动。
19
3.2 需求分析过程


1.沿数据流图回溯 2.用户复查 3.细化数据流图 4.修正开发计划 5.书写文档 6.技术审查和管理复审
20
沿数据流图回溯

通常从数据流图的输出端着手分析。
输出数据是由哪些元素组成的呢? 每个输出数据元素又是从哪里来的呢?
沿数据流图从输出端往输入端回溯，应该能够确定每
第3章
需求分析
3.1 需求分析的任务 3.2 需求分析过程 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结 习题
1
3.1需求分析的任务

需求分析的基本任务是:
准确地回答“系统必须做什么?”这个问题。 确定系统必须完成哪些工作，也就是对目标系统提出完整、
10
3.1.2 分析系统的数据要求

3.数据结构规范化
软件系统经常使用各种长期保存的信息，这些信息通常以
一定方式组织并存储在数据库或文件中，为减少数据冗余， 避免出现插入异常或删除异常，简化修改数据的过程，通 常需要把数据结构规范化(见3.5节)。
11
3.1.3 导出系统的逻辑模型

通常用数据流图（建立功能模型）、实体-联系图 （建立数据模型）、状态转换图（建立行为模型）、 数据字典和主要的处理算法描述这个逻辑模型。
2
需求分析方法的准则





尽管目前有许多不同的用于需求分析的结构化分析 方法，但是，所有这些分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这条准则应 该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要求建立 功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条准 则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行分解， 用层次的方式展示细节。


任何一个软件系统本质上都是信息处理系统，系统 必须处理的信息和系统应该产生的信息在很大程度 上决定了系统的面貌，对软件设计有深远影响，因 此，必须分析系统的数据要求，这是软件需求分析 的一个重要任务。 1.建立数据模型
分析系统的数据要求通常采用建立数据模型的方法(见3.4
节实体-联系图)。
9
准确、清晰、具体的要求。

需求分析的结果：
系统分析员应该写出软件需求规格说明书，以书面形式准
确地描述软件需求。

需求分析的出发点:
可行性研究的结果(文档)(尤其是数据流图) 需求分析要将数据流图具体化，从而产生更详细的数据流
图、数据字典和一组简明的算法描述。

需求分析非常重要，要精心完成，否则后面的工作 很可能白费。
3.1.2 分析系统的数据要求