Challenges

01Teardown a system you use

Time: 30 minutes · Needs: paper · You produce: a one-page system definition

Choose something familiar — a bike-share scheme, your company's onboarding, a checkout flow, a home heating system. Write:

• Purpose in one testable sentence (with a number or an observable outcome).
• Boundary: what's inside, what you design against.
• Five to seven elements, including at least one human and one procedure.
• Every interface you can find between them — including the informal ones.
• One emergent failure: a bad behavior that no single element is responsible for.

• My purpose sentence contains a number or observable outcome
• I named at least two things deliberately left outside the boundary
• At least one element is a person and one is a procedure
• My emergent failure can't be blamed on one element

02Rewrite five requirements

Time: 30 minutes · Needs: a real spec, ticket or README · You produce: five testable statements

Take five requirements, stories or "must-haves" from work. For each: mark the disease (vague, compound, solution-in-requirement, unverifiable, unnecessary), then rewrite it with a number, a condition and an acceptance method.

• Every rewrite has an acceptance method
• No rewrite contains "and" joining two behaviors
• Each rewrite traces back to a stated need
• I removed every "fast", "easy", "robust", "user-friendly"

03Audit the interfaces

Time: 45 minutes · Needs: a whiteboard or spreadsheet · You produce: an N² matrix plus one written contract

List the five or six major parts of a system you work on. Build the matrix: rows send to columns. Mark each cell sync, async, or blank. Then find:

• The coupling with no clear owner.
• The one where a change would require coordinated releases.
• The shared database or shared file everyone pretends isn't an interface.

Write the contract for the worst one: content, timing, failure behavior, owner, versioning rule.

• The matrix covers every pair, including blanks
• I found at least one interface with no owner
• My written contract describes error behavior and retry safety
• It says how the contract may change without breaking callers

04Run a trade study

Time: 45 minutes · Needs: a spreadsheet · You produce: a decision you can defend

Pick a decision you're actually facing with 2–4 real alternatives — a vendor, a queue, a hosting choice, a build-vs-buy. Define criteria, agree weights before scoring, score relative to a baseline, and compute the totals.

Then do the two things people skip: sensitivity (change one weight by ±2; does the winner change?) and disqualifiers (is any criterion actually pass/fail rather than a tradeoff?).

• Weights were agreed before any scoring
• Every score has a source: benchmark, quote, or spike
• I ran a sensitivity check and wrote down the result
• I wrote the condition that would reopen the decision

05Capstone: one page, one vertical slice

Time: one weekend · Needs: a real system · You produce: the one-pager plus proof of one requirement

Fill the one-page definition from module 10 for something you are actually responsible for. Then build one requirement end to end — including how it is verified — so the page has evidence behind at least one line.

• Eight headings complete: purpose, boundary, elements, interfaces, requirements, risks, V&V, lifecycle.
• Every requirement has an acceptance method.
• Top five risks have an owner and a mitigation.
• One requirement demonstrated or tested, with the result recorded.
• One sentence about retirement: how data leaves and what switches off.

• The one-pager fits on one page
• No requirement is missing an acceptance method
• Every top-five risk has a named owner
• At least one requirement has real evidence, not a plan
• I wrote the retirement sentence