Glossary

Acceptance criteria

The observation that settles whether a requirement passed. Without one, "done" is an opinion. 02

ADR (architecture decision record)

A short, versioned note recording a decision, its context, the alternatives rejected, and what would reopen it. 03

Allocation

Assigning each function to the physical element responsible for it. The mapping is a design decision, not bookkeeping. 03

Analysis (verification method)

Proving a requirement by calculation or modeling rather than by running the system. 07

Architecture

The expensive-to-reverse structure: major elements, their responsibilities, and how they interact. 03

Baseline

A frozen, approved version of requirements, design or code that changes only through change control.

Blue-green deployment

Two identical environments; traffic switches between them so a release can be reversed instantly. 09

Boundary

The line between what you design and what you design against. A choice, and a common source of expensive mistakes. 01

Bulkhead

Isolation of resources so one component or tenant consuming capacity cannot starve the rest. 06

Canary release

Sending a small slice of live traffic to a new version, then promoting or rolling back on measured evidence. 09

Circuit breaker

Stops calling a dependency after repeated failures, failing fast until a cool-down period passes. 06

Cohesion

How strongly the work inside one element belongs together. High cohesion makes change local. 03

Complicated vs complex

Complicated is knowable by analysis; complex is only explicable in hindsight and must be probed. 09

Configuration management

Knowing exactly what version of what is deployed, and controlling changes to it.

CONOPS (concept of operations)

How the system will be used in practice: actors, scenarios, sequence, environment. Often reveals needs the requirements missed.

Constraint

A non-negotiable boundary on the solution — law, budget, existing platform, physics. Constraints disqualify options; they don't trade off. 02

Coupling

The degree to which one element's changes force changes in another. Loose coupling localises failure and change. 04

Cynefin

A sense-making framework that sorts situations into clear, complicated, complex and chaotic, each with a matching response. 09

Demonstration (verification method)

Operating the system in front of a witness to show a behavior, without instrumented measurement. 07

Detection (FMEA)

How likely you are to catch a failure before the user notices, scored 1 (certain) to 10 (invisible). 06

Element

Any part that must exist for the purpose to be met: hardware, software, a person, a procedure. 01

Emergence

Behavior produced by interactions rather than by any single part — queueing, cascading failure, culture. 01

Environment

Everything outside the boundary that can affect the system or be affected by it.

Eval gate

An automated quality threshold a change must pass before being promoted — the model-era version of acceptance testing. 09

FMEA

Failure mode and effects analysis: enumerate how each element can fail, score severity, occurrence and detection, mitigate in priority order. 06

FTA

Fault tree analysis: work backwards from an undesired top event through AND/OR gates to the combinations of causes that produce it.

Functional architecture

What must happen, expressed as functions and flows, with no technology named. 03

Graceful degradation

Reducing capability deliberately under failure or load, instead of failing completely. 06

Guardrail

An automatic check on input or output that blocks, alters or escalates unsafe content. 09

Idempotency

The property that repeating an operation has the same effect as doing it once. The basis of safe retries. 04

Inspection (verification method)

Reading or examining an artefact against its specification, without executing it. 07

Interface

Everything that crosses a boundary — call, endpoint, message, file, handover — and the contract governing it. 04

Interface control document (ICD)

The written contract for one interface: content, format, timing, error behavior, owner, versioning.

Leverage point

A place in a system where a small change produces a large effect; Meadows ranks them from parameters up to paradigms. 09

Lifecycle

Concept, development, production, utilization, support, retirement — the whole life, not just the build. 08

Load shedding

Dropping low-priority work deliberately when overloaded, rather than degrading everything. 06

MBSE / SysML

Model-based systems engineering and its modeling language. Powerful at scale; unnecessary for a first one-pager.

N² matrix

A grid of system elements against themselves showing which pairs exchange what — the fastest way to find unowned coupling. 04

Occurrence (FMEA)

How often a failure cause is present, scored 1 to 10 from measured history.

Physical architecture

The real elements that will perform the functions: services, databases, devices, people. 03

Pugh matrix

A trade-study table scoring alternatives relative to a baseline as better, same or worse, weighted by criteria. 05

Reliability

How often the system works as specified. A prevention question. 06

Requirement

A statement of behavior or constraint the system must satisfy that can be verified. Uses "shall". 02

Resilience

The ability to absorb, adapt and recover from disturbance. A recovery question, not a prevention one. 06

Risk

A claim about consequence and likelihood, written down so it can be compared and mitigated. 06

RPN

Risk priority number: severity × occurrence × detection in FMEA, 1–1000. A sorting device, not a verdict. 06

Sensitivity analysis

Re-running a decision with different weights to check whether the conclusion survives. 05

Severity (FMEA)

How bad the consequence is, 1 to 10. 9–10 (safety, data loss, legal exposure) overrides the arithmetic. 06

Shall / should / may

Mandatory / preferred / optional. Precision here decides contract disputes.

Single point of failure

Anything whose loss stops the system — including people, keys, DNS and that one spreadsheet. 06

SLO / SLI

An objective (e.g. 99.9% availability) measured by an indicator (successful requests ÷ total).

Stakeholder

Anyone who affects or is affected by the system: users, operators, sponsors, regulators, maintainers.

Stakeholder need

An outcome a stakeholder wants, in their own language, before any solution is chosen. 02

System

A combination of interacting elements organized to achieve one or more stated purposes (ISO/IEC/IEEE 15288). 01

Technical debt

A decision that moved cost from development into support without a plan to repay it. 08

Test (verification method)

Execution under controlled conditions with measured results — the method for anything with a number. 07

Traceability

The link from need to requirement to design to evidence. Without it, change impact is guesswork. 07

Trade study

A structured comparison of alternatives against weighted criteria, documented with rationale. 05

Validation

Did we build the right thing — does it satisfy the need in real use? 07

Verification

Did we build it right — does it conform to the specified requirements? 07

V-model

A diagram pairing each decomposition level on the way down with its verification level on the way up. 07

15288

ISO/IEC/IEEE 15288: the international standard describing system life-cycle processes. A menu to tailor, not a mandate. 08

No terms match that search.