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 | 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 | 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, organization, or system that affects, is affected by, or perceives itself to be affected by a system or a decision related to that system.

Explanation

Stakeholders are the ultimate source of value, expectations, constraints, and acceptance criteria for a system. They play a central role throughout the entire system lifecycle, from the initial recognition of a need for change through system retirement.

Stakeholders may interact directly with a system, indirectly influence the system, or be impacted by the system without actively 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 and analyzed during the Requirements Elicitation activities. Understanding stakeholders, their interests, priorities, concerns, and business drivers is essential for deriving high-quality requirements.

Examples

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

Stakeholder Categories

Stakeholders can be categorized in many ways. Common categories include:

Stakeholder Analysis

Stakeholder Analysis is the activity of identifying stakeholders and understanding:

• Their interests and concerns.
• Their expectations and needs.
• Their priorities.
• Their influence on the project or system.
• Their business drivers and motivations.

Within IMPULS3, Stakeholder Analysis provides important context for understanding and interpreting Stakeholder Needs.

Stakeholder versus User

Related concepts

• 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.

Category: Foundations | Information Model | Requirements Engineering

Definition

A Stakeholder Need is any expectation, desire, concern, problem, opportunity, or objective expressed by a stakeholder that may influence the definition, realization, operation, or retirement of a system.

Explanation

Stakeholder Needs represent the starting point of the Requirements Engineering process. They express what stakeholders expect from a system, why a change is needed, or which problems need to be addressed.

Stakeholder Needs are typically expressed in natural language and are often incomplete, ambiguous, qualitative, or even contradictory. They therefore require analysis before they can be transformed into formal system requirements.

Examples of stakeholders include users, operators, maintainers, customers, owners, regulatory authorities, suppliers, and organizations affected by the system.

Within IMPULS3, stakeholder input is always referred to as a Stakeholder Need. The terms Stakeholder Requirement and Stakeholder Requirements Specification are deliberately avoided because they suggest a level of formality and quality that stakeholder statements usually do not yet possess.

Examples

The following examples illustrate typical Stakeholder Needs.

Stakeholder Need versus Requirement

Role in Requirements Engineering

Stakeholder Needs are elicited, analyzed, and transformed into formal requirements during the Requirements Engineering process. A single Stakeholder Need may lead to multiple requirements, while multiple Stakeholder Needs may contribute to a single requirement.

Maintaining traceability between Stakeholder Needs and the derived requirements is essential to preserve meaning and stakeholder intent.

Related concepts

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

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.

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.