3. 医生工作站需求工程

医生工作站的需求工程不是“问医生想要什么功能”，而是把临床工作流中隐含的约束、判断规则、数据依赖和异常处理，转化为可验证、可追踪、可变更控制的工程输入。需求一旦漏掉一个关键分支，例如“危急值未确认时的强制拦截”，上线后可能直接演变为医疗安全问题。因此，本节按“访谈—捕获—规格化—变更—评审”的闭环展开，重点说明每一步实际怎么做、产出什么、如何判断做对了。

一、临床用户访谈：按角色与场景分层，而不是按科室泛问

访谈对象至少覆盖四类角色：门诊医生、住院医生、护士（含主班）、医技与药房接口人。每类角色的关注点不同：门诊医生关心接诊效率与处方合规，住院医生关心医嘱闭环与病程记录，护士关心执行确认与给药核对，医技药房关心申请与结果回传。访谈前应准备“场景脚本”，例如“一位65岁糖尿病患者复诊，主诉头晕，需开检验、调整降糖药并预约复诊”，让医生按真实操作顺序走一遍，而不是抽象描述。

访谈中要刻意追问三类信息：触发条件（什么情况下必须做某动作）、例外路径（系统不可用、患者拒绝、结果未回时怎么办）、判断依据（医生依据哪些数据下结论）。例如医生提到“肌酐高要调整二甲双胍”，必须追问阈值、单位、是否按eGFR分层，这些就是后续需求规格中的可验证参数。访谈记录建议采用“原话+场景+待确认问题”三栏，避免直接写成功能清单而丢失上下文。

二、需求捕获：从原话到可追踪需求条目

捕获阶段的核心是把访谈原话拆解为原子需求，并赋予唯一编号与来源。推荐使用“需求条目卡”结构：编号、来源角色、场景、前置条件、主流程、异常分支、数据项、验收标准、优先级。例如：

REQ-OPD-012 门诊处方肾功能校验
来源：门诊医生访谈 2024-03-12
前置：患者本次就诊已录入血肌酐结果
主流程：开立二甲双胍时，系统读取最近一次eGFR
异常：eGFR<45 时弹出警示并要求填写理由；eGFR<30 时禁止开立
数据项：eGFR值、检测时间、单位、医生理由
验收：构造eGFR=28的测试患者，开立被拦截且记录理由
优先级：高（安全相关）

捕获时要注意区分“需求”与“实现方案”。医生说“要在处方界面加一个红色按钮”是方案，真实需求可能是“高风险处方需二次确认”。保留需求本质，方案留给设计阶段。同时建立需求追踪矩阵的雏形：每条需求对应来源访谈、对应验收用例、对应后续设计模块，确保不丢失也不重复。

三、需求规格说明书编写：让每条需求可验证

需求规格说明书（SRS）不是功能列表，而是开发、测试、临床三方共同认可的契约。建议按“业务场景—功能需求—数据需求—接口需求—非功能需求—验收标准”组织。每条功能需求必须包含可判定的验收条件，避免“界面友好”“响应较快”这类不可测描述。非功能需求要给出具体指标，例如“门诊开方保存操作在并发200用户下，95分位响应时间不超过2秒”。

数据需求要明确字段来源、单位、精度与更新时机。例如体温单位统一为摄氏度、保留一位小数；检验结果回传需带检测时间与仪器标识。接口需求要写清调用方向、触发时机、失败重试与幂等要求。SRS评审前应做一次“可测试性自检”：每条需求能否设计出一条通过/不通过的测试用例？不能的，退回重写。

四、需求变更管理：控制影响面，而不是拒绝变更

临床需求在建设期几乎必然变化，例如医保政策调整、新检验项目上线、科室流程优化。变更管理的目标不是“冻结需求”，而是让每次变更的影响可见、可评估、可追溯。建议流程为：提出变更申请 → 影响分析 → CCB（变更控制委员会）审批 → 更新SRS与追踪矩阵 → 通知开发测试 → 回归验证。

影响分析要回答四个问题：影响哪些已有需求？影响哪些接口与数据表？影响哪些已完成的测试用例？是否影响上线时间与安全合规？例如将“eGFR<45警示”改为“eGFR<60警示”，需评估：涉及处方模块、检验接口、警示规则表、3条已写测试用例，以及是否与临床指南一致。变更申请单应记录申请人、日期、变更前后内容、影响范围、审批结论与实施版本，形成可审计记录。

五、评审机制：分阶段、有检查项、有结论

评审不是一次性会议，而是分阶段嵌入：访谈记录评审、需求条目评审、SRS基线评审、变更评审。每次评审需有明确检查项与结论（通过/有条件通过/不通过）。核心检查项包括：完整性（异常分支是否覆盖）、一致性（同一参数在不同需求中是否冲突）、可测试性（能否写出通过/不通过用例）、安全合规（是否满足危急值、抗菌药物分级、隐私保护要求）。

评审结论要落到具体条目，避免“整体感觉可以”。例如“REQ-OPD-012 验收标准缺少eGFR单位校验，需补充后重新评审”。评审记录与SRS版本绑定，确保任何一条需求都能回答“谁在什么时候因为什么原因批准了它”。

把上述五步串起来，医生工作站的需求工程就形成了一条可追踪的链路：访谈获得真实场景，捕获形成原子需求，SRS给出可验证契约，变更管理控制影响，评审机制保证质量。最终交付的不只是一份文档，而是一套能支撑开发、测试、临床验收和后续运维的需求资产。