From Plain Words to Engineering Requirements
→ Try the app here: Open ReqAi
Just want the short version? Read the Quick Start
Before you start:
Thank you for taking the time to explore ReqAi. This article explains what the tool does, why it exists, and how to think about it while you try it out. Reading it before you open the app takes about five minutes and will make your session far more useful.
The problem ReqAi is built to solve
Every engineered product starts with someone describing what they want in ordinary language. A customer, a manager, or an end user says something like:
"The machine should heat up fast and make a proper cappuccino."
That sentence is clear to a human being. But it’s almost useless to an engineer.
What does "fast" mean - five seconds or five minutes? Fast from what starting point - cold, or already warm? What counts as "proper"? Which part of the machine is responsible? How would anyone ever test whether the requirement was met?
This gap between what a stakeholder says and what an engineer can actually build and verify is one of the oldest and most expensive problems in engineering. Requirements that are vague, ambiguous, or incomplete are a leading cause of project delays, cost overruns, and rework. Industry research consistently finds that projects with a disciplined requirements process are several times more likely to succeed than those relying on informal notes.
The discipline that addresses this is called requirements engineering, and it has a well-established standard: the way of writing requirements promoted by INCOSE (the International Council on Systems Engineering) and codified in ISO/IEC/IEEE 29148. A good system requirement is clear, measurable, testable, traceable, and written in a consistent structure such as:
"When [trigger], the [system element] shall [action] within [measurable criteria]."
Turning loose stakeholder language into requirements like this is skilled, careful, repetitive work. ReqAi exists to assist with exactly that transformation.
What ReqAi actually does
ReqAi takes a Stakeholder Requirement (StR), a natural-language statement of need, and helps an engineer turn it into one or more System Requirements (SyRs) that follow INCOSE-style structure and quality rules.
Crucially, it does this without pretending to know things it cannot know. This is the single most important idea in the tool, so it is worth stating plainly: ReqAi never invents engineering values.
If a stakeholder says "the water tank should be big enough," ReqAi will not silently decide the tank is 4 litres. Instead it flags the missing value as a TBR - To Be Resolved - and leaves the decision to the engineer. A polished sentence with a made-up number is worse than useless; it hides a decision that nobody actually made. ReqAi is designed to surface those decisions, not bury them.
Here is the workflow you will see in the app:
You enter a stakeholder requirement in plain language.
ReqAi checks its quality — flagging vague terms ("fast", "easy", "proper"), missing units, weak wording ("should" instead of "shall"), undefined triggers, and similar issues. These checks combine fixed rules, language analysis, and an AI layer.
ReqAi looks for similar requirements that have already been finalized, so you are not solving the same problem twice.
ReqAi drafts one or more system requirements, using the approved vocabulary of the product and a catalogue of recognised requirement-writing patterns.
ReqAi captures every unknown as a TBR, a temperature setpoint, a maximum time, a tank size, and asks you to resolve it.
You decide each value: approve it, propose it, defer it, or mark it not applicable.
ReqAi generates the final requirement together with fit criteria, the measurable conditions that say how the requirement will be verified.
The engineer stays in control at every step. ReqAi does the structuring, checking, and book-keeping. The human makes the engineering decisions.
Why a coffee machine?
When you open the app, the active project is a coffee machine. You might reasonably ask why a serious requirements tool is being demonstrated on something you find in an office kitchen.
The answer is that the coffee machine is one of the most respected teaching examples in systems engineering. It is not a toy. It is used as a worked example in the SEBoK (the official Systems Engineering Body of Knowledge), in SysML and MBSE textbooks, in the official tutorials of modelling tools such as Gaphor, in industrial PLC programming platforms such as CODESYS, and in conference presentations and academic papers on model-based systems engineering.
It earns this status because it is genuinely rich beneath a familiar surface. A coffee machine has:
measurable performance: brew temperature, pressure, extraction time, beverage volume;
real states and modes: idle, heating, brewing, cleaning, error;
triggers and events: beverage selected, water low, overheat detected;
safety concerns: overtemperature protection;
maintenance behaviour: cleaning and descaling cycles;
genuine configuration choices: reservoir or mains water, manual or automatic milk, button panel or touchscreen.
In other words, it exercises every part of the requirements workflow, while remaining something anyone can understand without domain training. That combination is exactly what makes it ideal for a mixed audience. You can focus on judging the tool, not on decoding the domain.
The scenario you are stepping into: BrewCraft Systems
To make things concrete, the app is framed around a fictional but realistic company.
BrewCraft Systems is a manufacturer of custom commercial coffee machines for business customers, offices, cafés, hotels, restaurants, and convenience stores. BrewCraft does not sell a single fixed product. Instead, it maintains a platform of capabilities, the full menu of everything its machines can do, and configures a specific machine for each customer based on that customer's needs.
This mirrors how real commercial coffee manufacturers such as WMF, Franke, Schaerer, and Jura actually operate.
Inside the app, this shows up as two layers:
The reference libraries describe the BrewCraft platform itself, its subsystems, vocabulary, units, states, triggers, and the full space of configurable parameters. These are customer-independent. A term like Brew_Temperature means the same thing for every customer.
The stakeholder requirements come from a specific customer and describe what that customer needs. They are messy, informal, and incomplete, exactly like real customer input.
For this round, the customer is Northwind Studio, a 20-person office whose facilities manager wants a machine for the team kitchen. Their requests sound like the things a non-technical person genuinely says: "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 statements like these into requirements an engineer could build from.
This is not really about coffee
Here is the part we most want you to keep in mind.
The coffee machine is a vehicle. The underlying problem, taking stakeholder needs in natural language and converting them into rigorous, verifiable system requirements, is universal. It is the same problem faced by any organisation that builds complex products to customer or stakeholder needs.
The industries that depend most heavily on this discipline include:
Automotive: where suppliers turn carmaker requests into system requirements under standards such as ASPICE and ISO 26262, with strict traceability from stakeholder to system requirement. This is the clearest near-term fit for a tool like ReqAi.
Aerospace and defence: where requirements must be traceable and verifiable under standards such as ARP4754A and DO-178C, and where a missed or ambiguous requirement can have severe consequences.
Medical devices: where requirements engineering under IEC 62304 and related standards is a regulatory necessity, not a nice-to-have.
Industrial machinery and automation: where machine builders configure products to each customer's process, much like BrewCraft does with coffee machines.
Anywhere a stakeholder says "I need it to be fast, reliable, and easy to use" and an engineer has to turn that into something buildable and testable, the ReqAi workflow applies.
Right now, only the coffee machine project is switched on, because it is the easiest way to understand and evaluate the tool. But the architecture is deliberately product-agnostic. The same workflow- quality checking, pattern-guided drafting, TBR capture, human resolution, fit-criteria generation- is designed to run on top of whatever reference library is loaded. Swap in an automotive braking subsystem or a medical infusion pump, and the tool works the same way. The coffee machine is simply the door we are asking you to walk through first.
How to get the most out of it
A few suggestions as you try the app:
Start by entering a vague requirement on purpose. Type something loose like "the machine should make good coffee quickly" and watch what the tool flags. Seeing it catch the ambiguity is the fastest way to understand its value.
Pay attention to the TBRs. When the tool refuses to invent a number and asks you instead, that is the tool working as intended, not failing. Ask yourself whether it caught the right unknowns.
Judge the drafts critically. Are the generated system requirements clear, measurable, and testable? Would an engineer be able to act on them? Where they fall short, that is exactly the feedback we need.
Think about your own domain. As you work through coffee-machine requirements, picture the equivalent in your field. Does the workflow transfer? Where would it need to change?
There are no wrong answers, and you cannot break anything. The most valuable thing you can give us is honest reaction — both where the tool helps and where it gets in your way.
In one sentence
ReqAi helps engineers turn messy human language into precise, verifiable requirements — without inventing the facts that only an engineer should decide — and although we are showing it to you through a coffee machine, the problem it solves belongs to every company that builds to stakeholder needs.
Ready to try it? Open ReqAi. Prefer the two-minute version? Read the Quick Start
Thank you for taking the time to explore ReqAi. We are looking forward to your feedback.
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.
