iSAQB CPSA Foundation Level key terms

The set of fundamental structures of a software system: its building blocks, their externally visible properties, and the relationships among them, together with the principles and guidelines that shape its evolution over time.

A person or group with an interest in the system because they are affected by it, fund it, build it, operate it, or depend on its behaviour, and whose concerns must be addressed by the architecture.

Any interest, requirement, or worry of a stakeholder that the architecture must address, such as performance, maintainability, cost, safety, or time to market. Concerns drive which views and decisions matter.

A representation of a coherent subset of the architecture, chosen to address specific stakeholder concerns. Each view highlights particular structures, for example runtime behaviour, deployment, or module organisation, while deliberately omitting other details.

A reusable template or convention that defines what a particular kind of view shows, which elements and relations it uses, and how it is documented. Viewpoints are defined once and instantiated as views for a specific system.

An abstract, simplified representation of the architecture or part of it, expressed in a notation with defined element types and rules, used to reason about the system before or instead of building it.

A structural element of the architecture at a chosen level of abstraction, such as a subsystem, component, or module. Building blocks have defined responsibilities and interfaces, and are composed hierarchically into larger units.

A description of a building block that states only its externally visible behaviour, responsibilities, and interfaces, hiding internal implementation. It supports replaceability and lets reviewers assess contracts without reading internals.

A description that reveals the internal structure of a building block, such as its contained sub-blocks and their interactions. It is used to show how responsibilities are realised and to guide developers working inside the block.

A defined contract through which a building block offers functionality or requires it from others, specifying signatures, semantics, protocols, and quality properties such as timing or error behaviour, independent of the implementation behind it.

The complete agreement attached to an interface: provided and required operations, data formats, preconditions and postconditions, error cases, and non-functional guarantees. It is the basis for independent development and testing of connected blocks.

The property of a system being composed of discrete units with well-defined boundaries, so that each unit can be understood, changed, tested, and replaced with limited knowledge of the others.

The degree to which the responsibilities inside a single building block belong together and serve one purpose. High cohesion makes blocks easier to understand and change; low cohesion signals a block that should be split.

The degree to which building blocks depend on each other, kept low so that changes in one block rarely force changes in others. Coupling is reduced by narrow interfaces, few shared data structures, and asynchronous interaction where suitable.

A design principle stating that each building block should conceal design decisions likely to change behind a stable interface, so that internal changes do not ripple outward to its users.

The technique of bundling data and the operations on that data inside a unit and restricting direct external access, exposing only a controlled interface. It protects invariants and limits the impact of internal change.

A design guideline holding that a module or class should have exactly one reason to change, meaning one cohesive responsibility assigned to one owner. It supports high cohesion and simpler testing.

A general, reusable guideline that shapes design decisions, such as separation of concerns, keep it simple, or depend on abstractions. Principles are not absolute rules; architects weigh them against each other in context.

A named, reusable solution template for a recurring design problem in a given context, describing participating elements, their collaboration, and consequences. Patterns transfer experience but must be adapted, not copied blindly.

A reusable, high-level structural solution for organising a whole system or major part of it, such as layers, pipes and filters, or microservices, together with its typical element types, interactions, benefits, and liabilities.

An architecture pattern that organises building blocks into horizontal layers, where each layer uses only the layer directly below through defined interfaces. It improves substitutability and separation of concerns but can add indirection overhead.

An architecture style in which a system is composed of small, independently deployable services, each owning its data and communicating over the network. It favours independent scaling and team autonomy but adds operational and consistency complexity.

A principle of dividing a system so that each part addresses a distinct concern, allowing it to be developed and reasoned about independently. It underlies layering, modularisation, and the choice of architecture views.

A non-functional property of a system that can be assessed, such as performance, availability, security, modifiability, usability, or testability. Quality attributes are often in tension and must be prioritised and traded off explicitly.

A concrete, testable statement of a quality requirement with source, stimulus, environment, affected artefact, response, and measurable response measure. Scenarios turn vague quality goals into criteria the architecture can be evaluated against.

A requirement describing how well the system must perform its functions, expressed measurably where possible. It constrains architectural decisions and must be elicited from stakeholders rather than assumed.

A decision in which improving one quality attribute or property degrades another, for example stronger security at the cost of usability or latency. Architects make trade-offs explicit and document the reasoning behind them.

A structured review of an architecture against stated quality requirements and stakeholder concerns, performed early to surface risks before implementation. Methods range from lightweight questioning to scenario-based analysis with documented findings.

A potential future problem arising from architectural decisions or unknowns that could jeopardise required quality attributes, schedule, or cost. Risks are identified, prioritised, and either mitigated or accepted with documentation.

The accumulated cost of shortcuts in design or implementation that make future changes harder. Like financial debt, it incurs ongoing interest through slower delivery and must be made visible and repaid deliberately.

A disciplined sequence of small behaviour-preserving transformations that improve the internal structure of code or design. Architecture-level refactoring is used to evolve structures incrementally without breaking external contracts.

A conscious choice about structure, technology, or standards that is significant, hard to reverse, and constrains further design. Recording context, alternatives, and rationale prevents later teams from unknowingly undoing it.

A short document capturing one architectural decision: its context, the decision made, alternatives considered, and consequences. Records are immutable and dated, forming a history that explains why the architecture looks as it does.

The organised set of artefacts describing an architecture for its stakeholders, typically including views, building block descriptions, interfaces, cross-cutting concepts, decisions, and guidance for reading the documents.

The deliberate tailoring of architectural information to each audience, using appropriate views, notation, and level of detail so that stakeholders can understand, review, and act on the architecture.

A UML diagram type showing components, their provided and required interfaces, and dependencies between them. It is commonly used to document the building block view of a software architecture at a coarse granularity.

The ability to follow links between requirements, architectural decisions, building blocks, and tests in both directions. It supports impact analysis when requirements change and shows that each requirement is realised and verified.

Automated examination of source code or models without executing them, to detect violations of rules such as layering, dependency cycles, naming conventions, or complexity thresholds. It enforces architectural constraints continuously.

A practice in which developers merge changes frequently and each merge triggers automated build, test, and analysis steps. For architects it provides fast feedback on whether implemented structures still match the intended architecture.

An approach that treats architecture as something guided and continuously adapted through small, reversible steps and fitness functions, rather than fixed up front. It assumes requirements and technology will change during the system's life.

An automated, objective check that measures how well an architecture satisfies a chosen property, such as dependency rules or response time. Results guide evolution and make quality attributes continuously verifiable.