Category: The Easy Framework for Conceptual Modelling

Have you ever sat through a meeting where engineers talk past each other? Where requirements feel like checkboxes to tick rather than insights to share?

Following up on our previous post, where we’ve explored the barriers to adoption, I will show how Conceptual Modelling contributes to engineering, with what role for requirements engineers, and why it matters. Let us first introduce the Engineering context.

Engineering: Building Machines for User Goals in the World

In The World and the Machine, Michael Jackson writes, […] we are engineers because we make useful machines. We are concerned both with the world, in which the machine serves a useful purpose, and with the machine itself. [Jackson, 1995].

Having spent the past 12 years at Sonova, I’ll be illustrating this post with hearing devices. The User is the wearer of the hearing devices, with her or his family and audiologist. The Machine is the pair of hearing devices and their companion apps. The World includes the user’s conversation partners, mobile phone, the audiologist’s equipment, the rain… The main Goal is to enjoy social interactions. Last, Engineering, the discipline of building Machines for Users in the World, gathers stakeholders besides R&D like Product Marketing, Usability Engineering, Manufacturing, Procurement. I’ll refer to them all either as stakeholders or Engineers.

To succeed, engineers must understand not just the hearing devices but also the user’s World. This brings us to Sensemaking.

Sensemaking: Making Sense of the World

To build the right Machine, Engineers need to make sense of the World and the Machine as they interact. I refer to this process as Sensemaking.

Consider our hearing devices. Engineers must make sense of many aspects, including:

• How diverse is the morphology of human ears?
• Do hearing device users wear bicycle helmets and sunscreen on rainy days?
• Is hearing involved in speaking? How do hearing devices affect own speech production?

Sensemaking is the collective cognitive process of apprehending the World – discovering, naming, questioning, structuring and sharing; agreeing and disagreeing; by the team and for the team.

Requirements Engineering: Facilitating Sensemaking

Requirements Engineering (RE) is often seen as bureaucratic burden caused by regulatory obligations. This perception is unfortunate as it prevents RE practitioners to deliver value – for example when they are not invited to early design meetings – and because it spoils the fun, driving Requirements Engineers to chase trendier titles like Project Manager.

I have experienced the essential value RE can contribute, which I want to share.

Requirements Engineering is the engineering discipline concerned with the real-world goals for, functions of, and constraints on machines [Zave, 1995].

Klaus Pohl breaks this down into three dimensions: understanding, agreement, and documentation(*):

Requirements engineering is a cooperative, iterative, and incremental process which aims at ensuring that:
(1) All relevant requirements are explicitly known and understood at the required level of detail.
(2) A sufficient agreement about the system requirements is achieved between the stakeholders involved.
(3) All requirements are documented and specified in compliance with the relevant documentation/specification formats and rules. [Pohl, 2010].

I argue that the essential purpose of requirements engineering is Sensemaking—facilitating the cognitive journey of the project stakeholders towards understanding and agreement, about the World, and about the Machine as it interacts with its context.

Requirements engineers are best suited to support the team in its Sensemaking journey – especially with their expert toolbox: Conceptual Modelling.

Conceptual modelling: The Toolbox for Sensemaking

Let’s first define Modelling.

Modeling in its broadest sense is the cost−effective use of something in place of something else for some purpose. It allows us to use something that is simpler, safer, or cheaper than reality instead of reality for some purpose [Rothenberg, 1989] 

In our engineering context, Conceptual Modelling is the process of developing an abstracted representation of the Machine, the World, their interfaces, including the Users and their Goals, often depicted using graphical notations.

With this set of diagrams, Conceptual Modelling helps humans to think together. Here is how:

1. Conceptual Modelling reduces cognitive load

Studies show that, for complex and interconnected concepts, humans process the information presented as visual diagramatic representations faster than textual sentential representations [Larkin & Simon, 1987].
Consider the two forms of the same semantic network below. How much effort to make sense of them?

digraph TheWorldAndTheMachine {
subgraph cluster_world {
World -> Machine -> User[label="interacts with" ];
World -> User[label="is in" ];
World -> Goal[label="in" ];
Goal -> User [label="has" ];
label = "The world";
}
subgraph cluster_disciplines {
Engineering;
label = "The disciplines";
}
Machine -> Engineering[label="builds"];
Goal -> Engineering [label="is driven by" ];
}

2. Conceptual Modelling enforces focus

Each model (or modelling language) focuses on a particular aspect of reality, excluding all others. By choosing a model, participants force themselves to focus on this particular aspect. As example, modern musical notation excels at representing western melodies, and it is very bad for most other uses.

Compared to natural language, this reduction of freedom is a major simplification as it reduces the dimensions of the problem space, therefore preventing ambiguity and misunderstanding. This focus also enables considerable more precision. Can you imagine Mozart writing his music in German?

3. Conceptual Modelling fosters multiplicity of viewpoints

Using multiple diagrams in a Conceptual Modelling framework encourages stakeholders to consider multiple perspectives, fostering deeper and more disciplined thinking.

When applied effectively, these three qualities—reduced cognitive load, focus, and multiplicity of viewpoints—accelerate, simplify, and enrich collective thinking, understanding, and problem-solving.

Conceptual modelling is, therefore, the perfect toolbox for sensemaking.

Conceptual Modelling in Real Life

Following up on my hearing device engineering example, at Sonova, using a model called causality diagram, we have recently explored top user pains related to their hearing. In small groups, with multi discipline experts from audiology to electroacoustic, we have systematically investigated and modeled the causal relationships between user goals, the involved system performances, and the device technologies and functions.

The resulting causality diagrams, the working sessions to get there, and the sharing session with the larger team have been focused, energizing, enjoyable and mind stretching, revealing new trade-offs and dependencies to the larger community.

Our Framework

I will go through the details of our Easy Framework for Conceptual Modelling in further posts. For now, let’s conclude our quest for the role and rationale for Conceptual Modelling.

The Big Picture

Conceptual Modelling is not about drawing nice diagrams—it’s about facilitating collective cognition as Engineers make sense of the World, therefore building Machines which truly serve their Users.

Stay tuned as we dig into our Easy Framework for Conceptual Modelling! And I’d love to get your views and experience as reply to my article duplicated on LinkedIn.

Sources

[Jackson, 1995] M. Jackson, “The world and the machine,” doi: 10.1145/225014.225041.

[Zave, 1995] P. Zave, “Classification of research efforts in requirements engineering,” doi: 10.1109/ISRE.1995.512563.

[Pohl, 2010] K. Pohl, “Requirements engineering: fundamentals, principles, and techniques.” Heidelberg ; New York: Springer, 2010.

[Rothenberg, 1989] J. Rothenberg, “The Nature of Modeling.”

[Larkin & Simon, 1987] “Why a Diagram is (Sometimes) Worth Ten Thousand Words“

(*) I’ve renamed “content” to “understanding” because I claim this is the real purpose. Klaus, I’d love to chat about that with you one day.

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:

1. 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.
2. 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.
3. 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.
4. 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!