← Summarising the development of a digital outcome

Choosing requirements worth writing about

The single biggest determinant of how high this summary can score is picking, in advance, requirements specific enough to argue a real trade-off about — not discovering this on the day.

What makes a requirement genuinely strong to write about

• It is SPECIFIC and TESTABLE — you can say clearly whether the finished outcome met it, ideally with a concrete detail (a measurement, a constraint, a named feature).
• It FORCED a real choice — two genuinely different ways to meet it existed, and choosing one meant giving something up. A requirement with only one obvious solution gives you nothing to argue.
• It connects to a NAMED person or group — the target audience, a specific user, a subject-matter expert — so the trade-off has a real stake, not an abstract one.
• You can point to a SPECIFIC feature or decision in your outcome as evidence it was met — not just describe the requirement in the abstract.

A quick self-check before committing to a requirement

• Could I have built this a genuinely DIFFERENT way? If not, there is no trade-off to argue.

Worked example Turning a vague requirement into a strong, arguable one A student's first draft requirement is "the app should be easy to use." Improve it into something worth a full trade-off discussion. VAGUE VERSION: "the app should be easy to use" — not testable, and does not force any real choice. STRONGER VERSION: "a first-time user must be able to book a session within three taps, without reading instructions" — specific, testable (you can check it), and tied to a named user group (first-time users). THE TRADE-OFF THIS UNLOCKS: fewer taps meant fewer configuration options shown up-front, so power users lost some flexibility — naming this trade-off is what turns a feature description into an argued requirement. EVIDENCE: a before/after screenshot of the booking flow, and a note from a test user who completed the three-tap flow unprompted. ✓ The improved version is testable, tied to a real user, and — critically — forced a genuine choice with a cost on the other side. That is what "worth writing about" means in practice. ✕

Choosing a requirement that was trivially easy to meet

A requirement with no real alternative approach and no cost to meeting it (e.g. "the outcome must have a title") gives the reflection nothing to discuss — there is no trade-off, no consideration, and no decision to evaluate. Choose requirements that made you choose BETWEEN options, not ones that were simply done.

Weak requirement	Stronger, arguable version
"It should look good"	"Must use the school's brand colours while remaining readable for colour-blind users"
"It should be fast"	"Must load in under 2 seconds on the library's older computers"
"It should work on phones"	"Must be fully usable on a 5-year-old phone with a small screen"

Practice for this standard covers the whole topic — flashcards and quiz.