Requirements in the Age of AI

Where AI Changes the Game

AI is not a future possibility for requirements engineering — it is a current capability that is changing how practitioners detect defects, find gaps, and manage complexity. The transformation is specific and practical, not abstract. Here is what AI actually does today, where it falls short, and where the engineer remains irreplaceable.

NLP Ambiguity Detection

Large language models and specialized NLP tools can scan natural-language requirements and flag specific ambiguity patterns that human reviewers miss — not because the patterns are subtle, but because humans lose concentration across hundreds of pages.

What AI detects: vague adjectives ("adequate," "sufficient," "appropriate"), passive voice constructions that hide the responsible actor ("data shall be encrypted" — by whom?), unmeasurable terms ("user-friendly," "high-quality"), missing thresholds on performance statements, and sentences with multiple valid interpretations.

What this replaces: the manual peer review where an engineer reads each requirement and mentally evaluates clarity. That process catches roughly 30-60% of ambiguity defects in a typical review session. NLP-based tools consistently identify over 85% of textual ambiguity patterns because they do not fatigue, do not lose focus on requirement 847, and apply the same rules to every statement.

What the engineer still does: determines whether the flagged ambiguity is actually a problem in context. "The system shall provide adequate margin" is flagged as ambiguous — but in some contexts, "adequate" is defined in a referenced standard. The engineer makes the judgment call; the AI ensures nothing is skipped.

Completeness Checking

A requirements set is complete when every stakeholder need is covered, every operational scenario is addressed, and no expected capability is missing. Traditionally, completeness is assessed by expert review — experienced engineers read the requirements and mentally compare them against their understanding of the domain.

AI transforms this by comparing the requirements set against domain ontologies, regulatory frameworks, and historical project data. The AI asks: "Based on similar systems in this domain, a requirement for electromagnetic compatibility should exist but does not. Based on the referenced standard, Section 4.3.2 imposes an obligation that has no corresponding requirement. Based on the operational concept document, the failure recovery scenario has no associated requirements."

This is not artificial intelligence in the sense of understanding — it is pattern matching at a scale humans cannot achieve. A domain expert might notice 10 missing requirements during a review. An AI scanning against a comprehensive ontology might surface 50 candidates, of which 30 are genuine gaps and 20 are false positives. The engineer evaluates each candidate. The net result is far better coverage than either human or AI achieves alone.

Conflict Detection

Requirements conflict when satisfying one makes it impossible or unnecessarily difficult to satisfy another. In small requirements sets, conflicts are detectable through manual review. In sets with thousands of requirements spanning multiple documents, subsystems, and authors, conflicts hide in the combinatorial space of pairwise comparisons.

Consider: Requirement A says "The thermal management system shall maintain electronics below 70 degrees C." Requirement B, written by a different team and stored in a different document, says "The enclosure shall be sealed to IP67 with no external venting." These requirements conflict — sealed enclosures restrict the thermal dissipation paths needed to meet the temperature limit — but the conflict is invisible unless both requirements are analyzed together.

AI performs pairwise and higher-order conflict analysis across the full requirements set. It identifies potential contradictions in performance thresholds, competing resource demands (weight, power, volume budgets that sum to more than available), and physical incompatibilities. The output is a ranked list of potential conflicts with explanations of why the AI flagged them. The engineer then determines which are genuine conflicts, which are manageable through design, and which are false positives.

Automated Allocation Suggestions

When a new requirement enters the baseline, it must be allocated to a subsystem. In traditional practice, this requires an engineer who understands the system architecture to manually assign each requirement. For large systems, this is a bottleneck.

AI trained on the project's architecture model and historical allocation patterns can suggest which subsystem should own a new requirement. "This requirement involves RF signal processing. Historically, 94% of RF signal processing requirements are allocated to the Communications Subsystem. Suggested allocation: Communications Subsystem." The engineer reviews and confirms — or overrides when the suggestion misses architectural context that the AI does not have.

The value is not that the AI is always right. It is that the AI reduces a decision that takes 10 minutes of context-gathering to a 30-second review of a suggested answer.

Requirements Generation from Standards

Regulatory documents, industry standards, and compliance frameworks contain hundreds of obligations that must be translated into system requirements. MIL-STD-810 (environmental testing), DO-178C (software assurance), ASME BPVC (pressure vessels), IEC 62443 (industrial cybersecurity) — each contains obligations that a human must read, interpret, and convert into shall statements.

AI extracts candidate requirements from standards text. It identifies obligation language ("shall," "must," "is required to"), maps it to the system's scope, and generates draft requirements with the standard section as the rationale. The engineer reviews each candidate for applicability (does this clause apply to our system?), completeness (does the generated requirement capture the full obligation?), and correctness (is the shall statement faithful to the standard's intent?).

For a standard with 400 obligation clauses, this reduces the initial extraction effort from weeks to hours — with the engineer's effort shifting from extraction to review.

What AI Cannot Do

AI cannot determine what the system should do. That requires understanding stakeholder intent — the political, operational, and strategic context that drives what matters and what does not. An AI can tell you that a requirement is ambiguous. It cannot tell you what the unambiguous version should say, because that depends on what the stakeholder actually needs.

AI cannot evaluate engineering judgment. When two requirements conflict, the resolution is a trade decision that depends on priorities the AI does not set — mission criticality, cost sensitivity, schedule pressure, risk tolerance. The AI identifies the conflict. The engineer resolves it.

AI cannot validate that the requirements set addresses the right problem. Completeness checking can identify missing requirements relative to a domain model or a standard. It cannot identify that the entire operational concept is flawed, or that the stakeholder's stated need does not reflect their actual need. That requires the kind of understanding that comes from domain expertise, operational experience, and direct conversation with users.

AI cannot replace the accountability that comes with engineering judgment. When an engineer signs off on a requirements baseline, they are asserting that the requirements are correct, complete, and achievable. That assertion carries professional responsibility. AI assists in forming that judgment — it does not substitute for it.

The Practitioner's Framework

Use AI for: detection (ambiguity, conflicts, gaps), extraction (requirements from standards), suggestion (allocation, classification), and verification of textual quality (INCOSE attribute checking).

Use engineering judgment for: resolution (what should the requirement say?), validation (are we solving the right problem?), trade decisions (which requirement yields when there's a conflict?), and acceptance (is this baseline ready for design?).

The most effective requirements engineering practice is neither purely manual nor purely automated. It is a workflow where AI handles the scale-dependent tasks — reading thousands of requirements, comparing them pairwise, checking them against standards — and engineers handle the judgment-dependent tasks — interpreting stakeholder intent, resolving conflicts, and accepting the baseline.

Assessment