Throughout my career, I’ve faced a recurring challenge: convincing fellow engineers to embrace conceptual modelling in early-phase engineering. Whether as a foundation for requirements documents, or as a vehicle for domain sensemaking with the team, the value of conceptual modelling is widely recognized—but it rarely gets done.
Why is that?
The problem lies in the complexity of the practice:
- Vastness of Modelling:
Models are everywhere. We use them daily to make sense of the world. But this abundance can be a handicap. Without structure and constraints, modelling efforts lack channelling and direction towards repeatable outcomes. - Modelling the Wrong Thing:
Modelling is, obviously, abstract. Without strong constraints, I’ve often seen the modeller focusing on the feature instead of the machine, or on stakeholders instead of actors. Or mixing a state for a function. Once you’re in such a trap, whatever your efforts, you end up with confusion, and distrust for the practice. - One Size Does NOT Fit All:
The tools and techniques suitable for banking applications may not work for medical devices. We need to recognize and name the scope for which our sensemaking effort and conceptual modelling toolbox is applicable. While I recognize the huge value of the IREB initiative gathering it all in one book, I envision something narrower, focused on the market-driven, software-intensive device engineering domain I know, ready to use out of the box. - Confusing the Phases:
While models serve from early prototyping to detailed design, their purposes may differ. I’ve seen modelling technique misapplied at the wrong engineering phase, again leading to confusion and distrust in the discipline. I’ll strictly consider the machine as a “black box in the world”.
The Easy Framework for Conceptual Modelling
Based on my practice in market-driven, software-intensive device engineering, I want to explore these issues and share my Easy Framework for Conceptual Modelling—the pragmatic toolkit I’ve been growing over the years.
This framework classically includes:
- A structured set of models, offering a multi faceted viewpoints on both the world and the machine
- For the purpose of sensemaking with the team – which I claim is the essential purpose of requirements engineering
- Each model following an established modelling language
- Their rationale, practical guidance and examples
I’m also intrigued by the potential of large language models to assist in transforming existing knowledge – e.g. your company’s internal wiki – into such models. How far can AI tools enhance the process? Paper publication is exploding, I’ll dig into it.
I’ll share my learning and insights here on recognizing.ch, and sample milestones on LinkedIn.
Now, what do you think ? Do you recognize the problem? Do see value in this exploration? Gaps we should focus on? Or do you feel like joining the effort? I’d love to hear your thoughts!
Leave a Reply