文 / STEM Career 编辑部
Business Analyst 面试里的“分析需求”，不一定要求先写 SQL。客户的一句话可能同时包含业务问题、解决方案猜测和情绪，你需要把它拆成可以确认、实现和验收的要求。
如果你正在申请 BA、IT BA 或相关业务分析岗位，先读清职责侧重。本文用原创退款进度案例，练习从模糊要求到用户故事、流程与验收条件，帮助你展示分析与协作能力。
从一句不完整的要求开始
教学客户说：“用户总来问退款到哪里了，我们想加一个更智能的页面。”这句话没有说明哪些用户、哪种退款、现在怎样查询，以及问题究竟出在数据、流程还是展示。
第一轮先请对方描述最近一次具体查询：谁提交退款、谁处理、状态从哪里更新、用户什么时候来问，以及客服怎样回答。通过例子识别现状，比直接画一个新页面更有依据。
还要确认目标。减少重复查询、缩短处理时间与提高状态透明度，不一定通过同一个改动实现。先让负责人确认本次最重要的结果。
把角色与流程写清楚
至少区分用户、客服、退款处理方和系统。用户需要理解当前状态，客服需要识别异常，处理方需要更新结果；不同角色不应自动拥有相同权限。
流程可以从申请、受理、处理、完成与异常开始，但这些只是教学设定。真正项目应按业务定义命名，不能擅自把资金退回时间写成系统已经完成的状态。
如果状态来自外部服务，需要确认数据时间、延迟与冲突处理。页面显示准确文字，也无法修复来源数据长期不更新的问题。
用需求访谈记录保留未知
| 问题 | 已知事实 | 待确认事项 |
|---|---|---|
| 谁查询 | 登录后的申请人 | 是否有代理查询 |
| 查什么 | 自己提交的退款 | 多笔退款怎样区分 |
| 状态来源 | 模拟处理系统 | 更新时间与延迟 |
| 允许动作 | 查看与联系客服 | 能否修改申请 |
| 成功结果 | 更清楚知道当前阶段 | 怎样观察重复询问变化 |
记录未知不影响推进，前提是说明谁来确认以及它影响哪项决定。不要为了让答案完整，给缺失信息填入没有依据的业务规则。
用户故事需要连接具体行为
一个教学用户故事可以是：“作为退款申请人，我希望看到自己申请的当前阶段和更新时间，以便判断是否需要继续等待或联系客服。”
故事解释了角色、任务和目的，但还没有覆盖全部验收。需要进一步说明正常状态、无记录、数据延迟和异常时的表现。IIBA 的验收与评价条件资料可帮助理解条件与完成判断的关系。
不要仅因为写成标准句式，就认为需求已经明确。真正的检查是工程、业务和使用者能否对同一结果达成一致理解。
验收条件怎样写成可检查事项
| 条件 | 预期行为 | 需要的证据 |
|---|---|---|
| 本人有一笔申请 | 显示对应状态与时间 | 与授权数据对照 |
| 本人有多笔申请 | 能辨认每笔记录 | 不混淆金额与标识 |
| 无申请记录 | 明确说明并给合适入口 | 不展示他人信息 |
| 来源暂时失败 | 说明暂时无法确认 | 不把未知显示成完成 |
| 状态过期 | 显示数据时间与下一步 | 不承诺未确认日期 |
写条件时避免“页面友好”“尽量快速”这类无法共同判断的表述。若要约定响应时间，需要给出测量方式和场景，并由相关方确认，而不是在面试中随意报数字。
需求与设计方案分别记录
“用户能看懂状态”是需求方向，“用时间轴展示”是一种候选设计。先比较列表、时间轴或简短说明能否完成任务，再决定界面，不让最初想法限制调查。
相同需求也可能通过数据更新流程、客服模板或通知方式改善。BA 需要帮助团队看见选择与依赖，不必把所有问题都转成新功能。
如果岗位偏产品，可以进一步练Product Sense 的用户与优先级；如果偏数据，则配合SQL 与业务指标准备不同任务。
加入一个变更请求
客户现在说：“能不能让用户直接催一下退款？”先问催促会通知谁、是否改变处理顺序、多久能催一次，以及可能造成的运营负担。按钮只是表面，后面还有流程责任。
把变更影响写出来：接口、权限、记录、频率控制、客服说明和验收。然后与负责人比较业务价值与成本，决定纳入本次、替换其他范围或留到后续。
这轮讨论能够检验你是否理解需求之间的关系。只回答“可以加”或“工期不够”，都缺少决策依据。
用追溯表连接问题与检查
给重点要求一个简单标识，记录来源、相关流程、对应设计与验收。比如用户需要知道数据是否更新，对应“显示更新时间”和“来源失败时不伪造当前状态”两个检查。
当来源字段改变时，可以顺着关系查看影响哪些条件；当某项测试失败时，也能回到它保护的业务需要。追溯表规模可以很小，关键是关系清楚。
IIBA 核心标准可作为澄清与确认需求的概念来源。面试展示则用原创案例的实际记录，不靠引用标准名称替代分析。
双人模拟怎样安排
一人扮演客户，只提供不完整要求；另一人先提问，再整理一页需求说明。观察者记录哪些问题改变了方案、哪些假设未经确认，以及验收是否可共同检查。
第二轮加入数据延迟或权限变化，看原说明是否需要调整。反馈可以具体到一句问题或一项条件，例如“你问了状态种类，但没确认用户能否看到他人的申请”。
用两个反例检验验收条件
第一例：页面显示“已完成”，来源记录却是昨天的处理中状态。即使界面按设计出现，也没有满足状态透明度，需要检查来源和更新时间。第二例：查询能返回正确记录，却只凭申请编号展示给任何访问者。功能结果看起来正确，角色与访问条件仍然有问题。
把这两个情境加入验收，说明每项检查保护哪条业务需要。条件不必一开始就很多，但应覆盖最重要的任务与约束。若不同参与者对预期结果意见不同，先确认定义，不能让工程师在实现中独自决定。
面试官可能追问“这算需求还是测试”。你可以解释，BA 先帮助大家明确可接受结果，之后由相应角色把它落实为设计与检查。职责会按团队变化，但共享理解是这项练习要交付的核心。
为每条验收条件注明对应的需求来源，方便变更时回查。如果条件只是个人偏好，就请相关方确认，不把它写成客户已经要求。这样能减少实现阶段的争议，也让面试中的分析过程有更清楚的依据。
把练习接到岗位定位
如果分不清目标 BA 岗偏数据、系统需求还是业务交付，可以加微信说一下正在看的岗位与已有经历。材料还没有整理完，也可以先描述最不确定的工作任务。
通过求职方向与案例准备先核对 JD，再讨论项目、材料和专项面试。把一句模糊要求整理成能确认的结果，既能帮助你判断是否喜欢 BA，也能形成招聘方可以追问的能力证据。
常见问题（FAQ）
BA面试一定要先写SQL吗？
取决于岗位，需求类任务更需澄清流程与验收。
用户故事写好就完成需求了吗？
还需确认边界、例外与可检查条件。
客户临时加按钮怎样处理？
先核对业务动作、影响与优先级，再确认范围。
- IIBA 的验收与评价条件资料· IIBA
- IIBA 核心标准· IIBA
分不清目标 BA 岗偏数据还是偏系统需求？加微信说一下你正在看的岗位和现有经历，可以先把准备方向理清。