Requirements Elicitation – Pace Tech

Requirements Engineering · Elicitation

Process

Requirements Elicitation is the starting point of the Requirements Engineering process. Its purpose is to discover and understand stakeholder needs by investigating relevant sources, capturing what stakeholders say or what other sources reveal, and exploring why those needs matter.

IMPULS3 definition. Requirements Elicitation is the systematic process of discovering, capturing, clarifying and formulating stakeholder needs and their rationale, while preserving traceability to the source information from which those needs were identified.

Process / activity Information Element IMPULS3 principle Stakeholders Added value / output

Elicitation does not start with formal requirements. It starts with people, documents, observations, existing systems, regulations and other sources that contain potentially relevant information. That information is first captured as source material. Through interaction, questioning and clarification, the elicitor seeks to understand what stakeholders need, why those needs are important and in which context they apply.

The principal outcome of Elicitation is therefore not a collection of raw statements, but a substantiated set of Stakeholder Needs, linked to the stakeholders who express or own them and traceable to the Source Statements that support them.

Input–Process–Output overview

Input

Sources and source information

Stakeholders and domain experts
Documents, records and data
Existing and predecessor systems
Operational and organisational context
Standards, policies and regulations
Observations, incidents and lessons learned

Process

Discover and understand stakeholder needs

Identify stakeholders and relevant sources
Capture Source Statements
Explore rationale and context
Clarify stakeholder intent
Identify and formulate Stakeholder Needs
Preserve provenance and traceability

Output

Substantiated stakeholder needs

Stakeholders
Stakeholder Needs
Rationale and context
Traceability to Source Statements
Open questions and unresolved issues

Information flow through Elicitation

IMPULS3 distinguishes explicitly between source information and the engineering information produced from it. This distinction prevents raw statements from being mistaken for already understood stakeholder needs.

Source The person, document, system, observation, regulation or other origin from which information is obtained.

Source Statement A faithful record of what was said, written, observed or otherwise discovered, including its provenance.

Elicitation The investigation of meaning, rationale, context, concerns and expectations through questioning and clarification.

Stakeholder Need A documented expression of what a stakeholder needs, together with the rationale that explains why it matters.

Inputs

An elicitation input is any source from which potentially relevant engineering information can be obtained. Inputs may already contain requirements, opinions, observations, constraints, assumptions, problems or factual information. Their status is not assumed in advance.

People

Customers, users, operators, maintainers, owners, managers, suppliers, regulators, domain experts and other stakeholders.

Documents and records

Contracts, policies, legislation, standards, procedures, reports, specifications, drawings, models, historical decisions and operational records.

Systems and environments

Existing systems, predecessor systems, interfaces, workplaces, operational environments, prototypes and comparable solutions.

Observed evidence

Measurements, performance data, incident reports, recurring problems, maintenance findings, workarounds and lessons learned.

Activities

1Identify stakeholders and relevant sources

Determine who has an interest in the system and where potentially relevant information resides. Identify people, documents, systems, regulations, operational situations and other sources that can contribute to understanding stakeholder needs.

2Capture Source Statements

Record what was actually said, written, observed or otherwise discovered. Preserve the original meaning, context and provenance of the information before transforming it into a Stakeholder Need.

3Explore rationale and context

Ask why an expressed need, concern or expectation is important. Investigate the circumstances in which it applies, the problem it addresses, the consequences if it is not satisfied and the objectives or concerns that lie behind it.

4Clarify stakeholder intent

Resolve ambiguities, unclear terminology and missing context with the stakeholder or source. The objective is to understand the stakeholder’s perspective faithfully, not yet to determine the system-level solution or formulate a requirement.

5Identify and formulate Stakeholder Needs

Transform the understood stakeholder intent into explicit Stakeholder Needs. Each need should express what the stakeholder needs and, where relevant, retain the rationale that explains why the need matters.

6Preserve provenance and traceability

Link Stakeholder Needs to the stakeholders and Source Statements that support them. This preserves the reasoning chain and allows later analysis, change assessment and validation to return to the original evidence.

Outputs

The primary outputs of Elicitation are Stakeholders and Stakeholder Needs. A Stakeholder Need is a documented expression of an outcome, capability, quality or condition needed by a stakeholder, including the rationale that explains why the need is important. It is therefore more than a cleaned-up Source Statement: it represents stakeholder intent that has been explored and understood through Elicitation.

Source Statements remain essential, but they serve a different role. They are the captured evidence from which Stakeholder Needs are identified and clarified. They therefore provide provenance and traceability rather than being the principal engineering output of the process.

Primary output entities

Stakeholder — the person, group or organisation with an interest in the system.
Stakeholder Need — a documented expression of an outcome, capability, quality or condition needed by a stakeholder, including the rationale that explains why the need is important.

Supporting information

Source Statement — captured evidence supporting one or more Stakeholder Needs.
Source reference — the origin of the captured information.
Open question / issue — unresolved information requiring further investigation.
Context information — circumstances needed to preserve meaning.

This treatment is consistent with the INCOSE Needs and Requirements Manual (NRM) Version 2, which treats needs as engineering information developed from stakeholder perspectives and emphasizes the importance of source, context, rationale and traceability across the lifecycle (Wheatcraft, Ryan, & Katz, 2024). IMPULS3 makes the transformation from captured Source Statements to Stakeholder Needs explicit in its Information Model.

Process boundary: where does Elicitation end?

Elicitation does more than record statements. It investigates stakeholder intent deeply enough to understand what the stakeholder needs and why that need matters. Questions such as why is this important?, when does this matter?, what problem are you experiencing? and what happens if this need is not satisfied? belong to Elicitation.

Elicitation seeks to understand individual Stakeholder Needs and their rationale. Analysis considers the elicited needs integrally and determines what they collectively mean for the system.

IMPULS3 principle. Preserve the distinction between understanding an individual stakeholder’s need and determining the system-level consequences of the complete set of needs.

Analysis therefore adds a different perspective. It brings Stakeholder Needs from different stakeholders and sources together, structures them, compares them and examines them for dependencies, conflicts, gaps, priorities and consequences for the system as a whole.

Example

Source Statement: “Cleaning this machine takes almost two hours. We really need to get that down because we’re losing too much production time.”

Elicitation Explore why the cleaning time is problematic, how often cleaning occurs, what happens during the downtime, what consequences it has for operations and what outcome the stakeholder actually needs.

Stakeholder Need “Production Operations needs the machine to support rapid cleaning in order to minimise production downtime between production runs.”

Analysis Consider this need together with other relevant needs, for example maintainability, hygiene, operator safety and production availability, and determine what the combined set of needs means for the system.

The Source Statement preserves what was communicated. The Stakeholder Need captures what is needed and why it matters. Analysis subsequently determines the system-level consequences of the complete body of elicited needs.

Relationship with the subsequent process

Elicitation produces a substantiated set of Stakeholder Needs with sufficient rationale, context and traceability to understand where they came from and why they matter. Requirements Analysis then considers these needs integrally rather than source by source or stakeholder by stakeholder.

Analysis structures and relates the needs, identifies relevant aspects of the system, exposes dependencies, conflicts and gaps, and determines what the complete stakeholder perspective means for the system. This creates the basis for subsequent requirement specification.

Requirements Engineering · Elicitation

Transformation Engine

The IMPULS3 Transformation Engine defines the rules that govern how engineering information is transformed into structured Information Elements and how those Information Elements may be related within the Information Model.

The Transformation Engine is not a software engine and does not imply that engineering interpretation is automated. Elicitation remains a human reasoning process involving investigation, questioning, interpretation and judgement. The Transformation Engine provides the rules within which the resulting engineering information is structured.

Purpose

Information encountered in the real world is rarely structured according to an engineering Information Model. Stakeholders speak in their own language, documents have different purposes and structures, and observations provide information that first needs to be understood in context.

During Elicitation, relevant information is captured, explored and interpreted. The Transformation Engine governs how the resulting understanding may be represented as IMPULS3 Information Elements without losing its original meaning, rationale, context or provenance.

Transformation and relationship rules

Transformation Rules

Define how information encountered and understood during Elicitation may be represented as structured Information Elements.

These rules preserve the distinction between source information and the engineering interpretation that results from Elicitation.

Relationship Rules

Define which semantic relations are permitted between Information Elements and the direction in which those relations are expressed.

Within IMPULS3, relations follow the parent–child principle: a child Information Element points to its parent.

Rules applied during Elicitation

Preserve source information

Relevant information is captured before it is transformed into an engineering interpretation. The original information remains available as Source Information.

Separate source from interpretation

A Stakeholder Need is not a rewritten Source Information element. It represents what has been understood through Elicitation about what the stakeholder needs and why that need matters.

Preserve rationale and context

Transformation must preserve the information necessary to understand the intent, rationale and circumstances behind a Stakeholder Need.

Preserve provenance

A Stakeholder Need remains traceable to the Source Information from which it originates and to the Stakeholder whose need it represents.

Do not specify prematurely

Information discovered during Elicitation is not transformed directly into a Requirement. Elicitation first establishes and substantiates Stakeholder Needs; their system-level implications are subsequently considered during Analysis.

Do not invent information

Transformation may clarify and structure meaning, but must not introduce unsupported stakeholder intent, rationale or need.

Relationship rules

For Elicitation, the Information Model currently defines three core Information Elements and the semantic relations between them. Relations are expressed from child to parent.

Stakeholder Need → Stakeholder

A Stakeholder Need points to the Stakeholder whose need is represented.

Relation: is needed by

Stakeholder Need → Source Information

A Stakeholder Need points to the Source Information from which the need was identified and understood.

Relation: originates from

Source Information → Stakeholder

Where Source Information was obtained from a Stakeholder, the Source Information points to that Stakeholder.

Relation: is provided by

Example

Source Information

“Cleaning this machine takes almost two hours. We really need to get that down because we’re losing too much production time.”

Elicitation

Explore why cleaning time is problematic, how frequently cleaning occurs, the consequences for production and what outcome the stakeholder actually needs.

Stakeholder Need

Production Operations needs the machine to support rapid cleaning in order to minimise production downtime between production runs.

The transformation does not replace the Source Information. Both remain part of the engineering information structure and are explicitly connected through the relation originates from.

IMPULS3 principle Transform information without losing information. Preserve the original source, distinguish source from interpretation, and maintain the semantic relations necessary to understand where engineering information came from, what it means and whom it concerns.

Requirements Engineering · Elicitation

Information Model

Elicitation produces structured engineering information rather than isolated statements. Within IMPULS3, the core information created and maintained during Elicitation is represented through three connected Information Elements: Source Information, Stakeholder and Stakeholder Need.

Their semantic relations preserve the context and provenance of the elicited information. This makes it possible to understand not only what a stakeholder needs, but also who the need belongs to and which source information supports it.

Information Elements

Source Information

Recorded information obtained from a source, such as a conversation, document, observation, existing system, dataset, regulation or other relevant origin.

Source Information preserves what was communicated, written, observed or otherwise discovered, together with its provenance and context.

Stakeholder

The Information Element representing an individual, group or organisation that has an interest in the system, can affect it, is affected by it, or perceives itself to be affected by it.

Stakeholders provide the perspective from which needs, concerns, objectives and expectations are understood.

Stakeholder Need

A documented expression of an outcome, capability, quality or condition needed by a stakeholder, together with the rationale explaining why that need matters.

A Stakeholder Need is therefore more than a transcription of source information: it represents an understood and substantiated stakeholder need.

Semantic Relations

The three Information Elements are connected through explicit semantic relations. In accordance with the IMPULS3 parent–child principle, relations are expressed from the child Information Element towards its parent. This ensures that every child can identify the information on which it depends or to which it belongs.

Stakeholder Need → Stakeholder

A Stakeholder Need points to the Stakeholder whose need is being represented.

Relation: is needed by

Stakeholder Need → Source Information

A Stakeholder Need points to the Source Information from which the need was identified and understood during Elicitation.

Relation: originates from

Source Information → Stakeholder

Where Source Information originates from a Stakeholder, the Source Information points to the Stakeholder from whom that information was obtained.

Relation: is provided by

IMPULS3 information structure.

The result of Elicitation is not merely a collection of statements. It is a connected information structure in which Stakeholder Needs remain traceable to the stakeholders they concern and to the source information from which they were identified.

Multiple Source Information elements may support a single Stakeholder Need, and one Source Information element may contribute to several Stakeholder Needs. Likewise, a stakeholder may be associated with many different needs.

IMPULS3 principle Preserve the connection between what was discovered, who it concerns, and what has subsequently been understood as a Stakeholder Need.

Requirements Engineering · Elicitation

Tools & Techniques

Requirements Elicitation can be supported by a wide range of tools and techniques. Different techniques are useful for different purposes: identifying relevant stakeholders and sources, acquiring information, stimulating discussion and discovery, understanding rationale and context, and structuring the information that emerges.

The techniques below form the initial IMPULS3 Elicitation toolbox. They are not intended as a prescriptive sequence. The appropriate combination depends on the system, lifecycle stage, stakeholder landscape, available evidence and the uncertainty of the problem situation.

Identify and frame the elicitation

Mendelow Matrix

Categorize stakeholders according to their relative power and interest in the engineering endeavor, helping determine how different stakeholders should be engaged during Elicitation.

Stakeholder Identification & Mapping

Identify whose perspectives, needs, interests and knowledge need to be explored during Elicitation.

Context Diagrams

Establish the system context and identify relevant external actors, systems, organisations and interactions.

Interface Analysis

Investigate interactions with external systems, organisations, users and environments that may give rise to stakeholder needs or constraints.

Glossary & Terminology Analysis

Establish shared meaning and uncover ambiguous, overloaded or stakeholder-specific terminology.

Acquire information

Interviews

Explore individual stakeholder needs, concerns, objectives, rationale and context in depth.

Workshops

Elicit information collaboratively and expose different stakeholder perspectives through structured discussion.

Questionnaires & Surveys

Collect structured input from larger or geographically distributed stakeholder groups.

Observation & Contextual Inquiry

Discover needs by observing stakeholders performing actual work in their operational environment.

Document Analysis

Extract potentially relevant information from specifications, contracts, policies, procedures, reports, standards, regulations and other documents.

Existing-System Analysis

Learn from predecessor, reference or currently operational systems, including their strengths, limitations, workarounds and recurring problems.

Voice of the Customer

Systematically capture and understand customer or user expectations, concerns, priorities and perceptions.

Critical Incident Technique

Use concrete experiences and significant events to uncover needs, problems and concerns that stakeholders may otherwise not articulate.

Explore and understand

Scenario Analysis

Explore needs by describing situations in which stakeholders interact with, depend upon or are affected by the system.

Use Cases

Systematically explore actor–system interactions and the outcomes actors need to achieve.

Operational Scenarios & Mission Threads

Explore end-to-end operational situations involving multiple actors, systems, activities and events.

Storytelling

Encourage stakeholders to describe concrete situations and experiences in order to reveal context, concerns and implicit needs.

Prototyping & Mock-ups

Use representations of possible solutions or interactions to provoke feedback and uncover implicit or previously unarticulated needs.

5 Whys

Explore the rationale behind an expressed statement and distinguish an underlying need from a symptom, assumption or proposed solution.

Kano Analysis

Analyse the relationship between a Stakeholder and a Stakeholder Need by exploring how different levels of need fulfilment influence stakeholder satisfaction and dissatisfaction.

Laddering

Progressively explore relationships between desired characteristics, consequences, objectives and underlying stakeholder values.

Root Cause Analysis

Investigate the causes behind observed problems rather than translating symptoms directly into requirements.

Process & Workflow Analysis

Understand how work is currently performed, where interactions occur and where stakeholder needs arise.

Journey Mapping

Explore stakeholder experience across a sequence of interactions, activities or lifecycle stages.

Structure and synthesise

Rich Pictures

Capture complex problem situations, stakeholders, concerns, relationships and perspectives without imposing premature formal structure.

Concept Mapping & Mind Mapping

Organise elicited concepts and expose relationships, terminology and areas requiring further investigation.

Affinity Mapping

Cluster larger quantities of elicited information to reveal recurring themes, patterns and areas of concern.

Assumption Identification

Surface beliefs that are being treated as true but for which adequate evidence may not yet exist.

Constraint Identification

Discover externally imposed conditions arising from legislation, standards, policies, technology, organisations or the operational environment.

Quality Function Deployment

Relate stakeholder and customer needs to characteristics that can subsequently inform engineering analysis.

Complementary architectural reasoning

CAFCR — Customer Objectives

Explore customer objectives, key drivers, concerns and the rationale behind stakeholder needs.

CAFCR — Application View

Explore operational usage, stakeholders and the context in which stakeholder needs arise.

IMPULS3 perspective. Tools and techniques support Elicitation; they do not define the process themselves. The purpose remains to discover, capture, clarify and understand Stakeholder Needs and their rationale while preserving meaning, context and traceability to the originating information.

IMPULS3 Principles

The following IMPULS3 principles are particularly relevant during Elicitation:

Preserve the source. Capture relevant source information before interpreting or transforming it.
Understand before specifying. Determine what a stakeholder needs and why it matters before formulating requirements.
Separate elicitation from analysis. Understand individual stakeholder needs first; determine their collective system-level implications during Analysis.
Preserve meaning and context. Transform information without losing its original intent, rationale or provenance.
Maintain traceability. Keep Stakeholder Needs explicitly connected to the stakeholders and source information from which they originate.