第3章需求分析

3.1.2 分析系统的数据要求

2.描绘数据结构
复杂的数据由许多基本的数据元素组成，数据结构表示数
据元素之间的逻辑关系。常常利用图形工具辅助描绘数据 结构。 常用的图形工具有层次方框图和Warnier图，在本章第 3.7节中将简要地介绍这两种图形工具。 利用数据字典可以全面准确地定义数据，但是数据字 典的缺点是不够形象直观。
3
3.1需求分析的任务

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

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

2. 性能需求

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

7. 逆向需求
逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求，我们应该仅选取能澄清
构建原型的要点是，它应该实现用户看得见的功能(例如，
屏幕显示或打印报表)，省略目标系统的“隐含”功能(例 如，修改文件)。
14
3.1.5 开发原型系统

快速原型应该具备的第一个特性是“快速”。
快速原型的目的是尽快向用户提供一个可在计算机上运行
的目标系统的模型，以便使用户和开发者在目标系统应该 “做什么”这个问题上尽可能快地达成共识。因此，原型 的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原 型的功能，不会使用户对产品的行为产生误解，就不必管 它们。
26
修正开发计划
数据要求
数据字典 (描述数据结构的)层次方框图或Warnier图 对存储信息(文件/数据库Baidu Nhomakorabea分解结果 用户系统描述(从用户角度描述) 功能、性能、使用方法/步骤、用户的责任(消除“子 系统分析员”与“用户”之间的误解) 修正开发计划(成本、资源使用、进度)

18
3.2需求分析过程



软件系统本质上是信息处理系统，任何信息处理系 统的基本功能都是把输入数据转变成需要的输出信 息。 结构化分析方法就是面向数据流自顶向下逐步求精 进行需求分析的方法。 通过可行性研究已经得出了目标系统的高层数据流 图，需求分析的目标之一就是把数据流和数据存储 定义到元素级。

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

为了追踪更详细的数据流，分析员应该把数据流图 扩展到更低的层次。通过功能分解可以完成数据流 图的细化。
新的数据流图使系统元素之间的关系变得更清楚。 对新数据流图的分析追踪可能产生新的问题。 (1)细化时要保持信息连续性

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



通过需求分析除了创建分析模型之外，还应该写出 软件需求规格说明书，它是需求分析阶段得出的最 主要的文档。 通常用自然语言完整、准确、具体地描述系统的数 据要求、功能需求、性能需求、可靠性和可用性要 求、出错处理需求、接口需求、约束、逆向需求以 及将来可能提出的要求。 自然语言的规格说明具有容易书写、容易理解的优 点，为大多数人所欢迎和采用。
性能需求指定系统必须满足的定时约束或容量约束，通常
包括速度(响应时间)、信息量速率、主存容量、磁盘容量、 安全性等方面的需求。
5
3.1.1 确定对系统的综合要求

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

4. 出错处理需求
个数据元素的来源，与此同时也就初步定义了有关的 算法。 补充未知元素或算法
21
沿数据流图回溯
通常把分析过程中得到的有关数据元素的信息记录在数据
字典中 把对算法的简明描述记录在IPO图(见3.7节)中。

通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位臵上。
22
用户复查

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

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

结构化分析实质上是一种创建模型的活动。
3.1.5 开发原型系统
(2) 可重用的软件构件
另外一种快速构建原型的方法，是使用一组已有的软
件构件(也称为组件)来装配(而不是从头构造)原型。 软件构件可以是数据结构(或数据库)，或软件体系结构 构件(即程序)，或过程构件(即模块)。必须把软件构件 设计成能在不知其内部工作细节的条件下重用。 应该注意，现有的软件可以被用作“新的或改进的” 产品的原型。
系统对环境错误应该怎样响应 应用系统发现它自己犯下一个错误时所采取的行动。
应该有选择地提出这类出错处理需求。对应用系统本
身错误的检测应该仅限于系统的关键部分，而且应该 尽可能少。
6
3.1.1 确定对系统的综合要求

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

为了消除用自然语言书写的软件需求规格说明书中 可能存在的不一致、歧义、含糊、不完整及抽象层 次混乱等问题，有些人主张用形式化方法描述用户 对软件系统的需求，第4章将简要地介绍形式化说明 技术。
输入/输出都要与原来相同 (2) 数据流图何时分解到头： 分解后使人考虑需写出程序代码时，就不应再分解了

24
细化数据流图

随着分析过程的进展，经过反复循环，分析员最终 得到对系统数据和功能要求的满意了解。 图3.1粗略地概括了上述分析过程。
图3.1 面向数据流自顶向下求精过程
25
2
需求分析方法的准则





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

修正开发计划
修正可行性研究时做出的计划

书写文档
有了功能、性能、定义的数据和算法后要用正式文档记
录下来 系统规格说明 (1)概貌、功能、性能、运行要求、将来可能的要求 (2)数据流图 (3)IPO图描述的算法 (4)用户需求和系统功能之间的参照关系(“用户的什 么需求”要用“系统的哪些功能”去实现) (5)设计约束(资源等各方面的限制因素)


任何一个软件系统本质上都是信息处理系统，系统 必须处理的信息和系统应该产生的信息在很大程度 上决定了系统的面貌，对软件设计有深远影响，因 此，必须分析系统的数据要求，这是软件需求分析 的一个重要任务。 1.建立数据模型
分析系统的数据要求通常采用建立数据模型的方法(见3.4
节实体-联系图)。
9
3.4节将介绍的实体-联系图，描绘数据对象及数据对象之
间的关系，是用于建立数据模型的图形。 2.4节讲过的数据流图，描绘当数据在软件系统中移动时 被变换的逻辑过程，指明系统具有的变换数据的功能，因 此，数据流图是建立功能模型的基础。 3.6节将介绍的状态转换图(简称为状态图)，指明了作为外 部事件结果的系统行为。 为此，状态转换图描绘了系统的各种行为模式(称为 “状态”)和在不同状态间转换的方式。状态转换图是 行为建模的基础。

快速原型应该具备的第二个特性是“容易修改”。
如果原型的第一版不是用户所需要的，就必须根据用户的
意见迅速地修改它，构建出原型的第二版，以更好地满足 用户需求。在实际开发软件产品时，原型的“修改—试 用—反馈”过程可能重复多遍，如果修改耗时过多，势必 延误软件开发时间。
15
3.1.5 开发原型系统
为了开发出复杂的软件系统，系统分析员
应该从不同角度抽象出目标系统的特性 使用精确的表示方法构造系统的模型 验证模型是否满足用户对目标系统的需求 在设计过程中逐渐把和实现有关的细节加进模型中 直至最终用程序实现模型。
29
3.3 分析建模与规格说明

根据本章开头讲述的结构化分析准则，需求分析过 程应该建立3种模型，它们分别是数据模型、功能模 型和行为模型。
第3章
需求分析
3.1 需求分析的任务 3.2 需求分析过程 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结 习题
1
3.1需求分析的任务

需求分析的基本任务是:
准确地回答“系统必须做什么?”这个问题。 确定系统必须完成哪些工作，也就是对目标系统提出完整、
当前系统的 逻辑模型 目标系统的 逻辑模型
当前系统的 物理模型 目标系统的 物理模型
12
3.1.4 修正系统开发计划

根据在分析过程中获得的对系统的更深入更具体的 了解，可以比较准确地估计系统的成本和进度，修 正以前制定的开发计划。
13
3.1.5 开发原型系统


正如第1章已经讲过的，快速建立软件原型是最准确、 最有效、最强大的需求分析技术。 快速原型就是快速建立起来的旨在演示目标系统主 要功能的可运行的程序。
19
3.2 需求分析过程


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

通常从数据流图的输出端着手分析。
输出数据是由哪些元素组成的呢? 每个输出数据元素又是从哪里来的呢?
沿数据流图从输出端往输入端回溯，应该能够确定每
17
3.1.5 开发原型系统
(3) 形式化规格说明和原型环境
在过去的20多年中，人们已经研究出许多形式化规格
说明语言和工具(参见第4章)，用于替代自然语言规格 说明技术。 今天，形式化语言的倡导者正在开发交互式环境，以 便可以调用自动工具把基于形式语言的规格说明翻译 成可执行的程序代码，用户能够使用可执行的原型代 码去进一步精化形式化的规格说明。
10
3.1.2 分析系统的数据要求

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

通常用数据流图（建立功能模型）、实体-联系图 （建立数据模型）、状态转换图（建立行为模型）、 数据字典和主要的处理算法描述这个逻辑模型。
真实需求且可消除可能发生的误解的那些逆向需求。

8. 将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但是
据分析将来很可能会提出来的要求。 这样做的目的是，在设计过程中对系统将来可能的扩 充和修改预做准备，以便一旦确实需要时能比较容易 地进行这种扩充和修改。
8
3.1.2 分析系统的数据要求
准确、清晰、具体的要求。

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

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

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