Requirements, Architecture and Design Quality

Introduction

Software quality is largely determined before implementation begins. Defects in requirements, architecture, and design are particularly expensive because they become embedded in interfaces, data structures, operational procedures, and stakeholder expectations. A coding team may implement a poorly understood requirement correctly and still deliver an unacceptable system. Similarly, an elegant component design may fail if the architecture cannot meet performance, security, availability, or regulatory obligations.

Requirements, architecture, and design quality therefore constitute a connected assurance problem. Requirements express what stakeholders and external constraints demand. Architecture establishes the system’s major structures, responsibilities, interactions, and quality mechanisms. Detailed design translates those structures into implementable components, interfaces, algorithms, and data models. Quality assurance must examine the consistency and fitness of all three levels, rather than treating them as isolated documents.

This chapter presents methods for assuring quality through quality attributes, traceability, modeling, prototyping, architecture evaluation, testability, design principles, and risk-based reviews. The emphasis is on evidence-based decision-making: quality claims should be linked to explicit criteria, scenarios, models, prototypes, analyses, or tests.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Distinguish functional requirements, quality requirements, constraints, and assumptions.

2. Express quality attributes as measurable, testable scenarios.

3. Construct and use requirements traceability relationships.

4. Evaluate models, prototypes, architectures, and detailed designs for quality risks.

5. Explain how architecture and design principles support maintainability, security, performance, and testability.

6. Apply risk-based review techniques to a realistic software project.

7. Critically assess limitations of documentation, metrics, automation, and AI-assisted analysis.

1. Quality Across the Development Structure

A requirement is a documented need, capability, constraint, or condition that a system must satisfy. Functional requirements describe services or behavior, such as “the system shall calculate the invoice total.” Quality requirements, often called non-functional requirements, specify measurable properties of the system or its development, such as response time, confidentiality, recoverability, or usability. Constraints restrict the solution space; examples include a mandated programming language, a legal retention period, or compatibility with an existing protocol.

The distinction between functional and quality requirements is useful but not absolute. “The system shall lock an account after five failed attempts” is functional behavior, while the security reason for that behavior is a quality concern. Quality attributes are often realized through many functions and architectural decisions. Availability, for example, may require redundancy, health monitoring, failover, data replication, and operational procedures.

A quality requirement should be:

• necessary for a stakeholder or external obligation;
• unambiguous to the intended readers;
• feasible within technological, financial, and schedule constraints;
• verifiable by inspection, analysis, demonstration, or test;
• consistent with other requirements;
• traceable to its source and to implementation evidence.

Statements such as “the application must be user-friendly” or “the system should be highly secure” are intentions, not sufficiently precise requirements. They must be refined into conditions and measures.

Quality-Attribute Scenarios

A quality-attribute scenario makes a quality concern concrete. A commonly used structure identifies six elements:

1. Source: the origin of the stimulus, such as a user, attacker, device, or administrator.

2. Stimulus: an event or condition, such as a request, failure, or configuration change.

3. Environment: the operating condition, such as normal load, peak load, or degraded mode.

4. Artifact: the system or component affected.

5. Response: the behavior expected from the system.

6. Response measure: the criterion used to judge the response.

For example: “During peak business hours, when a registered customer submits a product search, the search service shall return the first page within two seconds for at least 95 percent of requests measured over a one-hour interval.” This scenario identifies the condition and makes performance verifiable. It also exposes questions: how is time measured, what is the load, and what does “first page” include?

Quality attributes are related but may conflict. Encryption can increase processing cost; redundancy can increase complexity; strong consistency can reduce availability or response speed in distributed systems. Consequently, quality assurance is not merely checking isolated attributes. It is evaluating trade-offs against stakeholder priorities and risk.

Common attributes include performance efficiency, reliability, availability, security, usability, accessibility, maintainability, portability, compatibility, scalability, safety, and testability. International standards such as ISO/IEC 25010 provide useful quality models, but a standard model does not automatically supply project-specific measures. The team must define operational interpretations appropriate to the system’s context.

2. Requirements Quality Assurance

Requirements assurance begins with elicitation and continues through change management. It includes reviews by stakeholders, analysts, domain specialists, architects, testers, security professionals, and operations personnel. Different reviewers detect different classes of defect: a business user may identify an incorrect workflow, while an architect may identify an impossible integration constraint.

Core Review Criteria

A requirements set should be examined for:

• Correctness: does it represent a real stakeholder or regulatory need?
• Completeness: are normal, exceptional, boundary, failure, and recovery situations covered?
• Consistency: do requirements contradict one another?
• Feasibility: can they be met with available technology, skills, time, and budget?
• Verifiability: can compliance be demonstrated objectively?
• Traceability: can each requirement be linked to its source and downstream evidence?
• Prioritization: are essential and desirable capabilities distinguished?
• Volatility awareness: are likely changes identified and isolated where possible?

Ambiguity is a major source of defect. Words such as “appropriate,” “rapid,” “easy,” “regularly,” and “secure” require operational definitions. Requirements should also identify units, actors, timing, failure behavior, and data conditions where relevant.

Acceptance Criteria and Examples

Acceptance criteria translate requirements into observable outcomes. A useful pattern describes the initial context, triggering action, and expected result. For instance:

• Given an authenticated account with an outstanding balance,
• when the user submits a valid payment,
• then the system records the transaction, displays a confirmation identifier, and prevents duplicate processing if the same request is retried.

Examples should cover valid inputs, invalid inputs, boundaries, authorization, concurrency, interruptions, and recovery. Example-based analysis is particularly effective because it reveals missing assumptions and exposes disagreements among stakeholders.

Requirements Smells

A requirements smell is an indication of possible weakness. Examples include large compound statements containing several independent obligations, unexplained acronyms, passive voice that obscures responsibility, duplicated rules, unverifiable adjectives, and references to “the system” when several subsystems are possible. Smells do not prove defects, but they justify investigation.

3. Traceability and Change Impact

Requirements traceability records relationships among requirements, business objectives, risks, models, architecture decisions, design elements, source code, tests, defects, and release evidence. It supports coverage analysis, impact assessment, compliance demonstration, and controlled change.

A simple traceability matrix may contain requirements as rows and design elements or tests as columns. A more capable repository records typed links such as “derived from,” “implemented by,” “verified by,” “constrained by,” and “risk mitigated by.” Bidirectional traceability is important: forward tracing asks how a requirement is implemented and tested; backward tracing asks why a design element or test exists.

Traceability is not equivalent to quality. A project can have complete links to incorrect requirements. Links must therefore be reviewed for validity, not merely presence. Excessively fine-grained traceability can also become costly and obsolete. The appropriate level depends on risk, regulation, system complexity, and change rate.

A practical change-impact analysis follows these steps:

1. Identify the changed requirement and its rationale.

2. Find linked quality scenarios, models, decisions, interfaces, components, tests, and operational procedures.

3. Identify conflicts, newly exposed risks, and affected stakeholders.

4. Estimate effort and regression scope.

5. Obtain authorization and update baselines and evidence.

6. Reassess related assumptions and risks after implementation.

Requirements tools can automate link searches and coverage reports, but human judgment remains necessary. A syntactically complete matrix may contain stale or superficial links.

4. Modeling and Prototyping for Quality

Models provide abstractions that enable reasoning before implementation. Use-case models clarify actors and goals; activity and state models expose workflow and lifecycle behavior; sequence models reveal timing and collaboration; class and component models show responsibilities and dependencies; deployment models represent runtime nodes, networks, and operational boundaries.

A model is valuable when it answers a question. For example, a sequence model can help determine whether an authentication token is checked before a privileged operation. A state model can expose whether a suspended account can accidentally return to an active state. A deployment model can reveal that two supposedly redundant services share one failure domain.

Model quality should be assessed for:

• appropriate abstraction and scope;
• consistent terminology and notation;
• correct correspondence with requirements;
• explicit exceptional and failure behavior;
• understandable assumptions;
• usefulness for analysis, communication, and verification.

Models should not be produced merely for documentation. Overly detailed models become expensive to maintain, while overly abstract models conceal important risks.

Prototyping

A prototype is an exploratory artifact used to investigate an uncertain aspect of a solution. A user-interface prototype can validate workflow and accessibility. A performance prototype can test throughput assumptions. A technology spike can investigate an unfamiliar framework or integration. A security prototype can examine authentication or isolation behavior.

Prototypes have two principal risks. First, stakeholders may mistake a visual mock-up for a complete product. Second, developers may preserve prototype shortcuts in production code. Each prototype should therefore state its purpose, fidelity, assumptions, evaluation criteria, and disposal or evolution plan. Results should be recorded as evidence about the question investigated, not as proof that the final system will have identical properties.

5. Architecture Quality and Evaluation

Software architecture describes significant structures, externally visible behavior, relationships, constraints, and principles governing system evolution. It includes components, connectors, interfaces, data ownership, deployment boundaries, and cross-cutting mechanisms. Architecture quality concerns whether these decisions enable the required functional and quality outcomes under stated constraints.

An architecture decision record should state the context, decision, alternatives considered, rationale, consequences, and status. This prevents important reasoning from disappearing when personnel change. It also supports later evaluation when assumptions or requirements evolve.

Architectural Drivers

Architectural drivers are requirements and constraints with substantial influence on structure. Typical drivers include:

• high-risk quality scenarios;
• regulatory and safety obligations;
• integration and interoperability needs;
• expected scale and workload;
• organizational capabilities;
• required deployment environments;
• major business differentiators;
• known technical uncertainties.

Not every requirement is an architectural driver. A small formatting preference should not distort the system’s major structure. Conversely, a requirement for strict tenant isolation or sub-second response may require early architectural attention.

Architecture Evaluation Methods

Architecture evaluation may use several complementary methods:

• Scenario-based review: stakeholders walk through prioritized quality scenarios and identify tactics, sensitivities, and risks.
• Risk and trade-off analysis: reviewers identify decisions that may prevent quality goals, then examine competing attributes.
• Prototype or experiment: uncertain technology or performance behavior is measured in a representative setting.
• Static analysis and dependency inspection: structural properties such as cycles, coupling, and forbidden dependencies are examined.
• Operational rehearsal: deployment, recovery, monitoring, and failure response are exercised.

The Architecture Tradeoff Analysis Method, ATAM, is an example of a scenario-based approach. It emphasizes business drivers, quality-attribute scenarios, architectural approaches, sensitivity points, trade-off points, risks, and non-risks. Its value lies less in producing a score than in exposing consequences and disagreements.

Architecture review should ask: Which decisions support each critical scenario? What assumptions must hold? What happens when a component fails? Where are trust boundaries? How is data consistency maintained? How can the system be observed and changed? What evidence supports performance and capacity claims?

Architectural Styles and Trade-offs

Layered architecture can promote separation of concerns and replaceability, but excessive layering may introduce latency and rigid dependencies. Microservices can support independent deployment and team autonomy, but they increase distributed-systems complexity, operational overhead, and consistency challenges. Event-driven architecture can decouple producers and consumers, but requires careful treatment of ordering, duplication, replay, and observability. A modular monolith may provide strong boundaries with less operational complexity than distributed services.

No style is universally superior. The appropriate choice depends on quality scenarios, organizational maturity, domain boundaries, deployment constraints, and risk tolerance.

6. Design Quality and Testability

Detailed design quality concerns the clarity, cohesion, coupling, responsibility allocation, data representation, interface behavior, and changeability of components. A design should make correct behavior easy and incorrect behavior difficult.

Important principles include:

• Separation of concerns: distinct responsibilities should not be unnecessarily entangled.
• High cohesion: a module’s responsibilities should form a meaningful whole.
• Low coupling: dependencies should be limited, explicit, and stable.
• Information hiding: internal decisions should not be exposed without need.
• Single responsibility: a component should have a focused reason to change.
• Dependency inversion: high-level policy should not depend directly on volatile implementation details.
• Design by contract: preconditions, postconditions, and invariants should be explicit where useful.
• Defensive design: invalid states, untrusted inputs, timeouts, retries, and resource exhaustion should be considered.

These principles are heuristics, not mechanical laws. Excessive abstraction can make a system harder to understand; excessive generality can increase complexity without value. Design decisions must be judged against actual change scenarios and quality risks.

Testability as a Design Property

Testability is the degree to which a system supports effective test design, execution, observation, and diagnosis. A testable design provides controllable inputs, observable outputs and state, deterministic behavior where feasible, isolation of units, replaceable dependencies, and useful diagnostics.

Examples of testability techniques include dependency injection, stable interfaces, explicit clocks, controllable randomness, test seams, contract tests, feature flags, structured logging, correlation identifiers, and safe reset mechanisms. Testability must not be confused with test automation alone. A system may have automated tests yet remain difficult to diagnose or cover meaningfully.

Security and testability can conflict if test interfaces bypass authorization or expose sensitive data. Test-only capabilities must be isolated, authenticated, monitored, and prevented from reaching production unless explicitly controlled.

7. Risk-Based Reviews

Risk-based review allocates assurance effort according to the likelihood and consequence of failure. A practical risk statement identifies a condition, an uncertain event, and an effect. For example: “Because the payment provider’s timeout behavior is poorly understood, a retry may create duplicate charges, causing financial loss and customer disputes.”

A qualitative risk priority can be represented as:

Risk exposure = likelihood × consequence

This is a prioritization aid, not a universal law or precise probability model. If likelihood and consequence are assigned ordinal categories, multiplication produces an ordinal indicator; it should not be interpreted as a monetary expectation unless the scales and assumptions support that interpretation.

Review intensity should consider safety, security, financial impact, privacy, regulatory exposure, novelty, complexity, dependency uncertainty, and reversibility. High-risk items deserve early prototypes, independent review, explicit acceptance criteria, and evidence from representative environments.

Review techniques include structured walkthroughs, inspections, threat modeling, failure-mode analysis, architecture workshops, interface reviews, and scenario-based demonstrations. Review findings should be classified, assigned, tracked to closure, and checked for systemic causes. Repeated defects may indicate inadequate templates, training, tool support, or organizational incentives rather than individual carelessness.

8. Integrated Case Study: Illustrative Digital Payment Platform

Background

Consider a fictional organization developing a digital payment platform for small retailers. The platform accepts mobile and web payments, communicates with external payment providers, generates receipts, and provides settlement reports.

Problem

Early requirements stated that transactions must be “fast, secure, reliable, and available at all times.” The initial design used a single application server, synchronous calls to a payment provider, and a shared database. A demonstration worked successfully, but reviewers identified risks: provider timeouts could cause duplicate payments; the single server was a failure point; audit records were incomplete; and no clear recovery objective existed.

Analysis

The team converted vague goals into scenarios. One scenario required a payment confirmation within three seconds for 95 percent of requests under defined peak load. Another required that a retry not create a second charge. A security scenario required that only authorized staff view settlement data, with access recorded in an immutable audit trail. A recovery scenario specified restoration of critical transaction processing within an agreed period after infrastructure failure.

Traceability linked these scenarios to business objectives, threat-model risks, architecture decisions, interface contracts, and acceptance tests. A state model represented transaction states such as initiated, authorized, captured, failed, and reversal-pending. This exposed an omitted transition for provider timeout.

Approach and Solution

The team introduced an idempotency key for each client payment request and required the provider integration to preserve and check that key. Instead of assuming that every timeout meant failure, the design included reconciliation with the provider. The architecture separated transaction processing, reporting, and provider integration while retaining a modular deployment initially, avoiding premature operational distribution. A durable transaction record and an auditable state transition history were added.

A failure prototype simulated delayed and duplicated provider responses. A load experiment used representative transaction sizes and network conditions. Security review examined authorization boundaries, key management, log privacy, and administrative access. Testability was improved through injectable provider adapters, controllable clocks, deterministic test data, and structured correlation identifiers.

Outcome

The revised design did not eliminate all risk, but it made critical risks visible and assignable. Duplicate-charge scenarios became testable, recovery responsibilities were documented, and the organization could make an informed decision about infrastructure redundancy. The performance target was accepted only after measurement under stated assumptions.

Learning Points

The case demonstrates that quality is not created by adding tests at the end. It emerged from precise scenarios, explicit state modeling, traceability, architectural experimentation, and design choices that supported observation and failure handling. It also illustrates that a modular monolith can be a rational intermediate architecture when distributed deployment would add risk without addressing a current driver.

9. Governance, Ethics, and Contemporary Practice

Requirements and design decisions can affect privacy, accessibility, safety, fairness, and accountability. Privacy requirements should address data minimization, purpose limitation, retention, access, and deletion where applicable. Security reviews should consider misuse and abuse, not only normal users. Accessibility should be designed into interaction requirements and evaluated with standards, assistive technologies, and users with relevant experience.

Regulated or safety-related systems may require independence of review, controlled baselines, evidence retention, formal approvals, and documented change impact. Governance should define who may accept residual risk and how exceptions are recorded.

AI-assisted requirements analysis can identify duplicate statements, extract candidate entities, classify risks, generate trace links, or suggest test scenarios. However, generated content may be incomplete, biased, confidently incorrect, or based on confidential data. Human domain review, provenance, access control, versioning, and explicit accountability are necessary. AI should support analysis rather than become the authority for requirements or architectural acceptance.

Contemporary practice increasingly emphasizes continuous architecture, executable specifications, infrastructure as code, contract testing, software supply-chain assurance, observability, and resilience engineering. These practices extend quality assurance beyond design documents into deployment and operation. Nevertheless, automation cannot compensate for ambiguous goals, missing stakeholders, or poor risk judgment.

10. Best Practices and Limitations

Effective practice includes:

1. Start with business, user, regulatory, and operational drivers.

2. Convert quality intentions into measurable scenarios.

3. Review requirements collaboratively and independently where risk warrants.

4. Maintain useful, typed, bidirectional traceability.

5. Model behavior, boundaries, data, and failure conditions.

6. Prototype the most uncertain and consequential assumptions early.

7. Record architecture decisions and their consequences.

8. Evaluate trade-offs rather than seeking a universally “best” architecture.

9. Design for testability, observability, security, and recovery.

10. Prioritize review effort using risk and update it as evidence changes.

11. Treat metrics as indicators requiring interpretation, not as proof by themselves.

12. Keep assurance evidence current through controlled change.

These practices have limitations. Quality attributes may be difficult to measure in isolation; production context can differ from laboratory conditions; traceability can become bureaucratic; prototypes can mislead; and review outcomes depend on participant expertise. The solution is not to abandon disciplined assurance, but to combine methods, state assumptions explicitly, and validate claims with representative evidence.

Chapter Summary

Requirements, architecture, and design form a continuous quality chain. Requirements must be correct, complete, consistent, feasible, verifiable, and traceable. Quality attributes become actionable when expressed as scenarios identifying source, stimulus, environment, artifact, response, and measurable response criteria. Models and prototypes reduce uncertainty when their purpose and limitations are explicit.

Architecture quality depends on architectural drivers, appropriate structures, documented decisions, and evidence about trade-offs. Scenario-based evaluation, prototypes, static analysis, and operational rehearsal provide complementary forms of assurance. Design quality is strengthened by cohesion, controlled coupling, information hiding, explicit contracts, defensive behavior, and appropriate abstraction. Testability is a design property involving controllability, observability, isolation, determinism, and diagnosis.

Risk-based reviews focus effort on consequences, uncertainty, novelty, and irreversibility. Traceability, governance, privacy, security, accessibility, and responsible use of AI help make quality assurance accountable. No single model, metric, architecture style, or tool guarantees quality; professional assurance integrates structured reasoning with empirical evidence and continuous learning.

Key Terms

Quality attribute: A measurable property of a system, such as security, availability, or maintainability.

Quality-attribute scenario: A structured statement describing a stimulus, context, expected response, and measure.

Functional requirement: A required service, behavior, or capability of a system.

Constraint: A restriction on the solution, technology, process, or operating environment.

Acceptance criterion: An observable condition used to determine whether a requirement is satisfied.

Traceability: The documented relationship among requirements, decisions, implementation, tests, risks, and evidence.

Architecture: The significant structures, relationships, behavior, and decisions governing a system.

Architectural driver: A requirement or constraint that strongly influences architectural structure.

Architecture decision record: A record of context, decision, alternatives, rationale, and consequences.

Prototype: An exploratory artifact used to investigate uncertainty.

Cohesion: The degree to which a component’s responsibilities belong together.

Coupling: The degree and nature of dependency between components.

Information hiding: Encapsulation of internal design decisions behind stable interfaces.

Testability: The ease with which a system can be controlled, observed, tested, and diagnosed.

Idempotency: A property whereby repeating an operation has the same intended effect as performing it once.

Risk exposure: A prioritization indicator based on likelihood and consequence.

Threat modeling: Systematic analysis of assets, threats, trust boundaries, and mitigations.

Observability: The ability to infer internal system conditions from its externally available outputs.

Design by contract: Specification of preconditions, postconditions, and invariants.

Architectural trade-off: A consequence in which improving one quality attribute affects another.

Review Questions

Short Answer Questions

1. What are the six elements of a quality-attribute scenario?

2. Why is bidirectional requirements traceability useful?

3. State two risks associated with prototypes.

4. What is the difference between cohesion and coupling?

5. Why is testability considered a design property?

Long Answer Questions

1. Explain how requirements quality assurance can detect ambiguity, incompleteness, inconsistency, and infeasibility.

2. Discuss how architecture evaluation methods complement one another in assuring quality.

3. Explain the benefits and limitations of traceability in a regulated software project.

4. Compare layered, microservice, event-driven, and modular-monolith approaches in terms of quality trade-offs.

5. Describe how security, privacy, accessibility, and governance should influence requirements and design reviews.

Analytical / Application Questions

1. A hospital system must remain available during network interruptions and must prevent unauthorized access to patient records. Construct two quality-attribute scenarios and identify likely architectural tactics.

2. A payment service retries a request after receiving no response from an external provider. Analyze the duplicate-transaction risk and propose requirements, design measures, and tests.

3. A team proposes splitting a small application into twelve microservices to improve maintainability. Using risk-based reasoning, identify questions and evidence required before approving the architecture.

Multiple Choice Questions with Answers

Question 1

Which element of a quality-attribute scenario specifies the measurable criterion for judging system behavior?

A. Source

B. Environment

C. Response measure

D. Artifact

Correct Answer: C. Response measure

Question 2

What is the primary purpose of bidirectional requirements traceability?

A. To eliminate the need for testing

B. To connect requirements to downstream evidence and justify upstream design elements

C. To guarantee that requirements are correct

D. To replace stakeholder review

Correct Answer: B. To connect requirements to downstream evidence and justify upstream design elements

Question 3

Which statement best describes a prototype?

A. A complete production system with reduced documentation

B. An exploratory artifact used to investigate a specific uncertainty

C. A legally binding requirements baseline

D. A substitute for architecture evaluation

Correct Answer: B. An exploratory artifact used to investigate a specific uncertainty

Question 4

Which design property means that a component has a focused and meaningful set of responsibilities?

A. High cohesion

B. High coupling

C. Low observability

D. Information leakage

Correct Answer: A. High cohesion

Question 5

Which feature most directly improves testability?

A. Hidden global state

B. Uncontrolled real-time dependencies

C. Injectable dependencies and observable outputs

D. Undocumented shared databases

Correct Answer: C. Injectable dependencies and observable outputs

Question 6

In risk-based review, multiplying ordinal likelihood and consequence ratings should generally be interpreted as what?

A. A precise monetary loss

B. A guaranteed probability of failure

C. A prioritization indicator

D. A proof that a risk will occur

Correct Answer: C. A prioritization indicator

Question 7

What problem does an idempotency key primarily help address in the payment case?

A. User-interface accessibility

B. Duplicate processing caused by retries

C. Database schema normalization

D. Static code formatting

Correct Answer: B. Duplicate processing caused by retries

Question 8

What is an architectural driver?

A. Any line of source code influencing a component

B. A requirement or constraint with substantial influence on system structure

C. A post-release defect report only

D. A user-interface color preference in every case

Correct Answer: B. A requirement or constraint with substantial influence on system structure

Question 9

Which is a likely trade-off of microservices?

A. They always remove operational complexity

B. They eliminate consistency problems

C. They can support independent deployment while increasing distributed-systems complexity

D. They prevent all coupling

Correct Answer: C. They can support independent deployment while increasing distributed-systems complexity

Question 10

Why should AI-generated requirements or trace links receive human review?

A. AI outputs are always unusable

B. Generated outputs may be incomplete, biased, or confidently incorrect

C. Human review makes testing unnecessary

D. AI cannot process any software information

Correct Answer: B. Generated outputs may be incomplete, biased, or confidently incorrect