Skip to content

Exercise 2: From Business Need to Requirement

Four artifacts for Lintel, about three hours of work. They are the most load-bearing documents in Part 1: Exercise 3 selects an architectural style by scoring options against the ASRs you write here, and Exercises 4, 5 and 6 all score their decisions against this NFR budget.

A vague catalog now produces a design in Exercise 3 that satisfies nothing in particular. That is the honest reason this exercise is longer than the first.

In order. The ASR list depends on the catalog, the tree depends on the ASR list, and the budget is where the three-way tension becomes unavoidable.

  1. Requirements catalog — ~40 min

  2. ASR list with justification — ~30 min

  3. Utility Tree — ~40 min

  4. NFR budget — ~50 min

  5. Self-check — six pass/fail items

Keep Exercise 1’s business-value brief open throughout. Every requirement here should be traceable back to a driver in it; anything that is not traceable is either a requirement you invented or a driver your brief missed.


Two to four pages, or a table. Everything you can derive from the case, sorted into functional requirements, quality attributes and constraints.

Cover:

  • The functions, briefly. These are the least interesting part of the document and should look like it.
  • The quality attributes, each with a one-line statement of what the business cares about — not yet a full scenario.
  • The constraints, stated as constraints. Residency, SOC 2, the personal data in tickets, the two-quarter commitment. If you find yourself writing a target next to one, you have misfiled it.
  • An intent statement for the assistant: what good looks like, what it must refuse, what it must escalate, what is out of scope for release one.
  • A conflict register — at least two genuine conflicts, with who holds each side and who decides. Not resolved by you.
  • Your assumptions. Anything the case does not state and you needed. Label them.

The test: a reader should be able to tell, for every item, whether it is negotiable.


Artifact 2 — ASR list with justification

Section titled “Artifact 2 — ASR list with justification”

One page. The subset that will shape the structure, each with the reason it qualifies.

Expect somewhere between six and twelve. If you have thirty, you have copied the catalog; if you have three, you have missed the constraints.

For each: the requirement, and one sentence on why it is architecturally significant — which of the three tests it passes. “Forces a decision about where inference runs” is a reason. “Important to the business” is not; that is a value rating, and it belongs on the tree.

Write a six-part scenario for each ASR. Vary the environments deliberately — if every scenario says “normal operation”, you have specified the case that was never going to hurt you.


One diagram or one indented list. Root, quality attributes, refinements, scenarios at the leaves, each leaf rated (business value, architectural risk).

Rules that make it worth having:

  • Value ratings come from the stakeholders, in their terms. If you rated everything yourself, say so and mark it as unvalidated.
  • At least two different stakeholders’ priorities must appear, including the compliance constraints that can block you outright.
  • At least one leaf should be rated low value, high risk — and then explicitly not built. If you cannot find one, you are probably not being honest about something architecturally interesting that nobody asked for.
  • Date it. It is a snapshot of month one.

One table plus two sentences. The artifact Exercise 3 will hold you to.

Required rows: accuracy floor, confident-error ceiling, unnecessary-handoff ceiling, p95 streamed latency with its timeout and fallback, cost per interaction at p50 and p95, a monthly ceiling with degradation behaviour, and a refusal-rate ceiling.

Required columns: target, how it is measured, owner, and the give — what degrades when the system cannot satisfy everything at once.

The two sentences:

  1. The ordering. When accuracy, cost and latency collide, which wins. Justify it in one clause.
  2. The constraints bounding the table — listed separately, with no targets beside them, because they are not trades.

And do the cost arithmetic properly. Start from $6.40 → $3.00 and ~12,000 tickets a month, test whether the target as stated survives, and write down what you find even if the answer is that it does not. Show the working.


Pass or fail. Resist “sort of”.

  • Every ASR has a stated reason it is architecturally significant. A reason, not a value rating.
  • Scenarios have measurable response measures, not adjectives. Every one has a number and a percentile or a rate.
  • At least two requirements genuinely conflict, and the conflict is named rather than smoothed over. With a named decision-maker, who is not you.
  • The cost NFR is derived arithmetically from the $6.40 → $3.00 business driver. The working is visible and the assumptions are labelled.
  • At least three AI-specific NFRs appear that would not exist in a deterministic system. Confident-error ceiling, cost per interaction, confidence threshold, refusal rate, regression trigger — any three, but one must be the regression trigger: Exercise 6 tests it against the eval set’s noise floor, and Exercise 10 asks you to reconcile the result.
  • The tree reflects at least two different stakeholders’ priorities, including Lena’s blocking constraints.

The two that fail most often are the conflict and the arithmetic.

If no two requirements conflict, you have interviewed a committee that agrees — which does not exist in this case. Go back to the cast: the CFO’s cost ceiling and the support sponsor’s accuracy floor pull against each other mechanically, and the product deadline pulls against the compliance boundary. Those are in the facts, not in your interpretation of them.

If the arithmetic came out comfortable, check the denominator. The company-wide $3.00 target does not survive a 38% deflectable share, and a cost requirement that does not notice this will mislead every module after it. Finding the target unreachable is a pass, not a fail — provided you wrote down what you would put in front of the CFO instead.


→ The requirements are testable and the conflicts named. Next, a structure that satisfies them. — Exercise 3, after reading Handbook Module 3.