1. 非功能需求全景：分类框架、AI产品特殊性、与功能需求的关系
1.1 边界划分：非功能需求的领域定义
非功能需求（Non-Functional Requirements, NFRs）定义了系统如何工作，而非系统做什么。在实际AI产品中，NFRs的边界常常与功能需求（Functional Requirements, FRs）交叉，需要通过明确的依赖关系进行分层隔离。
| 维度 | 功能需求（FR） | 非功能需求（NFR） |
|---|---|---|
| 定义 | 系统必须执行的特定行为或计算 | 系统必须达到的质量属性或约束条件 |
| 示例 | “根据用户query返回top-5文档” | “TP99响应时间 < 200ms” |
| 验证方式 | 功能测试、AC测试 | 压测、监控、SLA审计 |
| 变更影响 | 通常影响单个模块 | 通常影响跨层架构选型 |
边界划分原则：FR定义行为契约，NFR定义质量契约。AI产品中，模型精度、推理时延、数据新鲜度等NFRs往往需要与FRs在需求阶段就做联合拆分，避免在集成阶段发现无法调和的冲突。
1.2 系统分层：非功能需求分类框架
采用“四层+两维度”的分类框架，将非功能需求按系统边界分层归类：
- 接入层：可用性、安全性、限流、认证
- 推理层：时延、吞吐、模型冷启动、缓存策略
- 数据层：一致性、新鲜度、存储容量、备份恢复
- 基础设施层：弹性扩缩、资源隔离、故障自愈
- 两维度：运维维度（可监控、可部署、可回滚）与合规维度（数据隐私、可解释性、审计追踪）
# 以非功能需求分层角度描述的接口规范示例
# 推理层时延约束
POST /v1/chat/completions
Request:
{
"messages": [...],
"max_tokens": 512
}
Response:
{
"choices": [...],
"usage": {},
"latency_ms": 450 # 服务端耗时，用于SLA采集
}
SLA: TP50 < 200ms, TP99 < 500ms (非流式)
1.3 组件职责：功能需求与非功能需求的依赖关系
功能需求是非功能需求的载荷载体。同一FR在不同NFR约束下可能导向完全不同的架构方案：
- FR不变：“对用户query进行意图识别”
- 场景A（低时延）：选用小模型+ONNX Runtime+GPU直通，放弃batch聚合
- 场景B（高吞吐）：选用大模型+动态batching+CPU/GPU混合调度
常见风险：在需求阶段只描述FR，未同步定义NFR，导致架构方案设计完成后发现时延、成本或合规要求无法满足，产生大量返工。必须在每个FR条目旁至少标注一项关键NFR。
1.4 数据流/控制流/信任链路：以非功能需求为驱动的架构视角
将非功能需求映射到数据流与控制流的关键节点，形成可审计的信任链路：
- 数据流：输入验证→预处理→模型推理→后处理→响应。每个环节均存在NFR检查点（如：数据脱敏检查→推理时延采集→输出安全过滤）
- 控制流：负载均衡→鉴权→限流→熔断→降级→回退。这些控制组件的主要职责是保障可用性与安全性NFR
- 信任链路：从用户请求到模型返回，需在日志中串联链路ID，确保可审计、可回朔，满足合规维度NFR
1.5 选型权衡：关键冲突点与决策矩阵
非功能需求之间天然存在冲突，选型时需要制定明确的优先级：
| 冲突对 | 对抗关系 | 典型场景 | 折中策略 |
|---|---|---|---|
| 时延 vs 吞吐 | 低时延需小batch，高吞吐需大batch | 在线对话系统 | 动态batching + 请求优先级队列 |
| 精度 vs 时延 | 高精度模型计算量大，推理慢 | 医疗影像诊断 | 模型蒸馏 + 边缘端裁剪 |
| 数据新鲜度 vs 成本 | 实时同步数据，存储与计算成本高 | 金融风控特征 | 离线+近实时混合数据管道 |
| 可用性 vs 一致性 | 高可用要求最终一致性，等级越高一致性越弱 | 推荐系统特征存储 | CRDT + 本地优先写入 |
决策建议：在架构方案阶段，使用NFR优先级矩阵（关键 / 重要 / 次要不急）对每个冲突对排序，然后选择最低成本满足关键NFR的方案，再逐步适配重要NFR。避免一开始就追求所有NFR的最优解。
1.6 风险点：AI产品非功能需求特有的陷阱
- 模型行为不可预测性：NFR指标（如时延、内存）可能因输入分布变化而剧烈波动，导致与功能测试阶段的结果偏离
- 冷启动惩罚：模型首次加载或首次推理时延通常比稳定态高数倍，需要在NFR中包含冷启动边界条件
- 数据漂移引发级联失效：输入数据分布变化导致模型输出质量下降，进而触发下游NFR（如重试次数激增，影响可用性）
- 合规成本滞后发现：数据隐私、可解释性等合规类NFR往往在后期审计时才发现不满足，回溯代价极高
1.7 落地步骤：从需求到架构的NFR映射
- FR-NFR联合识别：在每个用户场景（Use Case）下，同步列出该场景必须满足的3~5个关键NFR
- NFR分层归类：将NFR按接入层、推理层、数据层、基础设施层、运维/合规维度进行分组
- 冲突矩阵构建：识别同一层次及跨层次之间的NFR冲突对，标注优先级
- 架构方案选型：根据冲突矩阵，选择权衡成本最低的架构组件组合
- SLA基线定义：为每个关键NFR定义可量化的SLA指标及监测方式
- 验收用例编写：基于NFR编写压测、混沌工程、合规扫描等验收测试用例
1.8 验收标准
- NFR清单完整性：所有FR均已关联至少一项关键NFR，无遗漏
- 冲突对已分析：冲突矩阵覆盖了所有已知的NFR冲突对，并记录了决策理由
- SLA指标可测量：每个NFR均绑定了一个可自动化采集的度量指标（如TP99、QPS、准确率）
- 验收用例通过：压测、稳定性、合规性测试用例均有明确的通过/不通过阈值