Requirements Engineering and AI: Where Automation Ends and Human Expertise Begins

The pressure on IT decision-makers to accelerate processes through the use of Artificial Intelligence (AI) is increasing. And indeed: Generative AI is already delivering measurable efficiency gains in coding or testing. However, caution is advised during perhaps the most critical phase of any digital project – Requirements Engineering (RE).

Data from the IBM Systems Sciences Institute illustrates a fundamental truth of software development that still holds in the AI era: The cost of fixing a defect increases by a factor of 100 if it is found after release, rather than during the design phase.

If we allow AI to write requirements unchecked, we may accelerate document creation but risk embedding errors exponentially faster into the foundation.

Efficiency is not the same as Effectiveness

Large Language Models (LLMs) are excellent tools for processing existing information. They can summarize minutes or syntactically smooth user stories. However, they often fail in context.

The Practical Example: Suppose you feed an AI with meeting notes for a new customer portal. The AI generates perfect user stories in seconds in the format: "As a customer, I want to download my invoice as a PDF to file it."

What the AI overlooks: It was mentioned in passing that the ERP system is maintained at night. A human engineer would have immediately derived a technical requirement ("Asynchronous processing") here. The AI often ignores this context. The result: A feature that works during the day but causes a system crash at night.

Limit 1: Implicit Knowledge (The Iceberg Effect)

AI models operate solely based on the data explicitly provided to them (prompts). In the practice of Requirements Engineering, however, what is not said is often crucial.

Scenario from Logistics: A company wants to digitize its inventory management. The warehouse manager explains the official process. The AI documents this 1

. What the warehouse manager doesn't say, because it's self-evident to him: If "rush order" is on the delivery note, the regular scanning process is bypassed, and the goods are taken directly to the ramp.

An experienced Requirements Engineer observes processes ("shadowing") and asks questions like: "What actually happens in exceptions?". He discovers this implicit knowledge. An AI cannot recognize these nuances.

Limit 2: Stakeholder Management and Diplomacy

Software development is rarely a purely technological problem but often an organizational one. The famous Chaos Report by the Standish Group consistently lists "incomplete requirements" and "lack of user involvement" as top reasons for IT project failures.

A Requirements Engineer acts here as a diplomat. He must uncover contradictions in goals.

The Conflict Case:

• Marketing Director: "The registration must work in one click without a password for maximum conversion."
• CISO (IT Security): "We absolutely need two-factor authentication and complex passwords."

If you feed both statements to an AI, it will either hallucinate, favor one side, or generate a contradictory text. It lacks political sensitivity. A human expert, on the other hand, moderates a workshop, weighs risks against business value, and works out a compromise (e.g., "Social login with risk-based authentication").

Limit 3: Strategic Validation and Liability

Gartner predicts in its Strategic Predictions that companies will increasingly build protective mechanisms against AI risks. Who is liable if an AI-generated requirement leaves security gaps?

The use of AI in RE necessarily requires a "Human-in-the-Loop" approach. The final approval of a requirement must be done by experts who understand the strategic implications. AI can suggest options, but the decision must lie with humans.