IMPULS3 – definitions

Category: Information Model | Requirements Engineering | Requirements Analysis

Definition

An Analysis Statement is a documented conclusion, interpretation, assumption, decision, or insight resulting from the analysis of Stakeholder Needs and other source information, which provides the rationale for deriving one or more requirements.

Explanation

Requirements are rarely derived directly from stakeholder statements. Stakeholder Needs are often incomplete, ambiguous, qualitative, contradictory, or expressed from a particular stakeholder perspective.

During Requirements Analysis, Requirements Engineers study Stakeholder Needs, source documents, operational concepts, legislation, standards, existing systems, and other relevant information. The conclusions reached during this analysis are documented as Analysis Statements.

Analysis Statements capture the reasoning that transforms raw stakeholder input into formal requirements. They make the engineering thought process explicit and thereby preserve the meaning and intent behind the derived requirements.

Purpose

Analysis Statements serve several important purposes:

• Document the rationale behind requirements.
• Capture assumptions and engineering decisions.
• Resolve ambiguities and contradictions.
• Preserve stakeholder intent.
• Support traceability and impact analysis.
• Facilitate reviews, audits, and future system evolution.

Examples

The following examples illustrate typical Analysis Statements.

Example Traceability Chain

Within IMPULS3, the preferred traceability chain is:

Additional information objects such as source documents, assumptions, architectural decisions, functions, properties, and constraints may also participate in this traceability network.

Characteristics of Good Analysis Statements

Analysis Statement versus Requirement

Related concepts

• Stakeholder
• Stakeholder Need
• Requirement
• Traceability
• Requirements Analysis
• Rationale

References

Robertson, S., & Robertson, J. (2012). Mastering the Requirements Process: Getting Requirements Right (3rd ed.). Addison-Wesley.

Gilb, T. (2005). Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Elsevier Butterworth-Heinemann.

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

Category: Information Model | Configuration Management | Requirements Engineering | Systems Engineering

Definition

A Baseline is a formally approved and controlled set of information objects that serves as the authoritative reference for subsequent engineering activities and can only be changed through an established change management process.

Explanation

Throughout the system lifecycle, engineering information continuously evolves. At certain points in time, it is necessary to establish stable reference points that enable stakeholders to work with a consistent and agreed-upon set of information.

Such a reference point is called a Baseline.

Baselines provide stability and control in an otherwise continuously changing engineering environment. They ensure that all stakeholders work from the same agreed version of the system definition.

Within IMPULS3, baselines may contain any type of information object, including Stakeholder Needs, Requirements, Analysis Statements, Design Decisions, architectural information, verification information, or complete information models.

Purpose

Baselines serve several important purposes:

• Establish a common and agreed reference for all stakeholders.
• Provide stability during engineering activities.
• Enable controlled change management.
• Support traceability throughout the lifecycle.
• Facilitate audits, reviews, and contractual agreements.
• Preserve the history and evolution of engineering information.

Examples of Baselines

Lifecycle of a Baseline

The establishment of a baseline typically follows the following sequence:

Once established, modifications to baseline information are managed through formal change management procedures.

Baseline versus Version

Baseline versus Release

Configuration Management

Baselines are a fundamental concept within Configuration Management. They enable organizations to maintain consistency between engineering information, system realizations, and operational systems throughout the lifecycle.

Within IMPULS3, baseline management is an important activity of both Requirements Management and Publication & Release Management.

Related concepts

• Configuration Management
• Change Management
• Release
• Version
• Requirement
• Publication & Release Management

References

ISO/IEC/IEEE. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes. ISO.

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

National Aeronautics and Space Administration. (2007). NASA Systems Engineering Handbook (Rev. 1, NASA/SP-2007-6105). NASA.

Category: Information Model | Architecture & Design Engineering | Systems Engineering

Definition

A Building Block is an independently defined, coherent realization unit that contributes one or more functions to a system and is characterized by its own functions, properties, and constraints.

Explanation

Within IMPULS3, Building Blocks constitute the primary elements of the realization architecture of a system. They represent coherent units that can exist independently and that contribute value to the system by performing one or more functions.

Every Building Block is treated as an independent entity and is therefore defined in exactly the same manner as any other system element: by its own functions, properties, and constraints.

Functional Perspective versus Realization Perspective

IMPULS3 explicitly distinguishes between the functional architecture and the realization architecture.

Functional architectures describe what the system shall do by means of Systems, Subsystems, and Functional Elements.

Realization architectures describe how these functions are realized by means of Building Blocks.

A functional element such as a Braking System, Propulsion System, or Lighting System is not necessarily a Building Block. These elements describe functionality and are often realized by multiple Building Blocks.

Characteristics of a Building Block

A Building Block typically possesses the following characteristics:

• It forms a coherent realization unit.
• It performs one or more identifiable functions.
• It possesses its own properties and constraints.
• It can be independently specified and engineered.
• It can be physically, logically, organizationally, or digitally realized.
• It may participate in one or more Assemblies.

Building Blocks, Functional Elements, Parts, and Assemblies

Example: Passenger Car

Consider a passenger car as the System-of-Interest.

The Braking System is a Functional Element because it describes a set of functions:

• Decelerate vehicle.
• Stop vehicle.
• Hold vehicle stationary.

The Braking System itself is not a Building Block because it does not constitute a coherent realization unit. Instead, it is realized by multiple Building Blocks, for example:

• Brake Pedal.
• Master Cylinder.
• Brake Caliper.
• Brake Disc.
• ABS Controller.

The Brake Pedal constitutes a Building Block because it:

• Performs distinct functions.
• Possesses its own properties and constraints.
• Represents a coherent realization unit.

The Brake Pedal may itself contain multiple Parts.

Physically, the Brake Pedal may be grouped within the Cabin Assembly, together with other Building Blocks and Assemblies.

Relationships are External to the Building Block

Relationships between Building Blocks are modeled explicitly and are not considered part of the Building Block definition itself.

Consequently, the same Building Block may be mandatory in one system, optional in another system, and conditionally included in a third system without requiring multiple Building Block definitions.

Related concepts

• System
• Functional Element
• Function
• Property
• Constraint
• Part
• Assembly
• Architecture

References

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

Maier, M. W., & Rechtin, E. (2009). The Art of Systems Architecting (3rd ed.). CRC Press.

ISO/IEC/IEEE. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes. ISO.

Category: Foundations | Information Model | Systems Engineering

Definition

A constraint is a limitation, boundary condition, or externally imposed condition that restricts the design, realization, operation, or evolution of a system.

Explanation

While functions describe what a system does and properties describe how well it performs, constraints define the conditions under which the system must exist or operate.

Constraints typically originate from sources external to the system itself, such as legislation, standards, organizational policies, contractual obligations, physical limitations, existing architectures, or environmental conditions.

Constraints limit the solution space available to designers and engineers. They define boundaries that must be respected regardless of the chosen system design.

Examples of constraints include:

• Compliance with laws, regulations, and standards.
• Reuse of existing infrastructure or architectural elements.
• Budget limitations.
• Available physical space.
• Environmental operating conditions.
• Mandatory interfaces to external systems.

Unlike properties, constraints are not characteristics of the system itself, but conditions that the system must satisfy.

Example

Consider an electric kettle.

Function:

• Heat water.

Property:

• Heat 1 litre of water within 120 seconds.

Possible constraints:

• The kettle shall operate on a 230 V AC power supply.
• The kettle shall comply with applicable CE safety regulations.
• The kettle shall fit within a maximum footprint of 250 mm × 180 mm.
• The kettle shall reuse the organization’s standard power connector.

These constraints do not describe what the kettle does or how well it performs, but rather the conditions that limit or influence its design and operation.

Constraint versus Property

Related concepts

• Function
• Property
• Requirement
• System

References

International Council on Systems Engineering (INCOSE). (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. ISO.

Category: Information Model | Architecture & Design Engineering | Systems Engineering

Definition

A Design Decision is a documented engineering statement that records the selection of a Design Option and provides the rationale for that selection.

Explanation

During Architecture & Design Engineering, engineers search for solutions that address the design challenges represented by one or more requirements. Typically, multiple Design Options are identified and evaluated before a final solution is selected.

Within IMPULS3, the selected solution itself is not considered to be the Design Decision. Rather, the Design Decision is the explicit statement that documents which Design Option has been selected and why that option was chosen over alternative solutions.

Design Decisions therefore capture essential engineering knowledge, assumptions, trade-offs, and rationale. They preserve the reasoning behind the system architecture and provide an explicit bridge between the problem space and the solution space.

Design Challenge, Design Option, and Design Decision

Example

Consider the following requirement:

The vehicle shall be transportable by a CH-47 Chinook helicopter.

From the designer’s perspective, this requirement represents a Design Challenge.

Possible Design Options could be:

• Modular vehicle architecture.
• Foldable vehicle architecture.
• Lightweight monolithic vehicle architecture.

The corresponding Design Decision could be:

The modular vehicle architecture is selected because it provides the best balance between transportability, maintainability, and lifecycle cost.

Traceability

Within IMPULS3, Design Decisions play an important role in preserving engineering rationale.

The preferred traceability chain is:

Derived requirements are frequently introduced as a consequence of Design Decisions.

Instead, the engineering rationale leading to new requirements shall be made explicit through information objects such as Design Decisions.

Examples of Design Decisions

Design Decision versus Requirement

Related concepts

• Requirement
• Analysis Statement
• Traceability
• Architecture
• Constraint
• Systems Engineering

References

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

Maier, M. W., & Rechtin, E. (2009). The Art of Systems Architecting (3rd ed.). CRC Press.

ISO/IEC/IEEE. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes. ISO.

Category: Foundations | Quality Management | Systems Engineering | Information Model

Definition

Within IMPULS3, Extrinsic Quality is the degree to which an information object, product, or system satisfies relevant stakeholder needs and supports intended outcomes in a specified context of use.

Explanation

Extrinsic Quality concerns the relationship between an item and the purpose it is intended to serve. Assessment therefore requires identified stakeholders, intended use, relevant conditions, and explicit criteria for success.

The same item may be suitable in one situation and unsuitable in another. A report may support one decision well but omit information essential to another; a product may work effectively in one operating environment and inadequately in another.

Extrinsic Quality concerns demonstrated suitability, not merely reputation, appearance, or perceived prestige. Stakeholder perceptions may provide evidence where relevant, but assessment should also consider observable outcomes and applicable constraints.

High [[Intrinsic Quality]] can contribute to high Extrinsic Quality, but cannot guarantee it. Conversely, an item may serve an immediate purpose despite internal defects; those defects may still threaten its continued suitability.

Purpose

• Connect quality assessment to stakeholder needs and intended outcomes.
• Make context and assumptions explicit when judging suitability.
• Detect technically sound solutions that address the wrong problem.
• Support validation, acceptance decisions, and reassessment when needs or conditions change.

Examples

Assessment

• Identify stakeholders, intended outcomes, and relevant needs.
• Specify the context of use, including users, tasks, environment, and constraints.
• Define observable success criteria and evaluate representative scenarios.
• Record results and trade-offs, and reassess when the context or needs change.

[[Intrinsic Quality]] versus Extrinsic Quality

Relationship to Verification and Validation

Verification assesses conformity to specified requirements; validation assesses suitability for intended use. This is related to, but not identical with, the distinction made here. Verification can address requirements derived from either intrinsic or extrinsic quality criteria. Validation provides evidence relevant to Extrinsic Quality.

Related concepts

• [[Intrinsic Quality]]
• [[Stakeholder]]
• [[Stakeholder Need]]
• [[Requirement]]

References

The following sources provide related quality and assessment concepts; they do not prescribe the IMPULS3 definitions of Intrinsic Quality and Extrinsic Quality given here.

ISO/IEC. (2023). ISO/IEC 25010:2023 — Product quality model .

ISO/IEC. (2023). ISO/IEC 25019:2023 — Quality-in-use model .

NASA. Systems Engineering Handbook, Section 2.4: Distinctions between Product Verification and Product Validation .

Category: Foundations | Information Model | Systems Engineering

Definition

A function describes what a system, subsystem, or system element does, or is intended to do, in order to create value for one or more stakeholders.

Explanation

In IMPULS3, functions are used to describe the intended behavior or capability of a system without immediately prescribing how that behavior must be realized. A function therefore focuses on the purpose or contribution of an element within its context.

Functions can exist at different levels of a system. A system may have a primary function that expresses its main purpose, and secondary functions that support, enable, protect, inform, or improve the performance of the primary function.

A function is not yet a requirement by itself. It becomes part of the requirements specification when its relevant properties are quantified and expressed in verifiable terms.

Example

For an electric kettle, a primary function could be: heat water.

Related properties may include heating time, maximum water volume, target temperature, and energy consumption. Once these properties are quantified, they can be expressed as requirements.

Related concepts

• Property
• Constraint
• Requirement
• System

Category: Information Model | Architecture & Design | Integrated Engineering System Structure

Definition

A Functional Element is an architectural element in the Functional System Structure that represents a functionally coherent part of the system and groups the Building Blocks that collectively contribute to that functional responsibility.

Explanation

A Functional Element provides a functional perspective on the architecture of a system. It identifies a coherent area of system responsibility without prescribing where or how that responsibility is physically realized.

Functional Elements form the hierarchical structure of the Functional System Structure (FSS). A Functional Element may contain subordinate Functional Elements and may be associated with one or more Building Blocks that contribute to its functional responsibility.

A Functional Element should not be confused with a Function. A Function describes what the system does, whereas a Functional Element is an architectural element used to organize the system according to functional responsibility. Functions can therefore be allocated to Functional Elements.

Likewise, a Functional Element should not be interpreted as a physical component or location. The physical organization of Building Blocks is represented separately in the Physical System Structure (PSS).

Purpose

Functional Elements serve several important purposes:

• Structure the system according to functional responsibility.
• Organize related Functions and Building Blocks into coherent functional areas.
• Support allocation of Functions to architectural elements.
• Provide functional parentage for Building Blocks.
• Separate functional organization from physical organization.
• Support traceability between requirements, functions, architecture, and Building Blocks.
• Provide the structural basis for the Functional System Structure.

Example

Consider a passenger car as the System-of-Interest. The Braking System can be represented as a Functional Element because it groups the architectural responsibility associated with controlling and reducing the motion of the vehicle.

Functions such as detect driver braking demand, generate braking force, and control wheel braking can be allocated to this Functional Element.

Building Blocks such as the brake pedal, brake control unit, hydraulic components, brake calipers, and brake discs may contribute to realizing this functional responsibility. These Building Blocks may, however, be distributed across different physical parts of the vehicle.

Functional versus Physical Perspective

Relationship within the IESS

Within the Integrated Engineering System Structure (IESS), Functional Elements are used to construct the Functional System Structure. Building Blocks connect this functional perspective to the Physical System Structure.

A Building Block can therefore be viewed from two complementary perspectives: it has a functional context through its Functional Element and a physical context through its position in the Physical System Structure. This separation allows the functional and physical architectures to evolve without unnecessarily coupling the two structures.

Characteristics of a Good Functional Element

Related concepts

• Function
• Building Block
• Requirement
• System
• Traceability

Category: Information Model | Integrated Engineering | Configuration Management

Definition

An Instance is a uniquely identifiable individual realization of a Type.

Explanation

An Instance represents a specific element that exists in the real world and can be individually identified. Whereas a Type defines a class of interchangeable or equivalent elements, an Instance represents one particular realization of that Type.

An Instance therefore has its own identity, typically established by a serial number or another unique identifier, and can have information that is specific to that individual element, such as its actual configuration, measured property values, manufacturing records, inspection results, verification evidence, maintenance history, or operational state.

An Instance is not the same as its Type. A Type specifies what may be supplied or produced; an Instance is the individual element that has actually been supplied or produced according to that Type.

Building Block, Type, and Instance

IMPULS3 distinguishes three related but fundamentally different identities across the realization chain:

Relationship

The relationship between a Building Block, a Type, and an Instance can be expressed as:

Conversely, following the trace from a physical Instance towards its engineering definition:

Examples

The following examples illustrate the distinction at different levels of a system decomposition.

Property Example

The distinction between Building Block, Type, and Instance also applies to property information. The property itself retains its semantic meaning, while different information is associated with it throughout engineering and realization.

Instance and Conformity

Traceability from an Instance through its Type to the corresponding Building Block enables different conformity questions to be answered independently.

Instance versus Type

Terminology

The term Instance is preferred over Individual within IMPULS3 because it explicitly expresses the relationship between a uniquely identifiable realized element and the Type from which it originates. Individual may be used descriptively to emphasize that the Instance represents one specific element rather than a class or Type.

Instantiation refers to the relationship or act of realizing an Instance from a Type; it does not refer to the realized element itself.

Related concepts

• Building Block
• Type
• Property
• Requirement
• Traceability
• Configuration
• Verification

Category: Foundations | Quality Management | Systems Engineering | Information Model

Definition

Within IMPULS3, Intrinsic Quality is the degree to which an information object, product, or system satisfies explicit quality criteria concerning its own constitution, structure, and internal coherence, assessed separately from its suitability for a particular stakeholder purpose or context of use.

Explanation

Intrinsic Quality concerns how well an item is specified, organized, constructed, or realized. Depending on the type of item, relevant criteria may include clarity, consistency, structural integrity, precision, and workmanship.

For an information object, this may concern unambiguous statements, consistent terminology, and the absence of internal contradictions. For a physical product, it may concern assembly integrity or manufacturing precision against defined criteria.

A well-formed item is not necessarily a useful or appropriate item. A specification may be clear and internally consistent while describing a solution that does not meet the actual stakeholder need.

Intrinsic does not mean that quality is an absolute property without an assessment basis. The applicable criteria, scope, and measurement conditions must still be stated. Completeness and correctness require an explicit reference: completeness against a document structure differs from completeness against stakeholder needs.

Purpose

• Identify defects in the structure and realization of information objects, products, and systems.
• Support consistent reviews and measurable quality criteria.
• Reduce ambiguity, contradictions, and avoidable rework.
• Establish confidence in the integrity of items used in subsequent engineering activities.

Examples

Assessment

• Identify the item and the boundary of the assessment.
• Define applicable criteria for its constitution and internal coherence.
• Select reviews, inspections, analyses, or tests that provide evidence against those criteria.
• Record defects, evidence, and limitations; assess fitness for purpose separately.

Intrinsic Quality versus Extrinsic Quality

Relationship to Verification and Validation

Verification assesses conformity to specified requirements; validation assesses suitability for intended use. This is related to, but not identical with, the distinction made here. Verification can address requirements derived from either intrinsic or extrinsic quality criteria. Validation provides evidence relevant to Extrinsic Quality .

Related concepts

• Extrinsic Quality
• Requirement
• Property

References

The following sources provide related quality and assessment concepts; they do not prescribe the IMPULS3 definitions of Intrinsic Quality and Extrinsic Quality given here.

ISO/IEC. (2023). ISO/IEC 25010:2023 — Product quality model .

ISO/IEC. (2023). ISO/IEC 25019:2023 — Quality-in-use model .

NASA. Systems Engineering Handbook, Section 2.4: Distinctions between Product Verification and Product Validation .

Category: Information Model | Architecture & Design | Integrated Engineering System Structure

Definition

A Physical Element is an architectural element in the Physical System Structure that represents a physically coherent part, location, compartment, assembly, or spatial subdivision of the system and provides the physical context in which Building Blocks are positioned, mounted, installed, or assembled.

Explanation

A Physical Element provides a physical perspective on the architecture of a system. It identifies how the system is physically organized without defining the functional responsibility of the Building Blocks contained within it.

Physical Elements form the hierarchical structure of the Physical System Structure (PSS). A Physical Element may contain subordinate Physical Elements and may provide the physical parent for one or more Building Blocks.

A Physical Element should not be confused with a Building Block. A Building Block is a realizable element that contributes to the functionality of the system, whereas a Physical Element provides the physical or spatial structure in which Building Blocks are organized.

Likewise, a Physical Element should not be interpreted as a functional subdivision of the system. Functional organization is represented separately by Functional Elements in the Functional System Structure.

Purpose

Physical Elements serve several important purposes:

• Structure the system according to its physical organization.
• Represent physical parts, locations, compartments, assemblies, or spatial subdivisions.
• Provide physical parentage for Building Blocks.
• Support reasoning about positioning, mounting, installation, assembly, and spatial integration.
• Separate physical organization from functional organization.
• Support analysis of physical interfaces and integration.
• Provide the structural basis for the Physical System Structure.

Example

Consider a passenger car as the System-of-Interest. Physical Elements can be used to describe physically coherent parts of the vehicle such as the passenger compartment, engine compartment, front axle area, or wheel assembly.

The Building Blocks associated with the braking functionality are distributed across several of these Physical Elements. The brake pedal may be positioned in the passenger compartment, the brake control unit may be mounted elsewhere in the vehicle, and the brake caliper and brake disc may be assembled within the wheel area.

Although these Building Blocks collectively contribute to the functional responsibility represented by the Braking System Functional Element, they do not necessarily share the same physical parent.

Functional versus Physical Perspective

Relationship within the IESS

Within the Integrated Engineering System Structure (IESS), Physical Elements are used to construct the Physical System Structure. Building Blocks connect this physical perspective to the Functional System Structure.

A Building Block therefore participates in two complementary architectural structures. It has a functional context through its position relative to a Functional Element and a physical context through its position relative to a Physical Element.

This allows the same set of Building Blocks to be organized differently depending on the architectural perspective: according to functional responsibility in the Functional System Structure and according to physical organization in the Physical System Structure.

Characteristics of a Good Physical Element

Related concepts

• Functional Element
• Building Block
• System
• Requirement
• Traceability

Category: Foundations | Information Model | Systems Engineering

Definition

A property is a characteristic or attribute of a system, subsystem, or system element that describes how well it performs, behaves, or exists.

Explanation

While a function describes what a system does, a property describes an observable or measurable characteristic of that system. Properties characterize either the execution of a function or the system as a whole.

Examples of properties include performance, mass, volume, reliability, availability, energy consumption, accuracy, capacity, maintainability, and response time.

In IMPULS3, every property must ultimately be quantified. Once a property is quantified, it becomes part of the requirements specification and can be objectively verified.

Properties may be associated with:

• Functions — for example, the heating time of a kettle while performing its heating function.
• Systems as a whole — for example, the total mass, footprint, or lifecycle cost of a system.

IMPULS3 deliberately avoids the traditional distinction between “functional” and “non-functional” requirements. Instead, all system characteristics are expressed as either functions, properties, or constraints.

Example

Consider an electric kettle.

Function:

• Heat water.

Possible properties of this function:

• Heating time.
• Maximum water volume.
• Energy consumption.
• Temperature accuracy.

Initially, these properties may be expressed qualitatively:

The kettle shall heat water quickly.

In IMPULS3, such statements are considered incomplete because the property has not yet been quantified. A quantified property could be:

The kettle shall heat 1 litre of water from 20°C to 100°C within 120 seconds.

Related concepts

• Function
• Constraint
• Requirement
• Quantification
• System

References

Gilb, T. (2005). Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Elsevier Butterworth-Heinemann.

International Council on Systems Engineering (INCOSE). (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

Category: Foundations | Information Model | Requirements Engineering

Definition

A requirement is a quantified and verifiable statement that specifies a function, property, or constraint that a system or system element shall satisfy.

Explanation

Requirements are the primary means by which stakeholder needs are translated into an unambiguous and verifiable system definition.

Within IMPULS3, requirements are considered formal statements that communicate what a system must do, how well it must perform, or under which conditions it must operate.

IMPULS3 distinguishes between:

• Stakeholder Needs — expressions of expectations, desires, concerns, or problems originating from stakeholders.
• Requirements — formalized, quantified, and verifiable statements derived from stakeholder needs.

A requirement is not simply a wish or a statement of intent. It must be formulated in such a way that compliance can be objectively determined.

The assessment of whether a requirement is correctly formulated and accurately represents stakeholder needs is performed during the Verification & Validation activities within the Requirements Engineering process.

In IMPULS3, systems are fully defined by their functions, properties, and constraints. Consequently, requirements are used to specify one or more of these three aspects.

Examples

The following table illustrates the distinction between stakeholder needs and requirements.

Characteristics of Good Requirements

Within IMPULS3, a high-quality requirement exhibits both intrinsic and extrinsic quality.

Examples of Requirement Types

Related concepts

• Stakeholder Need
• Function
• Property
• Constraint
• Requirements Engineering
• Verification
• Validation

References

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. ISO.

Robertson, S., & Robertson, J. (2012). Mastering the Requirements Process: Getting Requirements Right (3rd ed.). Addison-Wesley.

Gilb, T. (2005). Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Elsevier Butterworth-Heinemann.

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

Category: Processes | Foundations | Systems Engineering

Definition

Requirements Engineering is the systematic process of eliciting, analyzing, specifying, verifying, validating, managing, and publishing requirements in order to transform stakeholder needs into a complete, consistent, and traceable system definition.

Explanation

Requirements Engineering (RE) forms the foundation of successful Systems Engineering. It ensures that stakeholder needs, expectations, concerns, and objectives are properly understood and translated into high-quality requirements that guide architecture, design, realization, verification, validation, and system usage activities.

Within IMPULS3, Requirements Engineering is considered an iterative and collaborative process involving stakeholders from multiple disciplines throughout the system lifecycle.

The primary objective of Requirements Engineering is not merely to produce requirements documents, but to establish and maintain a shared understanding of what the system must achieve and under which conditions it shall operate.

The IMPULS3 Requirements Engineering Process

The IMPULS3 method distinguishes six closely related Requirements Engineering activities:

Stakeholder Needs versus Requirements

IMPULS3 makes an explicit distinction between Stakeholder Needs and Requirements.

Within IMPULS3, every expectation, wish, concern, or problem expressed by a stakeholder is initially treated as a Stakeholder Need. Through analysis, these needs are transformed into formal requirements.

Requirements Quality

IMPULS3 distinguishes two complementary aspects of requirements quality:

Requirements Engineering versus Systems Engineering

Benefits of Requirements Engineering

• Improves communication among stakeholders.
• Reduces ambiguity and misunderstandings.
• Provides a sound basis for architecture and design.
• Supports objective verification and validation.
• Enables impact analysis and change management.
• Preserves stakeholder intent through traceability.
• Reduces project risks and lifecycle costs.

Related concepts

• Stakeholder
• Stakeholder Need
• Requirement
• Traceability
• Verification
• Validation
• Systems Engineering

References

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. ISO.

Robertson, S., & Robertson, J. (2012). Mastering the Requirements Process: Getting Requirements Right (3rd ed.). Addison-Wesley.

Gilb, T. (2005). Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Elsevier Butterworth-Heinemann.

Michielsen, C., Hasse, T., & Fischer, K. (2013). SITIO: A stakeholder-oriented approach for assessing requirements quality.

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.

Category: Foundations | Information Model | Requirements Engineering

Definition

A stakeholder is an individual, group, or organization that has an interest in a system, can affect it or decisions concerning it, is affected by it, or perceives itself to be affected by it.

Explanation

Stakeholders are a primary source of needs, expectations, concerns, objectives, and criteria by which system success is judged. Other relevant information may originate from sources such as legislation, standards, existing systems, operational data, and the physical or organizational environment.

Stakeholders may interact directly with a system, influence its development or operation, or be affected by it without directly interacting with it.

Examples of stakeholders include users, operators, maintainers, customers, owners, regulatory authorities, suppliers, management, support organizations, and neighboring communities.

Within IMPULS3, stakeholders are identified during Requirements Elicitation and their interests, concerns, expectations, needs, priorities, and underlying rationale are explored. The resulting Stakeholder Needs are linked to the supporting Source Statements and are subsequently analyzed integrally during Requirements Analysis to determine what the complete set of needs means for the system.

Understanding stakeholders and the reasons behind their needs is essential for establishing well-founded Stakeholder Needs and, ultimately, well-founded requirements.

Examples

The following table illustrates typical stakeholders for different types of systems.

Stakeholder Categories

Stakeholders can be categorized in many ways. The following categories can be used as a practical aid within IMPULS3; they are not intended as a normative taxonomy.

Stakeholder Analysis

Stakeholder Analysis is the activity of identifying relevant stakeholders and understanding their relationship to the system, including:

• Their interests and concerns.
• Their expectations and needs.
• The rationale behind their needs.
• Their priorities.
• Their influence on the project or system.
• Their business, mission, operational, or societal drivers and motivations.

Within IMPULS3, this stakeholder-focused investigation is primarily part of Requirements Elicitation. It should not be confused with the subsequent Requirements Analysis process, in which the complete set of elicited Stakeholder Needs is analyzed integrally from the perspective of the system.

Stakeholder versus User

Relationship to Source Statements and Stakeholder Needs

A stakeholder may provide one or more Source Statements during Elicitation. These statements preserve what was said, written, observed, or otherwise discovered. Through clarification and exploration of rationale and context, one or more Stakeholder Needs may be identified and linked back to the supporting Source Statements.

This preserves the information chain from original evidence to understood need and allows later analysis, change assessment, and validation to return to the stakeholder context in which the need originated.

Related concepts

• Source
• Source Statement
• Stakeholder Need
• Requirements Engineering
• Traceability
• Analysis Statement
• System

References

Freeman, R. E. (1984). Strategic management: A stakeholder approach. Pitman.

International Council on Systems Engineering. (2023). Systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley.

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. ISO.

Mitchell, R. K., Agle, B. R., & Wood, D. J. (1997). Toward a theory of stakeholder identification and salience: Defining the principle of who and what really counts. Academy of Management Review, 22(4), 853–886.

Wheatcraft, L. S., Ryan, M. J., & Katz, T. E. (2024). INCOSE needs and requirements manual: Needs, requirements, verification, validation across the lifecycle (Version 2). Wiley.

Category: Foundations | Information Model | Requirements Engineering

Definition

A Stakeholder Need is a documented expression of an outcome, capability, quality, or condition needed by a stakeholder, together with the rationale that explains why the need is important.

Explanation

Stakeholder Needs are a primary output of Requirements Elicitation and form an important input to Requirements Analysis. They express the stakeholder intent that has been identified and understood through investigation of relevant source information.

A Stakeholder Need is more than a direct stakeholder statement. During Elicitation, Source Statements are captured and the stakeholder is asked to explain the underlying problem, objective, concern, expectation, and context. This allows the elicitor to understand not only what is needed, but also why the need matters.

Stakeholder Needs are normally expressed in natural language and do not yet need to have the precision, quantification, structure, or verifiability expected of formal requirements. They should, however, be sufficiently clear to preserve the stakeholder’s intent, rationale, and relevant context.

A Stakeholder Need is therefore neither a raw Source Statement nor a Requirement. It is an understood expression of stakeholder intent that provides the bridge between captured source information and subsequent integral analysis.

From Source Statement to Stakeholder Need

A Source Statement preserves what was said, written, observed, or otherwise discovered. Elicitation explores the meaning, rationale, and context of that source information and uses it to establish one or more Stakeholder Needs.

Core Information

Within the IMPULS3 Information Model, a Stakeholder Need should retain sufficient information to preserve its meaning and origin. Typical information includes:

• Identifier — a unique identity for the Stakeholder Need.
• Statement — a concise expression of what is needed.
• Rationale — why the need is important to the stakeholder.
• Stakeholder — the stakeholder associated with the need.
• Context — relevant circumstances or lifecycle situations in which the need applies.
• Source Statement(s) — the captured source information supporting the need.
• Status — the current lifecycle or workflow state of the information element.

A stakeholder may also express a priority or urgency during Elicitation. Such information should be preserved as part of the stakeholder perspective, but should not automatically be interpreted as the overall system priority. Integral prioritization requires consideration of the complete set of Stakeholder Needs during Requirements Analysis.

Example

The following example illustrates how a Source Statement can lead to a Stakeholder Need.

Stakeholder Need versus Requirement

A Stakeholder Need expresses stakeholder intent before the complete set of needs has been analyzed from the perspective of the system. A Requirement specifies a necessary function, property, or constraint for the system or another subject of specification.

Role in Requirements Engineering

Stakeholder Needs are established during Requirements Elicitation from Source Statements and other relevant source information. Requirements Analysis then considers the complete set of Stakeholder Needs integrally to identify relationships, dependencies, conflicts, gaps, relevant system aspects, and the consequences for the system as a whole.

The results of this analysis are captured as Analysis Statements. Requirements are subsequently formulated during Specification. A Stakeholder Need should therefore not be transformed directly into a Requirement without preserving the intermediate analysis and reasoning.

Within IMPULS3, the information chain is:

Source → Source Statement → Stakeholder Need → Analysis Statement → Requirement.

A single Stakeholder Need may contribute to multiple Analysis Statements and Requirements, while multiple Stakeholder Needs may collectively support a single Analysis Statement or Requirement. Traceability preserves these many-to-many relationships and the stakeholder intent behind them.

Alignment with INCOSE

The IMPULS3 concept of a Stakeholder Need is consistent with the distinction made in the INCOSE Needs and Requirements Manual between stakeholder perspectives, needs, and requirements. IMPULS3 additionally makes the supporting Source Statements explicit as information elements in order to preserve provenance and traceability from original source information to understood stakeholder intent.

Related concepts

• Source
• Source Statement
• Stakeholder
• Analysis Statement
• Requirement
• Requirements Engineering
• Traceability

References

Robertson, S., & Robertson, J. (2012). Mastering the requirements process: Getting requirements right (3rd ed.). Addison-Wesley.

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. ISO.

International Council on Systems Engineering. (2023). Systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley.

Wheatcraft, L. S., Ryan, M. J., & Katz, T. E. (2024). INCOSE needs and requirements manual: Needs, requirements, verification, validation across the lifecycle (Version 2). Wiley.

Category: Foundations | Information Model | Systems Engineering

Definition

A system is a coherent set of interacting elements that collectively perform one or more functions in order to create value for one or more stakeholders.

Explanation

Systems exist to fulfill a purpose. They transform inputs into outputs, provide capabilities, deliver services, or otherwise create value within a particular context.

In IMPULS3, systems may exist at any level of abstraction. A complete enterprise, a product, a subsystem, a software component, a building, or even a single sensor can all be considered systems.

The defining characteristic of a system in IMPULS3 is that it can be completely described by its:

• Functions — what the system does.
• Properties — how well the system performs or behaves.
• Constraints — the limitations and boundary conditions imposed on the system.

Alignment with NASA Systems Engineering

The IMPULS3 definition of a system is strongly aligned with the definition provided in the NASA Systems Engineering Handbook:

“A system is the combination of elements that function together to produce the capability required to meet a need.”

Both definitions emphasize that a system consists of elements that work together to fulfill a purpose. NASA explicitly refers to the production of a capability required to meet a need. IMPULS3 expresses this in terms of interacting elements that collectively perform functions in order to create value for stakeholders.

IMPULS3 extends this perspective by adding a consistent modelling principle: every system can be described through its functions, properties, and constraints. This makes the definition directly usable for Requirements Engineering, architecture development, traceability, verification, and validation.

Examples

The concept of a system applies at many levels of abstraction:

System versus Element

Within IMPULS3, every element may itself be regarded as a system. The distinction between a system and an element is therefore primarily one of perspective and level of abstraction.

For example, an aircraft may be considered a system at one level of abstraction, while its navigation subsystem may be considered an element. When the navigation subsystem is analyzed in more detail, it becomes a system in its own right.

This recursive view enables IMPULS3 to model complex systems consistently across multiple levels of decomposition.

System versus Environment

A system is separated from its environment by a boundary. Everything inside this boundary belongs to the system; everything outside belongs to the environment.

The placement of the system boundary is a conscious engineering decision and strongly influences the scope of analysis, design, and verification activities.

Related concepts

• Function
• Property
• Constraint
• System Boundary
• Stakeholder
• Environment
• Systems Engineering

References

National Aeronautics and Space Administration. (2007). NASA systems engineering handbook (Rev. 1, NASA/SP-2007-6105). National Aeronautics and Space Administration. https://www.nasa.gov/seh/handbook/

International Council on Systems Engineering. (2023). Systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley.

ISO/IEC/IEEE. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes. ISO.

Checkland, P. (1999). Systems thinking, systems practice. Wiley.

Category: Foundations | Processes | Systems Engineering

Definition

Systems Engineering is a methodical and disciplined approach for defining, developing, realizing, operating, and retiring systems throughout their lifecycle while maintaining consistency, traceability, and control over system information.

Explanation

Systems Engineering is concerned with the successful realization and operation of systems that satisfy stakeholder needs and create value for stakeholders. It provides the processes, methods, and practices needed to transform stakeholder needs into operational systems.

Systems Engineering recognizes that modern systems are often complex, multidisciplinary, and evolve over time. As a result, it takes a holistic perspective, considering not only the system itself, but also its stakeholders, environment, lifecycle, interfaces, and interactions with other systems.

Within IMPULS3, Systems Engineering is viewed as an information-centric discipline. The primary objective is not merely to produce documents, but to continuously develop and maintain a consistent, complete, and traceable system information model throughout the system lifecycle.

The IMPULS3 Framework distinguishes four complementary layers:

• Foundations — the principles that guide engineering activities.
• Information Model — the structures used to capture and organize system information.
• Processes — the engineering activities that evolve the information model.
• Applications & Tools — the practical implementation of the method in real-world situations.

Alignment with NASA Systems Engineering

The IMPULS3 definition of Systems Engineering is strongly aligned with the definition provided in the NASA Systems Engineering Handbook:

“Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system.”

Both NASA and IMPULS3 view Systems Engineering as a disciplined lifecycle approach that spans from the initial need for change through system retirement.

IMPULS3 extends this perspective by emphasizing:

• The central role of a consistent and integrated information model.
• The preservation of meaning through traceability.
• The explicit distinction between functions, properties, and constraints.
• The importance of quantification and requirements quality.

Typical Systems Engineering Activities

Systems Engineering encompasses a broad range of engineering activities, including:

Examples

Systems Engineering is applied in many domains, including:

• Aerospace and defense systems.
• Healthcare systems.
• Transportation systems.
• Industrial manufacturing systems.
• Infrastructure and civil engineering projects.
• Software-intensive systems.
• Energy systems.

Related concepts

• System
• Requirements Engineering
• Information Model
• Traceability
• Stakeholder
• Verification
• Validation

References

National Aeronautics and Space Administration. (2007). NASA systems engineering handbook (Rev. 1, NASA/SP-2007-6105). National Aeronautics and Space Administration. https://www.nasa.gov/seh/handbook/

International Council on Systems Engineering. (2023). Systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley.

ISO/IEC/IEEE. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes. ISO.

Checkland, P. (1999). Systems thinking, systems practice. Wiley.

Category: Foundations | Information Model | Requirements Engineering | Systems Engineering

Definition

Traceability is the ability to establish, maintain, and navigate meaningful relationships between information objects throughout the system lifecycle in order to preserve intent, rationale, consistency, and impact.

Explanation

Traceability enables engineers and stakeholders to understand how information evolves throughout the system lifecycle. It makes explicit how stakeholder needs, analysis results, requirements, design decisions, architecture elements, verification results, and other information objects are related.

Within IMPULS3, traceability is not merely concerned with establishing links between information objects. Instead, traceability is primarily intended to preserve the meaning, intent, and rationale behind engineering decisions.

Traceability supports impact analysis, change management, verification, validation, audits, and system evolution by making the engineering thought process explicit and accessible.

Traceability in IMPULS3

Traditional traceability approaches often focus on establishing direct relationships between requirements.

IMPULS3 takes a fundamentally different approach by emphasizing the explicit capture of engineering rationale through dedicated information objects such as Analysis Statements and Design Decisions.

Direct requirement-to-requirement derivation relationships are discouraged because they conceal the reasoning that explains why additional requirements were introduced.

Instead, IMPULS3 promotes explicit traceability chains that preserve the engineering rationale.

Examples of Preferred Traceability Chains

Examples of Traceability Relationships

Traceability relationships may exist between many different information objects.

Benefits of Traceability

• Preserves stakeholder intent and engineering rationale.
• Facilitates impact analysis when changes occur.
• Supports verification and validation activities.
• Improves communication among stakeholders.
• Enables audits and compliance assessments.
• Preserves engineering knowledge throughout the system lifecycle.
• Supports reuse of engineering information.

Forward and Backward Traceability

Traceability versus Relationships

Within IMPULS3, traceability is implemented through explicit semantic relationships between independent information objects. Information objects remain autonomous entities and are not defined by their relationships.

For example, a requirement remains a requirement regardless of whether it participates in zero, one, or many traceability relationships.

Related concepts

• Stakeholder Need
• Analysis Statement
• Requirement
• Design Decision
• Verification
• Validation
• Systems Engineering

References

Gotel, O., & Finkelstein, A. (1994). An analysis of the requirements traceability problem. In Proceedings of the First International Conference on Requirements Engineering (pp. 94–101). IEEE.

Ramesh, B., & Jarke, M. (2001). Toward reference models for requirements traceability. IEEE Transactions on Software Engineering, 27(1), 58–93.

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. ISO.

International Council on Systems Engineering. (2023). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (5th ed.). Wiley.