GeoXMind

功能要求与质量属性不是一回事

区分系统做什么与在什么条件下做到何种程度，解释两类要求如何共同约束结构。

功能要求与质量属性不是一回事

功能要求说明系统要完成什么行为，质量属性说明这些行为在什么条件下达到何种程度。系统能够保存文档是一项功能；在并发写入、节点故障或权限变化时仍能以规定延迟正确保存，则涉及性能、可用性、一致性和安全。两类要求共同决定架构，不能用“非功能需求”把后者放到实现末期。

功能建立可见的行为

功能通常可以用输入、处理和输出描述。例如用户上传影像，系统校验格式并创建处理任务；管理员发布文章，公开页面随后可以读取。功能模型帮助确定业务状态和交互，却不自动说明负载、失败或攻击情况下会怎样。

同一功能可以由多种结构实现。文件可保存在本地、对象存储或数据库中；通知可以同步发送或进入消息队列。决定方案的往往不是功能本身，而是容量、恢复、成本和可修改性要求。

质量属性必须进入具体情境

“系统要快”“系统要可靠”无法直接分析。质量属性场景要说明刺激来自哪里、在什么环境发生、影响哪个部分、系统怎样响应以及如何测量。性能场景需要负载和响应时间，可用性场景需要故障类型和恢复目标，安全场景需要资产、威胁和允许行为。

CMU SEI 的质量属性研究强调通过可分析场景连接需求与架构决定。质量属性不是一张固定清单，项目应选择真正影响业务和结构的部分。

功能正确不代表系统可接受

一个接口返回正确结果，但在高峰期需要一分钟，可能仍然不可用；备份任务成功执行，但从未验证恢复，不能证明可恢复性；权限功能存在，但审计记录无法追踪，也难以满足安全责任。

质量问题常跨越多个功能。认证、日志、缓存、重试和限流不是单一业务功能的附属项，而是系统级机制。若每个模块独立实现，行为可能不一致，整体属性也无法推断。

质量目标之间存在权衡

更多缓存可以降低延迟，却增加一致性和失效管理成本；更严格的同步复制提高部分故障下的数据保障，却可能增加写入时间；更细粒度的审计增强追踪能力，也会消耗存储和处理资源。

权衡不是简单选择一个属性牺牲另一个，而是明确业务优先级、环境和可接受边界。相同系统在正常运行和灾难恢复期间可以采用不同响应策略。

从需求追踪到验证证据

功能要求可以通过业务测试验证，质量属性还需要负载测试、故障演练、安全测试和运行指标。每个架构上显著的质量目标应关联实现机制与证据。例如恢复时间目标关联备份频率、故障检测、恢复步骤和演练记录。

SEI 的早期架构分析方法关注架构信息是否足以判断质量风险。需求、决定和证据连成链后，团队才能在系统建成前发现结构不足，并在上线后检查假设是否成立。

资料依据