2. 需求分析与用户角色建模

远程访视平台的需求不是从功能清单开始的，而是从“谁在什么场景下完成什么任务”开始的。同一个“发起视频访视”动作，在医生端意味着排班确认与病历调阅，在护士端意味着设备检查与患者签到，在患者端意味着收到提醒并进入候诊，在管理员端意味着资源调度与合规审计，在家属端则意味着授权范围内的陪同与结果知悉。若不做角色建模，需求会退化为“加一个视频按钮”，最终在权限、通知、数据可见性和异常处理上反复返工。

角色画像：从职责边界推导权限边界

角色画像（Persona）不是人物小传，而是把职责、目标、约束和失败代价结构化，用于推导权限与交互。建议每个角色至少记录六项：核心目标、典型任务、使用环境、数字能力、关键约束、失败后果。以下为示例画像，参数为教学假设，实际项目应通过访谈与观察校准。

从表中可直接推导权限矩阵：患者只能读写自己的访视数据；家属默认只读且需患者显式授权，代操作需二次确认；医生可读写其负责患者的临床数据，但不可修改审计日志；护士可读写排程与执行状态，临床诊断字段只读；管理员可配置与审计，但访问临床内容应触发留痕。权限边界一旦明确，后续的功能需求就有了归属。

访视流程建模：状态机比流程图更能暴露需求

访视流程若只画成“预约→签到→视频→结束”，会遗漏大量异常分支。更有效的做法是建立状态机，明确每个状态的进入条件、允许操作、超时策略和异常出口。以一次计划访视为例，核心状态包括：已排程、待签到、候诊中、访视中、待补录、已完成、已取消、失访。关键转移条件如下：到达预约时间前30分钟进入待签到；患者签到且设备自检通过进入候诊中；医生接入后进入访视中；视频中断超过5分钟进入待补录；补录完成或医生确认后进入已完成；超过预约时间24小时未签到则标记失访。

状态机图的价值在于：每个状态都对应一组可测试的需求。例如“待补录”状态要求系统保存中断前的会话元数据、允许医生在24小时内补录结论、并在补录后自动通知患者与护士。这些需求若只靠流程图很难被完整识别。

功能性需求与非功能性需求的提取方法

功能性需求回答“系统做什么”，非功能性需求回答“做到什么程度”。提取时建议采用“角色—任务—状态”三轴交叉法：先列出每个角色在每个状态下要完成的任务，再为每个任务定义可验证的验收条件。以“患者签到”为例，功能性需求是“患者可在预约时间前30分钟至后15分钟内完成签到”；非功能性需求则包括“签到接口在200并发下P95响应时间不超过800ms”“签到失败时提供重试与护士求助入口”“签到记录不可被患者端修改”。

非功能性需求容易被写成口号，应尽量量化并绑定验证方式。常见维度包括：性能（响应时间、并发量、视频首帧时间）、可用性（月度可用性、故障恢复时间）、安全（传输加密、访问控制、审计留痕）、合规（数据保留期限、知情同意记录）、易用性（老年患者完成签到所需步骤数、错误率）、可维护性（配置变更生效时间、日志可检索性）。每条非功能性需求都应写明指标、测量方法和判定阈值，否则无法在验收阶段判断是否达成。

从需求到可执行成果：角色—状态—需求追踪表

为避免需求散落，建议直接产出一份追踪表，作为设计、开发与测试的共同依据。以下为示例片段，字段可根据项目裁剪。

这张表本身就是需求分析的交付物：它把角色、状态、功能与非功能需求绑定在一起，使后续的接口设计、权限配置和测试用例都能直接引用需求编号。实际项目中，建议在需求评审时逐条确认验收条件是否可测，对无法量化的条目当场改写，避免把模糊表述带入开发阶段。

完成角色建模、状态机梳理和需求追踪表后，下一阶段的设计工作就有了稳定输入：权限矩阵来自角色画像，接口与事件来自状态转移，性能与安全指标来自非功能性需求条目。需求分析的质量，直接决定远程访视平台在真实临床场景中能否被顺畅使用并经受合规审查。