4. 软件需求工程与可验证性设计

数字疗法软件的验证难点，往往不在测试执行阶段，而在需求阶段就已经埋下。临床意图通常是“改善失眠严重程度”“降低焦虑评分”“提高用药依从性”，而软件需求若只写成“系统应提供睡眠记录功能”，测试人员就无法判断什么算通过。需求工程的任务，是把临床意图逐层转化为可追溯、可测试、可验证的软件需求规格说明（SRS），并在评审后形成受控基线。

一、从临床意图到软件需求的转化链

临床意图属于临床层，描述的是患者结局；软件需求属于工程层，描述的是系统行为。两者之间需要经过“临床目标—临床需求—用户需求—软件需求—验证准则”的逐级分解。以失眠数字疗法为例：临床目标为“6周内失眠严重程度指数（ISI）下降≥7分”，对应临床需求为“提供结构化睡眠限制与刺激控制干预”，用户需求为“患者能按处方完成每日睡眠窗口与行为任务”，软件需求则细化为“系统应在患者设定睡眠窗口后，于窗口开始前30分钟推送提醒，并记录实际入睡/起床时间”。

这一链条中，每一层都要有明确的来源与去向。临床目标来自临床方案或文献依据，用户需求来自目标用户与使用场景，软件需求来自用户需求，验证准则来自软件需求。缺少任何一环，都会导致“临床有效但软件无法验证”或“软件通过测试但临床无意义”。

二、需求可追溯性设计

可追溯性不是事后补文档，而是需求编写时就应嵌入的结构。推荐为每条需求分配唯一标识，并建立双向追溯：正向追溯从临床目标到测试用例，反向追溯从测试失败回到临床意图。实践中常用需求追溯矩阵（RTM）承载这一关系，字段至少包括：需求ID、需求描述、来源ID、验证方法、测试用例ID、当前状态。

以“睡眠窗口提醒”为例，可建立如下追溯记录：临床目标 CL-001（ISI下降≥7分）→ 临床需求 CR-003（睡眠限制干预）→ 用户需求 UR-007（按处方执行睡眠窗口）→ 软件需求 SR-012（窗口前30分钟推送提醒）→ 测试用例 TC-045（验证提醒时间误差≤1分钟）。当 TC-045 失败时，可沿链条反向定位到 SR-012 的实现偏差，而不是盲目修改临床方案。

三、可测试性与可验证性设计

可测试性要求每条软件需求都能对应一个客观、可重复的判定条件。写法上应避免“友好”“快速”“稳定”等模糊词，改用可量化表达。例如“系统应快速响应”应改为“在4G网络下，患者点击‘记录入睡’后，界面反馈时间≤2秒，成功率≥99%”。

可验证性则进一步要求验证方法明确。常见验证方法包括：测试（Test）、演示（Demonstration）、分析（Analysis）、检查（Inspection）。对于算法类需求，如“根据睡眠效率自动调整睡眠窗口”，适合用分析加测试组合验证；对于界面类需求，如“患者可查看周报告”，适合用演示加检查。每条需求在SRS中应标注验证方法，避免评审时才发现无法验证。

四、需求评审与基线管理实战

需求评审不是通读文档，而是按检查单逐条质询。建议评审前由需求作者完成自检，评审中由临床、软件、测试、法规四方分别从各自视角提问。评审输出应包含：通过项、有条件通过项、退回项，以及每条问题的责任人与关闭期限。

基线管理的关键动作是“冻结—变更—再冻结”。评审通过后，SRS进入受控基线，任何修改都必须走变更申请。变更申请应说明变更内容、变更原因、影响范围（涉及哪些需求ID、测试用例、风险项），经影响分析后由变更控制委员会决定是否批准。批准后更新版本号，重新评审受影响部分，形成新基线。

上表为示例基线记录，实际项目中版本号、日期与需求ID应按团队配置管理规范填写。基线管理的价值在于：当临床方案调整或法规要求变化时，团队能快速判断哪些软件需求、测试用例和风险控制措施需要同步更新，而不是凭记忆修补。

五、常见陷阱与应对

• 临床意图直接当软件需求：“改善失眠”无法测试，应分解为可观察的行为与数据指标。
• 追溯链断裂：测试用例找不到对应需求，或需求找不到临床来源，评审时应作为退回项处理。
• 验证方法缺失：需求写了但没写怎么验，导致测试阶段临时补方案，容易遗漏边界条件。
• 基线形同虚设：变更不记录、不分析影响，导致文档与实现脱节，审计时无法自证。

把需求工程做扎实，后续的验证与风险控制才有稳固的起点。临床意图经过逐层转化、追溯、可测试化与基线冻结，才能成为软件团队可执行、测试团队可验证、法规团队可审查的SRS。