# Quality attribute A quality attribute is a non-functional requirement that describes how a system should perform a certain function or behave under certain conditions. It defines the system's properties and constraints, such as performance, security, or reliability, rather than its specific features. **Pronunciation:** KWAH-li-tee AT-tri-byoot **Difficulty:** Medium **Synonyms:** Non-Functional Requirement (NFR), Quality of Service (QoS) Requirement, System Quality, Architectural Characteristic, Ility **Categories:** Software Architecture, Software Engineering, System Design **Tags:** Non-Functional Requirements, System Qualities, Architecture, Software Design, Ilities Canonical: https://scaleengineer.com/glossaries/quality-attribute --- ## Definitions - **In Software Architecture:** In the context of software architecture, a **Quality Attribute** is a measurable or testable property of a system that indicates how well the system satisfies the needs of its stakeholders. These are often called **non-functional requirements (NFRs)** or **"ilities"** because many of them end in "-ility" (e.g., reliability, scalability). Quality attributes describe *how* a system should behave, rather than *what* it should do. While functional requirements define features (e.g., "a user can log in"), quality attributes define the constraints and characteristics of those features (e.g., "the login process must complete within 2 seconds and be secure against common attacks"). **Key Concepts** * **The "Ilities"**: Common quality attributes include Performance, Scalability, Availability, Reliability, Security, Maintainability, Usability, and Testability. Each one addresses a specific concern about the system's operation. * **Trade-offs**: A critical aspect of architectural design is managing trade-offs between quality attributes. For instance, increasing security with multiple layers of encryption might negatively impact performance. Architects must balance these competing concerns based on business goals. * **Measurability**: To be effective, quality attributes must be specific and measurable. A vague goal like "the system should be fast" is not useful. A better definition is a quality attribute scenario: "Under a load of 1,000 concurrent users, 99% of page loads must complete in under 500 milliseconds." **Usage** Quality attributes are primary drivers for architectural decisions. The choice of technology stack, design patterns, and infrastructure is heavily influenced by the need to meet specific quality attribute targets. They also form the basis for Service Level Agreements (SLAs) and performance testing. ## Etymology The term is a compound of "Quality" and "Attribute". "Quality" originates from the Latin word "qualitas," meaning "of what kind" or "character." "Attribute" comes from the Latin "attribuere," meaning "to assign" or "bestow." In combination, it signifies a characteristic or property that defines the nature or standard of a system. ## First used 1990s ## Historical context The concept of system qualities has existed since the early days of computing, initially focused on correctness and performance (efficiency). As software systems grew in complexity and became more integrated into business operations during the 1970s and 1980s, the need for other characteristics like reliability and maintainability became more apparent. The term **Quality Attribute** gained formal prominence in the 1990s with the rise of software architecture as a distinct discipline. Institutions like the Software Engineering Institute (SEI) at Carnegie Mellon University played a pivotal role in formalizing these concepts. They developed methods like the Quality Attribute Workshop (QAW) and architectural analysis techniques (e.g., ATAM - Architecture Tradeoff Analysis Method) to systematically identify, prioritize, and design for these non-functional requirements. This shift marked a move from an implicit understanding of system quality to an explicit, engineering-driven approach. ## Q&A - **What is the primary difference between a functional requirement and a quality attribute?:** A functional requirement specifies *what* a system should do (e.g., 'a user can add an item to a shopping cart'). A **quality attribute**, also known as a non-functional requirement, specifies *how well* the system performs that function (e.g., 'adding an item to the cart must take less than 200 milliseconds'). Functional requirements define features, while quality attributes define the characteristics and constraints of those features. - **Why are trade-offs between quality attributes inevitable in system design?:** Trade-offs are inevitable because improving one **quality attribute** often negatively impacts another. For example: * Increasing **security** by adding more encryption layers can decrease **performance** due to the computational overhead. * Designing for high **scalability** might increase complexity, which can negatively affect **maintainability**. * A system with very high **availability** might require redundant hardware, increasing costs. Architects must analyze these competing concerns and make deliberate choices based on business priorities and stakeholder needs. - **How is a quality attribute made measurable?:** A **quality attribute** is made measurable through a 'quality attribute scenario'. This scenario provides a specific, testable context. It typically includes six parts: 1. **Source of stimulus**: The entity that generates the stimulus (e.g., a user, another system). 2. **Stimulus**: The condition that needs to be considered (e.g., a user clicks 'submit'). 3. **Artifact**: The part of the system that is stimulated (e.g., the web server). 4. **Environment**: The conditions under which the stimulus occurs (e.g., during normal operation). 5. **Response**: The activity that occurs after the stimulus (e.g., the system processes the data and stores it). 6. **Response Measure**: A quantifiable measure of the response (e.g., the data is processed and stored within 500ms with zero data loss). For example, a vague requirement like 'the system should be fast' becomes a measurable attribute: 'Under a load of 1000 concurrent users (environment), a user request for a product page (stimulus) is processed by the system (artifact), resulting in the page being rendered (response) in under 2 seconds (response measure).' ## Usage examples - When designing the e-commerce platform, **availability** was the most critical **quality attribute** to ensure customers could always access the store. - The architect had to make a trade-off between the **security** and **performance** **quality attributes** of the new authentication service. - Each **non-functional requirement** was mapped to a specific **quality attribute** to guide the development team's implementation choices. - For our real-time data processing pipeline, low latency is a key **architectural characteristic** we must achieve. ## Related terms - Architectural Driver - Constraint - Trade-off Analysis - Service Level Agreement (SLA) - Functional Requirement ## Popular related terms - Scalability - Performance - Security - Reliability - Maintainability