# arc42 section 10: Quality Requirements

Checks for section 10 (Quality Requirements) of an arc42 document.

Quality tree and quality scenarios

- Each view states which stakeholder concerns it addresses. → [Stakeholder Perspective and Concern](https://arc.fuet.ch/concepts/documentation/stakeholder-perspective-and-concern.md)
- Quality requirements in chapter 10 are written as concrete scenarios that allow deciding whether each one is fulfilled. → [arc42 Quality Requirements](https://arc.fuet.ch/concepts/documentation/arc42-quality-requirements.md)
- Quality requirements are stated in specific, measurable terms. → [arc42 Quality Requirements](https://arc.fuet.ch/concepts/documentation/arc42-quality-requirements.md)
- Quality requirements are written as scenarios concrete enough to decide whether each one is fulfilled. → [arc42 Quality Requirements Chapter](https://arc.fuet.ch/concepts/documentation/arc42-quality-chapter.md)
- A quality tree starts with the generic term quality at its root and refines it into categories or topics. → [arc42 Quality Requirements Chapter](https://arc.fuet.ch/concepts/documentation/arc42-quality-chapter.md)
- The architecture was evaluated before major investment in implementation. → [ATAM Application Phases](https://arc.fuet.ch/concepts/evaluation/atam-application-phases.md)
- The evaluation team is external to the project and has three to five members. → [ATAM Evaluation Team and Stakeholder Selection](https://arc.fuet.ch/concepts/evaluation/atam-evaluation-team-and-stakeholder-selection.md)
- A stakeholder list was arranged between the evaluation team and key decision makers during Phase 0. → [ATAM Evaluation Team and Stakeholder Selection](https://arc.fuet.ch/concepts/evaluation/atam-evaluation-team-and-stakeholder-selection.md)
- Risks found in an evaluation are listed in the risks section, ordered by priority, with suggested mitigation measures. → [ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points](https://arc.fuet.ch/concepts/evaluation/atam-findings-risks-non-risks-sensitivity-points-and-trade-offs.md)
- Findings trace back to high-priority, voted scenarios from the utility tree. → [ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points](https://arc.fuet.ch/concepts/evaluation/atam-findings-risks-non-risks-sensitivity-points-and-trade-offs.md)
- Every non-risk traces to an area the evaluation team actually analyzed, not to an unexamined area. → [ATAM Non-Risk](https://arc.fuet.ch/concepts/evaluation/atam-non-risk.md)
- The evaluation plan allows about three to four days. → [ATAM Phase 1 and 2 Activities](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-and-2-activities.md)
- The utility tree reaches the level of scenarios with stimuli, responses and priorities. → [ATAM Phase 1 and 2 Activities](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-and-2-activities.md)
- The participants include a trained evaluation team, the architects and stakeholder representatives. → [ATAM Phase 1: Architecture-centric Analysis](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-architecture-centric-analysis.md)
- Identified risks are grouped into risk themes, and each theme names the business driver it threatens. → [ATAM Results](https://arc.fuet.ch/concepts/evaluation/atam-results.md)
- The business drivers are documented alongside the architecture presentation. → [ATAM Results](https://arc.fuet.ch/concepts/evaluation/atam-results.md)
- The evaluation team has about 3-5 people, all external to the project. → [ATAM Roles](https://arc.fuet.ch/concepts/evaluation/atam-roles.md)
- Broader stakeholders are scheduled for the second evaluation phase. → [ATAM Roles](https://arc.fuet.ch/concepts/evaluation/atam-roles.md)
- The effort for the evaluation (duration, participants) was estimated before it started. → [Advantages and Drawbacks of ATAM](https://arc.fuet.ch/concepts/evaluation/advantages-and-drawbacks-of-atam.md)
- Each recorded decision names the chosen alternative and the criteria used to select it. → [Architectural Decision Records as Evaluation Prerequisite](https://arc.fuet.ch/concepts/evaluation/architectural-decision-records-as-evaluation-prerequisite.md)
- The architecture documentation records an evaluation of the architecture against its quality attribute goals. → [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md)
- Sensitivity points and trade-off points found during the analysis are recorded. → [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md)
- Each sensitivity point names a decision that has a marked effect on one or more quality attributes. → [Battlefield Control System ATAM Case Study](https://arc.fuet.ch/concepts/evaluation/battlefield-control-system-atam-case-study.md)
- Risks are summarized as themes that name the business driver they threaten. → [Comparing Architectural Alternatives with ATAM](https://arc.fuet.ch/concepts/evaluation/comparing-architectural-alternatives-with-atam.md)
- Each non-risk names a scenario, a decision and evidence that the decision is adequate. → [Insufficient ATAM Application](https://arc.fuet.ch/concepts/evaluation/insufficient-atam-application.md)
- The document states whether the architecture review was a full ATAM or a lightweight variant. → [Lightweight ATAM](https://arc.fuet.ch/concepts/evaluation/lightweight-atam.md)
- The document admits that a lightweight review may not have uncovered all risks. → [Lightweight ATAM](https://arc.fuet.ch/concepts/evaluation/lightweight-atam.md)
- The review states quantified objectives for the system's top quality attributes. → [Lightweight Approach for Software Reviews (LASR)](https://arc.fuet.ch/concepts/evaluation/lightweight-approach-for-software-reviews-lasr.md)
- Controversial gaps between objectives and assessment are analyzed in depth. → [Lightweight Approach for Software Reviews (LASR)](https://arc.fuet.ch/concepts/evaluation/lightweight-approach-for-software-reviews-lasr.md)
- The scenario set was brainstormed with the entire stakeholder group. → [Scenario Weight Assignment and Prioritization](https://arc.fuet.ch/concepts/evaluation/scenario-weight-assignment.md)
- The whole stakeholder group voted to prioritize the scenarios. → [Scenario Weight Assignment and Prioritization](https://arc.fuet.ch/concepts/evaluation/scenario-weight-assignment.md)
- Each architectural driver is covered by at least one scenario. → [Scenario Weight Assignment and Prioritization](https://arc.fuet.ch/concepts/evaluation/scenario-weight-assignment.md)
- Each sensitivity point is documented with its rationale, ideally as an architectural decision record. → [Sensitivity Point](https://arc.fuet.ch/concepts/evaluation/sensitivity-point.md)
- The architecture document lists the change scenarios used to evaluate the design. → [Software Architecture Analysis Method (SAAM)](https://arc.fuet.ch/concepts/evaluation/software-architecture-analysis-method-saam.md)
- The document notes that the assessment depends on the evaluators' experience and possible bias. → [Software Architecture Analysis Method (SAAM)](https://arc.fuet.ch/concepts/evaluation/software-architecture-analysis-method-saam.md)
- The evaluation records identified risks, sensitivity points and trade-off points. → [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md)
- Sustainability is considered as a requirement category for resource-constrained cyber-physical systems. → [Requirements-Decision Modeling for Cyber-Physical Systems of Systems](https://arc.fuet.ch/concepts/forces-decisions/requirements-decision-modeling-for-cyber-physical-systems-of-systems.md)
- Each stakeholder concern is explicitly addressed in the architecture description. → [Stakeholder Concern](https://arc.fuet.ch/concepts/forces-decisions/stakeholder-concern.md)
- The product owner supplied or confirmed the high-level criteria for each story. → [Acceptance Criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md)
- Each criterion is precise enough that QA can tell how to test it. → [Frequent Mistakes in Defining Acceptance Criteria](https://arc.fuet.ch/concepts/functional-requirements/frequent-mistakes-in-defining-acceptance-criteria.md)
- Each architectural backlog item states its value to the business. → [INVEST Applied to Architectural Work](https://arc.fuet.ch/concepts/functional-requirements/invest-applied-to-architectural-work.md)
- Arc42 section 1 lists only top quality goals and points to section 10 for the complete quality requirements. → [Requirement Types and Documents (Wiegers/Beatty)](https://arc.fuet.ch/concepts/functional-requirements/requirement-types-and-documents.md)
- The document looks beyond what users stated and notes how overlooked requirements were sought. → [Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md)
- For each requirement, the document names the tests or criteria that show it has been met. → [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md)
- Stories are small enough to estimate and rank, and they capture the essence rather than every detail. → [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md)
- Detailed requirements exist for the subset needed for architectural decisions. → [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)
- Key decisions are documented, for example as ADRs. → [Architectural Thinking](https://arc.fuet.ch/concepts/fundamentals/architectural-thinking.md)
- Quality attributes are described explicitly and not only functions. → [Common Architect Mistakes](https://arc.fuet.ch/concepts/fundamentals/common-architect-mistakes.md)
- Long-running jobs extend the timeout with a heartbeat, within the maximum limit. → [Timeout-based Delivery](https://arc.fuet.ch/concepts/integration/timeout-based-delivery.md)
- If the documentation claims only relaxed soundness, it says so and does not call the model sound. → [Soundness of Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/soundness-of-process-models.md)
- The design favors small, loosely coupled elements over big, tightly coupled components. → [Continuous Architecture Principles](https://arc.fuet.ch/concepts/principles/continuous-architecture-principles.md)
- External systems are accessed through a single wrapping interface, not called directly across the code. → [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md)
- Components with a high distance from the main sequence are listed, with a stated threshold such as 0.7. → [Main Sequence (Balance of Abstractness and Instability)](https://arc.fuet.ch/concepts/principles/main-sequence.md)
- Log records have tamper detection, so modified or deleted records are noticed. → [Accountability](https://arc.fuet.ch/concepts/quality-attributes/accountability.md)
- The document names which hardware, software, or other environments the system must be adaptable to. → [Adaptability](https://arc.fuet.ch/concepts/quality-attributes/adaptability.md)
- Analysability appears as a sub-characteristic of maintainability in the quality tree. → [Analysability](https://arc.fuet.ch/concepts/quality-attributes/analysability.md)
- Analysability scenarios are specific and measurable, for example for impact analysis or failure diagnosis. → [Analysability](https://arc.fuet.ch/concepts/quality-attributes/analysability.md)
- The document shows that each relevant perspective was considered with each view, not in isolation. → [Architectural Perspective](https://arc.fuet.ch/concepts/quality-attributes/architectural-perspective.md)
- Authentication and authorization are described as separate steps. → [Authenticity](https://arc.fuet.ch/concepts/quality-attributes/authenticity.md)
- The document states whether scheduled maintenance counts as downtime, and why. → [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md)
- Each availability scenario names a source, stimulus, artifact, environment, response, and response measure. → [Availability Scenario](https://arc.fuet.ch/concepts/quality-attributes/availability-scenario.md)
- Each scenario states a response measure that can be checked, not only a vague percentage. → [Availability Scenario](https://arc.fuet.ch/concepts/quality-attributes/availability-scenario.md)
- Availability targets such as 99% state a measurement window and an SLO boundary. → [Availability Scenario](https://arc.fuet.ch/concepts/quality-attributes/availability-scenario.md)
- Internal and external dependencies are assessed separately as possible sources of faults. → [Fault](https://arc.fuet.ch/concepts/quality-attributes/fault.md)
- Retries are limited to idempotent operations. → [Fault Tolerance](https://arc.fuet.ch/concepts/quality-attributes/fault-tolerance.md)
- Replaceability targets are stated, and accepted lock-in is named as a conscious choice. → [Flexibility](https://arc.fuet.ch/concepts/quality-attributes/flexibility.md)
- The document says who the intended users are and under which conditions the functions must give accurate results. → [Functional suitability](https://arc.fuet.ch/concepts/quality-attributes/functional-suitability.md)
- The document states who receives risk warnings: operations, internal controls, or both. → [Hazard Warning](https://arc.fuet.ch/concepts/quality-attributes/hazard-warning.md)
- Quality requirements use the names of the nine characteristics and their subcharacteristics from the 2023 edition. → [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md)
- Security requirements address resistance, meaning continued operation while under attack. → [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md)
- Data quality is assessed with a data quality model, separate from the product quality model. → [ISO/IEC 25010 Quality Models and Their Target Entities](https://arc.fuet.ch/concepts/quality-attributes/quality-models-and-their-target-entities.md)
- Quality requirements use the 2023 name Interaction Capability instead of Usability, or state which edition of the model they follow. → [ISO/IEC 25010:2023 Product Quality Model Revision](https://arc.fuet.ch/concepts/quality-attributes/iso-25010-2023-revision.md)
- The document names the specific environment in which installation and uninstallation must succeed. → [Installability](https://arc.fuet.ch/concepts/quality-attributes/installability.md)
- Quality requirements are written as quality scenarios that can serve as acceptance criteria. → [Insufficient Quality as Driver of Change](https://arc.fuet.ch/concepts/quality-attributes/insufficient-quality-as-driver-of-change.md)
- The document describes how unauthorized changes to software and information are detected. → [Integrity](https://arc.fuet.ch/concepts/quality-attributes/integrity.md)
- Where systems must interpret exchanged data meaningfully, the document names the common reference model both sides use. → [Interoperability](https://arc.fuet.ch/concepts/quality-attributes/interoperability.md)
- Each interoperability requirement names the source system that starts the request and the systems involved in the exchange. → [Interoperability Scenario](https://arc.fuet.ch/concepts/quality-attributes/interoperability-scenario.md)
- The scenario states whether the interoperating systems are known before runtime or discovered at runtime. → [Interoperability Scenario](https://arc.fuet.ch/concepts/quality-attributes/interoperability-scenario.md)
- The scenario defines what happens when a request is accepted and when it is rejected, including who is notified. → [Interoperability Scenario](https://arc.fuet.ch/concepts/quality-attributes/interoperability-scenario.md)
- Test criteria are defined, and tests can show whether they are met. → [Maintainability](https://arc.fuet.ch/concepts/quality-attributes/maintainability.md)
- Each modifiability tactic in the document states which parameter it adjusts. → [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- Each scenario has a measurable response measure, such as person-weeks or person-hours of effort. → [Modifiability Scenario](https://arc.fuet.ch/concepts/quality-attributes/modifiability-scenario.md)
- Signing keys are protected, and the document says how, because forged signatures would undermine non-repudiation. → [Nonrepudiation](https://arc.fuet.ch/concepts/quality-attributes/nonrepudiation.md)
- Each operational hazard the product may meet is linked to a limit or constraint that applies to it. → [Operational Constraint](https://arc.fuet.ch/concepts/quality-attributes/operational-constraint.md)
- Performance targets for key flows are stated as acceptable user-experience effects and agreed with business stakeholders. → [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md)
- Each performance requirement is written as a scenario with a stimulus, an affected artifact, and an environment. → [Performance Efficiency Scenario](https://arc.fuet.ch/concepts/quality-attributes/performance-scenario.md)
- Performance scenarios are usable as acceptance criteria that decide whether the requirement is fulfilled. → [Performance Efficiency Scenario](https://arc.fuet.ch/concepts/quality-attributes/performance-scenario.md)
- The document separates usage scenarios (runtime reaction to a stimulus) from change scenarios (modifying the system). → [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md)
- Deployability is considered, or its omission is justified, for the type of system (e.g., embedded systems deploy less often). → [Quality Attribute Coverage in Bass et al.](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-coverage-in-bass-et-al.md)
- The quality goals appear as a table ordered by priority. → [Quality Attribute Prioritization](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-prioritization.md)
- Each quality requirement is written as a scenario that is specific and measurable. → [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md)
- Scenarios state the stimulus event, the stimulated system and the expected response. → [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md)
- Performance shortcuts that bypass security steps are backed by a documented risk analysis. → [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- System-wide quality requirements are stated separately from the use cases. → [Quality attributes in use case descriptions](https://arc.fuet.ch/concepts/quality-attributes/quality-attributes-in-use-case-descriptions.md)
- Each quality requirement for a use case states which environment applies, such as normal operation, peak load or error. → [Quality attributes in use case descriptions](https://arc.fuet.ch/concepts/quality-attributes/quality-attributes-in-use-case-descriptions.md)
- The document states the availability target and how it was estimated, for example from MTBF and MTTR. → [Quantifying Recovery and Availability Trade-offs](https://arc.fuet.ch/concepts/quality-attributes/quantifying-recovery-and-availability-trade-offs.md)
- Reliability goals state the time period during which the system must work without interruptions and failures. → [Reliability](https://arc.fuet.ch/concepts/quality-attributes/reliability.md)
- The document states which specified product a replacement must stand in for, and for what purpose and in which environment. → [Replaceability](https://arc.fuet.ch/concepts/quality-attributes/replaceability.md)
- The document defines resistance as keeping operations running while under attack, separate from confidentiality and authenticity. → [Resistance](https://arc.fuet.ch/concepts/quality-attributes/resistance.md)
- The document states which events or operations could expose life, property or the environment to unacceptable risk. → [Risk Identification and Safe Integration](https://arc.fuet.ch/concepts/quality-attributes/risk-identification.md)
- The conditions under which safety must hold are defined. → [Risk Identification and Safe Integration](https://arc.fuet.ch/concepts/quality-attributes/risk-identification.md)
- The document says how operators or controls get warned of unacceptable risks early enough to react. → [Safety](https://arc.fuet.ch/concepts/quality-attributes/safety.md)
- The scalability requirement names its workload dimension, such as concurrent requests or data volume. → [Scalability](https://arc.fuet.ch/concepts/quality-attributes/scalability.md)
- The design addresses attacks, such as DDoS, that could exhaust resources and cause downtime. → [Security](https://arc.fuet.ch/concepts/quality-attributes/security.md)
- Each security scenario names a source, stimulus, artifact, environment, response and response measure. → [Security Scenario](https://arc.fuet.ch/concepts/quality-attributes/security-scenario.md)
- Each response measure is quantitative, so a reviewer can decide whether the response is good enough. → [Security Scenario](https://arc.fuet.ch/concepts/quality-attributes/security-scenario.md)
- Security scenarios cover at least integrity, availability and non-repudiation. → [Security Scenario](https://arc.fuet.ch/concepts/quality-attributes/security-scenario.md)
- The number of quality scenarios is kept manageable, around ten for most systems. → [Standard Quality Attribute List](https://arc.fuet.ch/concepts/quality-attributes/standard-quality-attribute-checklist.md)
- The document states how testers can observe intermediate and final results of the system. → [Testability](https://arc.fuet.ch/concepts/quality-attributes/testability.md)
- Each testability scenario names whether the source is a human or an automated tester. → [Testability General Scenario](https://arc.fuet.ch/concepts/quality-attributes/testability-general-scenario.md)
- The scenario states how the system is controlled to run tests and how results are observed. → [Testability General Scenario](https://arc.fuet.ch/concepts/quality-attributes/testability-general-scenario.md)
- The scenario names the test harness or test environment where relevant. → [Testability General Scenario](https://arc.fuet.ch/concepts/quality-attributes/testability-general-scenario.md)
- Cancel or undo support is described for actions users may want to abandon. → [Usability](https://arc.fuet.ch/concepts/quality-attributes/usability.md)
- Each usability requirement is written as a scenario with a stimulus (user action) and an expected system response. → [Usability Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/usability-scenario.md)
- Usability scenarios carry a measurable value, such as a time limit in seconds. → [Usability Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/usability-scenario.md)
- Where users must make very few or no errors, a scenario uses error rate as its measure. → [Usability Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/usability-scenario.md)
- The quality tree has scenarios as its leaves, not only category names. → [Utility Tree](https://arc.fuet.ch/concepts/quality-attributes/utility-tree.md)
- Decisive stakeholders took part in building or discussing the tree, for example in a workshop. → [Utility Tree](https://arc.fuet.ch/concepts/quality-attributes/utility-tree.md)
- Bulk operations have an undo or other way to correct mistakes. → [Aggregate Tactic](https://arc.fuet.ch/concepts/tactics/aggregate-tactic.md)
- Where a remote call may fail, a fallback such as cached data or a default value is defined. → [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactic.md)
- The availability target is stated as a percentage over a period, and the need for it is justified. → [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md)
- Where a pattern is used, the tactics it relies on are named. → [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md)
- Callers define what they do when the breaker rejects a call, such as degrading functionality or informing the user. → [Circuit Breaker](https://arc.fuet.ch/concepts/tactics/circuit-breaker.md)
- Keys are mapped to data classifications, and key access is not overly permissive. → [Encrypt Data](https://arc.fuet.ch/concepts/tactics/encrypt-data.md)
- Where per-event processing is reduced, the maintenance cost of the added code is acknowledged. → [Energy Efficiency Tactic](https://arc.fuet.ch/concepts/tactics/energy-efficiency-tactics.md)
- Where triple modular redundancy is used, the document states that three components get identical inputs and their outputs are compared. → [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md)
- Where process state is monitored, the document says what conditions trigger corrective action. → [Fault Prevention Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-prevention.md)
- Where redundant spares are used, the document says which component takes over when the primary fails. → [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md)
- The probe interval is balanced against probe overhead, especially across many instances. → [Ping/Echo](https://arc.fuet.ch/concepts/tactics/ping-echo.md)
- The document states which safe state the system enters when something goes wrong (fail-safe default). → [Safety Tactic](https://arc.fuet.ch/concepts/tactics/safety-tactics.md)
- The review separates general questionnaire-style questions from concrete scenarios that describe a sequence of steps of using or changing the system. → [Scenario-based Questions from Tactics](https://arc.fuet.ch/concepts/tactics/scenario-based-questions-from-tactics.md)
- The scenario selection records how tradeoffs between competing qualities influenced which scenarios were chosen and ranked. → [Scenario-based Questions from Tactics](https://arc.fuet.ch/concepts/tactics/scenario-based-questions-from-tactics.md)
- Where a tactic term has no ISO 25010 (2011) equivalent, such as deployability, the document names the stand-in term used, for example installability. → [Tactic Coverage of ISO 25010 Quality Categories](https://arc.fuet.ch/concepts/tactics/tactic-sources-by-iso-25010-quality-category.md)
- The solution strategy ties each key quality goal to the decisions made for it, ideally in one table. → [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)
- Usability goals reference interaction capability, including learnability and user error protection. → [Usability Tactic](https://arc.fuet.ch/concepts/tactics/usability-tactics.md)
- Common-mode faults such as a shared specification, library, or input are discussed as a limit of voting. → [Voting](https://arc.fuet.ch/concepts/tactics/voting.md)