# Quality Attributes > ISO 25010 quality model, quality attribute scenarios, quality trees / utility trees, single quality attributes (availability, performance, security, modifiability, ...), trade-offs between them. ## Quality models, prioritization and trade-offs - [Architectural Perspective](https://arc.fuet.ch/concepts/quality-attributes/architectural-perspective.md): An architectural perspective is guidance for making sure a system has a group of related quality properties, such as security. You apply it to each architectural view, instead of adding a new view per property. - [Insufficient Quality as Driver of Change](https://arc.fuet.ch/concepts/quality-attributes/insufficient-quality-as-driver-of-change.md): Quality goals shape a system as much as features do. Changing one quality goal can force a different solution, so architects should state quality goals concretely and early. - [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md): ISO/IEC 25010 is a standard that sorts software product quality into named characteristics and subcharacteristics. The 2023 edition has nine characteristics. It gives teams a shared vocabulary for specifying quality. - [ISO/IEC 25010 Quality Models and Their Target Entities](https://arc.fuet.ch/concepts/quality-attributes/quality-models-and-their-target-entities.md): ISO/IEC 25010 and its sibling standards give separate quality models for different targets: an ICT product, data, or an IT service. Pick the model that matches what you are judging. - [ISO/IEC 25010:2023 Product Quality Model Revision](https://arc.fuet.ch/concepts/quality-attributes/iso-25010-2023-revision.md): The 2023 revision of ISO/IEC 25010 renames Usability to Interaction Capability. It also replaces some sub-characteristics and adds others, such as Resistance under Security and Scalability under Flexibility. - [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md): A quality attribute describes how well a system meets stakeholder needs, such as speed or security. Teams write them as specific, measurable scenarios because they strongly shape architectural decisions. - [Quality Attribute Coverage in Bass et al.](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-coverage-in-bass-et-al.md): The Bass et al. model of quality attributes is much smaller than ISO 25010, with 10 top-level areas. It covers topics the 2011 ISO standard lacks, such as deployability and safety, and it has no chapter on compatibility. - [Quality Attribute Prioritization](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-prioritization.md): Teams cannot maximize every quality at once, so they pick the few that matter most and rank them. arc42 asks for the top three, at most five, shown with concrete scenarios. - [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md): Improving one quality of a system usually costs another. Architects weigh these conflicts, rank what matters most to stakeholders, and improve the design step by step. - [Standard Quality Attribute List](https://arc.fuet.ch/concepts/quality-attributes/standard-quality-attribute-checklist.md): A standard quality attribute list is a ready-made checklist and shared vocabulary for quality needs. No list is complete, and names alone are ambiguous, so teams adapt the list and add scenarios. - [Utility Tree](https://arc.fuet.ch/concepts/quality-attributes/utility-tree.md): A utility tree breaks the broad idea of "quality" into branches, down to concrete scenarios. Teams build it with key stakeholders and use it as a checklist of what the system must achieve. ## Quality attribute scenarios - [Availability Scenario](https://arc.fuet.ch/concepts/quality-attributes/availability-scenario.md): An availability scenario describes one concrete failure and how the system should react, in six parts: source, stimulus, artifact, environment, response, and response measure. The measure makes the requirement testable. - [Interoperability Scenario](https://arc.fuet.ch/concepts/quality-attributes/interoperability-scenario.md): An interoperability scenario is a fixed template that describes how one system asks another to exchange information, and what should happen next. It turns a vague goal into a testable requirement. - [Modifiability Scenario](https://arc.fuet.ch/concepts/quality-attributes/modifiability-scenario.md): A modifiability scenario turns a vague wish like "easy to change" into one concrete change request with a measurable limit, such as effort in person-weeks. You can then check whether the architecture meets it. - [Performance Efficiency Scenario](https://arc.fuet.ch/concepts/quality-attributes/performance-scenario.md): A performance efficiency scenario turns a vague goal like "be fast" into a testable statement. Something triggers the system, the system reacts, and a measurable criterion says whether the reaction was good enough. - [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md): A quality attribute scenario turns a vague quality wish into a specific, measurable statement. It lets a team decide whether the system meets the requirement. - [Quality attributes in use case descriptions](https://arc.fuet.ch/concepts/quality-attributes/quality-attributes-in-use-case-descriptions.md): Most quality requirements belong to one specific use case. Write them in that use case, then refine them into measurable quality attribute scenarios. This also shows which conditions the use case left unstated. - [Security Scenario](https://arc.fuet.ch/concepts/quality-attributes/security-scenario.md): A security scenario describes one concrete attack on a system and how the system should respond. It has six parts, and a measurable result shows whether the response is good enough. - [Testability General Scenario](https://arc.fuet.ch/concepts/quality-attributes/testability-general-scenario.md): The testability general scenario is a template for writing concrete testability requirements. It covers who tests, how the system is controlled and observed, and how easily the system reveals its faults. - [Usability Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/usability-scenario.md): A usability scenario describes a user action (the stimulus) and how the system should react (the response). Adding a number, such as a time limit, makes a usability requirement testable. ## Reliability, availability and safety - [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md): Availability is the share of time a system is operational and usable when people need it. It is usually given as a percentage. Each extra nine cuts allowed downtime sharply but costs more to achieve. - [Fault](https://arc.fuet.ch/concepts/quality-attributes/fault.md): A fault is a defect that can cause a failure. It may stay dormant until certain conditions trigger it. Teams prevent, tolerate, detect and recover from faults so users do not see failures. - [Fault Tolerance](https://arc.fuet.ch/concepts/quality-attributes/fault-tolerance.md): Fault tolerance is how well a system keeps working as intended while hardware or software faults are present. It is separate from availability and recoverability, and it relies on detecting, recovering from and containing faults. - [Hazard Warning](https://arc.fuet.ch/concepts/quality-attributes/hazard-warning.md): Hazard warning is a Safety quality in ISO/IEC 25010. A product with it warns operations or internal controls about unacceptable risks, so they can react. - [Operational Constraint](https://arc.fuet.ch/concepts/quality-attributes/operational-constraint.md): Operational constraint is a safety quality in ISO/IEC 25010. It describes a product that keeps its operation within safe parameters or states when it meets an operational hazard. - [Quantifying Recovery and Availability Trade-offs](https://arc.fuet.ch/concepts/quality-attributes/quantifying-recovery-and-availability-trade-offs.md): You can estimate availability from how often a part fails and how fast it is repaired. Redundancy raises that estimate, but cost, takeover time, and slow responses pull the other way. - [Recoverability](https://arc.fuet.ch/concepts/quality-attributes/recoverability.md): Recoverability is how well a system gets its affected data back after an interruption or failure. Teams express it with recovery-time and data-loss targets, and improve it by cutting recovery time, for example through failover. - [Reliability](https://arc.fuet.ch/concepts/quality-attributes/reliability.md): Reliability is how well a system performs its specified functions under specified conditions. ISO 25010 splits it into faultlessness, availability, fault tolerance and recoverability. The 2023 version adds a time period without interruptions and failures. - [Risk Identification and Safe Integration](https://arc.fuet.ch/concepts/quality-attributes/risk-identification.md): Risk identification is a product's ability to spot events or operations that could put people, property or the environment at unacceptable risk. Safe integration is its ability to stay safe during and after joining with other components. - [Safety](https://arc.fuet.ch/concepts/quality-attributes/safety.md): Safety is a system's ability to avoid states that endanger people, property or the environment. ISO/IEC 25010 splits it into five parts, from limiting operation to staying safe after integration. ## Security - [Accountability](https://arc.fuet.ch/concepts/quality-attributes/accountability.md): Accountability means you can trace each action to the one entity that did it. It is a security quality in ISO/IEC 25010, next to authenticity, non-repudiation, and confidentiality. - [Authenticity](https://arc.fuet.ch/concepts/quality-attributes/authenticity.md): Authenticity is the degree to which you can prove that a user, device, or resource is the one it claims to be. ISO/IEC 25010 lists it as a security sub-characteristic. - [Confidentiality](https://arc.fuet.ch/concepts/quality-attributes/confidentiality.md): Confidentiality means only authorized parties can read data. It is one part of security. Teams achieve it with access controls, encryption and data classification, inside defined trust boundaries. - [Integrity](https://arc.fuet.ch/concepts/quality-attributes/integrity.md): Integrity means a system protects its state and data from unauthorized modification or deletion. It is one of several security sub-characteristics in ISO/IEC 25010, alongside confidentiality, non-repudiation, accountability and authenticity. - [Nonrepudiation](https://arc.fuet.ch/concepts/quality-attributes/nonrepudiation.md): Nonrepudiation means actions can be proven to have happened, so an author cannot successfully deny a message or a contract. Digital signatures and trusted third parties are the usual tools. - [Resistance](https://arc.fuet.ch/concepts/quality-attributes/resistance.md): Resistance is how well a system keeps operating while a malicious actor attacks it. ISO/IEC 25010 lists it as a security sub-characteristic. It is about withstanding attacks, not only blocking them. - [Security](https://arc.fuet.ch/concepts/quality-attributes/security.md): Security means protecting data from unauthorized access while still serving legitimate users, and keeping the system running under attack. It rests on confidentiality, integrity and availability, and it can pull against reliability. ## Maintainability, modifiability and portability - [Adaptability](https://arc.fuet.ch/concepts/quality-attributes/adaptability.md): Adaptability is how well a product can be adapted to changes in its requirements, contexts of use, or system environment, including different or evolving hardware and software. ISO 25010 places it in the group now called Flexibility. - [Analysability](https://arc.fuet.ch/concepts/quality-attributes/analysability.md): Analysability is how easily people can judge the effect of a change, diagnose a failure, and find the parts to modify. ISO/IEC 25010 lists it as one of five maintainability sub-characteristics. - [Flexibility](https://arc.fuet.ch/concepts/quality-attributes/flexibility.md): Flexibility is a product's ability to adapt to changed requirements and contexts of use. ISO 25010:2023 splits it into adaptability, scalability, installability and replaceability. - [Installability](https://arc.fuet.ch/concepts/quality-attributes/installability.md): Installability describes how well a product can be installed and removed in a specific environment. In the 2023 wording of ISO/IEC 25010, it sits under Flexibility, next to adaptability, scalability and replaceability. - [Maintainability](https://arc.fuet.ch/concepts/quality-attributes/maintainability.md): Maintainability is how effectively and efficiently people can modify a product to improve it, correct it, or adapt it to a new environment or new requirements. - [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md): Modifiability describes how well a system can be changed. Architects steer it by adjusting coupling, cohesion, and cost, using architectural tactics. - [Replaceability](https://arc.fuet.ch/concepts/quality-attributes/replaceability.md): Replaceability is how well one product can take over from another specified product for the same purpose in the same environment. It lowers lock-in risk, but a replacement's equivalence must be tested, not assumed. - [Reusability](https://arc.fuet.ch/concepts/quality-attributes/reusability.md): Reusability is how well something you built, such as code or a design, can serve in more than one system. You can reuse by copying or by depending on shared code. Each way has costs and risks. - [Testability](https://arc.fuet.ch/concepts/quality-attributes/testability.md): Testability is how well a system supports its own testing. High testability makes faults easier to find by testing. Low testability means more test effort. ## Performance, usability, compatibility and other attributes - [Compatibility](https://arc.fuet.ch/concepts/quality-attributes/compatibility.md): Compatibility is how well a product exchanges information with other products and does its job while sharing an environment and resources with them. Version numbers and tolerant reading help keep interfaces working as products change. - [Functional suitability](https://arc.fuet.ch/concepts/quality-attributes/functional-suitability.md): Functional suitability is the degree to which a product provides functions that meet stated and implied needs under specified conditions. It has three parts: completeness, correctness and appropriateness. - [Interoperability](https://arc.fuet.ch/concepts/quality-attributes/interoperability.md): Interoperability is how well separate systems can exchange information and then use it. It depends on shared formats and shared meaning. Open standards help, and translators bridge the gaps that remain. - [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md): Performance efficiency is a workload's ability to handle rising load without hurting user experience, and to use fewer resources when demand is low. Teams should consider it from the start and verify it by measuring. - [Scalability](https://arc.fuet.ch/concepts/quality-attributes/scalability.md): Scalability is how well a system copes with growing workload by adding resources. A capacity limit always exists, and the bottleneck, often a stateful part like a database, decides how far scaling can go. - [Usability](https://arc.fuet.ch/concepts/quality-attributes/usability.md): Usability describes how easily and efficiently people get tasks done through a system's interface. It covers learning, speed, error handling and satisfaction, and it links to how cheaply the interface can be changed.