System quality attributes have been of interest to the software community since at least the 1970s. Various published taxonomies and definitions exist, and many have their own research and practitioner communities. From the perspective of a system（architect）, there are three common problems with previous discussions of system quality attributes:
The definitions provided for each attribute are not operational. For example, it is （meaningless） to claim that a system is modifiable unless it is clearly stated with respect to which changes it is modifiable and which changes it is not. Other quality attributes face similar issues.
Discussions often focus on which quality attribute a particular issue belongs to. For example, is a system failure an availability issue, a security issue, or a usability issue? All three attribute communities may claim ownership of such a failure.
Each attribute community has developed its own terminology. The（performance）community speaks of "events" arriving at the system, the security community describes "attacks", the availability community discusses "failures", and the usability community refers to "user input". These may all describe the same phenomenon but use different terms.
A solution to the first two problems—non-operational definitions and overlapping concerns—is to use quality attribute（scenarios）to characterize quality attributes in a more structured way. To solve the third problem, a brief discussion of each attribute focusing on its underlying concerns and community（perspectives）can be helpful.
系统质量属性是软件架构设计的核心考量维度，系统架构师是主导其结构化分析、权衡与落地的核心角色，这类工作区别于开发人员聚焦的功能实现与测试人员负责的验证环节。质量属性的定义必须具备可操作性，若仅笼统提出如“系统需具备可修改性”却未明确具体修改范围，这类表述无实际指导意义，会导致需求模糊且无法验证。不同质量属性的研究与实践社区因对系统行为的关注视角存在差异，形成了各自的专属术语体系，比如性能领域用“events”指代系统接收的输入负载，安全社区将同类系统刺激描述为“attacks”，可用性社区称其为“failures”，易用性社区则用“user input”表述，这些术语常指向同一系统现象却表述各异。质量属性场景是解决定义非操作性与关注重叠问题的标准方法，它通过源、刺激、环境、响应、度量等结构化要素，将抽象的质量需求转化为可落地、可验证的具体内容。而要消解不同社区的术语壁垒，需从各社区的核心关注视角切入，明确其对系统行为的不同侧重点，从而实现术语体系的有效对齐。
问题 1：考察系统架构视角（Architectural Perspective）。质量属性的结构性讨论通常由系统架构师（architect）主导，他们负责系统设计层面上非功能需求的权衡与实现，因此“architect”是最合适的角色。其他选项如 developer 或 tester 通常聚焦于具体实现与验证，不是质量属性结构化讨论的主角。
问题 2：考察知识点：质量属性定义的可操作性。如果不说明“可修改”指的是哪类修改，那么这样的表述就是“meaningless（无意义的）”。这直接反映了质量属性定义中缺乏具体上下文的问题。其他选项虽接近，但没有“meaningless”准确。
问题 3：考察知识点：不同质量属性社区的术语。在性能（performance）领域中，"events" 是常见术语，用来描述系统接收到的输入负载或请求。其他选项不使用“events”来描述系统刺激，因此不符合题意。
问题 4：考察知识点：质量属性场景（Quality Attribute Scenarios）。scenarios 是构造质量属性结构化定义的标准方法，它包括 source、stimulus、environment、response、measure 等要素，帮助系统架构师明确质量需求并可验证。其他选项不具备结构化和可操作性的优势。
问题 5：考察知识点：术语差异的根源在于关注视角（perspectives）。不同质量属性社区的术语差异，源自它们对系统行为的不同视角与关注点。因此要解决术语不统一问题，应从“perspectives（视角）”出发。其他选项如 values、expectations 虽相关，但不如 perspectives 精确且贴切。