---
title: "Stakeholders, requirements, constraints, assumptions, and risks"
chapter: "03"
---

# Stakeholders, requirements, constraints, assumptions, and risks

Architecture begins by turning conflicting stakeholder concerns into explicit, prioritized forces. Functional requirements describe behavior; quality requirements describe how well; constraints restrict the option space; assumptions need validation; risks combine uncertainty with impact.

## Core ideas and patterns

| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| **Stakeholder map** | Identifies affected people and decision authority | Loud stakeholders can hide operators and end users |
| **Functional requirement** | Describes observable capability | Feature lists do not expose system qualities |
| **Constraint** | Marks a non-negotiable limit | Treating preference as constraint blocks better options |
| **Assumption** | Makes uncertain beliefs testable | Untracked assumptions silently become design facts |
| **Risk** | Prioritizes uncertainty by likelihood and impact | A risk register without owners and actions is theatre |
| **Non-goal** | Prevents accidental scope expansion | Must be revisited when context changes |
| **Acceptance criterion** | Defines observable success | Implementation-shaped criteria can prescribe the wrong solution |

## How to apply it

Interview users, operators, security, data owners, compliance, finance, support, delivery teams, and external partners. Rewrite wishes as scenarios with stimulus, environment, artifact, response, and measure. Separate must, should, could, and will-not. Give every constraint a source and expiry/review condition.

## Evidence, not opinion

Maintain a trace from concern to scenario, decision, implementation owner, test, telemetry, and review date. For the top assumptions, run spikes, load tests, supplier checks, or prototypes before committing.

## Small example

“Must use Kafka” is usually a proposed solution. “Orders must survive a regional interruption with no duplicate fulfillment and recover within 15 minutes” is an architectural requirement that allows options.

## Feynman check

Explain the design to a new engineer without using the pattern names. State the
problem, the forces that conflict, the chosen boundary or mechanism, what can
fail, and the evidence that would prove the choice still works.