IMPULS3 user
A person performing Requirements Analysis, such as a Requirements Engineer,
Systems Engineer, architect, domain specialist or another role involved
in understanding and structuring engineering information.
Source Information
Recorded information preserving what was communicated, written, observed
or otherwise obtained from a source. During Analysis it provides evidence
and context for understanding stakeholder needs and formulating analytical conclusions.
Stakeholder Need
A documented expression of an outcome, capability, quality or condition
needed by a stakeholder. Requirements Analysis examines what the need means
for the System-of-Interest and which aspects must be addressed.
Stakeholder
The Information Element representing the person, group or organisation
associated with the source information and stakeholder needs being analysed.
Existing Information Model
Analysis starts from connected Information Elements rather than isolated
statements. Source Information, Stakeholders and Stakeholder Needs retain
their explicit semantic relations, provenance and context throughout Analysis.
Click to explore the Information Model.
Analysis activities
Activities used to interpret, question, compare, decompose and structure
available engineering information, resolve ambiguity and identify what
the System-of-Interest must do, be like or comply with.
Click to explore the process.
From needs to structured understanding
Requirements Analysis transforms elicited information into explicit
engineering understanding. Meaning is preserved while assumptions,
interpretations, conclusions and relevant system aspects are made visible
and traceable.
Transformation Engine
IMPULS3 rules guide how existing Information Elements are interpreted,
how analytical conclusions are recorded as Analysis Statements, and how
relevant system aspects are identified and structured without losing
traceability to their origin.
Click to explore the Transformation Engine.
Tools & Techniques
Techniques that support Requirements Analysis, such as decomposition,
modelling, classification, scenario analysis, interface analysis,
conflict analysis, consistency checking and reasoning with domain experts.
Click to explore the tools & techniques.
Analysis Statement
An explicit statement capturing a relevant analytical conclusion,
interpretation, assumption, clarification or other result of Analysis.
It makes engineering reasoning visible and traceable between source
information or stakeholder needs and the subsequent specification.
Structured List
Relevant system aspects identified during Analysis are structured as
Functions, Properties and Constraints:
S ::= {F*, P*, C*}.
This structures what must be addressed during Specification; the resulting
elements are not yet requirements merely because they have been classified.
Semantic relations
Analysis Statements and identified Functions, Properties and Constraints
remain explicitly related to the Information Elements from which they
originate. These relations preserve meaning, rationale and traceability
into the next engineering process.
Click to explore the Information Model.
IMPULS3 Principles
Principles that guide how Requirements Analysis is performed within IMPULS3,
including preserving meaning and traceability, making engineering reasoning
explicit, and separating analysis from specification.
Click to explore the principles.
Hover over the symbols to explore Requirements Analysis. Active symbols can be selected for more detail.
Requirements Engineering · Analysis
Process
Process
Requirements Analysis develops a coherent engineering understanding of what the System-of-Interest must do, what properties it must exhibit, and what constraints apply. It considers elicited information integrally, makes engineering reasoning explicit, and prepares the system view for precise specification.
IMPULS3 definition.
Requirements Analysis is the systematic process of interpreting, relating,
questioning and structuring elicited engineering information in order to determine
its consequences for the System-of-Interest, while making relevant reasoning explicit
and preserving meaning and traceability.
Information Element
Added value / output
Analysis does not start from isolated statements. It starts from the body of engineering information established during Elicitation: Stakeholder Needs, Source Information, Stakeholders, rationale, context and the semantic relations between them.
These Information Elements are examined together. Their meaning is interpreted, assumptions and ambiguities are exposed, dependencies and conflicts are identified, and relevant consequences for the System-of-Interest are determined.
Where engineering reasoning is relevant for understanding how elicited information leads to a particular system consequence, that reasoning is made explicit as an Analysis Statement. The resulting system aspects are subsequently structured as Functions, Properties and Constraints.
Input–Process–Output overview
Elicited engineering information
Elicited engineering information
- Stakeholder Needs
- Stakeholders
- Source Information
- Rationale and context
- Semantic relations
- Open questions and unresolved issues
Interpret, reason and structure
- Understand information in context
- Clarify meaning and intent
- Identify assumptions, gaps and conflicts
- Determine system-level consequences
- Record Analysis Statements
- Identify Functions, Properties and Constraints
- Assess the resulting system view
Structured system understanding
- Analysis Statements
- Functions
- Properties
- Constraints
- Explicit semantic relations
- Identified conflicts, gaps and dependencies
- Open questions requiring further investigation
Information flow through Analysis
IMPULS3 makes the reasoning between elicited stakeholder information and subsequent specification explicit. Analysis is therefore not treated as an invisible mental step between a Stakeholder Need and a Requirement.
Inputs
The primary input to Analysis is the connected body of information produced and substantiated during Elicitation. Individual Information Elements should not be interpreted in isolation when their meaning depends on other needs, stakeholders, sources or contextual information.
Stakeholder Needs
Documented expressions of outcomes, capabilities, qualities or conditions needed by stakeholders, together with the rationale explaining why they matter.
Source Information
Source Information
Captured information and evidence that provide provenance, context and support for the Stakeholder Needs being analysed.
Stakeholders and context
Stakeholders and context
Information about who expresses, owns or is affected by a need, together with the operational, organisational and lifecycle context in which the need applies.
Relations and existing knowledge
Relations and existing knowledge
Explicit relations between Information Elements, supplemented where necessary by relevant system knowledge, terminology, models, interfaces and domain information.
Activities
Analysis is iterative rather than strictly sequential. The activities below represent distinct reasoning concerns, but findings in one activity may require returning to another activity or even initiating additional Elicitation.
1 Understand the information in context
Examine Stakeholder Needs together with their Source Information, stakeholders, rationale, context and relations. Determine what is actually being expressed, why it matters and under which circumstances it applies.
2 Clarify and reason
Investigate ambiguity, unclear terminology, assumptions, missing information, inconsistencies and conflicts. Distinguish facts from interpretations and avoid silently resolving uncertainty in later requirement wording.
3 Determine system-level consequences
Consider the elicited information integrally and determine what individual needs and combinations of needs imply for the System-of-Interest. Identify dependencies, interactions, tensions and consequences that are not necessarily visible in any single Stakeholder Need.
4 Make analysis explicit
Record relevant analytical conclusions, interpretations, assumptions, clarifications and reasoning as Analysis Statements. Relate them explicitly to the Information Elements that support them.
5 Identify Functions, Properties and Constraints
Determine the nature of the relevant system aspects and structure them according to the IMPULS3 grammar: what the system must do as Functions, what characterises the system or its functions as Properties, and what limits the permissible solution space as Constraints.
6 Assess the resulting system view
Examine the emerging set of Functions, Properties and Constraints as a whole. Check for completeness, consistency, conflicts, dependencies, duplication, unresolved questions and missing stakeholder perspectives before proceeding to Specification.
IMPULS3 principle. Analyse before you specify. First determine what the available information means for the System-of-Interest and identify the relevant Functions, Properties and Constraints. Only then formulate precise requirements.
Outputs
The principal outcome of Analysis is a coherent and traceable understanding of the System-of-Interest. This understanding is represented through explicit Analysis Statements and a structured set of relevant Functions, Properties and Constraints.
These outputs provide the engineering content needed for Specification, but they should not yet be confused with Requirements. Classification as a Function, Property or Constraint identifies the nature of a system aspect; Specification subsequently determines how that aspect must be expressed normatively and, where necessary, quantified.
Primary output entities
- Analysis Statement — an explicit analytical conclusion, interpretation, assumption, clarification or other relevant result of Analysis.
- Function — an aspect describing what the System-of-Interest does.
- Property — an aspect describing a characteristic of the system or one of its functions.
- Constraint — an aspect restricting the permissible solution space.
Supporting analysis information
- Assumptions requiring confirmation
- Identified conflicts and inconsistencies
- Dependencies between system aspects
- Gaps and missing information
- Open questions requiring further Elicitation
- Semantic relations preserving reasoning and traceability
Process boundary: where does Analysis end?
Analysis determines what the complete body of elicited information means for the System-of-Interest. It identifies and structures the relevant system aspects and makes the reasoning behind them explicit.
IMPULS3 principle. A Function, Property or Constraint identified during Analysis is not automatically a Requirement. Specification adds the normative expression and the precision needed for subsequent verification.
Analysis is also distinct from Design. It may identify what the system must do, what characteristics are relevant and which constraints apply, but it deliberately avoids deciding how those needs will be realised unless an implementation choice is itself imposed as a legitimate constraint.
Example
Stakeholder Need: “Production Operations needs the machine to support rapid cleaning in order to minimise production downtime between production runs.”
Property: Cleaning duration.
Constraints: Applicable hygiene and operator-safety conditions.
Analysis does not yet decide how the machine will be cleaned or prescribe a technical cleaning solution. Nor does the Property “cleaning duration” yet constitute a Requirement. Specification subsequently determines the required value and normative formulation.
Relationship with the subsequent process
Requirements Analysis produces structured engineering understanding that is sufficiently coherent, explicit and traceable to serve as the basis for Requirement Specification. Specification does not need to rediscover what the stakeholder information means; it can start from the Functions, Properties and Constraints established through Analysis.
During Specification, relevant system aspects are formulated as precise Requirements. Properties are quantified where necessary, Functions are expressed with the required behavioural precision, Constraints are stated normatively, and suitable verification criteria can subsequently be established.
IMPULS3 principle. Preserve the semantic chain from Stakeholder Need through Analysis Statement and identified system aspect into Specification. Requirement wording may become more precise, but the underlying meaning must remain traceable.
Requirements Engineering · Analysis
Transformation Engine
The IMPULS3 Transformation Engine defines the rules by which elicited engineering information is interpreted and transformed into explicit, structured system understanding. It preserves meaning and traceability while making the reasoning between stakeholder information and subsequent specification visible.
During Analysis, transformation does not mean rewriting one statement into another. The available information is interpreted in context, compared with other information, examined for dependencies and conflicts, and considered from the perspective of the System-of-Interest.
The Transformation Engine governs this reasoning. It determines how analytical conclusions are made explicit, how relevant system aspects are identified, how they are classified, and how semantic relationships to their origin are preserved.
Transformation overview
Connected engineering information
- Stakeholder Needs
- Source Information
- Stakeholders
- Rationale and context
- Existing semantic relations
- Relevant domain knowledge
Interpret, reason and classify
- Preserve meaning
- Consider information integrally
- Make reasoning explicit
- Determine system consequences
- Classify Functions, Properties and Constraints
- Preserve semantic traceability
Explicit system understanding
- Analysis Statements
- Functions
- Properties
- Constraints
- Semantic relations
- Identified gaps, conflicts and uncertainties
Analysis is not a one-to-one conversion
A fundamental characteristic of Requirements Analysis is that the relationship between elicited information and system consequences is not necessarily one-to-one.
One need may imply several system aspects
A single Stakeholder Need may have consequences for several Functions, Properties or Constraints. Analysis separates these aspects so that each can later be specified with the appropriate precision.
Several needs may imply one system aspect
A relevant Function, Property or Constraint may only become apparent when needs from several stakeholders or sources are considered together.
Source Information may influence interpretation
The original source, rationale and context may contain information required to understand the intended meaning of a Stakeholder Need and its consequences for the system.
Analysis may expose missing information
Analysis can reveal ambiguity, gaps or contradictions that cannot be resolved analytically. In such cases, additional Elicitation may be required before analysis can continue.
IMPULS3 principle. Do not assume a one-to-one relationship between Stakeholder Needs and system requirements. Analyse the complete body of relevant information before determining its consequences for the System-of-Interest.
Transformation rules
The Transformation Engine is governed by a number of rules. These rules help ensure that Analysis adds understanding without losing the meaning of the information from which that understanding was developed.
1 Preserve meaning
Transformation may restructure and interpret information, but it must not silently change its underlying meaning. Analytical conclusions must remain defensible from the information on which they are based.
2 Analyse information integrally
Stakeholder Needs are not analysed independently when their meaning or consequences depend on other needs, stakeholders, sources, interfaces or contextual information.
3 Make relevant reasoning explicit
Important interpretations, assumptions, conclusions and clarifications are recorded as Analysis Statements rather than remaining implicit in the mind of the analyst.
4 Identify the nature of each system aspect
Determine whether an identified aspect describes what the system does, what characterises it, or what restricts the solution space. Classify the aspect as a Function, Property or Constraint accordingly.
5 Preserve traceability
Every significant transformation should preserve explicit semantic relations to the Information Elements that support it. The path from elicited information to analytical conclusion must remain navigable.
6 Separate Analysis from Specification
Identification of a Function, Property or Constraint does not itself create a Requirement. Normative wording, required values and specification precision belong to the subsequent Specification process.
7 Avoid premature design
Analysis describes the required system behaviour, characteristics and applicable constraints without introducing implementation choices unless such a choice is itself imposed by a legitimate constraint.
8 Expose uncertainty instead of hiding it
Conflicts, gaps, unresolved assumptions and uncertainties are made visible. Transformation must not create false precision where the available information does not support it.
Making reasoning explicit with Analysis Statements
Engineering analysis inevitably involves reasoning. Information must be interpreted, relationships must be recognised, assumptions may have to be made and conclusions may need to be drawn. If that reasoning remains implicit, an important part of the engineering information is lost.
IMPULS3 therefore provides the Analysis Statement as an explicit Information Element for recording relevant analytical reasoning.
IMPULS3 principle. Do not hide engineering reasoning inside Requirement wording. Where reasoning is important for understanding why a system aspect exists, preserve that reasoning explicitly as Analysis information.
Structuring the system view
Once relevant system consequences have been identified, they are structured according to the fundamental IMPULS3 classification of Function, Property and Constraint.
Function — F
Describes what the System-of-Interest does. Functions express required system behaviour independently of the implementation chosen to realise that behaviour.
Property — P
Describes a characteristic of the System-of-Interest or one of its functions. Examples include capacity, accuracy, availability, mass, response time or maintainability.
Constraint — C
Describes a restriction on the permissible solution space. Constraints may arise from legislation, standards, existing interfaces, mandated technology, physical boundaries or other externally imposed conditions.
Structured system view
Together, Functions, Properties and Constraints provide a structured analytical representation of the system aspects that must subsequently be considered during Specification.
IMPULS3 principle. Classification comes before formulation. First understand whether an aspect is a Function, Property or Constraint; only afterwards determine how it should be expressed as a Requirement.
Transformation patterns and traceability
The Transformation Engine supports multiple legitimate transformation patterns. The information model must therefore support semantic relations rather than assuming a fixed one-to-one conversion chain.
One Stakeholder Need → multiple aspects
One need may result in several Functions, Properties and Constraints, each of which represents a different consequence for the System-of-Interest.
Multiple Stakeholder Needs → one aspect
Several needs may collectively justify a single system aspect. Its provenance therefore extends to more than one Stakeholder Need or source.
Information → Analysis Statement → system aspect
Where interpretation or reasoning is required, an Analysis Statement makes the intermediate reasoning explicit before a Function, Property or Constraint is identified.
Analysis → additional Elicitation
If analysis reveals missing, contradictory or insufficient information, the process may return to Elicitation. Requirements Engineering is iterative rather than strictly sequential.
Example
Consider the Stakeholder Need:
“Production Operations needs the machine to support rapid cleaning in order to minimise production downtime between production runs.”
- Function: Clean machine
- Property: Cleaning duration
- Constraint: Applicable hygiene conditions
- Constraint: Applicable operator-safety conditions
The Transformation Engine has not yet determined a cleaning technology or created a final Requirement. It has transformed stakeholder information into explicit analytical reasoning and a structured set of system aspects that can subsequently be specified.
What the Transformation Engine does not do
The Transformation Engine provides discipline for transforming engineering information, but it does not replace engineering judgement. Nor does it imply that every transformation can or should be automated.
It does not automatically generate Requirements
Analysis produces understanding and structured system aspects. Requirement formulation belongs to Specification.
It does not eliminate uncertainty
Where evidence is insufficient, the uncertainty should remain explicit until additional information becomes available.
It does not decide the design
Analytical reasoning should remain solution-independent unless a legitimate constraint restricts the available design space.
It does not replace the engineer
The rules structure engineering reasoning and make it inspectable, but interpretation, judgement and responsibility remain with the engineering process and its participants.
Requirements Engineering · Analysis
Information Model
The IMPULS3 Information Model defines the Information Elements used during Requirements Analysis and the semantic relations between them. It ensures that analytical reasoning, system consequences and their origins remain explicit, connected and traceable.
Analysis Statement
Structured system view
The Analysis Information Model builds on the information produced during Elicitation. Stakeholders, Stakeholder Needs and Source Information remain available and retain their original semantic relations. Analysis introduces additional Information Elements that make system-level reasoning and system consequences explicit.
The model is therefore cumulative rather than substitutive. New Information Elements are added to the existing information network; the information from earlier process steps is not discarded or overwritten.
Core Information Elements
Source Information
Recorded information preserving what was communicated, written, observed or otherwise obtained from a source, together with its provenance and context.
During Analysis, Source Information remains available as evidence and context for interpreting Stakeholder Needs and evaluating analytical conclusions.
Stakeholder
The person, group or organisation associated with the needs and information being analysed.
Stakeholder identity remains relevant because apparently similar needs may have different meanings, priorities or consequences depending on who expresses or owns them.
Stakeholder Need
A documented expression of an outcome, capability, quality or condition needed by a stakeholder, together with the rationale explaining why it matters.
Stakeholder Needs are principal inputs to Analysis but are not assumed to be system Requirements in their existing form.
Analysis Statement
An explicit statement capturing a relevant analytical conclusion, interpretation, assumption, clarification or other result of Analysis.
Analysis Statements preserve reasoning that would otherwise remain implicit between elicited information and subsequent system specification.
Function
An aspect describing what the System-of-Interest does. Functions represent required behaviour without prescribing how that behaviour is realised.
Property
An aspect describing a characteristic of the System-of-Interest or one of its Functions, such as capacity, response time, accuracy, availability or mass.
Constraint
An aspect restricting the permissible solution space. Constraints may originate from legislation, standards, interfaces, physical boundaries, mandated technologies or other externally imposed conditions.
Structured system view
The identified Functions, Properties and Constraints are organised into a coherent structure representing the relevant system aspects discovered during Analysis.
Semantic relations
The value of the Information Model lies not only in the Information Elements themselves, but also in the explicit semantic relations between them. These relations preserve provenance, rationale and analytical meaning.
Stakeholder ↔ Stakeholder Need
A Stakeholder Need is associated with the stakeholder or stakeholder group that expresses, owns or is affected by that need.
Source Information ↔ Stakeholder Need
Source Information provides provenance and evidence for the Stakeholder Need identified during Elicitation.
Stakeholder Need ↔ Analysis Statement
An Analysis Statement may interpret, clarify or draw a conclusion from one or more Stakeholder Needs.
Source Information ↔ Analysis Statement
Analytical reasoning may rely directly on Source Information where the original evidence or context is relevant to the conclusion.
Analysis Statement ↔ Function / Property / Constraint
An Analysis Statement may justify or explain why a particular Function, Property or Constraint is relevant to the System-of-Interest.
Stakeholder Need ↔ Function / Property / Constraint
Where no intermediate analytical reasoning is required, a system aspect may be related directly to one or more Stakeholder Needs while retaining explicit traceability.
Function ↔ Property
A Property may characterise a specific Function, for example the duration, capacity, accuracy or availability associated with that Function.
System aspect ↔ System aspect
Functions, Properties and Constraints may be related to one another where dependencies, interactions, conflicts or structural relationships exist.
From chain to traceability network
Requirements Analysis should not be represented as a simple fixed chain in which every Stakeholder Need produces exactly one Analysis Statement and exactly one system aspect. Real engineering information is more interconnected than that.
One-to-many
One Stakeholder Need may lead to several Analysis Statements and several Functions, Properties or Constraints.
Many-to-one
Several Stakeholder Needs may collectively support one Analysis Statement or one system aspect.
Many-to-many
A set of related needs may result in a network of system aspects whose meaning can only be understood from the complete body of information.
Direct and indirect relations
Some system aspects may be directly evident from a Stakeholder Need; others require intermediate Analysis Statements to make the reasoning explicit.
IMPULS3 principle. Traceability is a semantic network, not merely a sequence of identifiers. Relations should express why Information Elements are connected, not only that a connection exists.
Why Analysis Statements matter
Without an explicit analytical information layer, engineering reasoning is easily lost. A Requirement may then appear to have been derived directly from a Stakeholder Need, even when important interpretation, assumptions or trade-offs occurred in between.
Analysis Statements prevent this reasoning from disappearing. They provide a place to record why a system consequence follows from the available information and make that reasoning available for review, validation, change impact analysis and future reuse.
Stakeholder Need: Production Operations needs the machine to support rapid cleaning in order to minimise production downtime between production runs.
- Function: Clean machine
- Property: Cleaning duration
The structured system view
The structured output of Analysis is not merely a flat list. Functions, Properties and Constraints can be organised to reveal how relevant system aspects belong together and how they relate to the System-of-Interest.
The notation indicates that a system view may contain zero or more Functions, zero or more Properties and zero or more Constraints. The purpose is not mathematical formalism for its own sake, but to make the classification of system aspects explicit and systematic.
Functions
Functions capture what the system does. They provide the behavioural backbone of the system view.
Properties
Properties capture characteristics of the system or its Functions and can later be quantified where required during Specification.
Constraints
Constraints capture restrictions that limit the permissible design space independently of the design choices eventually made.
Coherent structure
Together, the system aspects form a structured analytical view that can be examined for completeness, consistency, dependencies and conflicts before Requirements are specified.
Information Model boundary: Analysis is not Specification
The Analysis Information Model deliberately distinguishes identified system aspects from Requirements. This prevents analytical understanding from being confused with normative specification.
A Property such as cleaning duration, for example, is analytically relevant but is not yet a complete Requirement. Specification must subsequently determine the required value, tolerance, conditions and normative formulation.
IMPULS3 principle. Preserve the distinction between understanding the system and specifying it. Analysis creates the structured system understanding on which Requirements can subsequently be based.
Relationship with Specification
The Information Model established during Analysis provides the semantic foundation for Specification. The next process step can formulate Requirements from an already structured and traceable body of system information rather than working directly from heterogeneous Stakeholder Needs and source material.
During Specification, relevant Functions, Properties and Constraints are expressed normatively and with the precision required for verification and validation. Their relations to the originating analysis and stakeholder information remain intact.
IMPULS3 principle. Precision may increase as information moves through the engineering lifecycle, but provenance, rationale and meaning must remain traceable to their origin.
Requirements Engineering · Analysis
Tools & Techniques
Tools & Techniques
Requirements Analysis relies on a combination of analytical techniques and supporting tools. Their purpose is to help engineers understand meaning, expose inconsistencies, identify system consequences, structure information and make reasoning explicit.
No single technique is sufficient for all Requirements Analysis work. Different questions require different approaches. Some techniques help understand meaning, others expose conflicts or dependencies, and others help structure the emerging system view.
IMPULS3 therefore treats Tools & Techniques as a toolbox from which the engineer selects the methods that best address the analysis problem at hand.
Start with the analysis question
A useful way to select a technique is to first formulate the question the analysis must answer.
What does this information mean?
Use clarification, terminology analysis, contextual analysis and discussion with domain experts to understand meaning and intent.
What does this imply for the system?
Use functional analysis, scenario analysis, modelling and causal reasoning to determine consequences for the System-of-Interest.
Does the information fit together?
Use consistency analysis, conflict analysis, dependency analysis and cross-checking between stakeholders, sources and system aspects.
Is anything missing?
Use completeness analysis, scenario walkthroughs, interface analysis and lifecycle thinking to identify gaps and missing perspectives.
Core analysis techniques
1 Decomposition
Break a complex need, concern or system aspect into smaller parts that can be understood and analysed independently while preserving their relationships.
Decomposition is particularly useful when a single Stakeholder Need contains several different concerns or implies several Functions, Properties or Constraints.
2 Classification
Determine the nature of an identified system aspect by classifying it as a Function, Property or Constraint.
Classification forces the analyst to understand what kind of information is being handled before attempting to formulate a Requirement.
3 Scenario analysis
Explore operational situations, use scenarios, exceptional conditions and lifecycle situations to understand how needs manifest themselves in practice.
Scenarios are especially effective for discovering hidden Functions, Properties, interfaces, exceptional behaviour and missing stakeholder needs.
4 Functional analysis
Identify what the System-of-Interest must do and examine how Functions relate, interact or depend on one another.
Functional analysis helps move from stakeholder language toward a system-oriented view without introducing implementation choices.
5 Property analysis
Identify characteristics that are relevant to the system or its Functions, such as performance, capacity, accuracy, availability, mass, maintainability or environmental behaviour.
At this stage the analyst identifies what matters; quantitative specification may follow later.
6 Constraint analysis
Identify restrictions that limit the permissible solution space and determine their origin, applicability and impact.
Constraints may arise from legislation, standards, existing interfaces, organisational policy, physical boundaries or mandated technology.
7 Interface analysis
Examine interactions between the System-of-Interest and external systems, users, organisations, environments or neighbouring system elements.
Interfaces frequently reveal Functions, Properties and Constraints that remain invisible when the system is considered in isolation.
8 Dependency analysis
Identify dependencies between Stakeholder Needs, Analysis Statements, Functions, Properties and Constraints.
Dependency analysis supports consistency checking and later change impact analysis.
9 Conflict analysis
Compare needs and identified system aspects to discover incompatible objectives, contradictory expectations or competing properties.
Conflicts should be made explicit and resolved deliberately rather than being hidden in Requirement wording.
10 Completeness analysis
Examine whether the emerging system view sufficiently covers relevant stakeholders, lifecycle stages, operational situations, interfaces and system aspects.
Completeness is assessed against the intended scope and available knowledge; it is not simply a matter of counting Requirements.
11 Consistency analysis
Check whether terms, assumptions, values, relations and identified system aspects are mutually compatible across the complete body of engineering information.
Consistency analysis includes semantic consistency as well as numerical, logical and structural consistency.
12 Assumption analysis
Identify assumptions that influence analytical conclusions and determine whether they are supported, need confirmation or introduce risk.
Significant assumptions should remain visible rather than being embedded unnoticed in the resulting specification.
Modelling techniques
Models help make relationships visible that are difficult to recognise in textual information alone. The model should be selected according to the analysis question, not because a particular notation happens to be available.
Functional models
Used to structure Functions and examine functional decomposition, dependencies, sequences and interactions.
Context models
Used to define the System-of-Interest, its boundary and relevant external actors, systems, organisations and environmental entities.
Interface models
Used to make interactions, exchanges and dependencies between the system and its environment explicit.
Behaviour models
Used to analyse sequences, states, events, modes and responses under normal and exceptional operating conditions.
Information models
Used to represent Information Elements and their semantic relations so that provenance, rationale and traceability remain explicit.
Dependency and relation maps
Used to expose connections between needs, assumptions, system aspects, interfaces and analytical conclusions.
IMPULS3 principle. A model is valuable when it reveals structure, behaviour or relationships that improve engineering understanding. Modelling is a means of analysis, not an end in itself.
Textual and semantic analysis
Much Requirements Analysis begins with language. Words that appear obvious may carry different meanings for different stakeholders or disciplines. Explicit semantic analysis is therefore an important part of the process.
Terminology analysis
Identify ambiguous, overloaded, undefined or domain-specific terms and establish agreed meanings where necessary.
Statement decomposition
Separate statements containing several concerns into distinct analytical elements so that each can be understood and traced independently.
Rationale analysis
Examine why a need exists and what consequence, objective or concern lies behind it. Rationale often reveals the actual system property that matters.
Semantic comparison
Compare apparently similar statements to determine whether they express the same intent, overlapping concerns or genuinely different system consequences.
Quantitative analysis
Where numerical information is available, quantitative techniques can reveal feasibility tensions, dependencies and required trade-offs before normative Requirements are formulated.
Budget analysis
Allocate or analyse an overall property across contributing system elements, such as mass, power, latency, accuracy or availability.
Sensitivity analysis
Examine how changes in one parameter influence relevant system outcomes and identify parameters to which system performance is particularly sensitive.
Trade-off analysis
Compare competing properties or objectives and make tensions visible without prematurely selecting a design solution.
Feasibility check
Examine whether combinations of intended values appear mutually achievable and identify areas requiring further investigation.
IMPULS3 principle. Quantitative analysis may inform Specification, but Analysis should not create false precision. Required values should only be introduced when sufficiently supported by stakeholder intent, evidence or justified engineering reasoning.
Supporting tools
Analysis may be performed with simple or sophisticated tools. The important criterion is whether the tool helps preserve structure, reasoning and traceability rather than obscuring them.
Requirements management systems
Support structured Information Elements, attributes, relations, status, traceability and controlled change.
Modelling environments
Support functional, behavioural, architectural and information modelling where graphical or formal representation improves understanding.
Spreadsheets and matrices
Useful for comparison, classification, coverage analysis, prioritisation, dependency mapping and quantitative analysis.
Diagrams and visual maps
Context diagrams, relation maps, state diagrams, functional trees and similar representations can reveal structure that is difficult to see in prose.
Calculation and simulation tools
Support quantitative reasoning, budgets, sensitivity studies and early assessment of system-level consequences.
Engineering repositories
Preserve Information Elements, semantic relations, Analysis Statements, supporting evidence and historical reasoning for later reuse and impact analysis.
Analysis Statements as an analytical technique
Recording an Analysis Statement is itself a useful analytical technique. Requiring the reasoning to be written explicitly often exposes assumptions, logical gaps or unsupported conclusions that remain invisible while reasoning stays implicit.
Suppose several stakeholders indicate that production interruptions must be minimised and that cleaning is required between product changes.
- Function: Clean machine
- Property: Cleaning duration
- Property: Production availability
Writing the analytical relation explicitly makes it possible to review whether the conclusion is justified and to trace later Requirements back to the reasoning that produced them.
Choosing the right technique
IMPULS3 does not prescribe a single mandatory set of analysis techniques. The appropriate technique depends on the system, the available information, the maturity of the analysis and the question that must be answered.
Need unclear?
Use clarification, terminology analysis, rationale analysis or additional Elicitation.
System consequences unclear?
Use scenarios, functional analysis, context modelling or causal reasoning.
Relations unclear?
Use dependency mapping, interface analysis or information modelling.
Conflicts or gaps suspected?
Use consistency, conflict and completeness analysis across the integrated information set.
IMPULS3 principle. Analysis is question-driven. Every model, matrix, calculation or workshop should contribute to a specific improvement in engineering understanding.
Requirements Engineering · Analysis
IMPULS3 Principles
IMPULS3 principles provide the rules that keep Requirements Analysis disciplined, transparent and traceable. They help ensure that analysis adds engineering understanding without losing stakeholder meaning, hiding reasoning or introducing premature solutions.
The principles below apply throughout Requirements Analysis. They are not separate process steps. They govern how information is interpreted, how conclusions are recorded, how system aspects are classified and how the resulting engineering information is related.
First determine what the available information means for the System-of-Interest. Identify and structure the relevant Functions, Properties and Constraints before attempting to formulate precise Requirements.
Analysis may interpret and structure information, but it must not silently alter the underlying stakeholder intent. Analytical conclusions must remain defensible from the information on which they are based.
Every significant analytical result should remain connected to the Information Elements that support it. Stakeholder Needs, Source Information, Analysis Statements and identified system aspects must remain semantically traceable.
Important interpretations, assumptions, clarifications and conclusions should not remain hidden in the analyst’s reasoning or be embedded implicitly in Requirement wording. Record them explicitly as Analysis Statements where they are relevant.
Stakeholder Needs should not be analysed in isolation when their meaning or consequences depend on other needs, stakeholders, sources, interfaces or contextual information. Analysis considers the complete relevant information set.
One Stakeholder Need may imply several system aspects, and several Stakeholder Needs may collectively lead to one Function, Property or Constraint. The Information Model must support the actual semantic relationships found during Analysis.
Determine first whether an identified system aspect is a Function, Property or Constraint. Classification clarifies the nature of the information before normative Requirement wording is introduced.
Ambiguities, assumptions, contradictions, missing information and unresolved dependencies should be made visible. Analysis must not create false certainty or hide unresolved issues in later Requirement wording.
Requirements Analysis determines required system behaviour, relevant properties and legitimate constraints without deciding how the system will realise them, unless an implementation choice is itself externally imposed as a valid constraint.
A Function, Property or Constraint identified during Analysis is not automatically a Requirement. Specification subsequently adds normative expression, required precision and, where applicable, quantitative values and conditions.
Three essential distinctions
Several of the principles above can be summarised through three distinctions that are particularly important in IMPULS3 Requirements Analysis.
Need versus analysis
A Stakeholder Need expresses what a stakeholder needs and why it matters. Analysis determines what that need, considered together with other information, means for the System-of-Interest.
Analysis versus specification
Analysis identifies and structures relevant system aspects. Specification turns those aspects into precise normative Requirements.
Requirement versus design
Requirements describe what is required of the System-of-Interest. Design determines how the system will realise those requirements.
Why the distinctions matter
Keeping these boundaries explicit prevents stakeholder intent, engineering reasoning, system specification and design decisions from becoming mixed into a single body of difficult-to-maintain statements.
Principles in the information flow
The Analysis principles can also be understood as safeguards applied to the flow of engineering information.
Common anti-patterns
The principles become especially useful when contrasted with recurring analysis mistakes.
Rewrite-and-call-it-a-requirement
A Stakeholder Need is linguistically rewritten into “The system shall …” without analysing what the complete stakeholder information means for the system.
Invisible reasoning
The analyst makes an important interpretation or assumption, but only the resulting Requirement is stored. The reasoning behind it disappears.
Statement-by-statement analysis
Every need is treated independently, causing dependencies, conflicts and system-level consequences across multiple needs to remain unnoticed.
Premature solutioning
A possible implementation is introduced during Analysis and subsequently mistaken for something the stakeholders or system inherently require.
False precision
Numerical values are introduced without sufficient evidence simply because a Requirement is expected to contain a measurable threshold.
Lost provenance
A system aspect appears in the specification, but it is no longer possible to determine which stakeholder information, evidence or analytical reasoning justified it.
The essence of Requirements Analysis
This sequence is not intended as a rigid procedural waterfall. Analysis remains iterative and may return to Elicitation when information is missing or contradictory. The principle expresses the logical separation of concerns: understanding and reasoning should precede normative specification.
IMPULS3 principle. Increase structure and precision as engineering information progresses, but never at the expense of meaning, provenance or justified uncertainty.
Thoughts, ideas, concepts, references, and other stuff related to Requirements Analysis
- “The results of the train of thought … are very useful and should not be lost.” [PottsTakahashiAnton1994]