See It Work: Stakeholder Words In, System Requirements Out
ReqAi: Quick Start
A two-minute read before you begin. A longer version is available if you want the full background
→ Try the app here: link to the app
Want the full story first? Read the full explanation
What ReqAi does:
Every product starts as someone describing what they want in plain language: "the machine should heat up fast and make a proper cappuccino." Clear to a human, unusable to an engineer: what does "fast" mean, from what starting point, and how would you ever test it?
ReqAi helps close that gap. It takes a Stakeholder Requirement (StR), a natural-language statement of need, and helps an engineer turn it into a structured, testable System Requirement (SyR) in the INCOSE style:
"When [trigger], the [system element] shall [action] within [measurable criteria]."
The one idea to remember: ReqAi never invents engineering values. If a stakeholder says "the tank should be big enough," the tool will not quietly decide it is 4 litres. It flags the missing value as a TBR - To Be Resolved, and leaves the decision to you. Surfacing unknowns instead of hiding them is the whole point.
The scenario you are stepping into:
The active project is a coffee machine, a familiar object that is, surprisingly, one of the most respected teaching examples in systems engineering. It is simple enough for anyone to follow, yet rich enough to exercise temperature, pressure, timing, states, safety, and maintenance.
You are working for BrewCraft Systems, a fictional manufacturer of custom commercial coffee machines. BrewCraft maintains a platform of everything its machines can do, and configures a specific machine for each customer.
One such customer has just got in touch. Northwind Studio, a 20-person office, is looking for a coffee machine for their team kitchen and has sent across a list of what they want. The requests come from their facilities manager, a non-technical person, and sound like the things anyone would say: "it should heat up fast," "it has to be easy to use," "the coffee should be hot but not scalding." Your job, with ReqAi's help, is to turn requests like these into requirements an engineer could actually build from.
How to start (try this first)
Enter a deliberately vague requirement, for example: "the machine should make good coffee quickly."
Watch ReqAi flag the problems: vague terms, missing units, undefined triggers.
Review the system requirement it drafts, and the TBRs it raises for the unknown values.
Resolve each TBR, approve, propose, defer, or mark not applicable, then generate the final requirement and its fit criteria.
When the tool refuses to guess a number and asks you instead, that is it working correctly, not failing.
Why this matters beyond coffee
The coffee machine is just the door we are asking you to walk through first. The real problem- turning stakeholder language into rigorous, verifiable requirements- belongs to every company that builds complex products to stakeholder needs: automotive, aerospace and defence, medical devices, industrial machinery, and more. The same workflow runs on top of whatever product library is loaded; today, that’s a coffee machine.
What we need from you
Be critical. Are the drafted requirements clear, measurable, and testable? Did the tool catch the right unknowns? Where does it help, and where does it get in your way? Honest reaction - good and bad- is the most useful thing you can give us.
You cannot break anything. When you are done, please leave your feedback in the form provided; it only takes a few minutes, and every response genuinely shapes where this goes next.
Ready? Open the app and try it.
Curious about the why? Read the full explanation
Thank you for taking the time to explore ReqAi.
A quick note: I used Claude to help with the flow and structure of this post. But every idea here is mine, and I read (and meant) every word.
