Turn a requirement into a data model

Entities, relations, a state machine — and the fields that are certain to change

Turn this requirement into a data model; no code yet. Output: 1) the entity list, one sentence each on what it represents in the real world; 2) the relations between entities and their cardinality, flagging the many-to-many ones that need a join table; 3) the state machine of the core object (states, triggers, irreversible transitions); 4) the fields that look sufficient now but will probably change within six months (price, permissions, localization, soft delete); 5) three places where the requirement is unclear and product has to be asked first.

[paste the requirement]

How to use

Take the questions from item 5 straight to product. It is less work than modeling on a guess.

Good for

The requirement review just passed and you need table structure and blast radius before estimating.
You must decide whether this feature adds a field or a new entity, before someone has to split the table two months after launch.

Not for

The requirement is still 'roughly, a membership system': settle roles and flows first, or the model is built on air.
It is a one-off report or export: a temp table or view is enough; do not build a long-lived model.

Example

Input

Requirement: a user can book a service at a physical store. One booking covers 1-3 service items and may name a technician.
Free cancellation up to 24 hours ahead, 30% fee after that.
A store can close temporarily, and existing bookings must be cancelled and refunded automatically.

What you get

Produce seven entities — user, store, service_item, technician, booking, booking_item, payment/refund — and note that booking to service_item is many-to-many, needing booking_item with a price snapshot and the assigned technician. Write the 24-hour boundary and refund rate as transition conditions on pending, confirmed, completed, cancelled_by_user and cancelled_by_store, with cancelled irreversible. Finish with the fields that will change: price (snapshot), cancellation policy (per store or campaign), time zone.

Common mistakes

Giving one sentence of requirement and asking for DDL: it fills in rules you never stated and does not mark them as assumptions.
Taking the field list as the final schema, skipping who writes, who reads and who will change it.

Try tweaking it like this

Add 'list every assumption separately so I can confirm with product' and the output becomes a checklist instead of a model.
Add 'what if we need a chain of stores and technicians working across them in six months' to expose entity-boundary problems early.