Skip to content
Software Architecture Guide

Requirements and Means Influence Architecture

Explanation

Section titled “Explanation”

Two things shape a system’s architecture: what the system must achieve, and what limits the architect’s choices.

Requirements as a driver. Some requirements affect the architecture more than others. An architecturally significant requirement has a measurable effect on a system’s architecture. Architects use these requirements to drive their decisions and to justify them later. See the article Architecturally Significant Requirement.

Quality goals matter especially. These are goals such as speed or reliability. The quality goals of the most important stakeholders (people with a stake in the system) influence the most fundamental architectural decisions. So architects should learn these goals early.

Constraints as a limit. A constraint narrows what the architect may do. Architects should know exactly where they are free to decide and where they must follow a constraint. Three points apply:

  • The team must always deal with constraints.
  • Some constraints are negotiable, so a constraint is not automatically final.
  • Some constraints reach beyond a single system. They can apply to a whole organization or company.

In practice. Early in a project, the architect can do two things:

  1. Find the requirements with the most weight, especially the quality goals of key stakeholders.
  2. Sort the constraints into fixed ones and negotiable ones.

The architectural decisions then sit inside the space that remains.

Example

Section titled “Example”

A team plans an online booking system. The operations manager, a key stakeholder, says the system must stay usable during busy sales. That quality goal pushes the team toward basic design choices. The company also requires one approved database product for all systems. This constraint covers the whole organization. The team notes it as fixed. A second rule, a preferred hosting provider, might be negotiable, so the team asks whether it can be changed. Now the team knows where it can decide freely and where it cannot.

Trade-offs

Section titled “Trade-offs”

Treating every constraint as fixed can remove options that were negotiable. Treating a fixed constraint as negotiable wastes effort. Learning requirements and constraints early takes time, but quality goals influence fundamental decisions, so late discovery is costly.

Checks

Section titled “Checks”
  • The document names the quality goals of the most important stakeholders.
  • The document lists constraints and shows where the architect is free to decide.
  • Each constraint is marked as fixed or negotiable.
  • Organization-wide constraints are identified separately from system-specific ones.
  • Key architectural decisions are justified by architecturally significant requirements.
Section titled “Related”

Sources

Section titled “Sources”