Introduction to the problem
The gap between "request a feature" and "solve a business problem" starts with requirements engineering. How often have you run a prompt in your go-to AI tool and the output was not what you expected? At work, the same pattern appears when a vague request enters the pipeline: the team executes, questions pile up, the cycle repeats, and delivery is late — or wrong for the business.
This article uses 90% as editorial hyperbole, not as a precise statistic for your next project. Classic software failure research — including Standish Group CHAOS reports — repeatedly cites poorly defined, incomplete, or unstable requirements among the top reasons projects fail or overrun. On regulated platforms, the cost is not only delay: rework, audits, and reputational risk.
An exaggerated analogy: you are head chef and the kitchen is chaos. The waiter rushes in: "the customer ordered pasta!" You, trained in Italy, make impeccable carbonara. The waiter returns: "they wanted glass-noodle salad." That restaurant is much of an industry that calls itself agile but operates in Go Horse mode when the order does not describe the problem.
Requirements engineering
Some definitions from the literature:
"The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed." — Ian Sommerville
That alone would have recorded at least that the "pasta" was rice noodles, not wheat.
"Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing the need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing requirements as they are transformed into an operational system." — Roger Pressman
Klaus Pohl frames it as information transformation:
- Vague wishes into explicit requirements;
- Informal language into formal models;
- Individual views into shared agreement among stakeholders.
There is an international standard: ISO/IEC/IEEE 29148. Use the standard or the authors' work to go deeper — I do not repeat the full academic treatment here.
The parallel with your prompt
If you use AI in the development cycle, your prompt is a partial materialization of requirements engineering. A weak process produces weak prompts; a solid process reduces — without eliminating — delivery surprise.
Files like AGENTS.md and SKILLS.md embed part of that discipline in the repo: context, constraints, and acceptance criteria before code generation.
In GitHub Copilot (Ask, Plan, Agent in VS Code), the parallel is direct:
- Ask — understand context and the problem in the codebase;
- Plan — structure the change with clear criteria;
- Agent — execute and validate against what was agreed.
Leaders in fintech or regulated domains already do versions of this in RFCs, ADRs, and backlog review. AI simply made the gap visible for teams that skipped the step.
Reflection
If you have been in software for a while, you have heard about requirements — but little time is reserved to practice them rigorously. AI made the topic unavoidable: older models already existed for fraud and scoring; LLMs generalized text and code generation beyond engineering.
Even without AI in your daily flow, it is worth asking whether scope incidents, rework, and "that is not what we meant" are, at root, missing requirements engineering — the discipline that separates vague orders from decisions the business can defend.