arc42 section 10: Quality Requirements

Quality tree and quality scenarios

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