IMPULS3 – a systems engineering method

IMPULS3 is a structured method for Systems Engineering, with an emphasis on Requirements Engineering, that ensures stakeholder needs are translated into clear, complete, and verifiable system requirements. It is based on the principle that any system can be fully defined by its functions, properties, and constraints, enabling a consistent and unambiguous specification. By emphasizing traceability, from stakeholder needs to requirements and further into design, IMPULS3 helps organizations maintain control over complexity, preserve the original intent of requirements, and support reliable decision-making throughout the entire system lifecycle.

---

What makes IMPULS3 different?

 

• • Systems are always defined as functions, properties, and constraints
    In IMPULS3, every system – at any level of decomposition – is described using a single, consistent structure: its functions, properties, and constraints. Functions describe what the system does, properties define how well it performs or behaves, and constraints define the boundaries within which the system must operate.

    This strict separation ensures that specifications remain complete, structured, and unambiguous, and prevents the mixing of fundamentally different types of information.

 

• • Every property is quantified, eliminating ambiguity
    In IMPULS3, a property only becomes a requirement when it is quantified. Statements such as “fast”, “efficient”, or “user-friendly” are not accepted as requirements unless they are expressed in measurable terms. This enforces clarity and enables objective verification, ensuring that requirements can be tested, validated, and agreed upon without interpretation. As a result, ambiguity is systematically removed from the specification.

 

• • Traceability preserves meaning, not just links
    Traceability in IMPULS3 goes beyond maintaining connections between artifacts. It ensures that the original intent of stakeholder needs is preserved as they are translated into analysis results and system requirements.
    Each requirement can be traced back to its origin in a way that retains its context and rationale, enabling stakeholders and engineers to understand not only where something comes from, but also why it exists. This supports better decision-making and impact analysis throughout the lifecycle.

 

• • Requirements quality is addressed both intrinsically (syntax) and extrinsically (semantics)
    IMPULS3 distinguishes between two complementary aspects of requirements quality. Intrinsic quality focuses on the formulation of requirements, ensuring they are clear, consistent, and follow agreed syntax rules.
    Extrinsic quality focuses on meaning, ensuring that requirements accurately represent stakeholder needs and are usable by those who rely on them. By addressing both aspects explicitly, IMPULS3 ensures that requirements are not only well-written, but also fit for purpose.

 

• • The method avoids ambiguous concepts and focuses on clarity and consistency
    IMPULS3 deliberately avoids terms and constructs that are used inconsistently across industry practices. Instead, it relies on a small set of clearly defined concepts that are applied consistently throughout the method. This reduces misinterpretation, improves communication between stakeholders, and ensures that models and specifications remain coherent across projects, teams, and system levels.

 

• • All model elements are treated as independent entities
    In IMPULS3, every element in the SE model is defined in the same consistent way, by its functions, properties, and constraints. Relationships such as hierarchy, dependency, or composition are not embedded within elements, but are explicitly modeled as separate relations.
    This avoids implicit assumptions and ensures that relationships do not distort the definition of an element itself.

 

• • Relationships are explicit, conditional, and context-dependent
    Instead of defining special element types (e.g. “optional component”), IMPULS3 models such distinctions as relations between elements.
    For example, an element may be optional in one system and mandatory in another, without changing the definition of that element. This allows the same element to be reused consistently across multiple contexts, while maintaining full flexibility in how it is applied.

Key References

International Council on Systems Engineering (INCOSE). (2023). Systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley.
https://www.incose.org/products-and-publications/se-handbook

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

ISO/IEC/IEEE. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering—System life cycle processes. ISO.
https://www.iso.org/standard/63711.html

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering—Life cycle processes—Requirements engineering. ISO.
https://www.iso.org/standard/72089.html

Pohl, K. (2010). Requirements engineering: Fundamentals, principles, and techniques. Springer.
https://doi.org/10.1007/978-3-642-12578-0

Hull, E., Jackson, K., & Dick, J. (2011). Requirements engineering (3rd ed.). Springer.
https://doi.org/10.1007/978-1-84996-405-0

Sommerville, I. (2016). Software engineering (10th ed.). Pearson.

Dijkstra, E. W. (1972). The humble programmer. Communications of the ACM, 15(10), 859–866.
https://doi.org/10.1145/355604.361591

Gilb, T. (2005). Competitive engineering: A handbook for systems engineering, requirements engineering, and software engineering using Planguage. Elsevier Butterworth-Heinemann.

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

Cabrera, D., & Cabrera, L. (2015). Systems thinking made simple: New hope for solving wicked problems. Odyssean Press.
https://doi.org/10.13140/RG.2.1.4338.9286
Cabrera, D., Colosi, L., & Lobdell, C. (2008). Systems thinking. Evaluation and Program Planning, 31(3), 299–310.
https://doi.org/10.1016/j.evalprogplan.2007.12.001

Credits

The work of Tom Gilb has strongly influenced the emphasis on quantification of system properties, while the contributions of Suzanne and James Robertson have informed practical approaches to Requirements Engineering. The Systems Thinking framework of Derek and Laura Cabrera, particularly the DSRP model, has provided valuable insights into structuring complexity through distinctions, systems, relationships, and perspectives.

functional element

 

---