软件需求模型之处理流程&系统流程

相关思考

业务干系人沟通

• 是否有遗漏任务用户群体？ （部门组织结构图-角色组织结构图-人员组织结构图，但不太适用于纯粹的消费者项目）
• 操作/步骤涉及的用户是否是业务中的真实用户？
• 步骤执行的地方，有无顺序的考虑？
• 哪些手工，哪些系统完成？
• 有哪些KPI？（这些KPI产生的相关因素反推角色与操作）

需求推导

• 在该步骤前需要做什么：找前提
• 该步骤会产生哪些不同的结果：找不同
• 该步骤可能会产生什么样的错误情况：找错
• 步骤完成后，如何让其他人知道它已完成：找去处（传给谁）与找存在感（告诉谁）
• 步骤的什么部分是由用户发起的，什么部分是由系统发起：找数据来源
• 这个决策性步骤需要评估什么业务规则：找规则范围
• 这个决策性步骤可能会出现什么结果 该步骤执行什么计算

处理流程&系统流程

目的

处理流程

理解用户采取哪些步骤来完成他们的任务，重点放在用户和他们的需求上，即用户执行的行动

• 帮助考虑一组非常简单的信息
• 推导和组织需求的工具（功能性需求从处理步骤得到；业务规则来源于决策性步骤和需求；提供起点考虑哪些方面需要额外的业务规则）
• 不适用与识别数据的需求、肺功能需求以及未封装在步骤中的步骤需求

系统流程

记录企业干系人所关心的自动化流程，而不是记录整个系统是如何运行的流程图，即系统自动化行动

思路

处理流程

1.确定流程步骤

常见方法：

• 召开提案会议 观察用户执行流程（实际工作中的业务流程）
• 执行现有步骤（走查现有的应用程序来发现流程）
• 审查现有的流程和处理流程（新功能：从现有处理流程入手；新增：从业务工作流程考虑）

2.核心主流程(L1）

• 展示项目业务流程的全部内容，可以用L1与所有干系人交流项目的范围
• 包括整个端到端的流程，通常为线性顺序（通常不会有决策）
• 主要流程环节的确定即可确定整个活动中重要环节点

3.环节中的操作/步骤分解次级流程（L2）

• 项目中，通常确定L1后再开始分解，即定义L2,L3
• 通常，L1中每个步骤将有自己的L2流程，但也有例外

4.必要时再依次分解（L3）

系统流程

同处理流程

元素

处理流程

开始/转入
操作/步骤
决策项/选择项
泳道图（涉及各个角色时）
其他流程（分析是涉及的其他流程项）
事件（流程分析中用户等待触发的事件）
元素之间的联系 ——>
结束/转出

系统流程

步骤
决策
转入
转出
其他流程
泳道图（分析对象：不同系统而非角色）
事件（系统分析中用户触发的事件）
元素间联系

例子

• 处理流程（用户视角）
  发数据给系统——>告诉系统去计算——>系统计算完成
• 系统流程（系统视角）
  用户启动计算——>执行计算