AI-Assisted Requirements - AI Can Produce the Answer Before You Have Decided the Question
Delivery Is Often Where Upstream Problems Become Visible
A delivery team receives a feature. The requirement looks reasonably complete. It has been estimated, prioritized and allocated to a sprint or release.
Then implementation starts.
The architect identifies an unresolved integration choice. The developer discovers that two business rules contradict each other. The product owner needs clarification from another business area. The data needed by the feature has no agreed owner. A question goes back upstream, another meeting is scheduled, and the work begins to wait.
The feature was planned. It was not ready.
This happens repeatedly in large transformations because work is often allowed to enter execution before the uncertainty surrounding it has been reduced sufficiently. The consequences appear downstream as delay, rework, design changes and coordination problems, even though their structural origin lies upstream.
Requirements engineering has long treated requirements as something that must be elicited, analyzed, specified and validated rather than merely written down. [1] In a complex transformation, however, these activities are spread across product management, business owners, architecture, program governance, vendors and delivery teams. The work can therefore appear complete administratively while remaining structurally unresolved.
That makes upstream refinement one of the most important places to improve transformation flow.
The Cheapest Time to Change the Work
Before implementation begins, most transformation work is still relatively easy to reshape. A requirement can be challenged. An architectural alternative can be explored. A dependency can be removed. A business rule can be clarified. Two overlapping features can become one.
After implementation begins, each decision starts accumulating structure around it.
Data models are created. Interfaces are specified. Software is configured. Contracts are agreed. Teams build dependencies on each other's solutions. Business stakeholders begin preparing for the expected result.
The same unanswered question therefore becomes more expensive with time. This is why upstream refinement is a leverage point. Systems thinking describes leverage points as locations where an intervention can have disproportionately large effects on system behaviour. [2]
In transformation, removing an ambiguity before it generates architecture, code and organizational commitments can eliminate a chain of downstream activity. The purpose is not to specify everything before execution. That would replace one illusion with another. Complex transformation always contains uncertainty. The purpose is to distinguish uncertainty that can safely travel with the work from uncertainty that must be resolved before the work moves.
That is what I think of as the horizon: the part of the transformation where future work is visible but still shapable.
Refinement Is More Than Writing Requirements
Weak refinement is often answered with more refinement activity. More workshops. Longer requirements. More acceptance criteria. Additional backlog sessions. More people reviewing the same material.
But more information is not necessarily more clarity.
Imagine that a business feature depends on one unanswered question: whether pricing will be centrally standardized or remain market-specific. Fifty detailed requirements can be written underneath that feature, but all fifty may still depend on the unanswered decision.
The volume of documentation has increased. Readiness has not.
Good upstream refinement therefore needs to convert intent into structure. The business purpose must become explicit. Assumptions must become visible. Dependencies need to be identified. Architectural implications need to be understood. Unknowns must either be resolved or consciously carried forward. Decision ownership must be clear.
This is where concepts such as Quantum Work and Phase Contracts become important. Work should not cross into another state simply because a planning date has arrived. It should cross when the structural conditions required by the next state have been satisfied.
The question changes from:
“When can development start?”
to:
“What must be true before development should start?”
That difference sounds small. In large transformations, it is enormous.
AI-Assisted Requirements Changes What Is Possible Upstream
Historically, thorough refinement has been expensive because it consumes expert attention. A major transformation may contain thousands of backlog items and enormous volumes of supporting material: process descriptions, architecture documents, business rules, meeting notes, regulations, contracts, customer requirements, decisions, risks, legacy documentation and data definitions.
No architect, product owner or program manager can continuously compare all of it.
AI changes that constraint.
Research into large language models and requirements engineering already describes applications across requirements elicitation, analysis, specification, validation and quality assurance. [3] Systems can review technical documents, compare requirements, generate candidate specifications and help identify inconsistencies or missing information.
Applied to transformation work, the possibilities are considerable.
An AI-Assisted Requirements and refinement system can compare a new business feature with hundreds of existing requirements and surface overlap. It can identify two documents that define the same business rule differently. It can examine a proposed solution against architectural principles and highlight potential conflicts. It can turn workshop notes into candidate requirements and open questions. It can inspect a portfolio and identify features repeatedly depending on the same unresolved decision.
The real value is not simply that AI writes faster.
The important change is that refinement capacity becomes dramatically cheaper.
Much more future work can be inspected before it becomes committed work. Human experts can spend less time searching, copying, summarizing and manually comparing information and more time dealing with the decisions that actually require their expertise.
That is where AI becomes interesting for transformation management.
AI Can Also Industrialize Ambiguity
There is, however, a dangerous property of generative AI: it can make incomplete thinking look remarkably complete.
Give an AI a vague requirement and it can produce ten detailed requirements.
Give it an uncertain architecture and it can produce a convincing solution design.
Give it a loosely described business process and it can construct an impressive process model.
The output can look more mature than the thinking underneath it.
Research into generative AI for requirements engineering shows exactly this tension. AI has substantial potential, while hallucinations, reproducibility, interpretability and validation remain significant issues. [4]
NIST's guidance on generative AI likewise emphasizes the need to manage the risks surrounding generated information rather than assuming that fluent output is trustworthy output. [5]
But there is an even more fundamental limitation in transformation work. AI cannot authoritatively decide something the organization itself has not decided. It can identify that two divisions define a customer differently. It cannot decide which division has the right to establish the enterprise definition.
It can describe three architectural alternatives. It cannot decide which business trade-off leadership is willing to accept. It can identify that five features depend on an unresolved pricing principle. It cannot create legitimate ownership of that decision.
AI can help formulate the question. It can analyze the evidence. It can propose alternatives and consequences.
The decision still belongs to the organization.
Structure First, AI Second
This is where the use of AI becomes inseparable from transformation structure. If AI is applied to an unstructured backlog, it can generate a larger unstructured backlog. If the organization has no explicit definition of readiness, AI can create beautiful readiness documents without knowing whether the work is actually ready. If work types are unclear, AI can decompose a requirement into dozens of smaller items without knowing whether that decomposition improves flow. If decision rights are unclear, AI can repeatedly identify the same unresolved issue without being able to close it.
In that environment AI does not eliminate transformation noise. It can multiply it.
A structurally defined transformation system gives AI something very different to work with. Quantum Work provides identifiable units. States make progress explicit. Phase Contracts define the conditions for movement. Transformation Patterns provide recognizable system behaviours. Architecture, dependencies, evidence and decisions can be connected to the work they constrain.
AI can then ask useful questions: What evidence is missing?
Which assumption remains unresolved?
Which other features depend on this decision?
Does this requirement contradict an existing rule?
Which Phase Contract condition has not been satisfied?
Where has a similar pattern occurred before?
That is a much more powerful role than generating another requirements document.
Human Expertise Moves to the Decisions
The most interesting consequence may therefore be a change in where human expertise is used.
Today, senior expertise is frequently pulled into transformation work too late.
Architects become heavily involved when implementation encounters a design problem. Business leaders are asked to make scope decisions after development has started. Data owners appear when integrations expose incompatible definitions. Operational stakeholders discover consequences during rollout. The knowledge existed upstream. The system simply did not request it until downstream work forced the question.
AI-assisted refinement creates an opportunity to reverse that flow. AI can continuously inspect future work and direct attention toward the smaller number of issues requiring human judgment. Instead of asking an architect to read hundreds of features, the system can surface the ten whose assumptions conflict with architecture. Instead of requiring a product owner to manually compare requirements, it can identify likely contradictions. Instead of waiting for three teams to discover the same missing decision independently, the common dependency can be exposed before any of them begin.
Human expertise is not removed. It is moved toward the part of the system where it creates the greatest effect.
The AI Advantage Is Before the Work Becomes Expensive
A great deal of transformation improvement has focused on execution: Agile delivery, automation, DevOps, deployment frequency, team collaboration and planning methods. All of those matter.
But a very fast delivery system processing poorly shaped work still produces rework very efficiently.
The larger opportunity may therefore sit before execution.
AI gives organizations an unprecedented ability to examine work while that work is still on the horizon: to compare information, identify gaps, expose dependencies, formulate questions and challenge assumptions before expensive commitments accumulate around them.
Used this way, AI becomes a force multiplier for human judgment.
Used without structure, it can become a force multiplier for ambiguity.
The sequence therefore matters:
Structure first. AI second. Judgment throughout.
The objective is not to let AI decide the transformation. It is to use AI to make the transformation clearer at the point where clarity is still inexpensive.
That may ultimately be the most valuable place for artificial intelligence in transformation management.
References
ISO/IEC/IEEE — ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering.
Why it matters: The standard establishes requirements engineering as a lifecycle discipline involving the creation and management of structured requirements information rather than simply documenting requests.
Donella H. Meadows — Leverage Points: Places to Intervene in a System.
Why it matters: Meadows' work provides the systems-thinking basis for understanding why intervening at certain places in a system can have disproportionately large effects on downstream behaviour.
Arshia Hemmat, Mohammadreza Sharbaf, Shekoufeh Kolahdouz-Rahimi, Kevin Lano and Sobhan Y. Tehrani — Research directions for using LLM in software requirement engineering: a systematic review.
Link: https://www.frontiersin.org/journals/computer-science/articles/10.3389/fcomp.2025.1519437/full
Why it matters: The review documents how LLMs are already being explored for requirements elicitation, analysis, specification and validation while identifying continuing challenges around context, accuracy and validation.
Cheng et al. — Generative AI for Requirements Engineering: A Systematic Literature Review.
Why it matters: This systematic review provides evidence of both the potential and current limitations of generative AI in requirements engineering, including hallucination, reproducibility, interpretability and still-limited production adoption.
National Institute of Standards and Technology — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
Why it matters: NIST provides a useful reference for understanding why generative output needs governance, evaluation and risk controls rather than being treated automatically as authoritative information.
Tags:
Comments