结构化分析与设计方法

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

软件工程 第二部分 第3章，主讲人：李欣

Created: 2024-03-05 Tue 16:42

0.1. 互动课堂

Click to host the seminar.

0.2. 签到

https://dash.memopixel.com/tool/attendance/

0.3. 本次课的目标

  • 第二部分：结构化分析与设计方法
    • 第3章：软件需求获取与结构化分析方法
      • 需求获取 与 需求分析 阶段的任务
      • 结构化分析方法
      • 系统需求规格说明
      • 需求评审
      • 需求管理

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

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

需求获取 的主要任务是

  • 与客户或用户沟通，了解
    1. 客户或用户
      • 想要实现什么
    2. 系统和产品
      • 目标是什么
      • 如何满足业务的要求
      • 如何用于日常工作
      • ……

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

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

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

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

  • 客户 是投资软件的 单位或个人 ，也可能是 销售商 ，
  • 用户 是 最终使用软件的人 。
  • 现代软件大多都不是单机软件，软件的 用户 数量 及 种类 往往很多。
  • 客户 或 用户 往往说不清自己到底需要什么，经常发生以下情况：
    • 不同用户的需求 相互矛盾 ；
    • 单个用户的表达 前后矛盾 。
  • 负责需求获取的 软件工程师 对用户的工作领域不熟悉的情况也会导致与用户交流时，
    • 不知 说 什么、 问 什么；
    • 不能 引导 用户表达需求；
    • 不能 判别 用户哪些需求正确、合理；
    • 不能 判断 和 解决 用户需求中出现的矛盾。

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

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

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

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

1.1.3. 需求获取活动中解决问题的手段和应遵循的原则

需求获取活动中解决问题的手段
  1. 发现 和 分析 问题，并分析问题的 原因 与 结果 之间的关系。
  2. 与用户进行各种方式的 交流 ，并使用 调查研究方法 收集 信息 。
  3. 按照三个成分即 数据 、 过程 和 接口 观察 问题的不同侧面。
  4. 将获取的需求 文档化 ，形式有 用例 、 决策表 、 决策树 等。
需求获取活动中应遵循的原则
  1. 深入浅出的原则 ：需求获取要尽可能 全面 、 细致 。
    • 获取的需求是个 全集 ，目标系统真正实现的是个 子集 。
    • 分析时的调研内容并不一定都纳入到新系统中，要弄清系统全局，方便以后的扩充。
  2. 以流程为主线的原则 ：在与用户交流的过程中，应该用 流程 将所有的 内容 串起来。 如 信息 、 组织结构 、 处理规则 等，这样便于交流沟通。 流程 的描述既有 宏观描述 ，也有 微观描述 。

1.2. 需求获取的过程

对于 不同规模 及 不同类型 的项目，需求获取的过程不会完全一样。 下面给出需求获取过程的 参考步骤 。

步骤1 开发高层的业务模型
  • 了解 应用领域 ，即目标系统的 应用环境 ，如 银行 、 电信公司 、
    书店 等。
  • 系统分析员对相应领域有了充分了解后，就可以
    • 建立 一个 业务模型 ，
    • 描述 用户的 业务过程 ，
    • 确定 用户的 初始需求 。
  • 然后通过 迭代 ，更深入地了解应用领域，之后再对 业务模型 进行 改进 。
步骤2 定义项目范围和高层需求
  • 要想项目成功，离不开项目利益相关方的支持。 在项目开始之前，应当在所有利益相关方中 建立 一个共同的 愿景 ，即 定义 项目范围 和
    高层需求 。
    • 项目范围 描述 系统的边界 以及与 外部事物 （包括 组织 、 人 、 硬件设备 、 其他软件 等）的关系。
    • 高层需求 不涉及过多的细节，主要表示 系统需求的概貌 。
步骤3 识别用户类和用户代表
  • 为了将用户分为不同的 用户类 ， 需要根据 系统的不同用户之间在以下方面存在的差异 ：
    • 使用产品的 频率
    • 用户在应用领域的 经验 和使用计算机系统的 技能
    • 所用到的产品 功能
    • 为支持业务过程所进行的 工作
    • 访问 权限 和 安全级别
      • 普通用户
      • 来宾用户
      • 系统管理员
    • ……
步骤4 获取具体的需求
  • 确定了 项目范围 和 高层需求 ，并确定了 用户类 及 用户代表 后， 就需要获取更 具体 、 完整 和 详细 的需求。 具体需求的来源可以来自以下几种 典型的途径 。
    • 与用户进行交流
    • 现有产品或竞争产品的描述文档
    • 系统需求规格说明
    • 当前系统的问题报告和改进要求
    • 市场调查和用户问卷调查
    • 观察用户如何工作
步骤5 确定目标系统的业务工作流
  • 针对当前待开发的应用系统，确定系统的 业务工作流 和主要的
    业务规则 ， 采取 需求调研 的方法获取所需的信息。 例如，针对 信息系统的需求调研 方法如下：
    • 调研 用户的 组织结构 、 岗位设置 、 职责定义 ， 从功能上 区分 有多少个 子系统 ， 划分 系统的大致 范围 ， 明确 系统的 目标 。
    • 调研 每个子系统的 工作流程 、 功能 与 处理规则 ， 收集
      原始信息资料 ， 用 数据流 来 表示 物流 、 资金流 、 信息流 三者的关系。
    • 对调研内容事先准备，针对不同管理层次的用户 询问 不同的 问题 ， 列出 问题清单 。 将 操作层 、 管理层 、 决策层 的需求既 联系 又 区分 开来，形成一个需求的层次。
步骤6 需求整理与总结
  • 必须对上面步骤取得的 需求资料 进行 整理 和 总结 ， 确定 对软件系统的 综合要求 ，即软件的 需求 。
  • 并 提出 这些需求的 实现条件 ，以及需求应达到的 标准 。
  • 这些需求包括：
    • 功能需求
    • 性能需求
    • 环境需求
    • 可靠性需求
    • 安全保密要求
    • 用户界面需求
    • 资源使用需求
    • 软件成本消耗与开发进度需求
    • ……

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

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

%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
flowchart LR
    A(("获取")) -->|N| B(("分析"))
    B --> |R1| C(("定义"))
    C --> |R2| D(("验证"))
    D --> |R3| E((" "))
    style E stroke: none
    style E fill: none

requirements-analysis-steps.svg

Figure 1: 软件需求分析阶段的工作步骤

Table 1: 软件需求分析各阶段的结果
结果 N R1 R2 R3
需求状态 获取的需求 分析的需求 定义的需求 验证的需求
需求获取
  • 通过 启发 、 引导 ， 从客户（或用户）那里得到的 原始需求 是他们的 业务要求（needs） ，记作 \(N\) 。
  • \(N\) 是分析之前 获取的需求 ，其中可能存在一些实际问题。
  • \(N\) 中存在的问题只有通过 分析 才能得到解决， 直接把 获取的需求 \(N\) 作为软件设计阶段的依据将会导致严重的后果 。
需求分析
  • 要认真地研究获取的需求，必须考虑以下方面：
    1. 完整性 ：每项获取的需求都应给出 清楚的描述 ， 使得软件开发工作能够取得 设计和实现 该功能所需要的 全部必要信息 。
    2. 正确性 ：获取的每项需求必须是 准确无误 的，并且需求描述 无歧义性 。
    3. 合理性 ：各项 需求之间 、 软件需求与系统需求之间 应是协调一致的， 不应存在矛盾和冲突 。
    4. 可行性 ：获取的每项需求必须具有 技术可行性 、 经济可行性 、 社会可行性 。
    5. 充分性 ：获取的需求是否 全面 、 周到 。

requirements-n-and-r1.svg

Figure 2: 获取的需求不同于分析的需求示意图

  • \(N\): 获取的需求
  • \(R_1\): 分析的需求
  • \(a\): 经分析去掉的部分
  • \(b\): 经分析保留的部分
  • \(c\): 经分析补充的部分

分析 的过程会对 获取 的需求做部分 调整 ，即：

  • 从 获取的需求 \(N\) 中 去掉 一些 \(a\) ，
  • 补充 一些 \(c\) ，
  • 从而 得到 分析的需求 \(R_1\) （即 \(b+c\) ）。
需求定义
  • 作为软件开发的依据，必须将已 经过分析的需求 清晰 、 全面 、 系统 、 准确 地 描述 成 正式的文档 ，
  • 这一步定义需求的工作是 编写 需求规格说明 。
需求验证
  • 为了确保已 定义的需求 \(R_2\) （ 需求规格说明 ）准确无误， 并能被客户（或用户） 理解 和 接受 ，需要对其进行严格的 评审 。
  • 评审一定要有客户（或用户）参加，并且充分听取他们的意见。 只有 经过评审的需求 才是设计和实现 可依据 的 验证的需求 \(R_3\) 。

2. 结构化分析方法

最有代表性的传统的分析建模方法称为 结构化分析（Structured Analysis, SA） 方法。

  • 结构化分析方法 是：
    • 一种 面向数据流 进行 需求分析 的 方法 ，最初于20世纪70年代由D.Ross提出， 后来又经过扩充，形成了今天的结构化分析方法的框架。
    • 一种 建模技术 ，它建立的分析模型如图所示。

structured-analysis.png

Figure 3: 结构化分析模型

2.1. 功能建模

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

  • 功能模型用 数据流图 来描述。

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

dfd-marks.png

Figure 4: 数据流图的基本图形符号

dfd-relationships.png

Figure 5: 多个数据流之间的关系

2.1.2. 环境图

环境图（context diagram） 也称为 顶层数据流图（或0层数据流图） ， 它仅包括 一个数据处理过程 ，也就是要开发的 目标系统 。

context-diagram.png

Figure 6: 环境图

环境图的作用
  • 确定 系统在其环境中的 位置 ，
  • 通过 确定 系统的 输入 和 输出 与 外部实体 的 关系 确定 其 边界 。
案例 招生系统 的需求描述
  • 学校 首先公布 招生条件 ， 考生 根据自己的条件 报名 ，
  • 之后 系统 进行资格审查，并给出 资格审查信息 ；
  • 对于资格审查合格的 考生 可以参加 答卷 ，
  • 系统 根据 学校 提供的 试题及答案 进行自动判卷， 并给出 分数 及
    答题信息 ，供考生 查询 ；
  • 最后 系统 根据 学校 的 录取分数线 进行录取，并将 录取信息 发送给考生。
案例 招生系统 的环境图

dfd-sample-context-diagram.png

Figure 7: 招生系统的环境图

2.1.3. 数据流图的分层

稍微复杂一些的实际问题，在数据流图上常常出现十几个甚至几十个 加工 。 这样的数据流图看起来 不直观 ， 不易理解 。

  • 分层的数据流图 能很好地解决这一问题。
    • 按照系统的 层次结构 进行逐步分解，并以 分层的数据流图 反映这种结构关系， 能清楚地表达整个系统，也容易理解。
案例 招生系统 的分层数据流图

dfd-sample-splited-layers.png

Figure 8: 招生系统的分层数据流图

数据流图的分层示意图

dfd-layers.png

Figure 9: 数据流图的分层

案例 订货系统 的需求描述
  • 某工厂采购部每天需要一张 订货报表 ，报表按零件编号排序，
  • 表中列出所有需要再次订货的零件。
  • 对于每个需要再次订货的零件应列出下列数据：
    • 零件编号 ， 零件名称 ， 订货数量 ， 目前价格 ，
    • 主要供应者 ， 次要供应者 。
  • 零件入库或者出库称为 事务 ， 通过放在仓库中的操作终端把事务报告给 订货系统 。
  • 当某种零件的库存数量少于库存量临界值时就再次订货。
案例 订货系统 的0层数据流图

dfd-sample-layer-0.png

Figure 10: 订货系统的0层数据流图（基本系统模型，突出源点、终点）

案例 订货系统 的1层数据流图

dfd-sample-layer-1.png

Figure 11: 订货系统的1层数据流图（功能级数据流图）

案例 订货系统 的2层数据流图

dfd-sample-layer-2.png

Figure 12: 订货系统的2层数据流图（细化的数据流程图）

2.1.4. 实例研究

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

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

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

第1步：识别外部实体及输入输出数据流
  • 外部实体 ： 储户 、 业务员 。
  • 输入数据 ： 在储户输入 密码 后，储户才直接与 系统 进行交互。 储户填写的存款或取款信息通过业务员键入系统， 可以将存款及取款信息抽象为 事务 。
  • 输出数据 ： 存款单 、 利息清单 。
第2步：画出环境图（顶层数据流图）

bank-system-context-diagram.png

Figure 13: 银行储蓄系统的环境图

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

bank-system-layer-1.png

Figure 14: 银行储蓄系统的一层数据流图

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

bank-system-layer-2-deposit.png

Figure 15: 处理存款的数据流图

bank-system-layer-2-withdraw.png

Figure 16: 处理取款的数据流图

2.1.5. 分层DFD图的优点

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

2.1.6. 画分层DFD的指导原则

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

2.2. 数据建模

在结构化分析方法中，使用 实体-关系建模技术 来建立 数据模型 。 这种技术是在 较高的抽象层次（概念层） 上对 数据库结构 进行建模的流行技术。

实体-关系模型 表示为可视化的 实体-关系图（Entity-Relationship Diagram, ERD） ， 也称为 ER图 。

  • ER图 中仅包含三种相互关联的元素：
    • 数据对象 （ 实体 ）
    • 描述数据对象的 属性
    • 数据对象彼此间相互连接的 关系

2.2.1. 数据对象

  • 数据对象 是目标系统所需要的 复合信息 的表示，
    • 所谓复合信息是 具有若干不同属性 的信息。
  • 在ER图中用 矩形 表示数据对象。

在实际问题中，数据对象（实体）可以是：

  • 外部实体
  • 事物
  • 角色
  • 行为或事件
  • 组织单位
  • 地点或结构
  • ……

2.2.2. 属性

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

er-properties.png

Figure 17: 属性的表示

2.2.3. 关系

关联关系的表示方式
  • 不同数据对象的实例间存在的 关联关系 ，在ER图上用 无向边 表示。
    • 在无向边上可以标明 关系 的 名字 ，也可以不标名字。
    • 在无向边两端应标出 关联实例 的 数量 （关联的 多重性 ）。
关联关系的种类（关联数量的角度）
  1. 一对一（ \(1:1\) ）关联
    • 系 和 系主任 、 大学 和 大学校长
  2. 一对多（ \(1:m\) ）关联
    • 班级 和 班干部
  3. 多对多（ \(m:n\) ）关联
    • 学生 和 课程
关联关系的可选性
  • 实例关联还有 必须 和 可选 之分。
    • 一所 大学 必须有一名 校长 ； 一个学期里有的 课程 可能没有 学生 选，个别 学生 也可能因特殊原因没选任何 课程 。
关联数量的表示及关联关系的种类
  • 在ER图中用 圆圈 表示所关联的实例是 可选 的，隐含表示 \(0\) ，
  • 没有出现圆圈 就意味着是 必须 的。
  • 而出现在连线上的 短竖线 可以看成是 \(1\) 。

er-relationship-number.png

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

er-relationship-example.png

Figure 19: 几种关系的示例

关系及其属性的表示
  • 关系 本身也可能有 属性 ，这在多对多的关系中尤其常见。
    • 如学生和课程之间的 关系 可起名为 选课 ，
    • 其 属性 应该有 学期 、 成绩 等。
  • 关系 及其 属性 的表示方法为：
    • 在表示关系的无向边上再加一个 菱形框 ，
    • 并在菱形框中标明 关系 的名字，
    • 关系的 属性 同样用 椭圆形 或 圆角矩形 表示，
    • 并用 无向边 将 关系 与其 属性 连接起来。

er-relationship-properties.png

Figure 20: 关系及其属性的表示

银行储蓄系统的ER图

er-bank-system.png

Figure 21: 银行储蓄系统的ER图

2.3. 行为建模

  • 状态转换图（简称状态图） 通过描绘

    1. 系统的 状态
    2. 引起系统状态转换的 事件

    来表示系统的 行为 。

state-diagram-marks.png

Figure 22: 状态图中使用的主要符号

2.3.1. 状态

  • 状态 是任何可以被观察到的 系统行为模式 ，
    • 一个状态代表系统的一种行为模式。
  • 状态 规定了系统对事件的 响应方式 。系统对事件的相应，
    • 既可以是 做 一个（或一系列） 动作 ，
    • 也可以是仅仅 改变 系统本身的 状态 ，
    • 还可以是既 改变状态 又 做动作 。
  • 在状态图中定义的状态可能有
    • 初态（初始状态）
      • 用 实心圆 表示，
    • 终态（最终状态）
      • 用 牛眼图形 表示，
    • 中间态
      • 用 圆角矩形 表示。

state-diagram-three-states.png

Figure 23: 三种状态的图形表示

  • 一张状态图中
    • 初态 只能有 一个 ，
    • 终态 可以有 零个 或 多个 。

2.3.2. 状态转换

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

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

state-diagram-without-trigger.png

Figure 24: 没有事件触发的状态转换

2.3.3. 事件

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

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

state-diagram-deposit.png

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

state-diagram-withdraw.png

Figure 26: 取款过程的状态图

2.4. 数据字典

  • 数据字典 以 词条方式 定义 在

    • 数据模型
    • 功能模型
    • 行为模型

    中出现的 数据对象 及 控制信息 的 特性 ，给出它们的准确定义，包括

    • 数据流 、 加工 、 数据文件 、 数据元素 ， 以及 数据源点 和 数据汇点 等。

数据字典 成为把3种分析模型黏合在一起的 黏合剂 ，是分析模型的 核心 。

2.4.1. 词条描述

对于在数据流图中每一个被命名的图形元素均加以定义，其内容包括：

  • 图形元素的 名字 ，
  • 图形元素的 别名 或 编号 ，
  • 图形元素 类别 ，如
    • 加工 、 数据流 、 数据文件 、 数据元素 、 数据源点 或 数据汇点 等，
  • 描述 ，
  • 定义 ，
  • 位置 等。
数据流词条
  • 数据流是 数据结构在系统内传播的路径 。一个 数据流词条 应有以下几项内容：
    • 数据流名 ：要求与 数据流图 中该图形元素的名字一致。
    • 简述 ：简要介绍它产生的 原因 和 结果 。
    • 组成 ：数据流的 数据结构 。
    • 来源 ：数据流来自哪个 加工 或作为哪个 数据源 的外部实体。
    • 去向 ：数据流流向哪个 加工 或作为哪个 数据汇点 的外部实体。
    • 流通量 ：单位时间数据的 流通量 。
    • 峰值 ：流通量的 极限值 。
Table 2: 读者借书信息流数据字典
数据流名称 借书流
编号 DF01
说明 读者借书时，流通组工作人员输入的信息
数据流来源 外部输入
数据流去向 读者有效性，图书有效性处理
数据流组成 图书号+读者证件号
数据流量和数据量 500条/日，0.01K/条
数据元素词条
  • 数据流图中的每个数据结构都是由 数据元素 构成的， 数据元素是数据处理中 最小的 、 不可再分 的单位，它直接反映事物的某一特征。
  • 组成数据结构的这些数据元素也必须在数据字典中给出 描述 。其描述需要以下信息：
    • 类型 ：数据元素分为 数字型 与 文字型 。 数字型 又分为 离散值 和 连续值 ， 文字的类型用 编码类型 和 长度 区分。
    • 取值范围
      • 离散值 的取值或是 枚举的 （如： \(3, 17, 21\) ）， 或是 介于上下界的一组数 （如： \(2..100\) ）；
      • 连续值 一般是 有取值范围的实数集 （如： \(0.0..100.0\) ）。
      • 对于 文字型 ，文字的取值需 加以定义 。
    • 相关的 数据元素 及 数据结构 。
Table 3: 图书号
数据项名称 图书号
简称 bookID
类型 char
长度 13字符
取值范围 无
初始值 无
相关的数据项及数据结构 无
数据存储文件词条
  • 数据存储文件是 数据保存的地方 。一个数据存储文件词条应有以下几项内容：
    • 文件名 ：要求与数据流图中该图形元素的名字一致。
    • 简述 ：简要介绍存放的是什么数据。
    • 组成 ：文件的数据结构。
    • 输入 ：从哪些加工获取数据。
    • 输出 ：由哪些加工使用数据。
    • 存取方式 ：分为顺序、直接、关键码等不同存取方式（或以文件/数据库表的形式存取）。
    • 存取频率 ：单位时间的存取次数（用于数据设计时考虑优化）。
Table 4: 图书信息表
名称 图书信息表
编号 DS001
简述 存贮图书基本信息
数据存储的组成 图书号+书名+出版社+作者+价格+分类
存储方式 数据库表
访问频率 5000次/日
加工词条
  • 加工可以使用诸如 判定表 、 判定树 、 结构化语言 等形式表达。主要描述有：
    • 加工名 ：要求与数据流图中该 图形元素的名字 一致。
    • 编号 ：用以反映该加工的 层次 和 亲子 关系。
    • 简述 ：加工 逻辑 及 功能 简述。
    • 输入 ：加工的 输入数据流 。
    • 输出 ：加工的 输出数据流 。
    • 加工逻辑 ：简述 加工程序 、 加工顺序 。
数据源点及数据汇点词条
  • 对于一个数据处理系统来说， 数据源点 和 数据汇点 应比较少。 如果过多则表明独立性差，人机界面复杂。定义数据源点和数据汇点时，应包括：
    • 名称 ：要求与数据流图中该外部实体的名字一致。
    • 简述 ：简要描述是什么外部实体。
    • 有关数据流 ：该实体与系统交互时涉及哪些数据流。
    • 数目 ：该实体与系统交互的次数。
Table 5: 流通组
名称 流通组
简要说明 图书馆流通组，负责为读者借还书，并可以查询读者信息和读者借还书信息
有关的数据流 借书流、还书流、读者编号

2.4.2. 数据结构描述

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

  • 定义式 ： 在数据流图中， 数据流 和 数据文件 都具有一定的数据结构。 因此必须以一种 清晰 、 准确 、 无二义性 的方式来描述数据结构。
  • Warnier图 ： 表示数据结构的另一种图形工具，它用 树形结构 来描绘数据结构。
Table 6: 数据结构定义式中的符号
符号 含义 解释
\(=\) 被定义为  
\(+\) 与 例如， \(x = a + b\) ，表示 \(x\) 由 \(a\) 和 \(b\) 组成
\([\dots, \dots]\) 或 例如， \(x = [a, b]\) ，表示 \(x\) 由 \(a\) 或由 \(b\) 组成
\([\dots \vert \dots]\) 或 例如， \(x = [a \vert b]\) ，表示 \(x\) 由 \(a\) 或 \(b\) 组成
\(\{\dots\}\) 重复 例如， \(x = \{a\}\) ，表示 \(x\) 由 \(0\) 个或多个 \(a\) 组成
\(m \{\dots\} n\) 重复 例如， \(x = 3 \{a\} 8\) ，表示 \(x\) 中至少出现 \(3\) 次 \(a\) ，至多出现 \(8\) 次 \(a\)
\((\dots)\) 可选 例如， \(x = (a)\) ，表示 \(a\) 可在 \(x\) 中出现，也可不出现
\(“\dots”\) 基本数据元素 例如， \(x = “a”\) ，表示 \(x\) 为取值为 \(a\) 的数据元素
\(\cdot\cdot\) 连接符 例如， \(x = 1..9\) ，表示 \(x\) 可取 \(1\) 到 \(9\) 之间的任一值
Table 7: 归纳及举例
符号 说明 举例
\(=\) 定义符 标识符 \(=\) 字母字符 \(+\) 字母数据串
\(+\) 用于连接两个数据分量 标识符 \(=\) 字母字符 \(+\) 字母数据串
\([ ]\) 选择项 教师的职称 \(= [\) 讲师 \(\vert\) 副教授 \(\vert\) 教授 \(]\)
\(\{ \}\) 重复项 级别 \(= 1\{A\}5\) ，即级别是 \(A, AA, \dots, AAAAA\)
\(( )\) 可选项 曾用名 \(= (\) 姓名 \()\) ，曾用名可有可无
\(\cdot\cdot\) 连接符 工龄 \(= 1..50\)
数据存储 读者信息 定义示例
Table 8: 读者信息
名字 读者信息
编号 DS1
描述 保存读者的基本信息
定义 读者信息 = 编号 + 姓名 + 单位 + 读者类型 + 电话
位置 数据库的读者信息表
访问频率 10次/天
数据项 读者类型 定义示例
Table 9: 读者类型
名字 读者类型
简称 ReaderType
类型 字符串
长度 4
取值范围 读者类型 = [本科 | 硕士 | 博士 | 教师]
初值 读者类型 = 本科
相关数据结构 读者信息
数据存储 存折 格式示例

bankbook.png

Figure 27: 存折格式

在数据字典中对 存折 的定义格式
  • 存折 = 户名 + 所号 + 账号 + 开户日 + 性质 + (印密) + 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图表示 存折 的数据结构

bankbook-warnier.png

Figure 28: 用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           
      
 条件 
       		 订货单金额             > 5000元    > 5000元   ≤ 5000元    ≤ 5000元 
 偿还欠款情况           > 60天      ≤ 60天     > 60天      ≤ 60天   
      
      
      
 动作 
      
      
       		 在偿还欠款前不予批准   ✓                                                
 发出批准书                            ✓      ✓       ✓    
 发出发货单                            ✓      ✓       ✓    
 发催款通知书                                        ✓                   

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

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

                               1             2           3           
      
 条件 
       		 订货单金额             > 5000元       -       ≤ 5000元 
 偿还欠款情况           > 60天     ≤ 60天   > 60天   
      
      
      
 动作 
      
      
       		 在偿还欠款前不予批准   ✓                              
 发出批准书                           ✓    ✓    
 发出发货单                           ✓    ✓    
 发催款通知书                                     ✓    

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

2.5.2. 决策树（decision tree）

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

检查订货单的决策树
%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["检查订货单"] --- B["金额>5000元"]
    A --- C["金额≤5000元"]
    B --- D["欠款>60天"]
    B --- E["欠款≤60天"]
    C --- F["欠款>60天"]
    C --- G["欠款≤60天"]
    D --- H["不发批准书"]
    E --- I["发批准书、发货单"]
    F --- J["发批准书、发货单及催款通知书"]
    G --- K["发批准书、发货单"]

decision-tree-order.svg

Figure 29: 检查订货单的决策树

航空公司的行李收费的决策表
Table 10: 航空公司的行李收费的决策表
  1 2 3 4 5 6 7 8 9
国内旅客   T T T T F F F F
头等舱   T F T F T F T F
残疾旅客   F F T T F F T T
行李重量 ≤ 30 T F F F F F F F F
免费 ✓                
\((W - 30) \times 2\)       ✓          
\((W - 30) \times 3\)         ✓        
\((W - 30) \times 4\)   ✓           ✓  
\((W - 30) \times 6\)     ✓           ✓
\((W - 30) \times 8\)           ✓      
\((W - 30) \times 12\)             ✓    

航空公司的行李收费标准：

  • 乘客 免费行李 不超过30公斤。
  • 超出部分 国内客头等舱 4/每公斤， 国内客其他舱 6/每公斤，
  • 国外客 是国内客的2倍， 残疾客 是正常客的一半。
航空公司行李收费的决策树
%%{init: { 'theme': 'forest', 'fontFamily': 'Times New Roman, KaiTi' }}%%
graph LR
    A["行李费计算"] --- B["行李重量>30公斤"]
    A --- C["行李重量≤30公斤"]
    B --- D["国内旅客"]
    B --- E["外籍旅客"]
    D --- F["头等舱"]
    D --- G["非头等舱"]
    E --- H["头等舱"]
    E --- I["非头等舱"]
    F --- J["残疾旅客"] --- JJ["(W−30)×2"]
    F --- K["正常旅客"] --- KK["(W−30)×4"]
    G --- L["残疾旅客"] --- LL["(W−30)×3"]
    G --- M["正常旅客"] --- MM["(W−30)×6"]
    H --- N["残疾旅客"] --- NN["(W−30)×4"]
    H --- O["正常旅客"] --- OO["(W−30)×8"]
    I --- P["残疾旅客"] --- PP["(W−30)×6"]
    I --- Q["正常旅客"] --- QQ["(W−30)×12"]
    C --- R["一律免费"]

decision-tree-airline.svg

Figure 30: 航空公司行李收费的决策树

3. 系统需求规格说明

需求分析阶段 的 重要任务 之一是根据分析的结果编写 软件需求规格说明 。

软件需求规格说明经过 严格评审 并得到 用户确认 之后，作为这个阶段的最终成果。

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

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

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

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

3.2. SRS和DRD的质量要求

  • SRS和DRD的 质量要求 包括：
    • 完整性
    • 无歧义性
    • 一致性
    • 可验证性
    • 可修改性
    • 可追踪性

参考教材

  • 3.3.2 pp.62-63

4. 需求评审

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

4.1. 正式的需求评审

正式的技术评审（Formal Technique Review, FTR） 是最主要的 需求评审机制 。

  • 一般要成立 评审小组 ，并采取 评审会议 的方式进行。
  • 评审小组 包括 软件工程师 、 客户 、 用户 和 其他利益相关方 。
  • 评审的主要内容 可以归纳如下：
1. 功能 7. 通信 13. 清晰性/无歧义性 19. 可维护性
2. 性能 8. 正确性 14. 安全性 20. 可追踪性
3. 接口 9. 完整性 15. 健壮性 21. 可靠性
4. 数据 10. 可行性 16. 可理解性 22. 其他
5. 硬件 11. 一致性 17. 可修改性  
6. 软件 12. 兼容性 18. 可测试性和可验证性  

参考教材

  • 3.4.1 pp.64-65

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

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

参考教材

  • 3.4.2 pp.65-66

5. 需求管理

需求管理的 定义
  • 一种 获取 、 组织 并 记录 系统需求 的 系统化方案 ，
  • 以及一个使 客户与项目团队 对 不断变更的系统需求 达成并保持一致的过程 。
需求管理的 目的
  • 在 客户 与 开发方 之间建立 对需求的共同理解 ，
  • 维护 需求 与 其他工作成果 的 一致性 ，并 控制需求的变更 。
需求管理 强调
  • 控制 对需求基线的 变动 ；
  • 保持 项目计划与需求 一致 ；
  • 控制 单个需求和需求文档的 版本 情况；
  • 管理 需求和跟踪链之间的 联系 或 管理 单个需求和其他项目可交付工作产品之间的 依赖 关系；
  • 跟踪 基线中需求的 状态 。

5.1. 需求跟踪

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

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

5.2. 需求变更管理

  • 管理需求变更包括这样一些活动：
    • 设立 基线
    • 追踪每项需求的 历史
    • 确定哪些 依赖关系 值得追踪
    • 在相关项之间建立 可追踪关系
    • 维护 版本控制
    • ……

此外，建立 变更控制 或 批准流程 也很重要， 它要求由 指定的团队成员 来负责复审所有提议的变更， 以在全局的高度上对 变更需求 的 好处 和可能引起的 后果 进行客观的权衡和把握。

6. 课后作业

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