Validating AI-Generated Requirements

What AI-generated requirements get wrong

The syllabus opens this section with a list of inherent limitations that Requirements Engineers must recognise and address. AI may generate requirements that:

• Appear syntactically correct and follow established templates, but do not address genuine stakeholder desires and needs (CPRE principle 2).
• Are not grounded in the actual system context (CPRE principle 4).
• Lack the necessary precision and verifiability that characterise high-quality requirements, introducing ambiguities or incomplete specifications that violate fundamental quality criteria.
• Seem comprehensive but miss critical functional requirements, quality requirements or constraints.
• Propose solutions rather than capturing actual requirements, violating the Problem-Requirement-Solution principle (CPRE principle 5).

That list is worth reading twice, because every item describes a defect that is invisible to a formal review. Each of these requirements passes a template check. Each looks like the others in the specification. The syllabus's phrase for the overall effect is that AI outputs "may seem comprehensive but actually miss critical" elements — and seeming comprehensive is precisely what makes them dangerous.

The last item is the most characteristic. Asked for requirements, a model trained on vast quantities of technical writing will readily produce "The system shall use a message queue to handle booking requests." That is a solution. Nobody asked for a message queue; somebody asked not to lose bookings at busy times. A model has no reliable way to stay on the problem side of that line, because in its training data the two are thoroughly mixed.

Consistency

AI genuinely helps here. It can support Requirements Engineers in maintaining consistency across specifications and product backlogs by automatically detecting:

• Contradictions.
• Overlapping functionality.
• Terminology inconsistencies that emerge as work products evolve over time.

It can cross-reference requirements against established glossaries and identify where the same concept is described using different terms — supporting the consistent terminology essential for shared understanding (CPRE principle 3). It can also analyse dependencies among requirements and flag potential conflicts that might compromise the specification's overall coherence.

But the syllabus is precise about the limit: ensuring true consistency requires more than automated pattern matching. It demands an understanding of the underlying business logic, stakeholder priorities and system architecture.

So the Requirements Engineer must validate that AI-detected inconsistencies represent genuine problems rather than acceptable variations, and must ensure that AI-suggested consistency improvements align with project goals and do not inadvertently introduce new conflicts or compromise the adequacy of individual requirements.

That first obligation is worth stressing. Not every difference is a defect. Two requirements may describe overlapping behaviour deliberately, for different actors or in different contexts. An automated pass reports the overlap; only someone who knows why it exists can say whether it is a problem.

Value-orientation, adequacy and necessity

Validating AI-generated requirements demands rigorous assessment against the value-orientation principle (CPRE principle 1): each proposed requirement must contribute meaningfully to satisfying stakeholder desires and needs, rather than merely appearing reasonable in isolation.

"Appearing reasonable in isolation" is exactly what a well-formed generated requirement does. Read alone, it looks fine. The question is whether it earns its place.

Requirements Engineers must therefore evaluate whether AI-generated requirements are truly necessary by:

• Tracing them back to their stakeholder source.
• Verifying alignment with identified business objectives and user goals.

As with human-generated requirements, the focus should be on adequacy and necessity: checking that AI has not introduced requirements exceeding the actual scope of stakeholder needs or project constraints.

Note the syllabus's framing here — as for human-generated requirements. The criteria are not new. What is new is the volume: AI can generate more plausible requirements in an hour than a team can validate in a week, so the discipline that was always required now has to be applied at a scale that makes shortcuts tempting.

Abstraction level and level of detail

The Requirements Engineer must also assess whether AI-generated requirements fit within the chosen abstraction levels and are at an appropriate level of detail for the current project phase.

The purpose test applies: requirements must serve their intended purpose rather than creating unnecessary complexity or scope creep that could compromise project success.