Module 2: Start Here

Overview

Module 1 left you with a charter, a context diagram and a business-value brief. You know what the business wants moved and what you are accountable for. Nobody has yet told you what the system has to be like.

This module answers one question:

Which requirements actually shape the architecture, and how do I get them out of people who disagree with each other?

The uncomfortable part is the arithmetic of attention. A real initiative generates hundreds of requirements. A handful of them determine the structure. Those few are rarely the ones anyone volunteers — and missing one means rebuilding rather than patching.

How the module is built

Two sections. The first is requirements engineering as it has worked for thirty years, compressed to what an architect actually uses. The second is the part that did not exist before models went into production: a cost budget measured in tokens is a genuinely new kind of constraint, and so is an accuracy target.

graph TD
  subgraph S1["Section 1 — From stated wants to architectural requirements"]
    A["1 · Three kinds<br/>of requirement"]
    B["2 · Quality attribute<br/>scenarios"]
    C["3 · The Utility Tree"]
    D["4 · Eliciting from people<br/>who disagree"]
    A --> B --> C --> D
  end
  subgraph S2["Section 2 — Requirements for probabilistic systems"]
    E["5 · Intent formulation"]
    F["6 · Specifying<br/>probabilistic outcomes"]
    G["7 · Latency and<br/>perceived time"]
    H["8 · Cost as<br/>a requirement"]
    I["9 · Safety and<br/>alignment"]
    J["10 · The NFR budget"]
    E --> F --> G --> H --> I --> J
  end
  D ==> E
  J ==> K(["Workbook — Exercise 2"])

  classDef s1 fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef s2 fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cap fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A,B,C,D s1
  class E,F,G,H,I,J s2
  class K cap

The module’s path. Section 1 gives you the machinery; Section 2 points it at requirements that behave differently.

Section 1 — From stated wants to architectural requirements

Sort them → make them testable → prioritise them → get them out of people.

1. Three kinds of requirementFunctions, qualities, constraints — and which of them shape structure.

2. Quality attribute scenariosTurning 'it should be fast' into something you can test.

3. The Utility TreePrioritising by business value and architectural risk, and using it to say no.

4. Eliciting from people who disagreeInterview technique, and what to do when two requirements genuinely conflict.

Section 2 — Requirements for probabilistic systems

Five requirement types that behave unlike anything in Section 1, and what happens when they collide.

5. Intent formulationSpecifying behaviour you cannot enumerate, and where a spec ends and an eval begins.

6. Specifying probabilistic outcomesAccuracy targets, confidence thresholds, and acceptable failure rates.

7. Latency and perceived timeWhy streaming changes which number you put in the requirement.

8. Cost as a requirementToken economics as a hard architectural budget, derived arithmetically.

9. Safety and alignmentWriting injection resistance and output boundaries as requirements, not intentions.

10. The NFR budgetAccuracy, latency and cost pull against each other. Pick a corner.

How to work this module

About six hours, split evenly:

1. Read the ten topics — about 3 hours. Section 2 is where the unfamiliar material is; do not skim it because the vocabulary looks easy.

2. Optional — Workbook exercise 2 — about 3 hours. Four artifacts, and one of them is arithmetic you cannot fake.

This module’s workbook exercise is the heaviest so far, and for a reason: every later module scores its decisions against the requirements you write here. A vague catalog now produces an architecture that satisfies nothing in particular in Module 3.

In the workbook

Four artifacts for Lintel:

• A requirements catalog — functions, qualities and constraints, sorted
• An ASR list — each with a stated reason it is architecturally significant
• A Utility Tree — prioritised by business value and architectural risk
• An NFR budget — accuracy, latency, cost and residency, with numbers

Before you start

You need Module 1’s business-value brief in front of you. Requirements are derived from drivers, and the chain in Why the job exists runs one way only. If your brief has no numbers in it, fix that before starting here.

Requirements elicitation is not re-taught from scratch. If you have run a discovery workshop, that experience transfers. What this module adds is the architect’s filter: which of the things people tell you will cost you a rebuild if you get them wrong.

Check your understanding

Write down your answers now and revisit them at the end of the module.

1. Think of a system you have worked on. Name one requirement that, had it arrived six months later, would have forced a restructure rather than a patch.
2. “The system should be fast.” What would you need to add to make that testable?
3. If a component is correct 92% of the time, who in your organisation should decide whether that is acceptable?

→ Start with Three kinds of requirement.