MODULE 6 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolExploring New Domains
Before requirements can be elicited, a Requirements Engineer must understand the domain, the goals, the stakeholders and the constraints. The exploratory phase establishes the foundation for everything that follows, and it is where a newcomer to a domain is at their least effective — which is exactly where AI support has the most leverage.
What AI can do in exploration
The syllabus lists several capabilities:
- Summarise internal documentation and publicly available sources to produce domain overviews covering goals, terminology, challenges and regulatory context.
- Analyse organisational structures to surface potential stakeholder groups that might otherwise be overlooked.
- Generate structured interview guides with open-ended questions tailored for exploratory conversations.
- Assist in organising requirements workshops by identifying key topics, stakeholder roles, and potential areas of conflict or alignment.
The stakeholder-discovery item deserves emphasis. Missing a stakeholder group is one of the more expensive failures in RE, because their requirements arrive late, when the cost of change is highest. An AI asked to enumerate the parties affected by a system in a given domain will produce a list that includes obvious groups and some non-obvious ones. Even when a third of the list is irrelevant, the exercise has done its job if it surfaces one group the team had not considered.
But the syllabus attaches a condition to all of it: these outputs serve only as starting points and require validation through human expertise and direct stakeholder interaction. Their true value depends on being used as catalysts for deeper inquiry, not as substitutes for the critical thinking and stakeholder engagement essential to establishing a shared understanding — CPRE principle 3.
Identification of system context
AI can significantly improve the identification of system context elements, in two distinct modes.
Extraction mode. Where artefacts such as stakeholder lists, system landscape diagrams, process descriptions or organisational charts already exist, AI can extract the relevant information and classify it according to the five core aspects of system context:
It can also reveal relationships and dependencies across those sources, which helps a Requirements Engineer form a comprehensive view of system and context boundaries and reduces the risk of missing critical elements.
Question-generation mode. Where those artefacts do not exist, AI can instead generate structured question lists and checklists designed to elicit information about each of the five aspects from stakeholders. These become comprehensive elicitation instruments for interviews or workshops, ensuring systematic coverage of every context dimension. The questions can be tailored to specific domains or system types.
The two modes are worth keeping distinct, because they apply at different moments. Extraction works when documentation exists; question generation works when it does not. A Requirements Engineer entering an undocumented domain uses the second and should not expect the first.
Establishing a shared understanding
Shared understanding depends fundamentally on consistent terminology. Glossaries are the central collection of definitions that mitigate misinterpretation and ensure stakeholders, Requirements Engineers and developers work from the same conceptual foundation.
AI can accelerate glossary creation and maintenance considerably by:
- Analysing existing documentation, stakeholder communications and domain materials to identify terms that require definition.
- Detecting inconsistent usage of terminology across different documents.
- Flagging potential homonyms — the same term used for different concepts.
- Suggesting synonyms that should be standardised.
- Proposing initial definitions based on contextual analysis of how terms are used in the project environment.
Of everything AI does for glossaries, flagging homonyms is the capability that finds problems humans reliably miss — and understanding why explains something about the technology.
A homonym in a project is a term two groups use confidently for different things. "Customer" means the paying account to the finance team and the person in the chair to the clinical team. Nobody notices, because each group is internally consistent and each reads the other's documents as confirming their own meaning. The defect surfaces during acceptance testing, when a report counts the wrong population.
Humans miss this because we resolve ambiguity automatically from context — the same capability that makes us good at language makes us blind to this class of defect. A tool comparing usage across documents has no such reflex. It sees that the contexts in which the word appears cluster into two groups that do not overlap, and it flags it.
That is embeddings doing exactly what module 2 described: measuring proximity of usage. Which is also why the tool cannot finish the job. It can tell you the term is used in two distinguishable ways. Only stakeholders can decide which meaning the project adopts, or whether both concepts need separate names — a negotiation, and negotiation is human work.
An AI produces a domain overview and a list of eleven stakeholder groups for an unfamiliar regulated domain. How should the Requirements Engineer treat this output?
Exploration (in elicitation)
Click to flipUnderstanding the domain, goals, stakeholders and constraints before formal elicitation begins. AI supports it by summarising domain knowledge, identifying stakeholder groups, and helping prepare structured interview guides and workshops.
Click to flip backIn exploration, AI summarises domains, surfaces stakeholder groups that might be overlooked, drafts interview guides, and helps structure workshops. It works on system context in two modes: extracting the five aspects from existing artefacts, or generating questions to elicit them when no artefacts exist. For glossaries it identifies terms, detects inconsistent usage, flags homonyms and proposes definitions. Every one of these is a starting point that stakeholder engagement must validate.