Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Chapter I · Area 02 of 12

Requirements & quality

The Question for Our ShopHow quickly must the shop respond to a payment request, and how do you measure that?

Here you will find the goals and guidelines against which you align your draft.

6 Building blocks

Starting hereFunctional requirements

Three questions for every requirement

  1. What should the shop do?

    Functional requirements

    A customer orders the contents of the cart and receives order B-1042.

  2. How well must it do it?

    Quality requirementsoften called non-functional requirements (NFR)

    95% of payment requests are answered within 800 ms (illustrative).

  3. What is already fixed?

    ConstraintsConstraints

    The payment provider is specified by contract.

The few requirements that shape the design most become architecture drivers.Architecture drivers

This is how the building blocks hang together

Functional requirements describe the functions needed. Quality attributes make quality measurable, constraints record fixed limits, and availability, performance and changeability make key quality goals concrete.

Quality attributeQuality attributesYou define measurable expectations for how well a function performs under specific conditions.ConceptFunctional requirementsname the business functions whose quality is made measurable by quality attributesConceptConstraintslimit the solution space for functions and agreed quality goalsQuality attributeAvailabilitymeasures when users can successfully access a functionQuality attributePerformanceassesses response time, throughput and resources under loadQuality attributeModifiabilitydescribes the effort and risk of particular changes
Relations: Functional requirements name the business functions whose quality is made measurable by quality attributes; Constraints limit the solution space for functions and agreed quality goals; Availability measures when users can successfully access a function; Performance assesses response time, throughput and resources under load; Modifiability describes the effort and risk of particular changes.

Your learning path through the area

Here you find functional requirements, quality goals and binding constraints. They let you align design options with concrete system capabilities, measurable quality and the applicable constraints. Each building block shows its theme at our shop.

  1. Functional requirements

    This is what you learnYou can formulate a functional requirement as observable performance with trigger and outcome.

    In the shopA customer places his shopping cart as an order. The shop checks the selection, places the order and returns an order identifier.

    Functional requirements Open

  2. Quality attributes

    Quality requirement

    This is what you learnYou can concretize a quality expectation with trigger, environment, reaction and metric.

    In the shopFor the shop, the reaction to a payment request under normal load is described in concrete terms. The numbers are an illustrative learning example.

    Quality attributes Open

  3. Constraints

    This is what you learnYou can distinguish binding constraints from negotiable goals and selected solutions.

    In the shopThe shop carries technical constraints (payment provider, Java-runtime), organizational ones (small team without call will), legal ones (GDPR, PCI DSS) and a convention (API policy). Delivery and module cutting remain decisions of the team.

    Constraints Open

  4. Availability

    Quality requirement

    This is what you learnYou can separately assess the availability of order acceptance and payment authorization during the same disruption.

    In the shopThe shop can accept an order with the status clarification running, while the external payment provider temporarily does not reply. The order acceptance thus remains usable; the payment authorization is disturbed during this period.

    Availability Open

  5. Performance

    Quality requirement

    This is what you learnYou can measure response time, throughput, and resource usage for the same flow separately.

    In the shopThe team measures the completion of an order with illustrative test data. The measurement includes shop processing and simulated response from the payment provider.

    Performance Open

  6. Modifiability

    Quality requirement

    This is what you learnYou can track the effects of a specific change in the subject via affected modules and contracts.

    In the shopThe shop introduces the pickup option. Ordering and warehouses change their behavior; payment, shipping and invoice should only be targeted via stable contracts.

    Modifiability Open
Afterwards in the learning path · area 03Principles & boundaries

Thinking ahead

These areas are technically directly related to Requirements & quality together.

Chapter I · Area 01Fundamentals & orientationArchitecture drivers rank requirements and quality goals by their effect on the structure.Open area Chapter II · Area 05Styles & patternsArchitectural styles and patterns have different consequences for quality goals and operations.Open area Chapter I · Area 04Domain modellingDomain modelling translates business requirements into terms, rules and states.Open area From practiceOne order, two systemsHow a business change connects data, messages and error handling.Opening up the scenario