软件需求获取与结构化分析方法

0.1. 互动课堂

Click to host the seminar.

0.2. 本次课的目标

第二部分：结构化分析与设计方法

第3章：软件需求获取与结构化分析方法

• 需求获取与需求分析阶段的任务
• 结构化分析方法
• 系统需求规格说明
• 需求评审
• 需求管理

1. 需求获取与需求分析阶段的任务

1.1. 需求获取的任务和原则

需求获取的主要任务是与客户或用户沟通，了解

• 系统或产品的 目标是什么
• 客户或用户 想要实现什么
• 系统和产品 如何满足业务的要求
• 最终系统或产品 如何用于日常工作
• ……

没有真正从事过 需求获取及分析 工作的人很难相信，

获取并理解用户的 需求 是软件工程师所面对的最困难的任务之一 。

1.1.1. 需求获取涉及到的对象

需求获取涉及 客户 、 用户 及 开发方 。

• 客户 是投资软件的 单位或个人 ，也可能是 销售商 ，
• 用户 是 最终使用软件的人 。

现代软件大多都 不是单机软件 ， 软件的 用户数量 及 种类 往往很多。 客户或用户 往往 说不清自己到底需要什么 ， 不同用户的需求相互矛盾 或 单个用户前后表达相矛盾 的情况时有发生。

另外，如果负责需求获取的 软件工程师 对用户的工作领域不熟悉， 则会导致与用户交流时 不知说什么、问什么 ， 不能引导用户表达需求 ， 不能判别用户哪些需求正确、合理 ， 不能判断和解决用户需求中出现的矛盾 等。

1.1.2. 需求获取困难的原因归纳

• 系统的目标或范围问题 ：系统的 边界 不清楚， 如 哪些问题应由计算机系统解决 、 哪些问题应由手工方式解决 不明确。 有时，客户或用户的说明中带有多余的技术细节 。
• 需求不准确问题 ：客户或用户不能够完全确定 需要什么 ， 对其计算环境的能力和限制所知甚少 ， 对问题域没有完整的认识 ， 与软件专业人员在沟通上有问题。 同一客户或用户的不同人员提出的需求相冲突， 具有歧义性 。
• 需求的易变问题 ：在整个软件生存期内，软件需求会随着时间的推移 发生变化 。 一方面，人们对 事物的认识 会随着时间的推移而 不断全面和深入 ； 另一方面，用户的 组织结构 、 业务流程 及 外部业务环境 可能 发生变化 。

需求获取 除了需要有专业的 系统分析师 ，

还需要 客户 / 开发者 有效地 合作 才能成功。

1.1.3. 需求获取的任务

需求获取活动需要 解决的问题 概括起来有以下几项：

1. 发现和分析问题 ，并分析问题的 原因 / 结果 关系。
2. 与用户进行各种方式的 交流 ，并使用 调查研究方法 收集 信息 。
3. 按照三个成分即 数据 、 过程 和 接口 观察问题的不同侧面。
4. 将获取的需求 文档化 ，形式有 用例 、 决策表 、 决策树 等。

1.1.4. 需求获取应遵循的原则

需求获取应 遵循以下原则 ：

1. 深入浅出的原则 ：需求获取要尽可能 全面 、 细致 。 获取的需求是个 全集 ，目标系统真正实现的是个 子集 。 分析时的调研内容并不一定都纳入到新系统中，要弄清系统全局，方便以后的扩充。
2. 以流程为主线的原则 ：在与用户交流的过程中，应该用 流程 将所有的 内容 串起来。 如 信息 、 组织结构 、 处理规则 等，这样便于交流沟通。 流程 的描述既有 宏观描述 ，也有 微观描述 。

1.2. 需求获取的过程

1.2.1. 开发高层的业务模型

应用领域 ，即目标系统的 应用环境 ，如 银行 、 电信公司 、 书店 等。

• 如果系统分析员对相应领域有了充分了解，就可以 建立一个业务模型 ， 描述用户的 业务过程 ，确定用户的 初始需求 。
• 然后通过 迭代 ，更 深入地了解应用领域 ，之后再 对业务模型进行改进 。

1.2.2. 定义项目范围和高层需求

要想项目成功，离不开 项目利益相关方的支持 。

• 在项目开始之前，应当在 所有利益相关方 中建立一个 共同的愿景 ，即 定义项目范围 和 高层需求 。 项目范围描述 系统的边界 以及与 外部事物（包括组织、人、硬件设备、其他软件等） 的关系。
• 高层需求 不涉及过多的细节 ，主要表示 系统需求的概貌 。

1.2.3. 识别用户类和用户代表

为了将用户分为不同的 用户类 ， 需要根据 系统的不同用户之间在以下方面存在的差异 。

• 使用产品的 频率
• 用户在应用领域的 经验 和使用计算机系统的 技能
• 所用到的产品 功能
• 为支持业务过程所进行的 工作
• 访问 权限 和 安全级别
  • 普通用户
  • 来宾用户
  • 系统管理员
• ……

1.2.4. 获取具体的需求

确定了 项目范围和高层需求 ，并确定了 用户类及用户代表 后， 就需要获取 更具体 、 完整 和 详细 的需求。 具体需求的来源可以来自以下几种 典型的途径 。

• 与用户进行交流
• 现有产品或竞争产品的描述文档
• 系统需求规格说明
• 当前系统的问题报告和改进要求
• 市场调查和用户问卷调查
• 观察用户如何工作

1.2.5. 确定目标系统的业务工作流

针对当前待开发的应用系统，确定系统的 业务工作流 和主要的 业务规则 ， 采取 需求调研 的方法获取所需的信息。 例如，针对 信息系统的需求调研 方法如下：

• 调研用户的 组织结构 、 岗位设置 、 职责定义 ， 从功能上区分有多少个 子系统 ，划分系统的大致 范围 ，明确系统的 目标 。
• 调研每个子系统的 工作流程 、 功能 与 处理规则 ，收集 原始信息资料 ， 用数据流来表示 物流 、 资金流 、 信息流 三者的关系。
• 对调研内容事先准备，针对不同管理层次的用户询问不同的问题，列出 问题清单 。 将 操作层 、 管理层 、 决策层 的需求既 联系 又 区分 开来，形成一个需求的层次。

1.2.6. 需求整理与总结

• 必须对上面步骤取得的 需求资料 进行 整理 和 总结 ， 确定 对软件系统的 综合要求 ，即软件的 需求 。
• 并提出这些需求的 实现条件 ，以及需求应达到的 标准 。
• 这些需求包括
  • 功能需求
  • 性能需求
  • 环境需求
  • 可靠性需求
  • 安全保密要求
  • 用户界面需求
  • 资源使用需求
  • 软件成本消耗与开发进度需求
  • ……

1.3. 软件需求分析阶段的任务

需求获取 只是软件需求分析阶段的 第一步 ， 需求分析 严格地说也只是 需求分析阶段 的一个步骤。

需求分析阶段 的工作可分为4个步骤

• 需求 获取
• 需求 分析
• 需求 定义
• 需求 验证

1.3.1. 需求获取

通过 启发 、 引导 ， 从客户（或用户）那里得到的 原始需求 是他们的 业务要求（needs） ，记作 \(N\) 。 这是 分析之前获取的需求 ，其中可能存在一些实际问题。 这些问题只有通过 分析 才能得到解决， 直接把 获取的需求 \(N\) 作为 软件设计阶段的依据 将会 导致严重的后果 。

1.3.2. 需求分析

要认真地研究获取的需求，必须考虑以下方面：

1. 完整性 ：每项获取的需求都应给出 清楚的描述 ， 使得软件开发工作能够取得 设计和实现 该功能所需要的 全部必要信息 。
2. 正确性 ：获取的每项需求必须是 准确无误 的，并且需求描述 无歧义性 。
3. 合理性 ：各项 需求之间 、 软件需求与系统需求之间 应是协调一致的， 不应存在矛盾和冲突 。
4. 可行性 ：获取的每项需求必须具有 技术可行性 、 经济可行性 、 社会可行性 。
5. 充分性 ：获取的需求是否 全面 、 周到 。

由于 分析的过程 会对 获取的需求做部分调整 ， 也即从 获取的需求 \(N\) 中去掉了一些 \(a\) ，又补充了一些 \(c\) ， 从而得到 分析的需求 \(R_1\) （即 \(b+c\) ）。

1.3.3. 需求定义

作为软件开发的依据，必须将已 经过分析的需求 清晰 、 全面 、 系统 、 准确 地描述成 正式的文档 ， 这一步 定义需求 的工作就是 编写需求规格说明 。

1.3.4. 需求验证

为了确保已 定义的需求 \(R_2\) （需求规格说明）准确无误， 并能 被客户（或用户）理解和接受 ，需要对其进行 严格的评审 。 该评审一定要 有客户（或用户）参加 ，并且充分听取他们的意见 。 只有 经过评审的需求 才是 设计和实现 可依据的 验证的需求 \(R_3\) 。

2. 结构化分析方法

最有代表性的传统的分析建模方法称为 结构化分析（Structured Analysis, SA） 方法。 它是一种 面向数据流 进行 需求分析 的方法，最初于20世纪70年代由D.Ross提出， 后来又经过扩充，形成了今天的 结构化分析方法 的框架。

结构化分析方法 是一种 建模技术 ，它建立的 分析模型 如图所示。

2.1. 功能建模

功能建模 的思想就是用抽象模型的概念， 按照软件内部 数据传递、变换 的关系， 自顶向下 逐层分解， 直到找到满足功能要求的所有可实现的软件为止。 功能模型用 数据流图 来描述。

2.1.1. 数据流图的基本图形符号

• 多个数据流之间的关系

2.1.2. 环境图

环境图（context diagram） 也称为 顶层数据流图（或0层数据流图） ， 它仅包括一个数据处理过程，也就是要开发的目标系统。 环境图的作用是 确定系统在其环境中的位置 ， 通过确定系统的 输入 和 输出 与 外部实体 的关系 确定其边界 。

案例：招生系统

• 需求描述

学校首先公布 招生条件 ，考生根据自己的条件 报名 ， 之后系统进行资格审查，并给出 资格审查信息 ； 对于资格审查合格的考生可以参加 答卷 ， 系统根据学校提供的 试题及答案 进行自动判卷， 并给出 分数及答题信息 ，供考生 查询 ； 最后系统根据学校的 录取分数线 进行录取，并将 录取信息 发送给考生。

• 环境图

2.1.3. 数据流图的分层

稍微复杂一些的实际问题，在数据流图上常常出现十几个甚至几十个 加工 。 这样的数据流图看起来 不直观 ， 不易理解 。 分层的数据流图 能很好地解决这一问题。 按照系统的 层次结构 进行逐步分解， 并以 分层的数据流图 反映这种结构关系， 能清楚地表达整个系统，也容易理解。

• 招生系统的分层数据流图

• 数据流图的分层示意图

案例：订货系统

• 需求描述

某工厂采购部每天需要一张 订货报表 ，报表按 零件编号 排序， 表中列出所有需要再次订货的零件。 对于每个需要再次订货的零件应列出下列数据： 零件编号 ， 零件名称 ， 订货数量 ， 目前价格 ， 主要供应者 ， 次要供应者 。

零件 入库 或者 出库 称为 事务 ， 通过放在仓库中的操作终端把 事务 报告给订货系统。 当某种零件的 库存数量少于库存量临界值 时就再次订货。

• 0层：基本系统模型（突出源点 / 终点）

• 1层：功能级数据流图

• 2层 细化的数据流程图

2.1.4. 实例研究

银行储蓄系统的业务流程：

• 储户 填写的存款单或取款单由 业务员 键入系统；
• 如果是 存款 则系统记录存款人姓名、住址（或电话号码）、身份证号码、 存款类型、存款日期、到期日期、利率、密码（可选）等信息，并印出 存款单 给储户；
• 如果是 取款 而且开户时留有密码，则系统首先核对储户密码， 若密码正确或存款时未留密码，则系统计算利息并印出 利息清单 给储户。

要求画出 分层的数据流图 ，并细化到 2层数据流图 。

第1步：识别外部实体及输入输出数据流

• 外部实体 ： 储户 ， 业务员 。
• 输入数据 ： 在储户输入密码后，储户才直接与系统进行交互。 储户填写的存款或取款信息通过业务员键入系统， 可以将 存款及取款信息 抽象为事务。
• 输出数据 ： 存款单 ， 利息清单 。

第2步：画出环境图（顶层数据流图）

第3步：画出一层数据流图

第4步：画出二层数据流图

对一层图中的 处理存款 及 处理取款 进行进一步分解， 得到二层数据流图，即 处理存款的数据流图 和 处理取款的数据流图 。

• 处理存款的数据流图

• 处理取款的数据流图

分层DFD图的优点

• 便于实现 ： 采用 逐步细化 的扩展方法，可避免一次引入过多的细节，有利于 控制问题的复杂度 ；
• 便于使用 ： 用 一组图代替一张总图 ，方便 用户及软件开发人员阅读 。

画分层DFD的指导原则

1. 注意数据流图中成分的命名 ：
   • 为 数据流（或数据存储） 命名
     1. 名字 应代表整个数据流（或数据存储）的内容 ，而不是仅仅反映它的某些成分。
     2. 不要使用空洞的、缺乏具体含义的 名字（如“数据”、“信息”、“输入”之类）。
     3. 如果在为某个数据流(或数据存储)起名字时遇到了困难， 则很可能是因为 对数据流图分解 不恰当造成的， 应该试试重新分解，看是否能克服这个困难。
   • 为 处理 命名
     1. 通常 先为数据流命名，然后再为与之相关联的处理命名 。 这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。
     2. 名字应该 反映整个处理的功能 ，而不是它的一部分功能。
     3. 名字最好由 一个具体的及物动词加上一个具体的宾语组成 。 应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。
     4. 通常名字中 仅包括一个动词 ，如果必须用两个动词才能描述整个处理的功能， 则把这个处理再分解成两个处理可能更恰当些。
     5. 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑 重新分解 。
2. 注意父图和子图的平衡（balance / coherence） ： 在分层图中，每一层都是它 上层的子图 ，同时又是它 下层的父图 。 所谓的 平衡 ，就是指 父图和子图的输入和输出数据应分别保持一致 。
3. 区分局部文件和局部外部项 ：随着DFD图的分解，在下层DFD中可能出现父图中没有的 文件和外部项 。 一般来说，除底层DFD需画出全部的外部文件外，各中间层的DFD仅显示处于加工之间的接口文件， 而其余的文件均不必画出，以保持图面的简洁。
4. 掌握分解的速度 ： 一般来说，每一个加工每次可分为 2-4个 子加工，最多不得超过 7个 。
5. 遵守加工编号规则 ： 顶层 加工不编号， 第二层 的加工编号为 \(1, 2, 3, \dots, n\) ， 第三层 编号为 \(1.1, 1.2, 1.3, \dots, n.1, n.2, \dots\) ，依此类推。
6. 分解到什么程度 ： 至少 三层 ， 四、五层 为宜。 每个处理相对完整地实现一个功能，如果再分解就考虑具体实现了。

2.2. 数据建模

在结构化分析方法中，使用 实体-关系建模技术 来建立 数据模型 。 这种技术是在 较高的抽象层次（概念层） 上对 数据库结构 进行建模的流行技术。 实体-关系模型 表示为可视化的 实体-关系图（Entity-Relationship Diagram, ERD） ， 也称为 ER图 。图中仅包含三种相互关联的元素： 数据对象（实体） 、 描述数据对象的属性 及 数据对象彼此间相互连接的关系 。

2.2.1. 数据对象

数据对象 是目标系统所需要的 复合信息 的表示， 所谓复合信息是 具有若干不同属性 的信息。 在ER图中用 矩形 表示数据对象。 在实际问题中，数据对象（实体）可以是 外部实体 、 事物 、 角色 、 行为或事件 、 组织单位 、 地点或结构 等。

2.2.2. 属性

属性 定义数据对象的特征， 如数据对象 学生 的 学号 、 姓名 、 性别 、 专业 等， 课程 的 课程编号 、 课程名称 、 学分 等。 在ER图中用 椭圆 或 圆角矩形 表示属性， 并用 无向边 将属性与相关的数据对象连接在一起。

2.2.3. 关系

• 不同数据对象的实例之间是有关联关系的，在ER图上用 无向边 表示。
• 在无向边的两端应标识出关联实例的数量，也称为关联的 重数 。
• 从关联重数的角度可以将关联分为3种。
  1. 一对一（ \(1:1\) ）关联
  2. 一对多（ \(1:m\) ）关联
  3. 多对多（ \(m:n\) ）关联
• 实例关联还有 必须 和 可选 之分。

ER图中表示关联数量的符号

在ER图中用 圆圈 表示所关联的实例是 可选的 ，隐含表示 \(0\) ， 没有出现圆圈 就意味着是 必须的 。 而出现在连线上的 短竖线 可以看成是 \(1\) 。

几种关系的示例

关系及其属性的表示

关系 本身也可能有属性，这在多对多的关系中尤其常见。 如 学生和课程之间的关系 可起名为 选课 ，其 属性 应该有 学期 、 成绩 等。

• 关系及其属性的表示方法：
  • 在表示关系的无向边上再加一个 菱形框 ，
  • 并在菱形框中标明 关系的名字 ，
  • 关系的属性同样用 椭圆形 或 圆角矩形 表示，
  • 并用 无向边 将 关系 与其 属性 连接起来。

银行储蓄系统的ER图

2.3. 行为建模

状态转换图（简称状态图） 通过 描绘系统的状态 及 引起系统状态转换的事件 来表示 系统的行为 。状态图中使用的主要 符号 如下图所示。

2.3.1. 状态

• 状态 是任何可以被观察到的 系统行为模式 ， 一个状态代表系统的一种 行为模式 。 状态规定了系统对事件的 响应方式 。
• 在状态图中定义的状态可能有： 初态（初始状态） 、 终态（最终状态） 、 中间态 。
  • 初态 用 实心圆 表示，
  • 终态 用 牛眼图形 表示，
  • 中间态 用 圆角矩形 表示。
• 在一张状态图中只能有 一个 初态 ，而 终态 则可以有 多个 ，也可以 没有 。

2.3.2. 状态转换

• 状态图 中两个状态之间 带箭头的连线 称为 状态转换 。
• 状态的变迁通常是由 事件 触发的， 在这种情况下应在表示状态转换的箭头线上 标出触发转换的事件表达式 。
• 如果在箭头线上 未标明事件 ，则表示在源状态的内部活动执行完之后 自动触发转换 。

下图为计算机应用软件的启动过程， 在这个过程中 没有外部事件触发 ， 每个状态下的活动完成时， 状态发生转换 。

2.3.3. 事件

事件 是在某个特定时刻发生的事情， 它是对引起系统从 一个状态 转换到 另一个状态 的 外界事件的抽象 。

事件表达式的语法如下：

事件说明〔守卫条件〕／ 动作表达式

• 事件说明 的语法为： 事件名（参数表） 。
• 守卫条件 是一个布尔表达式。 如果同时使用 守卫条件 和 事件说明 ， 则 当且仅当事件发生且布尔表达式成立时，状态转换才发生 。 如果 只有守卫条件 没有事件说明，则 只要守卫条件为真，状态转换就发生 。
• 动作表达式 是一个 过程表达式 ，当 状态转换开始时执行该表达式 。

存款过程的状态图（考虑新开户）

取款过程的状态图

2.4. 数据字典

数据字典 以 词条方式 定义 在 数据模型 、 功能模型 和 行为模型 中 出现的 数据对象 及 控制信息 的 特性 ， 给出它们的准确定义，包括 数据流 、 加工 、 数据文件 、 数据元素 ， 以及 数据源点 和 数据汇点 等。 因此， 数据字典 成为把3种分析模型黏合在一起的 黏合剂 ，是分析模型的 核心 。

2.4.1. 词条描述

对于在数据流图中每一个被命名的图形元素均加以定义， 其内容包括 图形元素的名字 ， 图形元素的别名或编号 ， 图形元素类别 （如 加工 、 数据流 、 数据文件 、 数据元素 、 数据源点 或 数据汇点 等）、 描述 、 定义 、 位置 等。

数据流词条

• 数据流是 数据结构在系统内传播的路径 。 一个 数据流词条 应有以下几项内容：
  • 数据流名 ：要求与 数据流图 中该图形元素的名字一致。
  • 简述 ：简要介绍它产生的 原因 和 结果 。
  • 组成 ：数据流的 数据结构 。
  • 来源 ：数据流 来自哪个加工 或 作为哪个 数据源 的外部实体 。
  • 去向 ：数据流 流向哪个加工 或 作为哪个 数据汇点 的外部实体 。
  • 流通量 ：单位时间数据的 流通量 。
  • 峰值 ：流通量的 极限值 。

• 读者借书信息流数据字典

数据元素词条

• 数据流图中的每个数据结构都是由 数据元素 构成的， 数据元素是数据处理中 最小的 、 不可再分 的单位，它直接反映事物的某一特征。 组成数据结构的这些数据元素也必须在数据字典中给出描述。其描述需要以下信息：
  • 类型 ：数据元素分为 数字型 与 文字型 。 数字型 又分为 离散值 和 连续值 ， 文字的类型用 编码类型 和 长度 区分。
  • 取值范围 ： 离散值 的取值或是 枚举的 （如： \(3, 17, 21\) ）， 或是 介于上下界的一组数 （如： \(2..100\) ）； 连续值 一般是 有取值范围的实数集 （如： \(0.0..100.0\) ）。 对于文字型，文字的取值需 加以定义 。
  • 相关的 数据元素 及 数据结构 。

• 例子：图书号

数据存储文件词条

• 数据存储文件是 数据保存的地方 。一个数据存储文件词条应有以下几项内容：
  • 文件名 ：要求与数据流图中该图形元素的名字一致。
  • 简述 ：简要介绍存放的是什么数据。
  • 组成 ：文件的数据结构。
  • 输入 ：从哪些加工获取数据。
  • 输出 ：由哪些加工使用数据。
  • 存取方式 ：分为顺序、直接、关键码等不同存取方式（或以文件/数据库表的形式存取）。
  • 存取频率 ：单位时间的存取次数（用于数据设计时考虑优化）。

• 例子：图书信息表

加工词条

• 加工可以使用诸如 判定表 、 判定树 、 结构化语言 等形式表达。主要描述有：
  • 加工名 ：要求与数据流图中该 图形元素的名字 一致。
  • 编号 ：用以反映该加工的 层次 和 亲子 关系。
  • 简述 ：加工 逻辑 及 功能 简述。
  • 输入 ：加工的 输入数据流 。
  • 输出 ：加工的 输出数据流 。
  • 加工逻辑 ：简述 加工程序 、 加工顺序 。

数据源点及数据汇点词条

• 对于一个数据处理系统来说， 数据源点 和 数据汇点 应比较少。 如果过多则表明独立性差，人机界面复杂。定义数据源点和数据汇点时，应包括：
  • 名称 ：要求与数据流图中该外部实体的名字一致。
  • 简述 ：简要描述是什么外部实体。
  • 有关数据流 ：该实体与系统交互时涉及哪些数据流。
  • 数目 ：该实体与系统交互的次数。

• 例子：流通组

2.4.2. 数据结构描述

在数据字典的编制中，分析员最常用的描述数据结构的方式有 定义式 或 Warnier图 。

• 定义式 ： 在数据流图中， 数据流 和 数据文件 都具有一定的数据结构。 因此必须以一种 清晰 、 准确 、 无二义性 的方式来描述数据结构。
• Warnier图 ： 表示数据结构的另一种图形工具，它用 树形结构 来描绘数据结构。

数据结构定义式中的符号

归纳及举例

数据存储 读者信息 定义示例

数据项 读者类型 定义示例

数据存储 存折 格式示例

在数据字典中对 存折 的定义格式

• 存折 = 户名 + 所号 + 账号 + 开户日 + 性质 + (印密) + 1{存取行}50
• 所号 = “001”..“999”
• 户名 = 2{字母}24
• 账号 = “00000000001”..“99999999999”
• 开户日 = 年 + 月 + 日
• 性质 = “1”..“6”
• 印密 = (“0” | “000001”..“999999”)
• 存取行 = 日期 + (摘要) + 支出 + 存入 + 余额 + 操作 + 复核
• 日期 = 年 + 月 + 日
• 年 = “0001”..“9999”
• 月 = “01”..“12”
• 日 = “01”..“31”
• 摘要 = 1{字母}4
• 支出 = 金额
• 存入 = 金额
• 余额 = 金额
• 金额 = “0000000.01”..“9999999.99”
• 操作 = “00001”..“99999”
• 复核 = “00001”..“99999”
• 字母 = [“a”..“z”|“A”..“Z”]

用Warnier图表示 存折 的数据结构

例子：某旅馆电话服务描述

• 某旅馆电话服务如下：
  • 可以拨 分机号 和 外线号码 。
  • 分机号 是从7201至7299。
  • 外线号码 先拨9，然后是 市话号码 或 长话号码 。
  • 长话号码 是以 区号 和 市话号码 组成。
  • 区号 是从100到300中任意的数字串。
  • 市话号码 是以 局号 和 分机号 组成。
  • 局号 可以是455、466、888、552中任意一个号码。
  • 分机号 是任意长度为4的数字串。
• 写出在数据字典中，电话号码的数据条目的定义（即组成）。

例子：某旅馆电话服务数据字典

• 电话号码 = [分机号 | 外线号码]
• 分机号 = [7201..7299]
• 外线号码 = 9 + [市话号码 | 长话号码]
• 长话号码 = 区号 + 市话号码
• 区号 = [100..300]
• 市话 = 局号 + 分机号
• 局号 = [455 | 466 | 888 | 522]
• 分机号 = 4{数字}4

2.5. 加工规格说明

• 在对数据流图的分解中，位于层次树最低层的加工也称为 基本加工 或 原子加工 ， 对于每一个基本加工都需要进一步说明，这称为 加工规格说明 。
• 在编写基本加工的规格说明时，主要目的是要表达 做什么 ，而不是 怎样做 。 因此它应满足如下要求：
  1. 对数据流图的每一个 基本加工 ，必须有一个 加工规格说明 。
  2. 加工规格说明必须描述基本加工如何把输入数据流变换为输出数据流，即 加工规则 。
  3. 加工规格说明必须描述实现加工的 策略 而不是实现加工的细节。
  4. 加工规格说明中包含的信息应是 充足的 、 完备的 、 有用的 ，没有重复的多余信息。

2.5.1. 决策表（decision table）

• 决策表由4个部分组成：
  • 左上部分是 条件茬 ，在此区域列出了各种可能的 单个条件 ；
  • 左下部分是 动作茬 ，在此区域列出了可能采取的 单个动作 ；
  • 右上部分是 条件项 ，在此区域列出了针对 各种条件 的每一组条件 取值的组合 ；
  • 右下部分是 动作项 ，这些动作项与条件项紧密相关，它指出了在条件项的 各组取值 的组合情况下应 采取的动作 。

商店业务处理系统中 检查订货单 的决策表

改进的 检查订货单 的决策表

如果表中有 两条或更多 的处理规则具有相同的动作， 并且其 条件项 之间存在着某种 关系 ，就可设法将它们 合并 。

建立决策表的步骤

1. 列出与一个 具体过程 （或 模块 ）有关的所有 处理 。
2. 列出过程 执行期间 的所有 条件 （或所有 判断 ）。
3. 将特定条件 取值组合 与特定的 处理 相匹配，消去不可能发生的条件取值组合。
4. 将右部每一纵列规定为一个 处理规则 ，即对于某一条件取值组合将有什么 动作 。

2.5.2. 决策树（decision tree）

决策树（decision tree）也是用来 表达加工逻辑 的一种工具，有时侯它比决策表更 直观 。

• 检查订货单的决策树

• 某航空公司的行李收费标准：
  • 乘客 免费行李 不超过30公斤。
  • 超出部分 国内客头等舱 4/每公斤， 国内客其他舱 6/每公斤，
  • 国外客 是国内客的2倍， 残疾客 是正常客的一半。

• 航空公司行李收费的决策树

3. 系统需求规格说明

需求分析阶段的重要任务之一是根据分析的结果编写 软件需求规格说明 ， 软件需求规格说明经过 严格评审 并得到 用户确认 之后，作为这个阶段的最终成果。

3.1. 软件需求规格说明模板

按照 GB/T 8567-2006 《计算机软件文档编制规范》， 涉及软件需求规格说明的文档有 软件需求规格说明（SRS） 和 数据需求说明（DRD） 等。

• SRS 描述了 计算机软件配置项的需求 以及 为确保需求得到满足所使用的方法 。 从系统工程角度来看， 软件系统 只是计算机系统的一个 系统元素 ，它将作为 配置项 置于配置管理机制之下。 （参考教材第60页）
• DRD 描述了 在整个开发过程中所需处理的数据 ，以及 采集数据的要求 等。 （参考教材第61页）

国家标准全文公开系统 - GB/T 8567-2006 计算机软件文档编制规范

3.2. SRS和DRD的质量要求

• 完整性
• 无歧义性
• 一致性
• 可验证性
• 可修改性
• 可追踪性

4. 需求评审

软件评审 是软件过程中的 过滤器 。 也就是说，在软件工程过程的 不同阶段进行软件评审 ， 可以起到 发现并消除错误和缺陷 的作用。

4.1. 正式的需求评审

正式的技术评审（Formal Technique Review, FTR） 是最主要的 需求评审机制 。 一般要成立 评审小组 ，并采取 评审会议 的方式进行。 评审小组 包括 软件工程师 、 客户 、 用户 和 其他利益相关方 。

评审的主要内容可以归纳如下：

4.2. 需求评审中的常见风险

• 在需求评审的实施过程中可能会遇到的风险包括
  • 需求评审的参与者选取不当
  • 评审规模过大
  • 评审组规模过大
  • 评审时间过长

5. 需求管理

需求管理可 定义 为： 一种 获取 、 组织 并 记录 系统需求 的 系统化方案 ， 以及一个使 客户与项目团队 对 不断变更的系统需求 达成并保持一致 的过程。

需求管理的 目的 是在 客户 与 开发方 之间建立 对需求的共同理解 ， 维护 需求 与 其他工作成果 的 一致性 ，并 控制需求的变更 。

• 需求管理强调
  • 控制 对需求基线的 变动
  • 保持 项目计划与需求 一致
  • 控制 单个需求和需求文档的 版本 情况
  • 管理 需求和跟踪链之间的 联系 或 管理 单个需求和其他项目可交付工作产品之间的 依赖 关系
  • 跟踪 基线中需求的 状态

5.1. 需求跟踪

需求管理是一组活动，用于帮助项目组在项目进展的过程中 标识需求 、 控制需求 、 跟踪需求 ，并对需求变更进行管理。

• 标识需求 是指给每项需求赋予 唯一的标识符 。
• 一旦需求被标识，便开始建立多个 跟踪表 。
• 每个跟踪表将 标识的需求 与 系统或其环境 的一个或多个方面相关联。
• 典型的 跟踪表 如下：
  • 特征跟踪表 显示需求如何与重要的、客户可见的 系统/产品特征 相关联 。
  • 来源跟踪表 标识每个 需求 的 来源 。
  • 依赖跟踪表 指明 需求之间 是如何 相互关联 的。
  • 子系统跟踪表 按照需求支配的 子系统 对 需求分类 。
  • 接口跟踪表 显示需求如何与 内部 和 外部 的 系统接口关联 。

5.2. 需求变更管理

• 管理需求变更包括这样一些活动：
  • 设立 基线
  • 追踪每项需求的 历史
  • 确定哪些 依赖关系 值得追踪
  • 在相关项之间建立 可追踪关系
  • 维护 版本控制
  • ……
• 此外，建立 变更控制 或 批准流程 也很重要， 它要求由 指定的团队成员 来负责复审所有提议的变更， 以在全局的高度上对 变更需求 的 好处 和可能引起的 后果 进行 客观的 权衡和把握。

6. 课后作业

1. （习题3.4） 请根据以下描述画出某库存管理系统的数据流图。 该系统的数据流描述如下：
   1. 根据计划部门转来的收货通知单和已存在的物资编码文件，建立物资采购单流水账。
   2. 根据技术部门的物资验收报告和物资采购单流水账，更新物资台账文件。
   3. 对物资台账分类汇总，将结果存储与物资总账文件中。
   4. 物资出库：物资使用部门填写物资出库单，包括 物资编号、物资名称、物资数量、物资使用部分、负责人、经手人。 系统根据物资总账文件的库存情况判断是否能够出库， 如果能够出库，则记录出库单，并更新物资总账文件。
2. （习题3.6） 一家书店计划开发图书管理系统对书店的业务进行管理， 以提高管理人员及书店工作人员的工作效率，并方便顾客对图书进行检索。 针对以下书店管理系统的基本功能需求建立需求分析模型，包括数据流图（至少画出两层）和ER图。
   1. 采购管理：实现与供货商的图书采购、退货及结算管理，提供月统计报表及任意时间段的统计报表。
   2. 图书信息管理：记录每种图书的信息（包括ISBN号、书名、作者、出版社、出版日期、单价、版次、印次等）、 折扣及库存量，并提供简单的图书查询功能。
   3. 销售管理：实现图书销售功能，记录顾客购买的图书种类、数量，计算总价，打印销售小票，并付款。 提供日/月统计报表及任意时间段的统计报表。
   4. 用户管理：提供用户组（角色）及用户管理功能。