Extracting Requirements Across Sources

Once stakeholder input exists, the next step is extracting clear and actionable requirements from it. AI can assist by identifying and categorising functional requirements, quality attributes and constraints from raw input, and by grouping them by topic or feature area to clarify priorities and dependencies.

The syllabus treats extraction across three source types.

Informal channels

AI can systematically analyse emails, chats, meeting minutes and collaboration threads to surface requirements-relevant content that is often missed in such channels.

This strengthens requirement source identification by capturing implicit requirements, stakeholder concerns and contextual cues from ongoing communication. AI can:

Classify items by type — functional requirements, quality requirements, constraints.
Detect conflicts between formal and informal statements.
Flag inconsistencies with official documents.

The syllabus notes this is especially valuable in agile settings, where requirements evolve through continuous stakeholder interaction and informal feedback rather than through a single specification event.

The conflict-detection capability is the one worth dwelling on. A decision reversed in a chat thread three weeks after it was written into the specification is a real and common failure mode. Nobody updated the document; nobody remembers that they should have. A tool comparing formal and informal sources can surface exactly that divergence — and note that it does not resolve it. It reports that two sources disagree. Which one is current is a question for people.

Existing documents

Generative AI can systematically analyse existing documents from various sources: business process documentation, regulatory documents, legacy system specifications, market analysis reports.

From these it can identify both explicit and implicit requirements embedded in the material, process multiple document formats simultaneously, and extract potential functional requirements, quality requirements and constraints, categorising them according to an established classification framework.

It can also:

Cross-check extracted requirements against project scope and system boundaries to ensure relevance — which is a direct mitigation for the scope misalignment risk from module 4.
Identify relationships among requirements found in different source documents.

This supports comprehensive coverage of requirements sources beyond direct stakeholder input, helping ensure that documented organisational knowledge and regulatory obligations are properly captured.

Pattern analysis and gap suggestion

The most sophisticated capability in this lesson: AI can analyse patterns across extracted stakeholder input to identify potential requirements gaps, implicit assumptions, or overlooked system aspects that stakeholders may have considered self-evident but never articulated.

By comparing stakeholder statements against comprehensive requirements frameworks and domain-specific checklists, AI can suggest areas for further investigation and propose questions that help elicit subconscious requirements as described in the Kano model.

It can also identify inconsistencies among different stakeholder perspectives, which may indicate missing requirements or unresolved conflicts requiring conflict resolution techniques.

The Kano model distinguishes requirements by how their presence or absence affects satisfaction. Subconscious — or "basic" — requirements are the ones stakeholders never state because they consider them too obvious to mention. Their presence delights nobody; their absence is a catastrophe.

The classic dental clinic example: nobody in any workshop will say "the system must not double-book two patients into the same chair." It is too obvious. It goes unstated, unspecified, untested, and then it happens.

This is structurally hard to elicit, because the standard elicitation techniques all rely on someone saying something. You cannot ask "what have you not thought to tell me?" and get a useful answer.

Where AI helps is comparison against a corpus. Having read enormous quantities of text about booking systems, scheduling and resource allocation, a model asked "what do specifications in this domain typically include that is absent here?" produces a list. Much of it will be irrelevant to this project. Some of it will be a basic requirement nobody said aloud.

The syllabus's caution applies with particular force here, though. The Requirements Engineer must validate all AI-generated insights through systematic stakeholder engagement, ensuring that identified gaps are genuine requirements rather than AI assumptions — that they represent actual stakeholder desires and needs (CPRE principle 2), and not merely theoretical completeness.

That phrase, theoretical completeness, names the failure mode precisely. An AI comparing your specification against everything typical in the domain will happily suggest requirements that are typical and irrelevant to your project. Adopting them uncritically produces a specification that is longer, more expensive and no more aligned with what your stakeholders actually need — which is scope misalignment arriving through the front door.

❓ Knowledge Check

An AI compares a specification against domain checklists and proposes fourteen requirements the team never discussed. What is the Requirements Engineer's obligation?

📚 Flashcards1 / 5

Term

Extraction (in elicitation)

Click to flip

Definition

Identifying and categorising functional requirements, quality attributes and constraints from raw input such as meeting notes, emails or transcripts, and grouping them by topic or feature area to clarify priorities and dependencies.

Click to flip back

💡Key Takeaway

AI extracts requirements from informal channels, existing documents and patterns across both — classifying by type, detecting conflicts between formal and informal statements, cross-checking against scope, and proposing questions that surface subconscious requirements. Its most valuable move is finding what nobody said. Its most dangerous is proposing what is merely typical: every suggested gap must be validated with stakeholders as a genuine need rather than an AI assumption.