2. 随访业务需求工程

随访系统失败，往往不是技术不行，而是需求没对齐。临床科室想要“术后 7 天必须电话随访”，护理部关心“谁在什么时候打了电话、患者接没接”，信息科担心“接口能不能拿到出院小结和检验结果”，患者则希望“别老在上班时间打、别问重复问题”。这四类诉求如果不在需求阶段拆开、对齐、写清，开发出来的系统就会变成“谁都能用、谁都不满意”的表格工具。本节要解决的核心问题是：如何从多方采集随访需求，区分功能需求与非功能需求，并输出可评审、可追溯的需求规格说明书与用户故事地图。

一、需求来源与采集方式

随访需求不是“问一遍”就能拿全的。不同角色掌握的信息不同，采集方式也应不同。临床科室掌握随访路径与临床判断规则，适合用路径走查会：拿一个真实病种（如腹腔镜胆囊切除术后）的出院流程，让医生逐步说出“出院后第几天、看什么指标、异常怎么处理”。护理部掌握执行细节与工作量，适合用跟班观察 + 访谈：跟随随访护士半天，记录她实际打开几个系统、打几个电话、遇到哪些打不通的情况。信息科掌握数据边界，适合用接口清单核对：逐项确认 HIS、LIS、EMR 中哪些字段可读、更新频率如何、是否有患者主索引。患者侧则适合用问卷 + 回访录音抽样：了解可接受的联系时段、对隐私的顾虑、最希望被提醒的事项。

采集时建议使用统一的需求记录卡，每张卡至少包含：需求编号、提出角色、原始诉求、触发场景、期望结果、优先级、验收线索。例如“护理部-003：电话未接通时，希望系统自动生成待重拨任务，而不是手工记在纸上”。原始诉求要保留原话，避免在采集阶段就替对方“翻译”成技术方案。

二、功能需求与非功能需求的区分

功能需求回答“系统做什么”，非功能需求回答“系统做到什么程度、在什么约束下做”。随访场景中，两者极易混淆。例如“支持电话随访记录”是功能需求；而“随访记录保存后 1 秒内可被护士站其他终端看到”是性能类非功能需求；“患者手机号在列表页脱敏显示，仅随访责任护士可查看完整号码”是安全与隐私类非功能需求；“系统在每日 8:00–9:00 高峰期仍能支持 200 名护士并发录入”是容量类非功能需求。

区分方法很简单：把需求写成“主语 + 动作 + 对象 + 条件 + 可验证结果”。如果结果只能靠“看功能有没有”判断，是功能需求；如果结果要靠“测指标、查约束、审权限”判断，是非功能需求。下表给出随访系统常见的需求分类示例，参数为教学假设值，用于说明写法，不代表真实项目实测。

三、需求规格说明书的组织方式

需求规格说明书不是需求卡片的简单堆叠，而是要让开发、测试、临床三方都能读懂。建议按“业务背景—角色与场景—功能需求—非功能需求—数据与接口—验收标准—变更记录”组织。其中“角色与场景”用用户故事地图承载，“功能需求”用编号条目承载，“非功能需求”单独成节并标注度量方式，“数据与接口”明确字段来源与更新频率，“验收标准”尽量写成可执行的检查项。

一个容易被忽略的点是需求追溯。每条需求应能追溯到来源角色和原始诉求，也能向下追溯到测试用例。例如 FR-02 来源于护理部-003，对应测试用例 TC-02“模拟连续 3 次未接听，检查任务状态流转”。这样在评审时，任何一条需求被质疑，都能快速定位到提出人和场景，而不是陷入“我觉得应该这样”的争论。

四、用户故事地图：把需求放回随访时间轴

用户故事地图的价值在于：它不按模块罗列功能，而是按患者随访的真实时间顺序展开。横轴是随访阶段（出院当天、术后 1 天、术后 3 天、术后 7 天、术后 30 天），纵轴是不同角色的活动（患者收到提醒、护士执行随访、医生查看异常、信息科监控接口）。每个交叉点放置用户故事卡片，卡片按优先级从上到下排列。这样团队一眼就能看出：哪个阶段故事最密集、哪个角色负担最重、哪些故事依赖同一接口。

下图给出一个简化但完整的用户故事地图示例，覆盖患者、随访护士、临床医生、信息科四类角色，以及出院至术后 30 天的关键节点。图中同时标出了功能需求与非功能需求的落点，便于在评审时快速定位。

地图画完后，团队应做一次“走图评审”：从出院当天走到术后 30 天，逐格确认故事是否完整、依赖是否明确、非功能需求是否落在具体节点上。例如 NFR-02 落在“校验手机号字段”和“审计号码查看日志”两处，说明脱敏与审计不是抽象原则，而是要在接口同步和护士查看两个动作上分别实现。

五、从需求到可执行成果

需求工程的最终交付不是一份文档，而是一组可被开发、测试、临床共同使用的约定。建议在需求规格说明书中固定一个“需求条目模板”，每条包含：编号、类型、来源角色、场景描述、需求陈述、优先级、验收标准、关联故事地图节点。评审时逐条过，重点检查三件事：功能需求是否有明确触发条件与结果；非功能需求是否有可度量指标；每条需求是否能在故事地图上找到落点。做到这三点，随访系统在开发前就已经把“谁在什么时候、因为什么、需要系统做什么、做到什么程度”说清楚了，后续的接口联调、测试用例编写和上线验收才有共同基准。