质量场景的两层描述与软件质量理想模型

架构需求天生抽象，而编程语言一般不提供实现架构需求的直接机制——因此必须先通过场景把抽象需求具体化，再用模型把场景结构化。质量场景分两层：抽象场景是对软件使用方式的一种粗粒度分类（例如”是流水线方式还是三层结构”），描述往往适用于一整类系统（如”用户点击浏览器链接、浏览器向系统发送请求”这种描述并未指明是哪种质量需求）；特定质量属性场景则是从抽象场景中提炼出的、针对具体质量属性（性能、可移植性、可替换性、可重用性等）的具体要求（如”要求1秒内返回页面”就是对性能提出的具体要求）。同一个用户需求可能同时影响多个质量属性（如性能、安全性、适应性），而不同利益相关者对同一需求的描述也不一样，因此提取质量场景时需要同时考虑”质量属性维度”和”利益相关者维度”，书中用一个三维立方体模型来同时刻画这两个维度。为了把质量场景进一步结构化描述，书中提出”软件质量理想模型”，融合了三种既有模型的思想：基于分类的ISO 9126模型（用于定义软件质量属性的分类体系）、基于度量的MI模型（用于评估软件质量）、基于预测的RGM模型（用于预测软件质量）——三者看似服务不同目的（定义/评估/预测），但并非互相独立，例如评估质量时首先要获得这些质量属性的定义，评估本身也是在找出设计中的潜在威胁，因此把三者融合成一个综合模型更有实际价值。细化后的质量场景需要用注解补充三方面信息：这个场景的来源（可追溯到哪些文档）、目的（商业目标还是业界标准）、以及这个场景的改变会影响哪些其他质量场景——第三点尤其关键，因为它是后续[[ATAM架构评估法的敏感点与权衡点]]分析的直接前提。