Requirement Discovery

"Need checkout" is one requirement written down and a dozen hidden inside it. Discovery is asking "what if" of the sentence — payment fails, the user refreshes, the backend crashes after the charge, the product sells out — until the hidden ones have names and each can be tested.

A functional requirement says what the system does, for whom, with what observable result. "Manage orders" is not one; "an admin can change an order from paid to shipped and the customer is notified" is. The test is whether you could watch it happen.

Latency, security, availability, accessibility, cost, auditability, scale — the qualities of a system, each of which is a requirement only when it has a measurement and someone who cares about it. The skill is finding the ones this system actually has, and refusing the ones it does not.

Some requirements cannot be found by asking; they appear when the first slice runs and the code asks a question nobody had. That is not a failure of discovery — it is the other half of it — and the move is to notice the question, write it down as a requirement, and decide rather than improvise.

Build the sequence where everything goes right — cart, pay, order, confirmation — before any failure handling, because the happy path is the thing the failures are failures *of*. The order is contested: the failure-first camp has a real argument, and this lesson says where each wins.

With the happy path working, each discovered failure becomes an injection: break the provider, click twice, kill the process, sell the last unit — against real code — and watch what happens before deciding what should. Failure handling designed from observation, not from imagination.

A brief is defined as much by what it leaves out as by what it says. "Build a payment service" that never mentions currencies, refunds, idempotency, a provider or a ledger is not a short brief — it is a brief with five decisions hidden in it, and the strong learner asks before building.