需求分析工具

一、流程图

1. 适用场景
• 梳理单一角色的操作流程，如「用户下单流程」「退款申请流程」
• 和客户、开发、测试对齐业务逻辑，确保对分支条件的理解一致
• 发现流程中的冗余步骤或逻辑漏洞

2. 核心元素

3. 绘制要点
• 明确起止点：每条流程必须有清晰的开始条件和结束状态
• 穷尽分支：每个判断节点都要覆盖所有可能的路径，包括异常和边界情况
• 粒度适当：避免过于宏观（看不到关键细节）或过于细碎（失去全局视角），一般控制在 15 个节点以内
• 单一职责：一张流程图只描述一个主流程，子流程可单独拆分

4. 示例

Tips：先画「主干流程」（Happy Path），再逐步补充异常分支，这样既高效又不容易遗漏。

二、泳道图

1. 适用场景
• 涉及多角色协作的业务流程，如「采购审批流程」「订单履约流程」。
• 需要明确各环节的责任归属，回答"这一步谁来做"的问题。
• 识别跨部门协作中的等待、瓶颈和推诿风险。

2. 核心元素
• 泳道：每条泳道代表一个参与角色、部门或系统
• 活动节点：落在对应泳道内，表示该角色负责的操作
• 流转箭头：跨泳道的箭头代表工作的交接和协作

3. 绘制要点
• 泳道命名清晰：使用具体角色名（如"仓库管理员"）而非模糊称谓（如"相关人员"）
• 交互点重点标注：跨泳道的流转是协作摩擦最容易发生的地方，建议标注交互方式（系统通知、邮件、线下沟通等）
• 从左到右或从上到下：保持统一的阅读方向，泳道排列顺序建议按照业务流转的先后关系
• 控制泳道数量：一般不超过 5-6 条泳道，过多时应考虑拆分为多张图

4. 四种布局方式

 

5. 示例

三、时序图

1. 核心元素
• 参与者（Actor/Object）：顶部的矩形，代表系统、模块或角色
• 生命线：参与者下方的虚线，表示其存在的时间范围
• 消息（Message）：参与者之间的箭头，表示请求、响应或通知
• 实线箭头：同步请求
• 虚线箭头：返回/响应
• 异步消息：开放箭头
• 激活框：生命线上的矩形，表示该参与者正在处理任务

2. 适用场景
• 描述系统间或模块间的接口调用关系，如「支付回调流程」「第三方登录流程」
• 需要和开发团队对齐接口设计和调用时序
• 分析复杂交互中的并发、超时、重试等技术细节

3. 绘制要点
1. 参与者从左到右排列：按照交互的主次关系排列，发起方放在最左侧
2. 聚焦核心交互：一张时序图描述一个核心场景，避免把所有分支都画在一张图上
3. 标注关键信息：在消息箭头上标注接口名称、关键参数或业务含义
4. 标记异常路径：使用 alt/opt 片段框标注条件分支和异常处理逻辑

4. 示例

四、状态机图

1. 核心元素
• 状态：圆角矩形，表示对象在某一时刻所处的状况（如"待审核""已发货"）
• 初始状态：实心黑圆点，表示生命周期的起点
• 终止状态：带圈的实心黑圆点，表示生命周期的终点
• 转换：带箭头的连线，表示从一个状态到另一个状态的迁移
• 触发事件/守卫条件：标注在转换箭头上，说明触发转换的事件和前置条件
• 动作：状态进入、退出或转换时执行的操作

2. 适用场景
• 梳理业务实体的完整生命周期，如「订单状态流转」「工单状态管理」「审批单据状态」
• 定义各状态下允许的操作和禁止的操作，为权限和按钮显示逻辑提供依据
• 发现状态设计中的死锁、遗漏状态或不可达状态等潜在缺陷

3. 绘制要点
1. 状态命名用"已XX"格式：使用完成态动词（如"已支付""待发货"），而非动作（如"支付""发货"），保持语义清晰
2. 穷举所有转换路径：每个状态都要思考"能从哪里来、能到哪里去"，特别注意逆向流转（如退回、撤销）和异常流转（如超时关闭）
3. 标注触发条件：每条转换箭头上都应标注触发事件和守卫条件（如"用户点击取消 [未发货]"），避免产生歧义
4. 避免状态爆炸：一张图聚焦一个核心实体，状态数量建议控制在 8-12 个以内；如果状态过多，考虑使用子状态机拆分
5. 区分主流程与异常流程：可用不同颜色区分正常流转路径和异常/逆向路径，提升可读性

4. 示例