Why requirements engineering matters more in the age of AI

Q Lab Academy opened its doors this year: a Kuala Lumpur training practice for software quality, built around two international certification families: IREB’s CPRE for requirements engineering and the TMMi pathway for test maturity. Every course is taught by practitioners who have done the work, in sessions capped at ten.

For our first post, we want to answer the question we hear most from engineering leaders: if AI now writes much of the code, why would I invest in requirements training? Our answer: because of AI, not despite it.

The bottleneck has moved

For most of software history, building was the expensive part. Deciding what to build was a meeting; making it real was months of engineering. Code-generation tools have upended that ratio. A capable team with modern assistants can produce a working implementation in days. What they cannot compress is the thinking that precedes it: whose problem is being solved, what the system must do, what “done” actually means.

The constraint has moved upstream. When implementation is cheap, the quality of the specification becomes the quality of the product.

Ambiguity now ships at machine speed

Barry Boehm showed in 1981 that a requirements defect costs roughly ten times more to fix in design and a hundred times more in production. Four decades on, nothing has contradicted the curve, but AI has steepened it. A misread requirement used to crawl through a sprint before it became code. Now it becomes code in an afternoon, passes its own generated tests, and reaches production while the misunderstanding is still fresh.

Language models do not resolve ambiguity; they paper over it. Given a vague prompt, they will confidently fill the gaps with assumptions: plausible, fluent, and frequently wrong. “The model will infer what we meant” is not a strategy. It is a defect generator with excellent grammar.

Prompting is specification

Look closely at what effective teams feed their AI tools: context, constraints, examples, acceptance criteria, edge cases. That is a requirements document. The craft of writing it, eliciting what stakeholders cannot articulate, resolving the conflicts between them, validating the result against actual needs, is requirements engineering. It has been a codified discipline for forty years; the industry has simply started calling parts of it “prompt engineering”.

The engineers who thrive alongside AI will be the ones who can ask precisely. The ones who can find the requirement nobody stated, write it so a machine cannot misread it, and check the output against the need rather than the prompt.

Testing the torrent

The same shift hits quality assurance. When code arrives faster, undisciplined testing becomes the new bottleneck, or worse, a rubber stamp. Test maturity frameworks like TMMi matter more in AI-assisted delivery, not less: they give organisations a way to measure whether their testing actually keeps pace with their throughput, and a structured path to improve it.

Where Q Lab fits

This is the gap Q Lab trains for. CPRE Foundation gives you the vocabulary and the toolkit. Requirements Elicitation Practitioner goes deep on finding what nobody states. RE@Agile applies it inside a sprint cadence, and TMMi Professional covers the testing side of the equation. All public sessions are HRD Corp claimable and capped at ten participants.

If you want a taste before committing, our free one-hour webinars run monthly from August. The first is literally titled “The Cost of Confusion”. Or browse the training calendar and pick a date.

The machines are getting very good at building. Someone still has to be very good at asking. That is the skill we teach.