Clarifying Questions That Change the Design

Foundations

In the first lesson, the verbs and qualities were handed over complete. Now, what if the prompt is two sentences long, and most of the requirements are still unasked questions?

Ask in order of consequence. A question is worth asking early when its answer adds or removes a component: what happens when the receiver is offline, how long data is kept, how many receivers one action can reach. Questions about wording, colors, or minor options change nothing in the diagram, so they wait. Record each answer as a numbered rule.

Take a service that relays a message from one user to another. Asking about offline receivers adds a durable store, since a message must wait somewhere. Asking about retention sizes that store, such as one year of messages. Asking about the largest audience for one message adds a fanout step if the answer is 500. Three answers, three architectural changes.

• Requirements

  Estimates and APIs start from an agreed list of what the system must do.

  Open lesson

Case Scenario

To see how a few questions reshape a design, consider a chat app like WhatsApp: two people exchange messages that must arrive while both are online and still be there tomorrow. Whether the recipient can be offline decides the message log, how long history is kept sizes it, and whether a group can hold 500 people decides fanout.

Two people chatting while online is easy to describe; tomorrow and group chat expose the missing promises. “Still be there tomorrow” needs a retention rule, an offline Bob needs a delivery rule, and a 500-person group changes the work behind one send. The scoped design must promise offline delivery and one year of history while stating whether 500-member groups are in scope.