可直接复制的分析与设计模板
按项目实际复杂度选择。小型应用不需要为了“文档齐全”机械填满所有表格，但目标、场景、对象、规则、权限和测试不能缺失。
使用建议
- 为项目建立一个设计文档；
- 复制本页需要的模板；
- 所有编号保持稳定，后续设计和测试引用同一编号；
- 不确定的内容标为“待确认”，不要猜测；
- 每次重要决定记录决定人和日期；
- 应用发生变化时同步更新相关模板。
模板一：业务目标卡
markdown
# 业务目标卡
## 基本信息
- 项目/应用名称：
- 业务负责人：
- 应用开发者：
- 目标用户：
- 计划试点范围：
## 业务背景
当前业务为什么需要改变：
## 现状事实
1.
2.
3.
## 造成的影响
1.
2.
3.
## 期望业务结果
1.
2.
3.
## 成功标准
| 编号 | 成功标准 | 怎样观察或衡量 | 负责人 |
|---|---|---|---|
| G-01 | | | |
## 第一版包含
-
## 第一版不包含
-
## 已知约束
-
## 主要风险和假设
-模板二：相关人员地图
| 角色 | 代表人员 | 参与阶段 | 主要目标 | 作出的决定 | 需要的信息 | 当前痛点 | 是否已访谈 |
|---|---|---|---|---|---|---|---|
| 否 |
补充检查：
- [ ] 发起者；
- [ ] 实际处理者；
- [ ] 审批或决策者；
- [ ] 后续执行者；
- [ ] 管理和统计使用者；
- [ ] 异常处理者；
- [ ] 平台和组织支持者；
- [ ] 受影响但不直接操作的人。
模板三：业务访谈提纲
markdown
# 业务访谈
- 访谈日期：
- 访谈对象：
- 所属角色：
- 访谈重点：
- 记录人：
## 从一笔真实业务开始
- 这笔业务为什么开始？
- 第一步做了什么？
- 接下来交给谁？
- 使用了哪些表格、消息或制度？
- 中间在哪里等待或返工？
- 最终怎样确认完成？
## 目标
- 这项工作为什么存在？
- 做得好是什么样？
- 最想改善的三个问题是什么？
## 人员与责任
- 谁发起、处理、批准、执行和管理？
- 人员不在时怎么办？
- 哪一步的最终负责人是谁？
## 信息
- 每一步需要什么信息？
- 信息从哪里来，由谁维护？
- 哪些信息经常错或缺？
- 哪些信息一旦确认就不能改？
## 规则
- 什么情况下允许、拒绝或走不同路线？
- 边界值是什么？
- 是否存在口头规则？
## 异常
- 填错、重复、退回、撤回、作废怎么办？
- 找不到处理人怎么办？
- 超时怎么办？
## 查询和管理
- 个人每天需要看什么？
- 团队如何发现积压？
- 负责人需要哪些统计和口径？
## 观察到的事实
-
## 受访者意见
-
## 待核实假设
-
## 冲突或待决策
-
## 可作为证据的材料
-模板四：现状流程步骤表
| 步骤 | 触发 | 执行角色 | 实际操作 | 输入 | 输出 | 使用工具/材料 | 等待时间 | 常见问题 | 是否有价值 |
|---|---|---|---|---|---|---|---|---|---|
| 1 |
检查：
- 哪些步骤在重复录入？
- 哪些步骤只是在搬运信息？
- 哪些步骤依赖个人经验？
- 哪些步骤通过聊天或纸张补充？
- 哪些交接点经常缺信息？
- 哪些异常没有正式处理方式？
模板五：业务场景
markdown
# 【场景编号】场景名称
- 参与者：
- 业务目标：
- 触发：
- 前提：
- 优先级：必须 / 重要 / 可选 / 暂不做
## 正常步骤
1.
2.
3.
## 完成结果
-
## 业务状态变化
- 开始状态：
- 结束状态：
- 下一责任人：
## 异常和替代路径
1.
2.
## 权限要求
-
## 需要查询或统计的结果
-
## 验收方式
-
## 待确认
-模板六：范围与优先级
| 编号 | 需求/场景 | 业务价值 | 缺少时影响 | 优先级 | 第一版是否包含 | 不包含原因/恢复条件 | 确认人 |
|---|---|---|---|---|---|---|---|
| R-01 | 必须 | 是 |
第一版边界声明：
markdown
本版从【开始事件】开始，到【结束结果】结束。
包含的组织和角色：
-
包含的数据：
-
不包含的业务：
-
历史数据处理：
-
外部工作仍然保留的部分：
-模板七：待决策清单
| 编号 | 问题 | 可选方案 | 各方案影响 | 决定人 | 决定期限 | 最终决定 | 决定日期 |
|---|---|---|---|---|---|---|---|
| D-01 |
模板八：业务词汇表
| 术语 | 统一定义 | 不包括什么 | 使用场景 | 确认人 |
|---|---|---|---|---|
特别检查：
- “完成”；
- “通过”；
- “提交”；
- “取消/撤回/作废”；
- “负责人/经办人/审批人”；
- 金额和日期口径；
- 部门和归属；
- 状态名称。
模板九：业务对象卡
markdown
# 业务对象：【名称】
## 业务目的
## 谁创建
## 何时产生
## 当前责任如何确定
## 何时结束
## 主要状态
## 主要信息
## 是否包含多行明细
## 与其他对象的关系
## 谁查询或统计
## 当前信息与历史事实
## 是否需要独立管理
判断依据：
- 是否有独立编号：
- 是否有独立生命周期：
- 是否被单独查询：
- 是否被其他对象反复引用：模板十：状态与动作表
| 当前状态 | 业务含义 | 当前责任人 | 允许角色 | 允许动作 | 必要条件 | 下一状态 | 可修改内容 | 终止否 |
|---|---|---|---|---|---|---|---|---|
检查：
- [ ] 初始状态；
- [ ] 正常结束状态；
- [ ] 拒绝；
- [ ] 退回；
- [ ] 撤回；
- [ ] 作废；
- [ ] 超时；
- [ ] 人员缺失；
- [ ] 已完成后纠正方式。
模板十一：业务规则
| 编号 | 类型 | 规则名称 | 事件/时点 | 条件 | 行为 | 不满足时 | 提示 | 来源/确认人 |
|---|---|---|---|---|---|---|---|---|
| BR-01 | 计算/校验/决策/权限 |
规则写作句式：
当【事件】发生时，如果【明确条件】，则【业务行为】并得到【业务结果】；否则【另一结果或明确失败】。边界【说明等号和时点】。
模板十二：决策表
先列条件，再列结果：
| 条件/结果 | 组合 1 | 组合 2 | 组合 3 | 组合 4 |
|---|---|---|---|---|
| 条件 A | ||||
| 条件 B | ||||
| 条件 C | ||||
| 执行动作 | ||||
| 下一状态 | ||||
| 处理人 |
检查：
- 所有组合是否都有结果；
- 是否有两个组合条件完全重叠；
- 空值和未知值怎样处理；
- 边界值属于哪一列；
- 一条都不满足时怎样处理。
模板十三：业务不变量
| 编号 | 任何时候都必须成立的事实 | 影响范围 | 验证场景 |
|---|---|---|---|
| INV-01 |
示例：
- 总金额必须等于有效明细金额之和；
- 已完成记录不能被普通业务角色修改；
- 一次提交只能形成一次有效审批；
- 未授权角色不能看到其他人的敏感记录。
模板十四：目标流程步骤卡
markdown
# 流程步骤：【名称】
- 步骤目的：
- 开始条件：
- 负责人：
- 参与者：
- 需要的信息：
- 执行动作或决定：
- 完成结果：
- 下一责任人：
- 正常时限：
- 通知对象：
## 异常
- 无负责人：
- 超时：
- 退回：
- 拒绝：
- 代理：
- 交接：
## 需要保留的业务事实
-模板十五：责任分配表
| 业务步骤 | 实际执行 | 最终负责 | 提供意见 | 需要知会 | 交接结果 |
|---|---|---|---|---|---|
如果“实际执行”和“最终负责”都是多人，继续确认是否真的需要共同负责。
模板十六：查询与指标
角色视图
| 编号 | 视图名称 | 使用者 | 业务任务 | 默认范围 | 关键列 | 默认筛选 | 默认排序 | 允许操作 | 导出否 |
|---|---|---|---|---|---|---|---|---|---|
| Q-01 |
管理指标
| 编号 | 指标名称 | 管理问题 | 统计对象 | 金额/数量定义 | 包含状态 | 使用日期 | 数据范围 | 更新频率 | 可下钻到 |
|---|---|---|---|---|---|---|---|---|---|
| M-01 |
模板十七：应用蓝图
markdown
# 应用蓝图
## 应用名称与边界
## 目标角色
## 目录结构
## 核心模板
| 模板 | 对应业务对象 | 主要使用者 | 生命周期 |
|---|---|---|---|
| | | | |
## 视图
| 视图 | 目的 | 使用者 |
|---|---|---|
| | | |
## 动作
| 动作 | 事件 | 业务结果 |
|---|---|---|
| | | |
## 流程
| 流程 | 用于什么业务 | 分支依据 |
|---|---|---|
| | | |
## 角色与权限
## 输出、通知和外部协作
## 第一版不包含
## 依赖和能力差距
## 开发波次模板十八：数据字典
| 编号 | 业务名称 | 所属对象/区域 | 业务定义 | 类型/格式 | 来源 | 必填时点 | 默认值 | 谁可修改 | 空值含义 | 使用场景 | 规则编号 | 敏感性 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| F-01 | 用户/默认/计算/过程 |
字段检查：
- [ ] 是否真的有业务用途；
- [ ] 应用是否已经知道；
- [ ] 是否能计算得到；
- [ ] 是否用于规则、流程、权限、查询或统计；
- [ ] 是否需要保留历史事实；
- [ ] 删除或改变会影响什么。
模板十九：表单设计卡
markdown
# 表单：【名称】
## 用户任务
- 新建：
- 修改：
- 查看：
- 审批：
- 后续执行：
## 信息分组和顺序
1.
2.
3.
## 自动信息
-
## 用户必须填写
-
## 草稿保存要求
-
## 正式提交要求
-
## 状态行为
| 状态 | 可查看内容 | 可修改内容 | 可执行按钮 | 重点提示 |
|---|---|---|---|---|
| | | | | |
## 明细行为
- 最少/最多行：
- 新增：
- 删除：
- 重复：
- 计算：
- 空白行：
## 错误提示
| 条件 | 提示 | 用户怎样修正 |
|---|---|---|
| | | |
## 打印和不同设备
-模板二十：动作设计
| 编号 | 动作名称 | 事件 | 条件 | 输入 | 执行步骤 | 成功结果 | 失败提示 | 是否可安全重试 | 影响字段/状态 | 规则来源 |
|---|---|---|---|---|---|---|---|---|---|---|
| A-01 |
动作测试：
- [ ] 正常输入；
- [ ] 空值；
- [ ] 边界；
- [ ] 错误输入；
- [ ] 多行；
- [ ] 删除后；
- [ ] 重复点击；
- [ ] 保存并重开；
- [ ] 不同状态；
- [ ] 无权限。
模板二十一：流程与节点设计
流程概览
| 项目 | 内容 |
|---|---|
| 流程名称 | |
| 提交角色 | |
| 允许提交状态 | |
| 提交前提 | |
| 业务结束结果 | |
| 用于哪些模板/条件 | |
| 在途版本原则 |
节点
| 节点 | 业务目的 | 处理人规则 | 需要查看 | 允许决定 | 同意后 | 退回后 | 拒绝后 | 超时 | 无处理人 |
|---|---|---|---|---|---|---|---|---|---|
流程测试
| 场景 | 输入/条件 | 路线 | 预期处理人 | 预期结束状态 |
|---|---|---|---|---|
模板二十二：角色权限矩阵
| 功能/数据 | 角色 A | 角色 B | 角色 C | 角色 D | 说明 |
|---|---|---|---|---|---|
| 进入应用 | |||||
| 新建 | |||||
| 查看本人 | |||||
| 查看部门 | |||||
| 查看全部 | |||||
| 修改 | |||||
| 删除/作废 | |||||
| 审批 | |||||
| 导出 | |||||
| 打印 | |||||
| 设计应用 |
每个角色补充：
- 正例：
- 必须拒绝的反例：
- 数据范围：
- 敏感内容：
- 交接方式：
模板二十三：通知、定时与外部协作
通知
| 编号 | 业务事件 | 接收者 | 为什么通知 | 内容 | 下一步 | 敏感信息限制 |
|---|---|---|---|---|---|---|
| N-01 |
定时工作
| 编号 | 时间/时区 | 业务范围 | 动作 | 重复保护 | 失败处理 | 负责人 |
|---|---|---|---|---|---|---|
| S-01 |
外部协作
| 编号 | 业务对象 | 方向 | 触发/频率 | 业务标识 | 必须信息 | 冲突规则 | 失败处理 | 责任人 |
|---|---|---|---|---|---|---|---|---|
| X-01 |
模板二十四：能力差距
| 编号 | 业务需要 | 当前可实现程度 | 差距 | 替代方案 | 业务影响 | 是否接受 | 决定人 | 后续条件 |
|---|---|---|---|---|---|---|---|---|
| GAP-01 | 直接/需准备/需验证/不支持 |
禁止做法：
- 未说明就用自由文本替代人员、部门和稳定分类；
- 未说明就把严格约束改成提示；
- 未验证就向业务承诺；
- 因为“能配置出来”就忽略运行和权限验证。
模板二十五：需求追踪表
| 需求编号 | 需求/场景 | 优先级 | 设计落点 | 开发项 | 测试编号 | 当前状态 | 证据/备注 |
|---|---|---|---|---|---|---|---|
| R-01 |
每个必须需求必须同时具有：
- 清楚需求；
- 设计落点；
- 开发结果；
- 可执行测试；
- 实际证据。
模板二十六：蓝图评审记录
markdown
# 应用蓝图评审
- 应用：
- 蓝图版本：
- 日期：
- 参与人：
- 最终决定人：
## 正常场景演练结论
## 异常和边界演练结论
## 完整性检查
- [ ] 目标
- [ ] 场景
- [ ] 对象和数据
- [ ] 状态和规则
- [ ] 流程和责任
- [ ] 表单和动作
- [ ] 权限
- [ ] 视图和指标
- [ ] 输出、通知和外部协作
- [ ] 测试和上线
## 一致性问题
| 编号 | 冲突 | 影响 | 处理 |
|---|---|---|---|
| | | | |
## 能力差距
| 编号 | 差距 | 替代/决定 |
|---|---|---|
| | | |
## 未决项
| 编号 | 问题 | 负责人 | 期限 |
|---|---|---|---|
| | | | |
## 评审结论
- 进入开发 / 修改后复审 / 暂停
- 说明：模板二十七：开发波次
| 波次 | 业务闭环 | 包含 | 不包含 | 依赖 | 目标角色 | 验收场景 | 完成状态 |
|---|---|---|---|---|---|---|---|
| 1 |
每个波次都执行：
- [ ] 保存；
- [ ] 重新进入；
- [ ] 目标角色实际使用；
- [ ] 反例；
- [ ] 业务结果核对；
- [ ] 问题回写蓝图；
- [ ] 通过后再进入下一波。
模板二十八：业务测试剧本
markdown
# 【测试编号】测试名称
- 对应需求：
- 测试目的：
- 角色：
- 测试日期：
- 执行人：
## 前提
-
## 测试数据
-
## 步骤与预期
| 步骤 | 操作 | 预期业务结果 | 实际结果 | 通过否 |
|---:|---|---|---|---|
| 1 | | | | |
## 保存与重新打开
- 保存结果：
- 重新进入路径：
- 核对内容：
## 权限反例
-
## 最终状态、责任和视图
-
## 证据
-
## 结论
- 通过 / 失败 / 受已知限制影响模板二十九：缺陷记录
| 项目 | 内容 |
|---|---|
| 编号 | |
| 标题 | |
| 类型 | 缺陷/设计遗漏/新需求/使用问题/能力差距 |
| 严重程度 | 阻塞/严重/一般/轻微 |
| 测试角色 | |
| 前提和数据 | |
| 复现步骤 | |
| 预期结果 | |
| 实际结果 | |
| 业务影响 | |
| 临时处理 | |
| 修复决定 | |
| 需要回归 | |
| 负责人 | |
| 状态 |
模板三十：用户验收剧本与结论
验收任务
| 编号 | 业务背景 | 参与角色 | 完成目标 | 不直接告诉用户的操作 |
|---|---|---|---|---|
| UAT-01 |
观察记录
| 用户 | 停顿/误解 | 需要口头帮助 | 外部绕行 | 反馈 | 分类 |
|---|---|---|---|---|---|
验收结论
markdown
- 应用版本：
- 验收范围：
- 已通过场景：
- 未通过场景：
- 已知限制：
- 上线前必须完成：
- 后续需求：
- 验收结论：通过 / 有条件通过 / 不通过
- 业务确认人：
- 日期：模板三十一：版本与发布说明
markdown
# 版本说明
- 应用：
- 版本：
- 发布日期：
- 业务负责人：
- 应用开发者：
## 变更原因
## 新增
-
## 修改
-
## 移除或停用
-
## 影响角色
-
## 影响范围
- 数据：
- 表单：
- 动作：
- 流程和在途业务：
- 权限：
- 视图和指标：
- 导出打印：
- 培训和说明：
## 执行的测试
-
## 已知限制
-
## 恢复方案
-
## 发布后立即验证
- [ ] 普通用户进入
- [ ] 创建、保存、重开
- [ ] 提交和任务
- [ ] 审批和状态
- [ ] 视图和统计
- [ ] 权限反例模板三十二：上线切换清单
人员
- [ ] 业务负责人；
- [ ] 应用管理员；
- [ ] 正式角色成员；
- [ ] 组织关系；
- [ ] 支持人员；
- [ ] 试点用户。
数据
- [ ] 初始数据来源；
- [ ] 清理和去重；
- [ ] 导入范围；
- [ ] 抽样核对；
- [ ] 新旧业务切分日期；
- [ ] 测试数据处理。
应用
- [ ] 正式版本；
- [ ] 核心场景通过；
- [ ] 权限通过；
- [ ] 通知范围；
- [ ] 导出打印；
- [ ] 已知限制。
切换
- [ ] 上线日期和时间；
- [ ] 首批部门；
- [ ] 旧渠道停止方式；
- [ ] 在途旧业务处理；
- [ ] 严重问题暂停和恢复；
- [ ] 当天检查；
- [ ] 第一周检查。
培训
- [ ] 申请人；
- [ ] 审批人；
- [ ] 后续执行者；
- [ ] 管理者；
- [ ] 问题反馈入口。
模板三十三：变更请求
| 项目 | 内容 |
|---|---|
| 编号 | |
| 提出人/角色 | |
| 当前业务问题 | |
| 真实场景 | |
| 期望结果 | |
| 影响人数 | |
| 时间要求 | |
| 是否阻塞核心业务 | |
| 影响数据 | |
| 影响表单和动作 | |
| 影响流程和在途 | |
| 影响权限 | |
| 影响视图和输出 | |
| 替代方案 | |
| 优先级决定 | |
| 确认人 |
模板三十四：上线后复盘
markdown
# 应用复盘
- 应用版本：
- 复盘周期：
- 参与人：
## 原成功标准
| 标准 | 当前证据 | 达成情况 |
|---|---|---|
| | | |
## 使用情况
- 新业务进入应用比例：
- 仍在使用的旧渠道：
- 高频求助：
- 高频错误：
- 长期草稿/退回/待办：
## 业务结果
- 效率：
- 质量：
- 管理：
- 权限和风险：
## 问题分类
| 问题 | 类型 | 影响 | 负责人 | 计划 |
|---|---|---|---|---|
| | | | | |
## 应简化或停止的内容
-
## 下一迭代目标
-最小项目包
如果项目很小，至少保留以下八项：
- 业务目标卡；
- 核心业务场景；
- 业务对象和状态；
- 关键规则；
- 数据字典与表单草图；
- 角色权限矩阵；
- 需求追踪和测试剧本；
- 版本与上线说明。
这些内容足以让另一位应用开发者理解“为什么这样设计、怎样证明它正确”，而不是只能打开应用逐项猜测。