Want a brutally honest test for your requirements process before you build on a complex platform with ontology systems, or AI + workflow tools?
Don’t start with the factory. Start with dinner.
Dinner has everything real business operations have. Hard deadlines, hidden dependencies, missing ingredients, distractions, and people who expect to eat at 7:00 PM. If your model survives dinner, it can survive almost anything.
Here’s the dead-simple 6-phase framework I actually use (and teach teams) to turn fuzzy ideas into clean, buildable requirements, zero buzzwords, just clarity:
Phase 1: One Big Business Question. Define success in a single sentence. Dinner version: “Serve dinner by 7:00 PM with no forgotten steps and minimal chaos.” Can’t do it? Your scope is already leaking.
Phase 2: Supporting Questions (6 buckets only). Every requirement must fit one of these or it’s fluff:
• Identity – MealInstance vs RecipeTemplate? Can steps repeat?
• State – Meal: Planned / In Progress / Served / Failed Step: Not Started / Active / Blocked / Done
• Dependencies – Which steps must come before others? Which need the oven? Which consume ingredients?
• Actions – What starts the meal? What happens when an ingredient is missing?
• Functions – How do we calculate timing plans, critical path, ETA prediction, and late-risk score?
• Truth – Recipe estimate or real observed time? How do we adjust if the oven runs hot?
Phase 3: Turn talk into a real model. Nouns → Objects Relationships → Links Verbs → Actions Logic → Functions
(The attached image shows exactly this in action — a neural network feeding live ETA Prediction + Late Risk Score into the MealInstance.)
Phase 4: Define Lifecycles. Meal: Planned → In Progress → Served (or Failed) Step: Not Started → Active → Done (or Blocked)
Every action must actually change state. No vibes allowed.
Phase 5: Source of Truth rules. Be explicit: • Default duration → RecipeTemplate • Actual duration → Observed history (this always wins) • Oven bias → Learned from past runs
Simple rule: history beats the recipe. Flag crazy days (holiday chaos) as outliers.
Phase 6: Run one end-to-end scenario. Test it with reality: “7 PM target, missing ingredient at 6:40 PM.”
- Create MealInstance (targetServeTime = 7:00 PM)
- StartMeal → triggers computeTimingPlan (with neural ETA + risk score)
- Missing ingredient → MarkStepBlocked + impact calc
- SubstituteIngredient → update + auto-recalculate
- Finish → ServeMeal closes the loop
If the story flows without big “uh-oh” moments, your requirements are ready for the engineers.
This exact approach has saved me and every team I’ve worked with from building the wrong thing on Foundry-style platforms. It forces real clarity on objects, states, truth layers, and live ML predictions, the pieces that actually matter.
Try it on your next project. Start with dinner. You’ll be shocked how easy the factory work suddenly feels.
What’s the messiest requirements situation you’ve faced lately? Drop it in the comments or send me a direct message if you’d like help applying this framework to your own project. Happy to assist!