4. 系统需求工程

医院预约与排队管理系统的需求工程，不是把“能挂号、能排队”写成一句话，而是要把业务目标翻译成可验证、可追踪、可验收的工程约束。需求一旦含糊，后续架构选型、数据库设计、接口定义和测试用例都会失去基准。本节围绕功能需求、非功能需求、可用性指标、并发指标以及需求规格说明书（SRS）的编写方法展开，重点说明如何把模糊诉求转化为可度量的条目。

一、功能需求：按角色与业务闭环拆解

功能需求描述系统“必须做什么”。对预约排队系统而言，最有效的拆解方式是按角色和业务闭环组织，而不是按页面罗列。核心角色包括患者、医生/科室、挂号收费员、系统管理员。以患者侧为例，一个完整的预约闭环至少包含：选择院区与科室 → 查看号源与医生排班 → 选择时段 → 提交预约 → 支付/确认 → 生成排队序号 → 到院签到 → 候诊叫号 → 就诊完成。每个环节都要明确输入、输出、前置条件和异常分支。

功能需求应写成“主体 + 动作 + 对象 + 约束”的句式。例如：“患者可在就诊日前 7 天 00:00 至就诊当日 30 分钟前，对同一科室同一时段提交 1 次预约，重复提交时系统返回已有预约单号。”这比“支持在线预约”可测试得多。号源管理还需定义放号规则、退号规则、爽约规则和加号规则，这些规则往往决定并发冲突的处理方式。

二、非功能需求：质量属性的量化表达

非功能需求决定系统“做得怎么样”，包括性能、可靠性、安全性、可维护性、兼容性和合规性。医院场景下，非功能需求往往比功能需求更棘手：早高峰 7:30—9:00 的集中放号、现场大屏叫号的实时性、医保与支付接口的稳定性，都会直接冲击用户体验。

非功能需求必须量化。例如：“系统在 500 并发用户下，号源查询接口 P95 响应时间不超过 800ms；预约提交接口 P95 不超过 1.5s；叫号状态从医生点击到候诊屏刷新不超过 2s。”再如：“系统年可用性不低于 99.9%，单次故障恢复时间（MTTR）不超过 15 分钟；预约数据每日增量备份，保留 180 天。”安全方面需明确：患者身份认证方式、敏感字段加密存储、操作日志留存不少于 6 个月、接口防重放与限流策略。

三、可用性指标与并发指标

可用性指标通常用“几个 9”表达。99.9% 对应全年不可用约 8.76 小时，99.99% 对应约 52.6 分钟。对预约系统而言，放号瞬间和就诊早高峰是关键时段，可用性目标应分时段定义，而不是全年平均。并发指标则要区分“在线用户数”“并发请求数”和“并发事务数”。在线用户数不等于并发压力，真正压垮系统的是同一秒内对同一号源的争抢。

以某三甲医院为例（示例假设）：日预约量 8000 单，其中 70% 集中在 7:30—9:00，即约 5600 单在 90 分钟内完成，平均 62 单/分钟，峰值按 3 倍估算约 186 单/分钟。若每单预约涉及 1 次号源校验、1 次锁号、1 次写单，则峰值 TPS 约 9.3。这个量级看似不高，但锁号必须保证不超卖，因此需要数据库行锁、Redis 原子扣减或队列串行化等机制配合。

四、需求规格说明书的编写方法

SRS 的价值在于“可追踪”。建议每条需求分配唯一编号，并记录来源、优先级、验收标准和关联测试用例。功能需求用“FR-XX”，非功能需求用“NFR-XX”，接口需求用“IR-XX”。优先级可采用 MoSCoW 法：Must have（必须）、Should have（应该）、Could have（可以）、Won't have（本期不做）。例如“预约不超卖”是 Must，“候诊室大屏显示预计等待时间”可以是 Should。

编写时要注意三点。第一，避免歧义词，如“较快”“尽量”“友好”，应替换为具体数值或可观察行为。第二，区分需求与设计，SRS 说“系统应在 2 秒内刷新叫号状态”，而不是“使用 WebSocket 推送”。第三，为异常场景写需求：网络超时、支付回调重复、医生临时停诊、号源被锁后未支付，这些都必须有明确的系统行为定义。

五、从需求到验收：一个可操作的追踪示例

以“预约不超卖”为例，需求条目可写为：NFR-07 号源一致性——在峰值 200 TPS 下，同一号源被并发预约时，成功预约数不得超过号源总数，超卖数为 0。验收方式：使用压测工具对同一医生同一时段发起 500 并发预约，号源总数设为 100，检查最终成功订单数是否为 100，失败请求是否返回“号源已满”且不产生脏数据。对应设计约束：号源扣减必须在数据库事务或原子操作中完成，并记录操作日志。

再如“叫号实时性”：NFR-08 叫号延迟——医生点击“下一位”后，候诊区大屏和患者端状态更新延迟 P95 ≤ 2s。验收时在 50 个候诊终端同时在线的情况下，连续触发 100 次叫号，统计从点击到终端刷新的时间分布。若 P95 超过 2s，则需检查推送通道、终端轮询间隔和消息队列积压情况。

需求工程的最终产出不是一份文档，而是一组可被设计、开发和测试共同引用的契约。功能需求定义边界，非功能需求定义质量，可用性与并发指标定义容量底线，SRS 则把这些内容组织成可追踪、可评审、可验收的工程基线。只有把“患者希望少排队”翻译成“P95 响应时间、超卖数为 0、可用性 99.9%”这样的语句，系统建设才真正具备可落地的起点。