Architecture Atlassoftware · systems · evidence
Software · Systems · Quality · EvolutionView Markdown source

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.

Architecture AtlasIndependent study material · verify standards at their primary sources