Requirements Engineering is the engineering discipline concerned with establishing, preserving, and communicating the information that defines what a system must achieve.
Every engineering initiative begins with stakeholders who have expectations, concerns, operational needs, business objectives, or legal obligations. These Stakeholder Needs are often incomplete, implicit, contradictory, or expressed in domain-specific language.
Requirements Engineering provides a structured process for transforming this information into clear, quantified, traceable, and usable system requirements without prematurely introducing assumptions, feasibility judgements, or design decisions.
Within IMPULS3, Requirements Engineering is regarded as an information-transformation process. Information is progressively refined from Stakeholder Needs, through analysis, into formal Requirements, while preserving both its content and intended meaning.
The objective is not to produce more Requirements, but to establish a trustworthy system definition that provides a reliable foundation for architecture, design, realization, system-level verification and validation, operation, and system evolution.
Requirements Engineering is not primarily about writing Requirements. It is about transforming stakeholder information into a trustworthy system definition while preserving its meaning.
Modern systems are developed across many disciplines, organizations, suppliers, lifecycle phases, and levels of decomposition. During this journey, information is repeatedly interpreted, transformed, allocated, and communicated.
Every transformation introduces the risk that stakeholder intent is gradually lost, narrowed, distorted, or unintentionally replaced by assumptions and design choices.
Requirements Engineering exists to prevent this loss of meaning. It has two closely related responsibilities:
- Establish a complete and coherent understanding of Stakeholder Needs. Relevant stakeholder perspectives, operational contexts, lifecycle phases, source documents, regulations, interfaces, and existing systems must be considered.
- Ensure the correct and complete transition from needs to implementation. As information moves through analysis, specification, architecture, design, realization, and system-level verification and validation, its content and semantics must remain intact.
Without a disciplined Requirements Engineering process, projects frequently experience:
- Ambiguous or contradictory interpretations.
- Missing stakeholders and incomplete needs.
- Implicit Design Decisions hidden inside Requirements.
- Unquantified Properties and unverifiable statements.
- Broken traceability and weak impact analysis.
- Repeated rework caused by late discovery of misunderstandings.
- Systems that satisfy written Requirements but fail to satisfy the original stakeholder intent.
Requirements Engineering therefore acts as the guardian of meaning throughout system development. It gives stakeholders and engineering disciplines a shared, explicit, and traceable understanding of what the system must achieve.
Requirements Engineering ensures that the right information is available at the appropriate level of abstraction and remains trustworthy as it moves through the engineering lifecycle.
IMPULS3 treats Requirements Engineering as the controlled transformation of engineering information rather than as the production of Requirements documents.
The approach is distinguished by seven closely related principles.
1. Stakeholder Needs are not Requirements
Stakeholders express expectations, concerns, objectives, problems, opportunities, and contextual limitations. These expressions are captured as Stakeholder Needs, not as Requirements.
A Requirement only exists after stakeholder information has been analyzed, interpreted, structured, and formally specified.
2. Analysis is explicit and separated from Design
IMPULS3 explicitly separates understanding the problem from designing the solution.
During Requirements Analysis, engineers determine what Stakeholder Needs mean for the system. The conclusions of this reasoning are documented as Analysis Statements, which preserve the rationale between source information and the resulting Requirements.
Requirements Analysis identifies and structures the Functions, Properties, and Constraints of the system without deciding how the system will be realized. Feasibility assessments, solution selection, architectural choices, and Design Decisions belong to Architecture & Design Engineering.
3. Systems are defined through Functions, Properties, and Constraints
IMPULS3 uses a consistent semantic structure for defining systems:
- Functions describe what the system does.
- Properties describe how well the system performs or which observable characteristics it possesses.
- Constraints define the conditions and boundaries that the system must respect.
This structure avoids the ambiguous distinction between functional and non-functional Requirements.
Properties may initially be identified conceptually during Analysis, but they become Requirements only when assigned a measurable value, threshold, range, or limit. No Property remains unquantified in the final Requirements Specification.
4. Traceability preserves meaning, not merely links
IMPULS3 traceability is based on explicit semantic relationships between independent information objects. A traceability chain must make clear why information exists, how it was interpreted, and which reasoning caused a subsequent information object to be introduced.
A typical Requirements Engineering traceability chain is:
Across the boundary with Architecture & Design Engineering, a typical chain is:
Consequently, IMPULS3 does not derive Requirements directly from other Requirements. Such a relationship would hide the analytical or design rationale that explains why the new Requirement exists.
5. Requirements quality is both intrinsic and extrinsic
IMPULS3 distinguishes two complementary dimensions of Requirements quality:
- Intrinsic quality concerns the Requirement itself, including clarity, atomicity, consistency, quantification, structure, and verifiability.
- Extrinsic quality concerns the Requirement in context, including whether it correctly represents analyzed Stakeholder Needs and is useful to downstream stakeholders.
A well-written Requirement that expresses the wrong intent is still a poor Requirement. Likewise, a correct intention that is expressed ambiguously is not usable for engineering.
6. Requirements Engineering includes Development, Verification & Validation, and Management
Within IMPULS3, Requirements Engineering includes the creation of Requirements, the assessment of their quality and correctness, and the preservation of their integrity over time.
Requirements Development includes:
- Requirements Elicitation.
- Requirements Analysis.
- Requirements Specification.
Requirements Verification & Validation forms an explicit quality gate within the Requirements Engineering process.
The object being verified and validated is the Requirements Engineering output itself, not the realized system. This includes Requirements, their traceability to Analysis Statements and Stakeholder Needs, and the supporting information required to understand and use them correctly.
- Requirements Verification assesses whether the Requirements and associated information are correctly formulated, complete, consistent, quantified where applicable, and compliant with agreed quality rules.
- Requirements Validation assesses whether the Requirements correctly represent the analyzed Stakeholder Needs, system scope, intended purpose, and operational context.
This activity is distinct from the system-level Verification and Validation processes described in ISO/IEC/IEEE 15288. At system level, the object of assessment is the realized system. Within Requirements Engineering, the object of assessment is the engineering information produced by the RE process.
Requirements Verification & Validation therefore establishes confidence that the RE output is fit for controlled release and use by Architecture & Design Engineering and other downstream processes.
Requirements Verification & Validation is the final quality gate within Requirements Development. It ensures that the Requirements Engineering output is suitable for controlled release and downstream use.
Requirements Management preserves the reliability of the Requirements Engineering information over time and includes:
- Identification and versioning.
- Traceability maintenance.
- Change and impact management.
- Immutable Baselines.
- Publication and controlled release.
7. The information model is primary
Stakeholder Needs, Analysis Statements, Requirements, Design Decisions, Baselines, and Relationships are treated as first-class information objects.
Documents, reports, and specifications are publications or views of selected information. They are not the information model itself.
This allows the same authoritative engineering information to be structured, traced, reviewed, baselined, and presented in different forms without duplicating or changing its meaning.
Requirements Engineering is the disciplined transformation of stakeholder information into a trustworthy system definition while preserving its meaning throughout the engineering lifecycle.
