Relationship: Complementary | Systems Architecting | Requirements Engineering
Overview
The emphasis in IMPULS3 on understanding not only what stakeholders need, but also why those needs matter, has a strong parallel with Gerrit Muller’s CAFCR model. CAFCR describes a system and its context through five complementary views: Customer Objectives, Application, Functional, Conceptual, and Realization. Together, these views help the architect connect customer and stakeholder concerns to system functionality, architectural concepts, and implementation choices [Muller2020].
Where the strongest relationship lies
The strongest relationship with Requirements Elicitation lies in the Customer Objectives view. This view focuses on the objectives, concerns, business context, and key drivers that explain why a system or product is needed and what value it is expected to provide. This closely corresponds to the IMPULS3 principle that Elicitation should establish not merely what a stakeholder asks for, but also the underlying rationale that explains why the need is important.
The Application view provides an additional bridge. It considers how the system is used, which stakeholders interact with it, and in which operational context activities take place. This can help reveal the circumstances, scenarios, dependencies, and constraints in which Stakeholder Needs arise.
CAFCR and IMPULS3 are not equivalent
CAFCR and IMPULS3 serve different purposes and should not be interpreted as equivalent models. CAFCR is a multi-view framework for architectural reasoning [Muller2000], whereas IMPULS3 Elicitation is a Requirements Engineering process step concerned with discovering, understanding, and documenting Stakeholder Needs and their rationale.
The CAFCR views are also not intended as sequential process steps. Architectural reasoning deliberately moves between the views as understanding develops [Muller2007]. In the same way, the IMPULS3 sequence Elicitation → Analysis → Specification represents a logical transformation of engineering information rather than a rigid waterfall. Analysis may expose missing information that requires further Elicitation, while Specification may reveal questions that require renewed Analysis.
How CAFCR can support IMPULS3
CAFCR can provide valuable perspectives and techniques within IMPULS3. In particular, the Customer Objectives perspective and associated Key Driver methods [Muller2004] can strengthen Elicitation by helping engineers uncover the business, mission, operational, or societal objectives behind Stakeholder Needs.
Elements of the Application view can support both Elicitation and the subsequent Requirements Analysis process. During Elicitation they help explore stakeholder context and usage situations; during Analysis they help engineers reason about what the complete set of elicited Stakeholder Needs means for the system and its operational environment.
CAFCR does not replace Requirements Elicitation. It provides complementary viewpoints and reasoning techniques that can help engineers understand the objectives, drivers, and operational context behind Stakeholder Needs.
Illustrative relationship
| IMPULS3 Perspective | Related CAFCR View | Relationship |
|---|---|---|
| Stakeholder objectives and rationale | Customer Objectives | Explains why the system is needed and which drivers make Stakeholder Needs important. |
| Operational context and usage | Application | Helps understand where, when, by whom, and under which circumstances Stakeholder Needs arise. |
| System functions and behaviour | Functional | Becomes increasingly relevant during Requirements Analysis when stakeholder-oriented information is interpreted from the perspective of the system. |
| Architecture and design choices | Conceptual and Realization | Primarily belongs to Architecture and Design rather than Requirements Elicitation, but remains traceable to the objectives and needs that justify those choices. |
Key takeaway
CAFCR reinforces an important principle for IMPULS3: stakeholder statements should not be treated as isolated requests. Their value lies in understanding the objectives, drivers, and application context that explain why they matter. Preserving that rationale creates a stronger foundation for subsequent Analysis, Specification, and architectural reasoning.
References