While functionality describes exactly what a software system does, quality attributes describe how well the system performs those functions.
Quality attributes measure the overarching “goodness” of an architecture along specific dimensions, encompassing critical properties such as extensibility, availability, security, performance, robustness, interoperability, and testability.
You may hear these called non-functional requirements, but that phrase can be misleading. A quality attribute is not unrelated to functionality. It is usually a measurable expectation attached to a specific function or scenario. “Search” is functionality. “During peak load, 95% of search requests return within 200 ms” is a performance quality attribute for that functionality.
Important quality attributes include:
Interoperability: the degree to which two or more systems or components can usefully exchange meaningful information via interfaces in a particular context.
Testability: degree to which a system or component can be tested via runtime observation, determining how hard it is to write effective tests for a piece of software.
Other common quality attributes include:
Modifiability: the ease with which a class of changes can be made to a system, often measured by development time or by which modules must not be touched.
Extensibility: a subtype of modifiability focused on adding new functionality with low effort and low risk of mistakes.
Availability: the ability of a system to mask or repair faults, often measured by uptime, mean time to repair, or mean time between failures.
Performance: the ability to meet timing requirements under specified demand, measured by latency, throughput, jitter, deadline miss rate, or resource usage.
Security: the ability to protect confidentiality, integrity, availability, and accountability against specific threats.
Portability: the ease with which the system can run in a different environment, such as another operating system, cloud provider, or hardware platform.
The Architectural Foundation
Quality attributes are often described as the load-bearing walls of a software system. Just as the structural integrity of a building depends on walls that cannot be easily moved once construction is finished, early architectural decisions strongly impact the possible qualities of a system. Because quality attributes are typically cross-cutting concerns spread throughout the codebase, they are extremely difficult to “add in later” if they were not considered early in the design process.
Detailed features are more like furniture: you can often add, remove, or rearrange them after the basic structure exists. Load-bearing qualities are different. If a system was built with synchronous in-process calls everywhere, making it highly available across multiple data centers is not a one-line patch. If a system was built around global mutable state, making it testable later requires structural redesign, not just more test files.
Categorizing Quality Attributes
Quality attributes can be broadly divided into two categories based on when they manifest and who they impact:
Design-Time Attributes: These include qualities like extensibility, changeability, reusability, and testability. These attributes primarily impact developers and designers, and while the end-user may not see them directly, they determine how quickly and safely the system can evolve.
Run-Time Attributes: these include qualities like performance, availability, and scalability. These attributes are experienced directly by the user while the program is executing.
Specifying Quality Requirements
To design a system effectively, quality requirements must be measurable and precise rather than broad or abstract. A high-quality specification requires two parts: a scenario and a metric.
The Scenario: This describes the specific conditions or environment to which the system must respond, such as the arrival of a certain type of request or a specific environmental deviation.
The Metric: This provides a concrete measure of “goodness”. These can be hard thresholds (e.g., “response time < 1s”) or soft goals (e.g., “minimize effort as much as possible”).
For example, a robust specification for a Mars rover would not just say it should be “robust”, but that it must “continue scientific measurements during a 72-hour dust storm that reduces solar input by 60%, transmit a beacon every 6 hours, and resume full operations within 1 hour after normal solar input returns.”
Good Quality-Attribute Specifications
The following examples show the pattern. Notice that good specifications do not always use the same kind of number. Runtime qualities often use latency, throughput, or uptime. Design-time qualities often use development time, number of modules touched, or dependency boundaries that must not be crossed.
Quality
Weak specification
Better specification
Performance
“Search should be fast.”
“During the Friday-evening peak load of 10,000 concurrent users, 95% of product-search requests return results within 200 ms and 99% return within 500 ms.”
Availability
“The service should be highly available.”
“For any rolling 30-day window, the checkout API maintains at least 99.95% successful responses, excluding scheduled maintenance announced at least 48 hours in advance.”
Extensibility
“Adding new sensors should be easy.”
“Adding a new depth sensor requires implementing one sensor adapter and must not require changes to components that process depth images.”
Modifiability
“The rules engine should be flexible.”
“Changing a tax rule for one state can be completed by one developer in less than one day and must not require changes to payment authorization or invoice rendering.”
Testability
“Payment code should be easy to test.”
“A developer can run deterministic tests for payment authorization outcomes, including declined cards and network timeouts, without contacting the real payment provider.”
Interoperability
“Hospitals should exchange records.”
“When Hospital A sends an HL7 patient-discharge message to Hospital B, at least 99.9% of required fields are parsed and interpreted with the same units, codes, and timestamp semantics.”
Security
“User accounts should be secure.”
“After 5 failed login attempts for one account within 10 minutes, further attempts are rate-limited for 15 minutes and the event is recorded in the audit log within 5 seconds.”
Scalability
“The system should scale.”
“When read traffic increases from 1,000 to 20,000 requests per minute, the service can add replicas without downtime and keep p95 read latency below 300 ms.”
Robustness
“The robot should handle bad data.”
“If a camera publishes 10 consecutive malformed frames, the perception component discards those frames, reports the fault within 1 second, and continues processing valid lidar input.”
Portability
“The app should run anywhere.”
“Moving the service from AWS to GCP requires replacing cloud-storage and secret-management adapters only; domain and API modules remain unchanged.”
Two of these examples are deliberately softer than a pure pass/fail threshold. “Must not require changes to components that process depth images” is a structural boundary rather than a time measurement. “Minimize changes to existing preprocessing components” can also be acceptable when the team is optimizing a direction rather than enforcing a hard threshold. The key is that the statement still guides architectural decisions.
Common Specification Smells
Watch for these failure patterns:
Adjective-only requirements: “fast,” “robust,” “secure,” “usable,” and “scalable” do not mean the same thing to every stakeholder.
Metrics without scenarios: “respond within 200 ms” is incomplete unless it says under what load, for which request, and with which data size.
Scenarios without metrics: “during a network outage” names the condition but not what counts as success.
System-wide blanket claims: “every request must complete within 1 second” is usually wrong. Architecture work needs the specific requests that matter.
Implementation disguised as requirement: “Use Kafka for scalability” chooses a solution before stating the quality scenario it is supposed to satisfy.
Practice: Quality-Requirement Triage
Use the quiz below to practice deciding whether a statement is a usable quality-attribute requirement, and when it is not, which specification smell is getting in the way.
Quality-Requirement Triage
Decide whether each statement is a usable quality-attribute requirement, then identify the smell or strength that matters.
Difficulty:Basic
A team writes: “During the Friday-evening peak load of 10,000 concurrent users, 95% of product-search requests return results within 200 ms and 99% return within 500 ms.” Is this a good quality-attribute requirement?
No implementation mechanism is named. The statement leaves the design open while still making the performance goal testable.
The peak-load condition and product-search request are the scenario. The p95 and p99 latency targets are the metrics.
Correct Answer:
Explanation
This is a good performance requirement because it combines a specific scenario with concrete success measures. A team can test it under the stated load and compare results against the p95 and p99 thresholds.
Difficulty:Basic
A team writes: “The API must respond within 200 ms.” Is this a good quality-attribute requirement?
A number helps, but the number needs context. A checkout request, search request, and admin report can have very different latency budgets.
Numbers are often necessary for performance requirements. The problem here is not measurement; it is measurement without context.
Correct Answer:
Explanation
This is a metric-without-scenario smell. The statement says “200 ms” but does not say which request or operating condition the target applies to.
Difficulty:Basic
A team writes: “Use Kafka for scalability.” Is this a good quality-attribute requirement?
Kafka might be a reasonable design choice, but the requirement should first say what load or growth the system must handle.
Scalability is observed at runtime, but it should be specified before design decisions are made. The missing piece is the scenario and metric.
Correct Answer:
Explanation
This is an implementation-first smell. A better requirement would describe the traffic increase, acceptable downtime or latency, and any other success criteria before choosing a messaging system.
Difficulty:Intermediate
A team writes: “Adding a new depth sensor requires implementing one sensor adapter and must not require changes to components that process depth images.” Is this a good quality-attribute requirement?
Design-time qualities are not always measured by latency. Extensibility can be measured by the number of places that must change or by boundaries that must stay stable.
“One sensor adapter” describes the allowed shape of the change, not a premature framework choice. The important constraint is that depth-image processors stay untouched.
Correct Answer:
Explanation
This is a good extensibility requirement because it defines what change is expected and what ripple effect is unacceptable. Structural boundaries can be valid measures for design-time qualities.
Difficulty:Intermediate
A team writes: “During a payment-provider outage, checkout should keep working gracefully.” Is this a good quality-attribute requirement?
The outage condition is useful, but “working gracefully” is still ambiguous. The team needs to know whether to queue orders, reject payment, retry for a duration, or show a specific user message.
Robustness is about behavior under faults and unusual conditions. Failure scenarios are exactly where robustness requirements belong.
Correct Answer:
Explanation
This is a scenario-without-success-criteria smell. A stronger version would state what checkout does during the outage, for how long, and what information is logged or shown to users.
Difficulty:Intermediate
A team writes: “Every request in the whole system must complete within 1 second.” Is this a good quality-attribute requirement?
System-wide blanket thresholds usually mix unrelated work. A search request, login request, nightly export, and admin analytics query rarely need the same latency target.
The statement does include a metric: 1 second. The problem is that the metric is applied too broadly without identifying the meaningful scenarios.
Correct Answer:
Explanation
This is a system-wide blanket smell. Good performance requirements name the specific request types (search, checkout, batch export) and the operating conditions under which each target applies, rather than imposing one number on everything.
Difficulty:Intermediate
A team writes: “Changing a tax rule for one state can be completed by one developer in less than one day and must not require changes to payment authorization or invoice rendering.” Is this a good quality-attribute requirement?
“Flexible” would be weaker because different stakeholders interpret it differently. Naming the expected change and the untouched modules makes the architectural target clearer.
Modifiability should be planned early. The statement can guide module boundaries before the codebase exists.
Correct Answer:
Explanation
This is a good modifiability requirement. It describes a likely future change, a development-time threshold, and the parts of the system that should remain unaffected.
Difficulty:Basic
A team writes: “The system should be secure, scalable, robust, and user-friendly.” Is this a good quality-attribute requirement?
Listing important qualities does not make them actionable. The architects still cannot tell which threats, loads, failures, or user tasks matter.
Usability can be a real quality attribute. The problem is that “user-friendly” needs a concrete task, user group, and success criterion.
Correct Answer:
Explanation
This is the adjective-only smell. The words name desirable qualities, but they do not yet define requirements that can drive architecture or testing.
Difficulty:Advanced
A team writes: “When adding support for a new image format, minimize changes to existing preprocessing components.” Is this a good quality-attribute requirement?
Runtime qualities often use latency, throughput, or uptime numbers, but design-time qualities can be measured by ripple effects and dependency boundaries.
Design-time qualities such as modifiability and extensibility are still real requirements. They guide code structure even when end users do not observe them directly.
Correct Answer:
Explanation
This is softer than a pure pass/fail threshold, but it still guides architectural decisions: changes for new formats should stay away from the existing preprocessing components. If the risk is high, the team can strengthen it into a hard boundary such as “must not require changes to existing preprocessing components.”
Workout Complete!
Your Score: 0/9
Trade-offs and Synergies
A fundamental reality of software design is that you cannot always maximize all quality attributes simultaneously; they frequently conflict with one another.
Common Conflicts: Enhancing security through encryption often decreases performance due to the extra processing required. Similarly, ensuring high reliability (such as through TCP’s message acknowledgments) can reduce performance compared to faster but unreliable protocols like UDP.
Synergies: In some cases, attributes support each other. High performance can improve usability by providing faster response times for interactive systems. Furthermore, testability and changeability often synergize, as modular designs that are easy to change also tend to be easier to isolate for testing.
Because trade-offs are unavoidable, architecture work is partly the discipline of prioritizing. A system cannot be “maximally secure, maximally fast, maximally cheap, maximally portable, and maximally easy to change” all at once. A good architecture identifies the few quality attributes that are load-bearing for this system, then accepts and documents the costs paid on other dimensions.
Architectural Tactics
Architectural styles shape the dominant structure of a system. Architectural tactics are smaller reusable design moves that improve a particular quality attribute inside that structure. For example, a publish-subscribe system might use the heartbeat tactic to detect failed subscribers, and a layered web application might use caching to reduce request latency.
Common tactics include:
Ping-echo for availability: a watchdog pings monitored components and expects an echo before a timeout.
Heartbeat for availability: monitored components periodically send “I am alive” messages to a watchdog.
Active redundancy for availability: multiple replicas run at the same time so one can take over when another fails.
Cold spare for availability: a backup component stays inactive until a failure requires recovery.
Caching for performance: a fast local copy prevents repeated expensive retrieval of the same resource.
The useful question is not “which tactic is best?” but “which tactic improves the target quality scenario, and what does it cost?” Ping-echo and heartbeat both improve availability by detecting failures, but both consume network and processing resources. Caching improves performance when requests repeat, but it introduces invalidation and stale-data risks. See Architectural Tactics for the detailed comparison.
Quality Attributes Quiz and Flashcards
Use these flashcards and quiz questions to review the whole topic: definitions, measurable quality specifications, design-time and run-time qualities, trade-offs, synergies, tactics, and architectural prioritization.
Quality Attributes Comprehensive Flashcards
Broad review of quality attributes, measurable specifications, architectural trade-offs, tactics, and design-time versus run-time qualities.
Difficulty:Basic
What is a quality attribute?
A quality attribute describes how well a system performs its functions, such as performance, availability, security, modifiability, testability, interoperability, robustness, scalability, or portability.
A functional requirement says what the system does. A quality attribute says how well that function must work in a specific context.
Difficulty:Basic
Why is the phrase non-functional requirement potentially misleading?
Because quality attributes are usually attached to a specific function or scenario. “Search” is functional behavior; “95% of searches return within 200 ms during peak load” is a performance quality attribute for that behavior.
The quality is not separate from functionality. It constrains the way a function must behave under particular conditions.
Difficulty:Basic
What two ingredients make a quality requirement measurable?
A scenario and a metric. The scenario names the relevant condition, stimulus, user, failure, or operating environment. The metric names what counts as success.
A scenario without a metric is vague; a metric without a scenario floats without context. Good quality requirements need both.
Difficulty:Basic
Distinguish run-time and design-time quality attributes.
Run-time qualities are observed while the system executes, such as performance, availability, robustness, scalability, and some security properties. Design-time qualities affect development and maintenance, such as modifiability, extensibility, reusability, portability, and testability.
The distinction is about when the quality shows up and who feels it first, not about whether the quality matters to users or the business.
Difficulty:Intermediate
Why are quality attributes described as load-bearing walls?
Early architecture choices strongly constrain achievable qualities, quality concerns cut across many modules, and retrofitting them later is often expensive.
You can usually rearrange features later. Retrofitting high availability, testability, or security into an architecture that works against those qualities is closer to structural renovation.
Difficulty:Intermediate
Write the shape of a good performance quality requirement.
It should name the operation, the operating condition, and measurable timing or throughput targets. Example: “During peak load of 10,000 concurrent users, 95% of product-search requests return within 200 ms and 99% within 500 ms.”
Performance numbers are only meaningful when tied to a workload, request type, data size, and percentile or threshold.
Difficulty:Intermediate
What makes an availability requirement measurable?
It states the time window, what counts as successful service, and any exclusions or recovery expectations. Example: “For any rolling 30-day window, the checkout API maintains 99.95% successful responses, excluding scheduled maintenance announced 48 hours in advance.”
Availability requirements often use uptime, successful-response rate, mean time to repair, mean time between failures, or failover time.
Difficulty:Advanced
Why can a structural boundary be a valid measure for a design-time quality?
Design-time qualities are often about ripple effects. A requirement can be measurable if it says which modules must not change, which dependencies must not be crossed, or how many components should be touched.
“Adding a depth sensor must not require changes to depth-image processors” is measurable even though it is not a latency or uptime number.
Difficulty:Intermediate
What are controllability and observability in testability?
Controllability is the ability to put the component into important states and provide relevant inputs. Observability is the ability to see outputs, side effects, faults, timing, and other behavior clearly enough to test them.
A system is hard to test when important states cannot be triggered or when failures happen silently.
Difficulty:Intermediate
Give a testability requirement for payment authorization.
“A developer can run deterministic tests for approved cards, declined cards, and provider timeouts without contacting the real payment provider.”
The requirement names important scenarios and removes an external dependency that would make tests slow, flaky, or impossible to force into rare states.
Difficulty:Intermediate
What makes interoperability more than just sending data?
Interoperability requires shared meaning: units, codes, required fields, timestamp semantics, identifiers, error handling, and interpretation must match across systems.
Two hospitals can exchange bytes and still fail interoperability if one treats a timestamp, unit, or discharge code differently.
Difficulty:Intermediate
Name three common quality-attribute conflicts.
Security can conflict with performance; reliability can conflict with latency; modifiability can conflict with raw performance; portability can conflict with platform-specific optimization.
Conflicts are normal. Architecture work makes the trade-off explicit instead of letting it appear accidentally in code.
Difficulty:Intermediate
Name two common quality-attribute synergies.
Performance can improve usability for interactive systems, and testability often improves changeability because modular, controllable components are easier to modify safely.
Synergies are valuable because one design investment pays off across more than one quality attribute.
Difficulty:Intermediate
Why is ‘Use Kafka for scalability’ a specification smell?
It chooses an implementation before stating the scalability scenario and success measure. A better requirement says what traffic, growth, latency, downtime, or data-volume target the system must handle.
Kafka may be a good design choice, but it cannot be evaluated until the actual quality requirement is clear.
Difficulty:Advanced
How should an architect respond when stakeholders say the system should maximize all quality attributes?
Push for prioritization. Identify the few qualities that are load-bearing for this system, make trade-offs explicit, and document the costs accepted on lower-priority qualities.
“All of them” gives the team no basis for resolving conflicts. Priorities make later design decisions coherent.
Difficulty:Advanced
How do architectural tactics relate to quality attributes?
Tactics are reusable design moves that improve a specific quality scenario, such as heartbeat for availability detection, active redundancy for availability, or caching for performance.
The useful question is not which tactic is best in general, but which tactic improves the target quality scenario and what it costs.
Difficulty:Expert
Use this checklist to draft a quality requirement.
Name the quality, the function or component, the scenario, the metric or structural boundary, the measurement window, and any exclusions or acceptable trade-offs.
This checklist keeps the requirement solution-neutral while still giving architects enough detail to design, test, and negotiate trade-offs.
Difficulty:Advanced
When is a softer quality goal still useful?
A softer goal is useful when it names a direction and a relevant scenario, such as minimizing changes to existing preprocessing components when adding a new image format. High-risk work may still need a hard threshold or forbidden boundary.
Not every quality target needs a pure pass/fail number. The key is that the statement must still guide architectural decisions.
Workout Complete!
Your Score: 0/18
Come back later to improve your recall!
Quality Attributes Comprehensive Quiz
Practice identifying, specifying, prioritizing, and trading off quality attributes across realistic architecture scenarios.
Difficulty:Basic
Which statement best distinguishes functionality from a quality attribute?
Some quality attributes, such as performance and availability, are directly user-facing. Developer-facing qualities are only part of the set.
Quality attributes should be measurable enough to guide design and testing.
Quality attributes belong in requirements because they shape architecture early.
Correct Answer:
Explanation
“Search by keyword” is functionality. “95% of keyword searches return within 200 ms during peak load” is a quality attribute attached to that function.
Difficulty:Intermediate
Which statements include both a scenario and a success measure? Select all that apply.
“Easy to use” names a desired quality, but it does not specify a task, user group, or success criterion.
This includes a load scenario and a p95 latency threshold.
This includes the measurement window, success threshold, affected API, and maintenance exclusion.
This names a failure condition, but “gracefully” does not define what the system must do.
This uses a structural success measure: only one adapter changes and depth-image processors remain untouched.
Correct Answers:
Explanation
Good quality requirements connect conditions to success criteria. The criteria may be runtime numbers or design-time boundaries.
Difficulty:Basic
A requirement says: “The report API must respond within 200 ms.” What is the main weakness?
“200 ms” is a metric. The missing part is the operating context around that number.
APIs can absolutely have performance requirements when the relevant request and load are specified.
The statement does not name a technology or design mechanism.
Correct Answer:
Explanation
A bare metric is not enough. The team needs to know which reports, data size, load level, cache state, and percentile the target applies to.
Difficulty:Basic
Which attributes are primarily design-time qualities? Select all that apply.
Modifiability affects how safely and quickly developers can change the system.
Extensibility is about adding new capability with limited ripple effects.
Performance is observed while the system runs.
Testability affects the ability to control and observe the system during tests.
Availability is observed while the system runs and failures occur.
Correct Answers:
Explanation
Design-time qualities primarily affect evolution and maintenance. Run-time qualities are experienced during execution.
Difficulty:Intermediate
A team built a synchronous monolith. A year later, it cannot scale beyond 10,000 concurrent users without major rework. Which idea does this best illustrate?
Scalability is deeply shaped by state management, communication patterns, data partitioning, and deployment structure.
A monolith can be a good choice in some contexts. The issue is whether the architecture fits the expected growth profile.
Real measurements are valuable, but architectural choices should still account for plausible growth before launch.
Correct Answer:
Explanation
The lesson is not “never use a monolith.” It is that load-bearing qualities need to be considered early enough that the chosen structure can support the expected future.
Difficulty:Intermediate
A service must detect a failed worker within 10 seconds so another worker can take over. Which tactic most directly addresses failure detection?
Caching can improve performance, but it does not detect failed workers.
Naming conventions may help maintainability, but they do not provide runtime failure detection.
Search indexing can improve search performance, but it does not monitor worker liveness.
Correct Answer:
Explanation
Heartbeat is an availability tactic: monitored components periodically report that they are alive, and the watchdog can react when the signal stops.
Difficulty:Advanced
A team adds aggressive caching to improve read latency. Which quality effects should they discuss? Select all that apply.
Avoiding repeated expensive retrieval is the main performance benefit of caching.
Cache invalidation and stale data are the classic costs of caching.
Some caches can mask backend failures for read-only content, depending on the freshness requirements.
Caching often adds invalidation paths and distributed-state complexity, which can make modification harder.
Cached sensitive data can create confidentiality and access-control risks.
Correct Answers:
Explanation
Tactics improve one quality scenario while introducing costs elsewhere. Caching is a performance tactic with freshness, complexity, and sometimes security trade-offs.
Difficulty:Intermediate
A hospital integration requirement says: “When Hospital A sends an HL7 discharge message to Hospital B, 99.9% of required fields are parsed with the same units, codes, and timestamp semantics.” Which quality is primarily specified?
Portability is about moving the system to a different environment.
Extensibility is about adding new capability with limited change effort.
The statement is not about timing or throughput; it is about shared meaning across systems.
Correct Answer:
Explanation
Interoperability requires more than exchanging bytes. The receiving system must interpret the fields with the same meaning.
Difficulty:Advanced
Which statements are quality-requirement smells? Select all that apply.
“Robust” is an adjective without a scenario or success criterion.
This names a solution before stating the scalability requirement.
This gives a load scenario and a latency threshold.
This names a condition but not what behavior counts as success.
Blanket system-wide timing claims usually ignore which requests matter and under what conditions.
Correct Answers:
Explanation
Common smells include adjective-only phrasing, implementation-first statements, scenarios without metrics, metrics without scenarios, and blanket claims.
Difficulty:Advanced
A product manager asks for maximum security, maximum performance, maximum portability, and minimum development cost. What is the best architectural response?
Equal priority gives the team no basis for resolving real conflicts.
Ease of measurement is not the same as importance.
Development cost is affected by architecture through complexity, tooling, team skill, and change effort.
Correct Answer:
Explanation
Quality-attribute work is partly prioritization. The architect helps stakeholders decide what matters most for this system and what trade-offs are acceptable.
Difficulty:Advanced
A robotics team has two options for adding new sensors. Design A requires changes in sensor adapters only. Design B requires changes in adapters, perception, and planning. The priority quality is extensibility. Which design better fits the quality goal?
More modules touched usually means higher change cost and higher regression risk.
Extensibility is a design-time quality and is often measured by ripple effects.
Future details matter, but the expected change scenario is enough to compare the designs.
Correct Answer:
Explanation
The quality goal says new sensors should be added with low ripple effect. Design A preserves a clearer dependency boundary.
Difficulty:Advanced
Which rewrite best turns “the login system should be secure” into a useful quality requirement?
“Best practices” is too vague to test or design against.
This chooses mechanisms before stating the threat scenario and success criteria.
Adding more adjectives makes the requirement broader but not more measurable.
Correct Answer:
Explanation
The strong rewrite names the security scenario (repeated failed logins), the threshold that triggers a response (5 attempts in 10 minutes), and the measurable response (a 15-minute account lock).
Difficulty:Advanced
A team says: “We cannot put numbers on modifiability, so we should not include it in requirements.” What is the best correction?
Design-time attributes are legitimate requirements even when users do not observe them directly.
Replacing a hard-to-measure quality with an easier one can optimize the wrong thing.
One hour may be appropriate for some contexts but absurd for others. The measure must fit the change scenario.
Correct Answer:
Explanation
Not all quality measures are latency or uptime numbers. Design-time qualities often rely on change cost and structural boundaries.
Difficulty:Expert
You are drafting a quality requirement for moving a service from AWS to GCP. Which details belong in the requirement? Select all that apply.
The change scenario anchors the portability requirement.
Allowed ripple effect is a useful design-time measure.
Stable module boundaries make the portability target architectural rather than vague.
A language rewrite is an implementation choice and may be unrelated to the portability goal.
The team needs criteria for deciding whether the port succeeded.
Correct Answers:
Explanation
A portability requirement should describe the migration scenario and success boundaries without prematurely forcing a particular rewrite strategy.
Workout Complete!
Your Score: 0/14
Cookie & Privacy Notice:
This site stores a few preferences and your progress locally in your browser
(cookies and localStorage) so it works the way you left it.
Nothing is sent to or stored on any external server, and this site does not
sell, share, or disclose any user data to third parties.
View & manage your data →