结构化分析与设计方法

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

软件工程 第二部分 第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. 用户管理:提供用户组(角色)及用户管理功能。