工作案例 02 / 需求分析与流程设计
把一句需求，变成共同的理解。
我关心的不只是“要做什么”，还有“怎样知道它做对了”。
真实经历 / 案例背景
连接业务语言与系统行为。
在这段需求分析与流程优化经历中，我把制度和多方需求整理成需求文档、字段字典、界面原型、计算逻辑和验收标准，涉及 8 项以上内部工作流。
我在意的是，这些交付物是否能相互对得上：需求里说的事，界面怎样呈现，开发怎样实现，最后又怎样验收。
查看简历阅读版 ↗从需求到验收 / 四个相连的环节
同一个问题，贯穿每一层。
诉求
听清问题
先辨认谁提出问题、希望改变什么，以及什么仍待决定。不要让一句“系统应该自动处理”直接变成开发任务。
规则
写清边界
明确输入、适用条件、例外路径与处理责任。字段字典和计算逻辑，应能回答同一个业务问题。
界面
明确操作方式
把规则放回人的工作流：缺少信息时如何提示，发生例外后谁接手，下一步怎样继续。
验收
对照标准验收
针对正常操作、边界条件、异常情况和信息缺失准备验收样例，让业务与开发团队对预期结果形成共识。
交付关系 / 保持可追溯
让几份文档，说清同一件事。
把目标、角色、流程和待确认的问题放在一起，让后续设计知道从哪里开始、到哪里结束。
说明字段含义、来源、有效条件和关联记录，让同一个数在不同环节中保持一致。
把填写顺序、操作入口和反馈位置摆出来，让抽象的规则有一个可以讨论的界面。
梳理输入、计算顺序与分支条件，帮助开发和测试按同一套逻辑复核结果。
写清谁可以做什么、什么条件会转入例外，以及后续由谁处理。
把要求放进可复现的输入和预期结果里，再检查正常、边界、例外和缺失信息的情况。
需求追踪台 / 同一个例子，四种交付物
一个条件变了，文档和界面怎样跟着变？
选择一个验收情境，沿着需求、字段、界面和验收标准读下去。这个独立构造的例子沿用工作方法实验台的虚构 500 阈值。
情境 01
信息完整的申请
- 金额
- 350
- 用途
- 研讨会用品
- 例外授权
- 未附
处理路径常规复核
- 01 / 需求
先说清要解决什么。
申请人能填写金额与用途；系统先检查信息，再按金额和授权记录决定复核路径。
- 02 / 字段与规则
同一组字段，得出明确的路径。
字段有效后，金额不超过 500 可进入常规复核；超过 500 时，演示规则要求附有例外授权记录。
- 03 / 界面行为
告诉人接下来怎样做。
保留已填写的信息，交由人员继续复核。
- 04 / 验收标准
用相邻条件检查理解。
金额恰好为 500、信息完整时，仍进入常规复核；800 附有例外授权记录时，也进入这一路径。
展开字段字典与完整验收对照
| 字段 | 含义与约束 |
|---|---|
amount演示金额 | 数值大于 0、不超过 100000；无币种。 |
purpose用途 | 去掉首尾空格后，至少 3 个字符。 |
exception例外授权记录 | 用于金额超过 500 时的路径判断。 |
| 情境 | 预期路径 |
|---|---|
| 信息完整的申请 | 常规复核 |
| 金额恰好为 500 | 常规复核 |
| 比阈值多 1 | 例外复核 |
| 附有例外授权记录 | 常规复核 |
| 有授权，仍缺少用途 | 先修正字段 |
| 金额无效 | 先修正字段 |
规则变更 / 改动前后，一起检查
多一个“等于”，哪些结果会变？
沿用上方六组验收输入，固定原规则，只修改另一版的阈值或比较条件。先看哪些路径改变，再试填一组自己的字段。这里仍是无币种的虚构方法演示。
字段有效、金额大于 500 且无授权记录时，转入例外复核。
输入校验、授权记录和人员复核的安排保持不变。
组情境的路径发生变化这是固定样例的对照条数，不代表业务发生频率。
| 验收情境 | 原规则> 500 | 新规则≥ 500 | 对照 |
|---|---|---|---|
| 信息完整的申请金额 350无授权 · 用途完整 | 常规复核 | 常规复核 | 路径相同这组输入不受影响 |
| 金额恰好为 500金额 500无授权 · 用途完整 | 常规复核 | 例外复核 | 路径改变边界条件不同 |
| 比阈值多 1金额 501无授权 · 用途完整 | 例外复核 | 例外复核 | 路径相同这组输入不受影响 |
| 附有例外授权记录金额 800有授权 · 用途完整 | 常规复核 | 常规复核 | 路径相同已附授权记录 |
| 有授权，仍缺少用途金额 350有授权 · 缺少用途 | 先修正字段 | 先修正字段 | 路径相同先修正字段 |
| 金额无效金额 0无授权 · 用途完整 | 先修正字段 | 先修正字段 | 路径相同先修正字段 |
再填一组字段，检查两版规则
金额须大于 0 且不超过 100000；用途去掉首尾空格后，至少 3 个字符。
- 原规则
- 常规复核
- 新规则
- 例外复核
交接与复盘 / 让下一步有据可循
交接前，把这四个问题留清楚。
这段实习既涉及需求材料，也涉及口径确认、开发交底、问题反馈和提测跟进。现在回看，我会用下面四个问题，检查一份需求是否已经方便别人接手。
口径由谁确认？
管理层、财务、人事行政和开发测试，关心的问题并不相同。把待确认的定义与负责确认的人写在一起，下一位接手的人才知道该找谁继续。
几份材料对得上吗？
字段字典里的约束，应该能在原型、计算流程和验收样例里找到对应。改动一个条件后，沿着同一个字段逐项核对，比只更新一段说明更稳妥。
例外出现后，谁接手？
权限和例外规则需要落到操作上：谁能发起、谁能查看或修改、缺少信息怎样退回，以及后续处理需要留下什么记录。
结果怎样反馈回来？
把输入、预期路径和实际表现放在一起，反馈才容易定位。再注明涉及哪版规则、还有什么待确认，方便下一轮修改与复测。
材料导览 / 顺着内容继续读
案例背后，还可以展开看什么？
每个入口都标明材料类型，可以回看经历，也可以直接操作原型或方法示例。
简历中的工作经历
2026 年 8 月版简历记录了涉及的工作流、交付物与跨部门协作。
展开阅读↗02 / 方法演示需求追踪台
用六种虚构情境，对照需求、字段、界面行为与验收标准。
展开阅读↗03 / 交互演示自己改一次申请
在虚构的工作方法实验台中修改字段，查看流程去向。
展开阅读↗
读完之后 / 接着聊
你会怎样看？
欢迎补充经历、提出问题，或指出需要勘误的地方。中英文页面共用这一篇的讨论。
评论服务尚未开放。可以先写下想法，暂存在本机，或通过联系页发给我。
写一份本机草稿
点击“暂存本机”才会保存。共用设备上请在离开前清除；草稿不会自动发布。
0 / 1600