(第二部分:结构化分析与设计方法,第3章)
Created: 2022-04-06 Wed 00:55
第二部分:结构化分析与设计方法
第3章:软件需求获取与结构化分析方法
需求获取的主要任务是与客户或用户沟通,了解
没有真正从事过 需求获取及分析 工作的人很难相信,
获取并理解用户的 需求 是软件工程师所面对的最困难的任务之一 。
需求获取涉及 客户 、 用户 及 开发方 。
现代软件大多都 不是单机软件 , 软件的 用户数量 及 种类 往往很多。 客户或用户 往往 说不清自己到底需要什么 , 不同用户的需求相互矛盾 或 单个用户前后表达相矛盾 的情况时有发生。
另外,如果负责需求获取的 软件工程师 对用户的工作领域不熟悉, 则会导致与用户交流时 不知说什么、问什么 , 不能引导用户表达需求 , 不能判别用户哪些需求正确、合理 , 不能判断和解决用户需求中出现的矛盾 等。
需求获取 除了需要有专业的 系统分析师 ,
还需要 客户 / 开发者 有效地 合作 才能成功。
需求获取活动需要 解决的问题 概括起来有以下几项:
需求获取应 遵循以下原则 :
应用领域 ,即目标系统的 应用环境 ,如 银行 、 电信公司 、 书店 等。
要想项目成功,离不开 项目利益相关方的支持 。
为了将用户分为不同的 用户类 , 需要根据 系统的不同用户之间在以下方面存在的差异 。
确定了 项目范围和高层需求 ,并确定了 用户类及用户代表 后, 就需要获取 更具体 、 完整 和 详细 的需求。 具体需求的来源可以来自以下几种 典型的途径 。
针对当前待开发的应用系统,确定系统的 业务工作流 和主要的 业务规则 , 采取 需求调研 的方法获取所需的信息。 例如,针对 信息系统的需求调研 方法如下:
需求获取 只是软件需求分析阶段的 第一步 , 需求分析 严格地说也只是 需求分析阶段 的一个步骤。
需求分析阶段 的工作可分为4个步骤
通过 启发 、 引导 , 从客户(或用户)那里得到的 原始需求 是他们的 业务要求(needs) ,记作 \(N\) 。 这是 分析之前获取的需求 ,其中可能存在一些实际问题。 这些问题只有通过 分析 才能得到解决, 直接把 获取的需求 \(N\) 作为 软件设计阶段的依据 将会 导致严重的后果 。
要认真地研究获取的需求,必须考虑以下方面:
由于 分析的过程 会对 获取的需求做部分调整 , 也即从 获取的需求 \(N\) 中去掉了一些 \(a\) ,又补充了一些 \(c\) , 从而得到 分析的需求 \(R_1\) (即 \(b+c\) )。
作为软件开发的依据,必须将已 经过分析的需求 清晰 、 全面 、 系统 、 准确 地描述成 正式的文档 , 这一步 定义需求 的工作就是 编写需求规格说明 。
为了确保已 定义的需求 \(R_2\) (需求规格说明)准确无误, 并能 被客户(或用户)理解和接受 ,需要对其进行 严格的评审 。 该评审一定要 有客户(或用户)参加 ,并且充分听取他们的意见 。 只有 经过评审的需求 才是 设计和实现 可依据的 验证的需求 \(R_3\) 。
最有代表性的传统的分析建模方法称为 结构化分析(Structured Analysis, SA) 方法。 它是一种 面向数据流 进行 需求分析 的方法,最初于20世纪70年代由D.Ross提出, 后来又经过扩充,形成了今天的 结构化分析方法 的框架。
结构化分析方法 是一种 建模技术 ,它建立的 分析模型 如图所示。
功能建模 的思想就是用抽象模型的概念, 按照软件内部 数据传递、变换 的关系, 自顶向下 逐层分解, 直到找到满足功能要求的所有可实现的软件为止。 功能模型用 数据流图 来描述。
环境图(context diagram) 也称为 顶层数据流图(或0层数据流图) , 它仅包括一个数据处理过程,也就是要开发的目标系统。 环境图的作用是 确定系统在其环境中的位置 , 通过确定系统的 输入 和 输出 与 外部实体 的关系 确定其边界 。
案例:招生系统
学校首先公布 招生条件 ,考生根据自己的条件 报名 , 之后系统进行资格审查,并给出 资格审查信息 ; 对于资格审查合格的考生可以参加 答卷 , 系统根据学校提供的 试题及答案 进行自动判卷, 并给出 分数及答题信息 ,供考生 查询 ; 最后系统根据学校的 录取分数线 进行录取,并将 录取信息 发送给考生。
稍微复杂一些的实际问题,在数据流图上常常出现十几个甚至几十个 加工 。 这样的数据流图看起来 不直观 , 不易理解 。 分层的数据流图 能很好地解决这一问题。 按照系统的 层次结构 进行逐步分解, 并以 分层的数据流图 反映这种结构关系, 能清楚地表达整个系统,也容易理解。
案例:订货系统
某工厂采购部每天需要一张 订货报表 ,报表按 零件编号 排序, 表中列出所有需要再次订货的零件。 对于每个需要再次订货的零件应列出下列数据: 零件编号 , 零件名称 , 订货数量 , 目前价格 , 主要供应者 , 次要供应者 。
零件 入库 或者 出库 称为 事务 , 通过放在仓库中的操作终端把 事务 报告给订货系统。 当某种零件的 库存数量少于库存量临界值 时就再次订货。
银行储蓄系统的业务流程:
要求画出 分层的数据流图 ,并细化到 2层数据流图 。
第1步:识别外部实体及输入输出数据流
第2步:画出环境图(顶层数据流图)
第3步:画出一层数据流图
第4步:画出二层数据流图
对一层图中的 处理存款 及 处理取款 进行进一步分解, 得到二层数据流图,即 处理存款的数据流图 和 处理取款的数据流图 。
分层DFD图的优点
画分层DFD的指导原则
在结构化分析方法中,使用 实体-关系建模技术 来建立 数据模型 。 这种技术是在 较高的抽象层次(概念层) 上对 数据库结构 进行建模的流行技术。 实体-关系模型 表示为可视化的 实体-关系图(Entity-Relationship Diagram, ERD) , 也称为 ER图 。图中仅包含三种相互关联的元素: 数据对象(实体) 、 描述数据对象的属性 及 数据对象彼此间相互连接的关系 。
数据对象 是目标系统所需要的 复合信息 的表示, 所谓复合信息是 具有若干不同属性 的信息。 在ER图中用 矩形 表示数据对象。 在实际问题中,数据对象(实体)可以是 外部实体 、 事物 、 角色 、 行为或事件 、 组织单位 、 地点或结构 等。
属性 定义数据对象的特征, 如数据对象 学生 的 学号 、 姓名 、 性别 、 专业 等, 课程 的 课程编号 、 课程名称 、 学分 等。 在ER图中用 椭圆 或 圆角矩形 表示属性, 并用 无向边 将属性与相关的数据对象连接在一起。
ER图中表示关联数量的符号
在ER图中用 圆圈 表示所关联的实例是 可选的 ,隐含表示 \(0\) , 没有出现圆圈 就意味着是 必须的 。 而出现在连线上的 短竖线 可以看成是 \(1\) 。
几种关系的示例
关系及其属性的表示
关系 本身也可能有属性,这在多对多的关系中尤其常见。 如 学生和课程之间的关系 可起名为 选课 ,其 属性 应该有 学期 、 成绩 等。
银行储蓄系统的ER图
状态转换图(简称状态图) 通过 描绘系统的状态 及 引起系统状态转换的事件 来表示 系统的行为 。状态图中使用的主要 符号 如下图所示。
下图为计算机应用软件的启动过程, 在这个过程中 没有外部事件触发 , 每个状态下的活动完成时, 状态发生转换 。
事件 是在某个特定时刻发生的事情, 它是对引起系统从 一个状态 转换到 另一个状态 的 外界事件的抽象 。
事件表达式的语法如下:
事件说明〔守卫条件〕/ 动作表达式
存款过程的状态图(考虑新开户)
取款过程的状态图
数据字典 以 词条方式 定义 在 数据模型 、 功能模型 和 行为模型 中 出现的 数据对象 及 控制信息 的 特性 , 给出它们的准确定义,包括 数据流 、 加工 、 数据文件 、 数据元素 , 以及 数据源点 和 数据汇点 等。 因此, 数据字典 成为把3种分析模型黏合在一起的 黏合剂 ,是分析模型的 核心 。
对于在数据流图中每一个被命名的图形元素均加以定义, 其内容包括 图形元素的名字 , 图形元素的别名或编号 , 图形元素类别 (如 加工 、 数据流 、 数据文件 、 数据元素 、 数据源点 或 数据汇点 等)、 描述 、 定义 、 位置 等。
数据流词条
数据流名称 | 借书流 |
编号 | DF01 |
说明 | 读者借书时,流通组工作人员输入的信息 |
数据流来源 | 外部输入 |
数据流去向 | 读者有效性,图书有效性处理 |
数据流组成 | 图书号+读者证件号 |
数据流量和数据量 | 500条/日,0.01K/条 |
数据元素词条
数据项名称 | 图书号 |
简称 | bookID |
类型 | char |
长度 | 13字符 |
取值范围 | 无 |
初始值 | 无 |
相关的数据项及数据结构 | 无 |
数据存储文件词条
名称 | 图书信息表 |
编号 | DS001 |
简述 | 存贮图书基本信息 |
数据存储的组成 | 图书号+书名+出版社+作者+价格+分类 |
存储方式 | 数据库表 |
访问频率 | 5000次/日 |
加工词条
数据源点及数据汇点词条
名称 | 流通组 |
简要说明 | 图书馆流通组,负责为读者借还书,并可以查询读者信息和读者借还书信息 |
有关的数据流 | 借书流、还书流、读者编号 |
在数据字典的编制中,分析员最常用的描述数据结构的方式有 定义式 或 Warnier图 。
数据结构定义式中的符号
符号 | 含义 | 解释 |
---|---|---|
\(=\) | 被定义为 | |
\(+\) | 与 | 例如, \(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\) 之间的任一值 |
归纳及举例
符号 | 说明 | 举例 |
---|---|---|
\(=\) | 定义符 | 标识符 \(=\) 字母字符 \(+\) 字母数据串 |
\(+\) | 用于连接两个数据分量 | 标识符 \(=\) 字母字符 \(+\) 字母数据串 |
\([ ]\) | 选择项 | 教师的职称 \(= [\) 讲师 \(\vert\) 副教授 \(\vert\) 教授 \(]\) |
\(\{ \}\) | 重复项 | 级别 \(= 1\{A\}5\) ,即级别是 \(A, AA, \dots, AAAAA\) |
\(( )\) | 可选项 | 曾用名 \(= (\) 姓名 \()\) ,曾用名可有可无 |
\(\cdot\cdot\) | 连接符 | 工龄 \(= 1..50\) |
数据存储 读者信息 定义示例
名字 | 读者信息 |
编号 | DS1 |
描述 | 保存读者的基本信息 |
定义 | 读者信息 = 编号 + 姓名 + 单位 + 读者类型 + 电话 |
位置 | 数据库的读者信息表 |
访问频率 | 10次/天 |
数据项 读者类型 定义示例
名字 | 读者类型 |
简称 | ReadType |
类型 | 字符串 |
长度 | 4 |
取值范围 | 读者类型 = [本科 | 硕士 | 博士 | 教师] |
初值 | 读者类型 = 本科 |
相关数据结构 | 读者信息 |
数据存储 存折 格式示例
在数据字典中对 存折 的定义格式
用Warnier图表示 存折 的数据结构
例子:某旅馆电话服务描述
例子:某旅馆电话服务数据字典
商店业务处理系统中 检查订货单 的决策表
1 | 2 | 3 | 4 | ||
条件 |
订货单金额 | > 5000元 | > 5000元 | ≤ 5000元 | ≤ 5000元 |
偿还欠款情况 | > 60天 | ≤ 60天 | > 60天 | ≤ 60天 | |
动作 |
在偿还欠款前不予批准 | ✓ | |||
发出批准书 | ✓ | ✓ | ✓ | ||
发出发货单 | ✓ | ✓ | ✓ | ||
发催款通知书 | ✓ |
改进的 检查订货单 的决策表
如果表中有 两条或更多 的处理规则具有相同的动作, 并且其 条件项 之间存在着某种 关系 ,就可设法将它们 合并 。
1 | 2 | 3 | ||
条件 |
订货单金额 | > 5000元 | - | ≤ 5000元 |
偿还欠款情况 | > 60天 | ≤ 60天 | > 60天 | |
动作 |
在偿还欠款前不予批准 | ✓ | ||
发出批准书 | ✓ | ✓ | ||
发出发货单 | ✓ | ✓ | ||
发催款通知书 | ✓ |
建立决策表的步骤
决策树(decision tree)也是用来 表达加工逻辑 的一种工具,有时侯它比决策表更 直观 。
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\) | ✓ |
需求分析阶段的重要任务之一是根据分析的结果编写 软件需求规格说明 , 软件需求规格说明经过 严格评审 并得到 用户确认 之后,作为这个阶段的最终成果。
按照 GB/T 8567-2006 《计算机软件文档编制规范》, 涉及软件需求规格说明的文档有 软件需求规格说明(SRS) 和 数据需求说明(DRD) 等。
软件评审 是软件过程中的 过滤器 。 也就是说,在软件工程过程的 不同阶段进行软件评审 , 可以起到 发现并消除错误和缺陷 的作用。
正式的技术评审(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. 可测试性和可验证性 |
需求管理可 定义 为: 一种 获取 、 组织 并 记录 系统需求 的 系统化方案 , 以及一个使 客户与项目团队 对 不断变更的系统需求 达成并保持一致 的过程。
需求管理的 目的 是在 客户 与 开发方 之间建立 对需求的共同理解 , 维护 需求 与 其他工作成果 的 一致性 ,并 控制需求的变更 。
需求管理是一组活动,用于帮助项目组在项目进展的过程中 标识需求 、 控制需求 、 跟踪需求 ,并对需求变更进行管理。