第十二章 需求工程之一图胜千言

需求建模

• 可视化需求模型能帮助我们识别被遗漏的、不相关的和不一致的需求。
• 数据流图（DFD）
• 流程图，如泳道图
• 状态转换图（STD）和状态表
• 对话图
• 决策表和决策树
• 事件-响应表
• 需求树
• 用例图
• 活动图
• 实体关系图（ERD）

从用户需求到分析模型

用户需求和分析模型组件之间的关联

词语类型	示例	分析模型的组件
名词	人员、组织机构、软件系统、数据元素或者已经存在的对象	外部实体、数据库库房或者数据流（数据流图，DFD） 参与者（用例图） 实体或者实体属性(实体关系图，ERD) 通道（泳道图） 带状态的对象（状态转换，STD）
动词	行为、用户或者系统所做的情况或者能够发生的事件	处理（数据流图，DFD） 处理步骤（泳道图） 用例（用例图） 关系（实体关系图，ERD） 转换（状态转换图，STD） 活动(活动图) 事件（事件响应表）
条件	条件逻辑的陈述，如if/then	判定条件（决策树、决策表或者活动图） 分支（泳道图或者活动图）

选择正确的表达方式

• 无须为整个系统创建一套完整的分析模型
• 建模时关注重点是系统中最复杂的部分，最忌风险的部分，不确定的或是容易产生分歧的部分

所表达的信息	表达技巧
系统的外部接口	项目环境图和用例图能够识别与系统交互的外部对象。环境图和数据流图在高度抽象的层面描述系统的输入和输出。生态关系图能够识别出系统可能交互的对象，也包含间接有联系的对象。泳道图描述不同系统之间所发生的交互行为 外部交互的细节可以输入/输出文件格式或者报表格式记录。同时包含软件和硬件组件的产品尝尝都有一个包含数据属性定义的规范说明，其形式或许是一个应用编程接口或者硬件设备的输入/输出说明
业务过程图	顶层的数据流图从高层抽象表述业务过程处理数据的方式。泳道图描述在业务处理流程中参与不同处理步骤的角色 优化后的数据流图或者泳道图能够在恰当的细节层次上表达业务处理流程。流程图和活动图同样也可以用于高层抽象和低层抽象的视图描述，只不过它们通常都是用来定义流程细节的。
数据定义和数据对象关系	实体-关系图表数据数据对象（实体）之间的逻辑联系。类图表述对象类和类对象数据间的逻辑联系 数据字典包含数据结构的详细定义以及各个数据条目。复杂的数据对象要逐步分解成它所包含的数据元素
系统和对象状态	状态转换图和状态表是高度抽象的视图，呈现了系统或者对象可能的状态以及在一定条件下发生的转换。表达多个用例能操控某些对象或者改变这些对象的状态时，这些视图将很有帮助 有些分析人员会创建一个事件响应表来作为范围工具，用它来识别外部事件（帮助定义产品的范围边界）。通过在一个事件响应表里详述系统对外部事件和系统状态每个组合的不同响应方式，还可以用它来描述写单个的功能需求 功能性需求提供用户和系统行为的导致状态变化的详细信息
复杂逻辑	决策树表述一组相联系的判断或条件下可能的输出结果。对于一系列判断或条件的组合，决策表能识别出结果为真和假时各自的功能需求。
用户接口	对话图从高层及提供建议的或是实际的用户接口视图。它描述各种不同显示元素以及元素之间可能导航的路径。 通过展示没有精确细节的画面，故事滑板和低精度的原型方法能充实对话图的内容 展示-行为-响应 （Display-action-response）图描述了每一屏显示的元素及其各自的行为需求 详细的屏幕布局和高精度的原型描述了界面元素的外观。数据域定义和用户界面控制描述进一步提供更多细节
用户任务描述	用户故事，场景和用例规范说明在不同详细程度上描述用户任务 泳道图，描述了业务过程域多个用户或者系统之间的内部交互 流程图和活动图直观描述了用例对话流程和其他可选流程和异常的分支 功能性需求详尽描述系统和用户如何交互以获得有价值的输出。测试用例提供另一个低抽象层次的视图，描述在特定的输入、系统状态和操作条件下期望的系统行为
非功能性需求（质量特征、限制条件）	这两特征和限制条件经常以自然语言文字描述的方式来描述。但是这也经常导致缺少精确描述或是描述得不完整。

数据流图

• data flow diagram DFD,是一种基本的结构化分析工具。

• 数据流图用于标识一个系统中的加工处理、系统所操作的数据集合（存储）或者物理介质以及在处理、存储和系统外部之间的数据流。

• 数据流图采用功能分解的方法来进行系统分析，并在不同的层级上将复杂的问题逐步分解展开。

• 非常适用于实物处理系统和其他偏重功能性的应用。

• 通过使用额外的控制流程元素来加强数据流图的功能，已扩展至对实时系统进行建模。

• 数据流图展示数据流经系统的全貌，这是其他视图做不到的。

• 作为单一的模型技术来使用，数据流图的功能还不够强大，更好的方式是使用用例图或者泳道图中的流程步骤来表示数据加工机制的细节。

• 可以把数据流图作为一种方法来识别被遗漏的数据需求。

• 在各个流程（加工）之间的数据、数据存储里面的数据以及外部实体也应该在实体-关系图（DRD）中进行建模，还要在数据字典中描述。

• 针对用户如何执行某个特定任务的功能性需求，比如化学品申请，数据流图还能提供环境。

• 数据流图能够在不同的抽象层级上描述系统。对数据和以多个步骤行为组成的处理模块，高层数据流图提供了一个整体的鸟瞰图。
  ![[数据流图.excalidraw]]

• 由加工流向存储的箭头表示正在改存储上保存数据

• 流出存储的箭头表示读取数据操作

• 在存储和圆圈之前的双向箭头表示更新操作。

• 在0层数据流图中，以相互独立的圆圈来表示的每一个处理都可以进一步扩展称为一个独立的数据流图，经过扩展的视图可以展示更多的工功能细节。

• 业务分析师可以逐步细化，指导最底层的视图里质保函基本的处理操作，这些操作可以清楚表达成一段叙述文字、一段伪代码、一个泳道图或者一个活动视图。

• 每层数据流图必须与其上层视图保持平衡和一致。是子视图中所有的输入流、输出流和父视图中的输入流、输出流相匹配。

• 在低层数据流图中，高层视图中的复杂数据结构可能分解成其各个构成元素并定义在数据字典中。

• 数据流图的约定：

  • 工序（处理）通过数据存储进行通信，而不是直接地从一个工序流向另个一工序。同样数据不是直接有一个数据存储流向另一个存储，或者在外部实体和数据存储之间直接流动，数据必须流经一个表示工序的圆圈。
  • 请不要试图在数据流图中表达工序的时序相关内容
  • 请用简洁的短语来命名每个工序，动词+名词，且与具体的业务相关的词语。
  • 每个工序的标号应该唯一并且具有层次性。在第0级试图中用一个整数命名每道工序，子数据流图就应该用3.1、3.2等命名在这个子数据流图的工序。
  • 在单个数据流图中，包含的工序不要超过8-10个，否则难画、难改、难理解。可引进另外一个抽象层来解决。
  • 要质疑只有数据流入和数据流出的工序。工序通常既有流入和流出。

泳道图

• 泳道图为我们提供一种方法来描述业务过程中设计的步骤或者计划开发的软件系统中的操作。
• 他们是流程图中的另外一种形式，它把子模块分解称为可视化的泳道。
• 泳道表示在流程中执行操作的不同系统或者执行者。
• 泳道图尝尝用来描述业务过程，工作流或者是系统和用户间的交互。
• 泳道图能够描述数据流图（DFD）中处理（工序）节点内部所发生的的细节。
• 它们有助于把用户执行某个特定任务的功能需求连在一起。
• 在识别支持每个流程步骤的需求时，泳道图也常常用来进行详细分析。

状态转换图和状态表

状态转换图

• 软件系统是一个包含功能行为、数据操作和状态转换的综合体。
• 实时系统和流程控制应用在任何时候都处于一个数量有限的状态集合中的某一个状态。
• 只有当某个完整定义的标准被满足时才发生状态转换。如在某种特定的条件下，接收到一个特定的输入。
• 状态转换图和状态表是两个状态视图，他们都能以一种简明、完整、无歧义的方式来表述一个对象或者一个系统的各个状态。
• 状态转换视图直观表示了状态之间可能的转换。
• 状态转换视图包含以下三种类型的元素：
  • 可能的系统状态，用矩形或圆形表示
  • 允许的状态变化或者转换，链接矩形或原型的箭线表示。
  • 导致状态转换发生的事件或状态。箭线上的文字标签表示，可能是一个事件，也可能是相对应的系统响应。
• 针对一个要经理某个确定生命周期的对象而监理的状态转换图，它包含一个或多个终端状态，这些状态代表一个对象能够有的最终状态。
  

状态表

• 状态表用矩阵的形式来表现不同状态之间可能存在的所有转换。
• 单元格表示改行左边的状态到该列上部状态之间的转换是否有效。
• 如果是有效的状态转换，还要识别出导致相关转换的事件
• 状态转换图和状态表提供了一种横跨多个用例或者用户故事的高层视图，每个用例或用户故事都可能由一个状态执行到另一种状态。
• 状态模型并由展示系统执行的处理细节，仅表示系统运行可能导致的状态编号。
• 帮助开发人员立即系统的预期行为。
• 状态转换图涵盖所有允许的转换路径，测试人员可以由状态转换图衍生出测试用例。
• 如需要保证所有必要的状态和转换都完整、正确地在功能需求里描述出来，
• 状态转换图和状态表都是很有用的工具。

	准备申请	延期申请	通过申请	下订单	延期交货	完成订单	取消
准备申请	无	申请人保存未完成的申请	系统接受有效的申请	无	无	无	无
延期申请	申请人查询未完成的申请	无	无	无	无	无	无
批准申请	无	无	无	购买人项供应商下单	无	化学品库房完成申请	申请人取消申请
下订单	无	无	无	无	供应商延迟交付化学品	从供应商那里收到化学品	购买者向供应商取消订单
延期交付	无	无	无	无	无	从供应商那里收到化学品	购买人项供应商取消订单
完成订单	无	无	无	无	无	无	无
取消	无	无	无	无	无	无	无

对话图

• 对话图（dialog map）在较高的抽象层次上对用户界面设计进行表述。
• 表达了系统中的对话元素及其之间的导航连接，但没有描述详细的界面设计。
• 可以把用户界面看作是一系列状态转换。
• 在任意给定的某个时刻，只有一个对华元素（如菜单、工作区、对话框、命令行提示符或触摸显示屏）可以接收用户的输入。
• 基于用户在活动输入区域的某个动作，他可以被导航到其他的某些对话元素。
• 对话图实际上就是以状态转换图形式建模的用户交互。
• 对话图使我们可以在理解需求的基础上研究假设中的用户交互概念。
• 对话图与系统故事板相关，他也可以包含对每个界面用户的简短描述。
• 对话图捕获的是基本的用户-系统交互和任务流，没有让团队纠缠于界面布局的细节。
• 导致用户导航行为的冬季条件以文本标签的形式现在转换箭头旁边，动机条件如下：
  • 一个用户行为，比如按下一个功能键、点击一个超链接或者在一个触摸屏上做出一个手势动作。
  • 一个数据值，比如能够触发一条错误信息显示的非法用户输入。
  • 一个系统状态，比如检测到打印机缺纸
  • 这些动机条件的某一个组合，比如键入一个菜单选项后按下回车键。
    

判定表和判定树

• 软件系统经常受制于复杂的逻辑，有很多不同的条件组合导致系统产生不同的行为。
• 开发人员需要的功能需求是在所有可能条件组合下对系统响应对坐的描述。
• 系统的逻辑和判定条件变得复杂之后，判定表和判断树都可以用来描述系统应该做出什么响应。
• 判定表列出的是影响系统行为的所有因素的各个取值，并且表明在每一种因素组合条件下系统预期的响应动作。
• 判定表

需求编号
条件	1	2	3	4	5
用户有权限	F	T	T	T	T
化学品仓库或者供货商哪里有货	–	F	T	T	T
该化学品有毒	–	–	F	T	T
申请人受过培训	–	–	–	F	T
动作
批准申请			√		√
驳回申请	√	√		√

• 判定树
  

事件响应表

• 另一种了解用户的需求的方式是识别出系统必须响应的外部事件
• 事件是指在用户环境中发生的某个变化或者活动，厚着可以使软件系统做出某种响应。
• 事件响应表秩逐项记录所有这些事件以及作为对这些事件交互而产生的系统预期行为
• 一共有三类系统事件
  • 业务事件
    • 指一个普通用户所执行的动作，该动作是软件弹出对话框，就像用户初始化用户用例时那样。事件响应顺序与用例中或泳道图中的步骤一致。
  • 信号事件
    • 当系统接收到一个控制信号或者数据读取，或者来自某个外部硬件设备或者另一个系统的某个终端指令时，一个信号事件就被注册。
  • 时间相关的事件
    • 是指在某个时刻触发的事件。
    • 如定时任务，或从前一个事件开始时，已经到预先设定的时间（每10秒把传感器读取的温度记录到日志中）
• 为了识别事件，要思考与分析对象相关的所有状态，还有能使该对象转移到某个状态的所有事件。
• 对项目环境图进行审查，识别出所有外部实体，这些外部实体可能初始化某一个动作或申请一个自动化响应。
• 列出跨越系统边界的事件是一种有用的界定软件系统范围的技巧。
• ![[事件模型.excalidraw]]

ID	事件	事件前系统状态	系统响应
1	雨刷控制设置成低速运行	雨刷器处于关闭状态，高速运行状态或者间隔运行状态	将雨刷控制设置为低俗运行
2	设置为高速运行	关闭、低速、间隙	高速
3	设置为关闭状态	高速、低速、间隙	完成当前刮扫循环 关闭雨刷引擎
4	设置为间隙运行	关闭状态	执行一个刮扫循环 读取间隙时间设置 初始化刮扫定时器
5	设置为间隙运行	低速、高速状态	完成当前刮扫循环 读取间隙时间设置 初始化刮扫定时器
6	自上次刮扫循环结束已经度过了一个时间间隔	雨刷器处于间隙运行状态	以低速执行一个刮扫循环
7	改变刮扫时间间隔	间隙运行状态	读取间隔时间设置 初始化刮扫定时器
8	改变刮扫时间间隙	关闭、高速、间隙	没有响应
9	及时接收到刮扫信号	关闭	低速运行一个刮扫循环