E6 · 出版卷 28

需求与专业边界

用户角色、决定、风险、范围与非目标

*用户角色、决定、风险、范围与非目标*

地学系统的决定、角色、证据、风险与非目标边界
地学系统的决定、角色、证据、风险与非目标边界

学习目标

本课是通用、机构中立内容，不使用任何真实公司、个人、矿权、项目或可识别地点。通用角色只描述职责，SYN-ARCH 标识符明确表示合成教学证据。

  • 界定由“用户角色、决定、风险、范围与非目标”治理的决定。
  • 在选择实现前建立相关边界、状态与合同模型。
  • 定义可测不变量、故障证据与安全发布后果。
  • 基于合成证据产出一份以决定为中心的需求与专业边界登记表并为其权衡辩护。

决策边界

先定义系统可以支持的决定，以及绝不能替人作出的决定。识别行动角色、受影响对象、合格证据、决定时域、错误后果、升级路径与负责批准的角色。“建设地质仪表板”不是需求，因为它没有说明决定与响应量度。应改写为有边界场景：审查角色必须在声明的数据版本内定位冲突区间状态，从来源记录解释冲突，并在身份或参考未解决时阻止发布。非目标是一等约束，防止便利功能悄然变成专业结论。

核心概念

区分利益相关方需要、系统需求、软件需求、政策约束与验收证据。需要描述期望结果；需求规定可验证义务；设计决定选择满足义务的一种方式。混合这些层级会把备选方案误写成强制要求，也会隐藏组件存在的理由。功能适合性只是质量关注之一；可靠性、安全、性能效率、兼容性、可维护性、可用性、安全相关后果与可移植性都会改变可接受架构。专业边界还要追问：哪些陈述必须由具备能力的领域角色、独立审查或软件边界之外的法定权限判断？

系统模型与合同

为角色、决定、关注点、需求、风险、控制、验收测试与发布制品维护带稳定标识符的追踪图。每条需求记录来源、理由、优先级、验证方法、适用范围、版本与状态。质量需求使用包含刺激、环境、受影响元素、响应与响应量度的场景。语境模型标出人员、外部系统、信任边界、证据流与排除职责。专业边界表区分计算、呈现、建议、批准与发布。架构决定向后连接其处理的需求，向前连接发布后继续观察主张的测试与遥测。

不变量与验收标准

| 不变量 | 测试证据 | 发布后果 | |---|---|---| | 每项系统行为都追溯到决定、需求或明确非目标。 | 合同测试与反例记录 | 阻止发布 | | 专业批准始终分配给获授权的人工角色。 | 回放比较与摘要检查 | 隔离制品 | | 每项适用需求都有验证方法与发布后果。 | 基于角色的验收追踪 | 把决定返回为未解决 | | 豁免具有范围、批准、时限且可复审。 | 故障注入与恢复记录 | 保留上一已验证版本 | | 合成证据绝不表示为实测运行证据。 | 依据声明证据的领域审查 | 记录明确评审发现 |

量化工程

追踪覆盖率为 C_t=n_{verified}/n_{applicable}，分母是本次发布适用的需求，分子是已连接通过证据的需求。缺失、含混与豁免项要分开报告；高比例不能为一个未经测试的高后果需求开脱。筛查模型可把期望暴露写为 E=p_1c_1+p_2c_2+...+p_nc_n，但概率与后果必须有来源或明确界限，不能凭空编造。无法数值校准时使用风险类别。验收量度必须说明总体、环境、阈值、观察窗口与发布后果。

数据质量、证据与不确定性

需求证据包括观察到的任务、决定记录、代表性数据集、错误历史、适用政策与直接评审发现。访谈陈述只是输入，不能自动成为权威需求。记录每条陈述的提供角色、语境、冲突说法与需求解决方式。合成案例可以测试结构与故障处理，却不能确定真实运行风险的频率、严重性或可接受程度。未知法律、安全或专业义务应作为开放依赖交给外部审查；架构不能用笼统“合规”标签把它们隐藏起来。

互操作性与版本

为需求与验收测试分配独立于文档标题的机器稳定标识符。交换字段包括标识、陈述、理由、角色、决定、风险链接、验证方法、状态、有效区间与取代关系。对需求集进行版本管理，并保留每次发布使用的基线。文字调整但义务不变时保留身份并记录修订；义务发生不兼容变化时签发新身份或声明主合同版本。导出必须保留链接与受控术语，不能把图压平成无法重新连接的散文。

安全与专业责任

需求可能暴露敏感位置、脆弱点、个人职责或特权工作流。按对象级别分类访问，只收集决定所需信息。不要把秘密、凭证或可被利用的实现细节放入广泛分发的需求文档。同一角色可能定义、实现、验证并批准高后果控制时，必须进行职责分离。豁免应记录范围、理由、补偿控制、批准角色、到期与复审触发条件。“安全”“行业标准”“最佳实践”等词本身不可测试，不能作为验收标准。

运行流程与可观测性

把需求变更作为可观察工作流：提出、影响分析、解决冲突、批准、实施、验证、发布与监测。发布候选声明所用需求基线，并为每项适用验收测试输出结果。运行信号检验数据量、延迟、拒绝率与角色行为等假设。阈值失败时，把事件连接到需求与决定，而不是只开一个无分类缺陷。周期复审检查过期假设、未使用控制以及用户试图绕过的非目标。紧急变更仍需事后追踪与明确到期。

集成检查点

把“需求与专业边界”制品连接到本卷前面的架构。追踪一个合成对象从来源身份穿过新边界到达已审查输出，再把一个拒绝或故障追溯到最早被违反的不变量。更新架构决定记录，写明所选方案、备选方案、假设、证据、后果、责任角色、评审状态与重新考虑触发条件。只有另一位审查者无需口头说明即可重建成功路径与阻断路径，检查点才通过。

合成案例

SYN-ARCH-01 最初提出“自动批准有效数据集”。分解后发现三个决定：结构验证、领域适用性与发布批准。系统可以计算结构发现并汇集证据，但只有指定审查角色可判断领域适用性与发布。需求集为坐标参考未解决定义阻断状态，为重复身份定义可测响应，并用非目标禁止自动地质背书。追踪评审发现“快速上传”没有总体或百分位，因此退回澄清，而不是猜测阈值。

练习与考核

  1. 这条需求治理什么决定与错误后果？
  2. 哪项职责被刻意放在软件边界之外？
  3. 什么证据会使需求通过、失败或保持未解决？
  4. 需求变化到何种程度必须获得新身份？

考核制品：一份以决定为中心的需求与专业边界登记表。提交时附来源清单、验收证据、未解决风险，并简要说明为何没有选择一个合理备选方案。

常见失败模式

  • 把组件愿望清单当成以决定为中心的需求。
  • 未分析备选方案就把一种设计选择嵌入需求。
  • 让软件跨越未声明的专业批准边界。
  • 使用缺少环境、总体或阈值的含糊质量词。
  • 把合成演示当成真实运行可接受性的证据。

来源与延伸阅读