需求建模
- 可视化需求模型能帮助我们识别被遗漏的、不相关的和不一致的需求。
- 数据流图（DFD）
- 流程图，如泳道图
- 状态转换图（STD）和状态表
- 对话图
- 决策表和决策树
- 事件-响应表
- 需求树
- 用例图
- 活动图
- 实体关系图（ERD）
从用户需求到分析模型
用户需求和分析模型组件之间的关联
| 词语类型 | 示例 | 分析模型的组件 |
|---|---|---|
| 名词 | 人员、组织机构、软件系统、数据元素或者已经存在的对象 |
|
| 动词 | 行为、用户或者系统所做的情况或者能够发生的事件 |
|
| 条件 | 条件逻辑的陈述，如if/then |
|
选择正确的表达方式
- 无须为整个系统创建一套完整的分析模型
- 建模时关注重点是系统中最复杂的部分，最忌风险的部分，不确定的或是容易产生分歧的部分
| 所表达的信息 | 表达技巧 |
|---|---|
| 系统的外部接口 |
|
| 业务过程图 |
|
| 数据定义和数据对象关系 |
|
| 系统和对象状态 |
|
| 复杂逻辑 |
|
| 用户接口 |
|
| 用户任务描述 |
|
| 非功能性需求（质量特征、限制条件） |
|
数据流图
-
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 | 及时接收到刮扫信号 | 关闭 | 低速运行一个刮扫循环 |
