软件工程第3章--软件需求分析

(4) 可选 即一个分量是可有可无的(重复零次或一 次)。 虽然可以使用自然语言描述由数据元素组成数据的 关系，但是为了更加清晰简洁，建议采用下列符号： =意思是等价于(或定义为)； +意思是和(即，连接两个分量)； ［ ］意思是或(即，从方括弧内列出的若干个分量 中选择一个)，通常用“|”号隔开供选择的分量； { }意思是重复(即，重复花括弧内的分量)； ( )意思是可选(即，圆括弧里的分量可有可无)。
尽管目前有许多不同的用于需求分析的结构化 分析方法，但是，所有这些分析方法都遵守下 述准则：
(1) 必须理解并描述问题的信息域，根据这条准 则应该建立数据模型。
(2) 必须定义软件应完成的功能，这条准则要求 建立功能模型。
(3) 必须描述作为外部事件结果的软件行为，这 条准则要求建立行为模型。
(4) 必须对描述信息、功能和行为的模型进行分 解，用层次的方式展示细节。
3.4 实体-联系图
为了把用户的数据要求清楚、准确地描述出来，系 统分析员通常建立一个概念性的数据模型(也称为 信息模型)。概念性数据模型是一种面向问题的数 据模型，是按照用户的观点对数据建立的模型。它 描述了从用户角度看到的数据，它反映了用户的现 实环境，而且与在软件系统中的实现方法无关。
数据模型中包含3种相互关联的信息：数据对象、 数据对象的属性及数据对象彼此间相互连接的关系。
3.2.2 面向数据流自顶向下求精
软件系统本质上是信息处理系统，而任何信息处理系统的基本功 能都是把输入数据转变成需要的输出信息。 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析 的方法。通过可行性研究已经得出了目标系统的高层数据流图， 需求分析的目标之一就是把数据流和数据存储定义到元素级。为 了达到这个目标，通常从数据流图的输出端着手分析，这是因为 系统的基本功能是产生这些输出，输出数据决定了系统必须具有 的最基本的组成元素。
3.1.2 分析系统的数据要求
任何一个软件系统本质上都是信息处理系统， 系统必须处理的信息和系统应该产生的信息 在很大程度上决定了系统的面貌，对软件设 计有深远影响，因此，必须分析系统的数据 要求，这是软件需求分析的一个重要任务。 分析系统的数据要求通常采用建立数据模型 的方法.
3.1.3 导出系统的逻辑模型
3.1 需求分析的任务
3Fra Baidu bibliotek1.1 确定对系统的综合要求
1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求 分析应该划分出系统必须完成的所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束， 通常包括速度(响应时间)、信息量速率、主存容量、 磁盘容量、安全性等方面的需求。
第3章 软件需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 实体-联系图 3.4 状态转换图 3.5 数据流图 3.6 数据字典 3.7 小结
需求分析是软件定义时期的最后一个阶段，它的基 本任务是准确地回答“系统必须做什么?”这个问 题。 需求分析的任务还不是确定系统怎样完成工作，而 仅仅是确定系统必须完成哪些工作，也就是对目标 系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软 件需求规格说明书，描述软件需求。
数据流图的符号
数据存储和数据流都是数据，仅仅所处的状 态不同。 数据存储是处于静止状态的数据 数据流是处于运动中的数据。 通常在数据流图中忽略出错处理，也不包括 诸如打开或关闭文件之类的内务处理。数据 流图的基本要点是描绘“做什么”而不考虑 “怎样做”。
2.4.3 命名
数据流图中每个成分的命名是否恰当，直接影响数 据流图的可理解性。 1. 为数据流(或数据存储)命名 (1) 名字应代表整个数据流(或数据存储)的内容，而 不是仅仅反映它的某些成分。 (2) 不要使用空洞的、缺乏具体含义的名字(如“数 据”、“信息”、“输入”之类)。 (3) 如果在为某个数据流(或数据存储)起名字时遇到 了困难，则很可能是因为对数据流图分解不恰当造 成的，应该试试重新分解，看是否能克服这个困难。
2. 为处理命名
(1) 通常先为数据流命名，然后再为与之相关联的 处理命名。这样命名比较容易，而且体现了人类习 惯的“由表及里”的思考过程。
(2) 名字应该反映整个处理的功能，而不是它的一 部分功能。
(3) 名字最好由一个具体的及物动词加上一个具体 的宾语组成。应该尽量避免使用“加工”、“处理” 等空洞笼统的动词作名字。
2.4.4 用途
画数据流图的基本目的是利用它作为交流信息的工 具。分析员把他对现有系统的认识或对目标系统的 设想用数据流图描绘出来，供有关人员审查确认。 由于在数据流图中通常仅仅使用4种基本符号，而 且不包含任何有关物理实现的细节，因此，绝大多 数用户都可以理解和评价它。
数据流图应该分层，并且在把功能级数据流图细化 后得到的处理超过9个时，应该采用画分图的办法， 也就是把每个主要功能都细化为一张数据流分图， 而原有的功能级数据流图用来描绘系统的整体逻辑 概貌。
面向数据流自顶向下求精过程
2.4 数据流图
数据流图(DFD)是一种图形化技术，它描绘信息流 和数据从输入移动到输出的过程中所经受的变换。 在数据流图中没有任何具体的物理部件，它只是描 绘数据在软件中流动和被处理的逻辑过程。数据流 图是系统逻辑功能的图形表示，设计数据流图时只 需考虑系统必须完成的基本逻辑功能，完全不需要 考虑怎样具体地实现这些功能。
3. 可靠性和可用性需求
可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关，它量化了用户可以 使用系统的程度。
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。 在某些情况下，“出错处理”指的是当应用系 统发现它自己犯下一个错误时所采取的行动。 但是，应该有选择地提出这类出错处理需求。 我们的目的是开发出正确的系统
由数据元素组成数据的方式只有下述三种基本类型：
(1) 顺序 即以确定次序连接两个或多个分量； (2) 选择 即从两个或多个可能元素选取一个； (3) 重复 即把指定的分量重复零次或多次。 因此，可以使用上述3种关系算符定义数据字典中 的任何条目。为了说明重复次数，重复算符通常和 重复次数的上下限同时使用(当上下限相同时表示 重复次数固定)。当重复的上下限分别为1和0时， 可以用重复算符表示某个分量是可选的。
为了更好地理解复杂事物，人们常常采用建 立事物模型的方法。所谓模型，就是为了理 解事物而对事物做出的一种抽象，是对事物 的一种无歧义的书面描述。通常，模型由一 组图形符号和组织这些符号的规则组成。
结构化分析实质上是一种创建模型的活动。 需求分析过程应该建立3种模型。 数据模型 功能模型 行为模型
(4) 通常名字中仅包括一个动词，如果必须用两个 动词才能描述整个处理的功能，则把这个处理再分 解成两个处理可能更恰当些。
(5) 如果在为某个处理命名时遇到困难，则很可能 是发现了分解不当的迹象，应考虑重新分解。
数据源点/终点并不需要在开发目标系统的过程中 设计和实现，它并不属于数据流图的核心内容，只 不过是目标系统的外围环境部分(可能是人员、计 算机外部设备或传感器装置)。通常，为数据源点/ 终点命名时采用它们在问题域中习惯使用的名字 (如“采购员”、“仓库管理员”等)。
2.5.1 数据字典的内容
一般说来，数据字典应该由对下列4类元素 的定义组成： (1) 数据流 (2) 数据流分量(即数据元素) (3) 数据存储 (4) 处理
2.5.2 定义数据的方法
定义绝大多数复杂事物的方法，都是用被定义的事 物的成分的某种组合表示这个事物，这些组成成分 又由更低层的成分的组合来定义。从这个意义上说， 定义就是自顶向下的分解，所以数据字典中的定义 就是对数据自顶向下的分解。那么，应该把数据分 解到什么程度呢?一般说来，当分解到不需要进一 步定义，每个和工程有关的人也都清楚其含义的元 素时，这种分解过程就完成了。
举例：某程序设计语言规定，用户说明的标 识符是长度不超过8个字符的字符串，其中 第一个字符必须是字母字符，随后的字符既 可以是字母字符也可以是数字字符。 解答： 标识符=字母字符+字母数字串 字母数字串=0｛字母或数字｝7 字母或数字=［字母字符｜数字字符］
3.3 分析建模与规格说明
3.3.1 分析建模
情景分析技术的用处主要体现在下述两个方面：
(1) 它能在某种程度上演示目标系统的行为，从而 便于用户理解，而且还可能进一步揭示出一些分析 员目前还不知道的需求。
(2) 由于情景分析较易为用户所理解，使用这种技 术能保证用户在需求分析过程中始终扮演一个积极 主动的角色。需求分析的目标是获知用户的真实需 求，而这一信息的惟一来源是用户，因此，让用户 起积极主动的作用对需求分析工作获得成功是至关 重要的。
3.4.1 数据对象
数据对象是对软件必须理解的复合信息的抽象。所 谓复合信息是指具有一系列不同性质或属性的事物， 仅有单个值的事物(例如，宽度)不是数据对象。
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外，还应该写出 软件需求规格说明书，它是需求分析阶段得出的最 主要的文档。
通常用自然语言完整、准确、具体地描述系统的数 据要求、功能需求、性能需求、可靠性和可用性要 求、出错处理需求、接口需求、约束、逆向需求以 及将来可能提出的要求。自然语言的规格说明具有 容易书写、容易理解的优点，为大多数人所欢迎和 采用。
5. 接口需求
接口需求描述应用系统与它的环境通信的格式。常 见的接口需求有：用户接口需求；硬件接口需求； 软件接口需求；通信接口需求。
6. 约束
设计约束或实现约束描述在设计或实现应用系统时 应遵守的限制条件。在需求分析阶段提出这类需求， 并不是要取代设计(或实现)过程，只是说明用户或 环境强加给项目的限制条件。常见的约束有：精度； 工具和语言约束；设计约束；应该使用的标准；应 该使用的硬件平台。
2.5 数据字典
数据字典是关于数据的信息的集合，也就是对数据 流图中包含的所有元素的定义的集合。
任何字典最主要的用途都是供人查阅对不了解的条 目的解释，数据字典的作用也正是在软件分析和设 计的过程中给人提供关于数据的描述信息。
数据流图和数据字典共同构成系统的逻辑模型，没 有数据字典数据流图就不严格，然而没有数据流图 数据字典也难于发挥作用。只有数据流图和对数据 流图中每个元素的精确定义放在一起，才能共同构 成系统的规格说明。
7. 逆向需求
逆向需求说明软件系统不应该做什么。理论上有无 限多个逆向需求，我们应该仅选取能澄清真实需求 且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴， 但是据分析将来很可能会提出来的要求。这样做的 目的是，在设计过程中对系统将来可能的扩充和修 改预做准备，以便一旦确实需要时能比较容易地进 行这种扩充和修改。
（1）实体-联系图，描绘数据对象及数据对 象之间的关系，是用于建立数据模型的图形。
（2）数据流图，描绘当数据在软件系统中 移动时被变换的逻辑过程，指明系统具有的 变换数据的功能，因此，数据流图是建立功 能模型的基础。
（3）状态转换图(简称为状态图)，指明了作 为外部事件结果的系统行为。为此，状态转 换图描绘了系统的各种行为模式(称为“状 态”)和在不同状态间转换的方式。状态转换 图是行为建模的基础。
数据流图 实体-联系图 状态转换图 数据字典 主要的处理算法描述
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深 入更具体的了解，可以比较准确地估计 系统的成本和进度，修正以前制定的开 发计划。
3.2 与用户沟通获取需求的方法
3.2.1 访谈
访谈是最早开始使用的获取用户需求的技术，也是 迄今为止仍然广泛使用的需求分析技术。 访谈分别是正式的和非正式的访谈。 (1)正式访谈时，系统分析员将提出一些事先准备好 的具体问题。 (2)在非正式访谈中，分析员将提出一些用户可以自 由回答的开放性问题，以鼓励被访问人员说出自己 的想法。