【软考高级·系统分析师全链路通关实战】第 27 篇：需求获取技术——面向六类干系人的实战方法
本系列定位：面向有开发经验、从零备考软考高级「系统分析师」的工程师，以《系统分析师教程（第 2 版）》为主线，按「综合知识 → 案例分析 → 论文」三科组织，需求工程与 UML 建模深拆，60 篇带你从考试小白到三科同过。
本篇你将学到
- 需求获取六大技术全谱：访谈、问卷调查、JAD 联合需求计划、原型法、现场观察、文档考古（含各自适用场景与优缺点对比表）
- 面谈的艺术：开放式与封闭式问题的使用时机、需求获取会议的组织方法
- 获取技术的组合策略：按干系人特征与需求类型选技术，而不是一种技术打天下
- 云诊通实战：对医生（忙、碎片时间）、监管方（合规刚性）等六类干系人的差异化获取策略
- 获取记录 → 原始需求条目的转化规范：让每条需求「有出处、可追溯」
学完本篇，案例题「为该项目设计需求获取方案」这类开放设问，你将有一套按干系人分层的完整答法；论文「论需求获取方法的应用」也有了正文的实践素材。
考点热力表
|| 知识点 | 综合知识 | 案例分析 | 论文 |
|--------|:—😐:—😐:—😐
| 需求获取技术分类与适用场景 | ★★★ | ★★★ | ★★★ |
| 访谈法（开放/封闭式问题） | ★★ | ★★★ | ★★★ |
| 问卷法与抽样设计 | ★★ | ★ | ★ |
| JAD 联合需求计划 | ★★ | ★★ | ★★ |
| 原型法在获取中的应用 | ★★★ | ★★ | ★★ |
| 干系人分析与获取策略 | ★★ | ★★★ | ★★★ |
一、需求获取的本质与难点
1.1 获取不是「记录」，是「挖掘」
需求获取（requirements elicitation）是从干系人、文档、环境中主动挖掘需求线索并转化为原始需求条目的过程。它难在三个天然障碍：
- 用户说不出来：业务专家的知识是内隐的（「这个号就是这么排的」），要靠追问和观察才能显性化
- 用户说的不是要的：用户惯于直接给解决方案（「给我加个导出 Excel 按钮」），分析师要回溯到问题本身
- 干系人之间存在利益冲突：患者要便捷、监管要留痕（第 03 篇冲突表），获取阶段就要把冲突暴露出来留给分析阶段调解（第 28 篇）
因此获取技术的选择逻辑是：按「被访者的可接触性 × 需求的类型（显性/内隐/冲突性）」匹配技术。
1.2 六大技术总表
| 技术 | 做法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 访谈 | 一对一（或小组）结构化/半结构化交谈 | 关键干系人、深挖动机与规则 | 深入、灵活、可追问 | 费时、依赖访谈技巧、样本小 |
| 问卷调查 | 面向大量用户发放结构化问题 | 大样本用户（患者群体）、验证普遍性 | 覆盖广、成本低、可量化 | 无法追问、回收率与真实性存疑 |
| JAD 联合需求计划 | 组织跨部门联合工作坊集中定义需求 | 需求涉及多方、冲突需当场对齐 | 效率高、冲突早暴露、共识直接达成 | 组织成本高、强势方可能压制发言 |
| 原型法 | 快速做可交互的界面/流程原型供评价 | 需求模糊、用户无法凭空想象 | 用户「看得见才说得清」、反馈具体 | 易被当成产品承诺、范围诱导扩张 |
| 现场观察 | 到工作现场跟班作业记录实际流程 | 内隐知识多、口头描述与实际不符 | 揭示真实流程与例外、发现文档外的知识 | 费时、被观察者行为可能失真 |
| 文档考古 | 收集分析既有表单、制度、系统日志 | 存在成熟业务、历史系统替代项目 | 客观、不打扰业务方、细节丰富 | 文档可能过时、只反映「应有」而非「实有」 |
综合知识爱考「给场景选技术」：大量分散用户 → 问卷；规则深挖 → 访谈；多方冲突对齐 → JAD；需求模糊 → 原型；流程内隐 → 观察；有历史系统 → 文档考古。
二、面谈的艺术与会议组织
2.1 开放式与封闭式问题
| 类型 | 形态 | 作用 | 风险 |
|---|---|---|---|
| 开放式 | 「您现在处理退号是怎么做的？遇到什么麻烦？」 | 打开话题、挖掘未知信息、获取语言素材 | 跑题、耗时 |
| 封闭式 | 「退号截止时间是挂号当天 24 点前，对吗？」 | 确认事实、收敛结论 | 过早封闭会漏信息 |
使用节奏：先开放后封闭——开局用开放式把领域铺开，中段对关键规则用封闭式逐条钉死，收尾复述确认（「我总结一下，您看对不对……」）。反面教材是通篇封闭式：访谈变成查户口，用户只答不吐，内隐知识全部漏掉。
追问的三个利器：「为什么」（追到业务目标层）、「如果……会怎样」（探例外与边界条件，如「如果医生 24 小时未回复呢？」）、「能举个例子吗」（拿到可写进需求的具体场景）。
2.2 需求获取会议（JAD）的组织
JAD（Joint Application Development，联合需求计划）把患者代表、医生、护士导诊、药师、运营、监管方拉进同一场结构化工作坊，关键组织要点：
- 角色分工：主持人（分析师，控流程不强观点）、记录员、决策人（业主代表，现场拍板冲突项）、参与人（各方业务骨干）
- 议程前置：议题、背景材料提前发放，避免现场从零开始
- 可视化工具：白板/在线协作画流程，当场确认当场改
- 冲突登记而非当场死磕：谈不拢的记入问题清单，会后分头沟通，避免会议瘫痪
云诊通用了两场 JAD：第一场对齐「线上号源与现场号池的分配规则」（患者/护士导诊/运营三方），第二场对齐「处方流转与审方时序」（医生/药师/监管方）。
三、技术组合策略与决策
单一技术总有盲区，实战按两个维度组合：
- 按干系人分层：决策层（访谈，谈业务需求）→ 业务骨干（访谈 + 观察 + JAD，谈规则细节）→ 大众用户（问卷 + 原型试用，验证体验）
- 按需求形态分型：显性规则 → 文档考古 + 封闭式确认；内隐流程 → 观察 + 开放式访谈；冲突性议题 → JAD 当面对齐；模糊体验 → 原型迭代
选择决策树（案例答题可直接套用）：
四、云诊通实战：六类干系人的差异化获取
4.1 干系人 × 策略矩阵
| 干系人 | 特征 | 主策略 | 辅策略 | 获取重点 |
|---|---|---|---|---|
| 患者 | 大样本、非专业 | 问卷（分层抽样） | 低保真原型试用 | 体验痛点：排队、取报告、复诊提醒 |
| 医生 | 极忙、碎片时间、抵触冗长会议 | 短时结构化访谈（15-20 分钟，约在门诊间隙） | 观察接诊过程 | 接诊操作流、时效预期、开方习惯 |
| 护士/导诊 | 现场秩序责任人 | 现场观察 + 访谈 | JAD（号源分配场） | 加退号规则、号池管理、例外处置 |
| 药师 | 强规则、责任重 | 访谈 + 文档考古（审方制度） | JAD（处方流转场） | 审方规则、拒方流程、双人复核红线 |
| 医院运营 | 数据驱动、有话语权 | 访谈（决策层口径） | 问卷（满意度指标） | 号源利用率、留存转化、报表需求 |
| 卫生监管方 | 合规刚性、文件完备 | 文档考古（监管文件）+ 正式函访 | — | 上报范围、频率、格式、时效红线 |
4.2 两个难点的具体打法
难点一：医生没时间。云诊通不打持久战访谈：先通过文档考古（电子病历系统操作手册、现有 HIS 界面）把 80% 的显性规则自学掉，访谈只问手册里没有的（「什么情况下你会让患者转线下？」「图文问诊消息你希望在什么时候收到提醒？」）；每次访谈控制在 20 分钟、带封闭式问题清单逐条钉死；对确实无法约到的专家，用「随手可答」的移动端微问卷补位。结果：38 位医生覆盖访谈 31 位，规则确认率超过九成。
难点二：监管方口径刚性。监管需求不能靠「聊」获得——一切以正式文件为准。团队的做法是建立合规需求清单：逐条摘录监管文件中的义务性表述（复诊限定、处方实时上报、数据留存年限），每条登记为带「合规」标签的原始需求，并附文件名与条款号出处；模糊之处（如「实时」的具体时限）通过正式函访获得书面答复，绝不口头默认。这份清单后来成为第 31 篇变更控制的判断基准。
4.3 获取记录 → 原始需求条目
所有渠道的记录统一转化为结构化条目，字段包括：编号、来源（干系人/文档+条款）、日期、原始陈述、初步归类（功能/非功能/约束/待澄清）、优先级初判。两个纪律：
- 不加工不删减：原始陈述照录（「系统要快」就是照录），翻译成规范需求是第 28 篇分析阶段的事，获取阶段翻译会丢失语境
- 条条有出处：没有来源的条目不允许入库——这正是第 31 篇需求跟踪矩阵第一列的雏形
云诊通口径：六个渠道共产出 100 余条原始需求（与第 26 篇预告一致），其中监管合规类 14 条、医生时效类 11 条、患者体验类 40 余条——分布本身就说明了「谁的声音容易被漏掉」（监管与医生），需要分析师主动补位。
真题风格自测题
1. 需求获取阶段面对「大量分散、地理上无法集中的终端用户」，最适用的技术是（ ）。
A. 问卷调查 B. 一对一深度访谈 C. 现场观察 D. 文档考古
2. JAD 联合需求计划最突出的价值是（ ）。
A. 成本最低 B. 多方冲突在工作坊中当面暴露并对齐 C. 完全不需要分析师参与 D. 可替代所有其他获取技术
3. 「您现在处理退号是怎么做的？」属于（ ）。
A. 封闭式问题 B. 开放式问题 C. 引导性问题 D. 无效问题
4. 访谈中确认具体事实（如截止时间）应优先使用（ ）。
A. 开放式问题 B. 封闭式问题 C. 反问 D. 沉默
5. 用户「说不清想要什么」时，最有效的获取技术是（ ）。
A. 原型法 B. 问卷 C. 文档考古 D. 正式函访
6. 口头描述与实际操作经常不符的业务，应补充（ ）。
A. 现场观察（跟班作业） B. 加发问卷 C. 电话访谈 D. 邮件确认
7. 存在成熟业务表单与待替代旧系统的项目，性价比最高的获取技术是（ ）。
A. JAD B. 原型 C. 文档考古 D. 观察
8. 原型法用于需求获取的主要风险是（ ）。
A. 用户拒绝参与 B. 原型被误当作产品承诺，诱导范围扩张 C. 无法展示界面 D. 必须使用真实数据
9. 好的访谈节奏通常是（ ）。
A. 全程封闭式 B. 先开放式铺开、关键规则封闭式钉死、收尾复述确认 C. 全程开放式 D. 只问是与否
10. 云诊通对监管方的获取策略核心是（ ）。
A. 口头访谈记录口径 B. 以正式文件为准逐条摘录并函访澄清模糊时限 C. 发放满意度问卷 D. 用原型演示征求反馈
11. 原始需求条目「条条有出处」的纪律，主要服务于（ ）。
A. 需求跟踪与后续变更评估的可追溯性 B. 增加文档篇幅 C. 便于删除需求 D. 提高打字效率
12. 获取记录入库时「不加工不删减、照录原始陈述」的原因是（ ）。
A. 分析师翻译能力不足 B. 过早翻译会丢失语境与原始意图，规范化应留给分析阶段 C. 用户喜欢原文 D. 工具限制
13. 简答：为「医院运营方关注号源利用率与患者留存」设计两条访谈提问（一开放一封闭）。
参考答案：1.A 2.B 3.B 4.B 5.A 6.A 7.C 8.B 9.B 10.B 11.A 12.B 13. 示例——开放式：「您现在通过哪些报表判断号源利用情况？最不满意哪个环节的数据？」；封闭式：「如果系统每日自动推送各科室号源利用率与爽约率对比，是否满足您的日常运营决策需要？」
本篇小结
| 知识点 | 核心内容 |
|---|---|
| 获取三难 | 用户说不出来、说的不是要的、干系人利益冲突 |
| 六大技术 | 访谈（深挖）、问卷（大样本）、JAD（对齐冲突）、原型（化模糊）、观察（显内隐）、文档考古（挖存量） |
| 访谈节奏 | 先开放铺开 → 封闭钉死 → 复述确认；三大利器：为什么/如果…会怎样/举个例子 |
| JAD 要点 | 主持+记录+决策人角色分工，议程前置，冲突登记不死磕 |
| 组合策略 | 按干系人分层 × 按需求形态分型匹配技术 |
| 云诊通示范 | 医生：短时访谈+自学先行；监管：文件为准+函访澄清；100+ 条原始需求条条有出处 |
下篇预告
第 28 篇：需求分析与建模——从原始需求到需求模型
100 多条带着口水话的原始需求怎么变成干净的需求模型：分类框架、建模双路线（DFD/UML）、质量属性冲突分析，以及 MoSCoW 优先级排序与「实时性 vs 留痕合规」的冲突调解全过程。
如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。
