Models instead of requirements? Eight arguments for the best of both worlds

This was the - admittedly provocative - title of my recent session at the RE-Barcamp in Cologne. This question was answered, among other things, by the exciting world cafe at the SE Get Together at oose was initiated. It was about the question of what "requirements modeling" actually is. We came to the conclusion that modeling is used in two ways in this context: On the one hand, to support the writing of requirements; on the other hand, to replace a large part of the requirements with the model. But can requirements really be replaced by a model?

Black or white?

Let's get straight to the point: The world is not black and white, and in most cases a hybrid model, i.e. a mixture of requirements and models, makes sense. Redundancies are more problematic. So if requirements and models are mixed, care must be taken to ensure that there is no duplication. And if duplications cannot be avoided, it must be clarified how these can be kept synchronized.

We don't have to choose between requirements and models, both make sense. But we must avoid redundancies. [tweetthis]We don't have to choose between requirements and models[/tweetthis]

The Barcamp session

The Barcamp is about active participation. In this case, my aim was to collect and structure the experiences of the twenty or so people present on this topic. There was just enough time, and the comments were often taken up and discussed by the group. Here are the most important results:

What is a model anyway? Models include mockups, prototypes, abstractions, physical models (like the sailing ship above), and much more. Natural language is also a modeling language, albeit usually a fairly informal one. This can also be formalized in small steps. This starts with a glossary, and can be taken further with text templates, for example. This certainly also explains why mixing requirements and models is not a problem if it is done systematically.

Consistency and traceability require less effort during modeling than with natural language requirements, as many relationships are implicitly set and maintained during modeling. More importantly, in some modeling languages, relationships themselves are model elements with clearly defined semantics.

Anyone can read requirements (with patience), but reading models must be learned. Stakeholders must therefore be approached differently when modeling than with traditional requirements. In particular, model reading training can be the difference between success and failure.

But on the other hand, models enable the generation of specialized views and are therefore superior to traditional requirements: it is easy to hide what is not important for the reader. A keyword from the session was document generation: Many stakeholders will consume models in the form of generated documents. These can be mixed with requirements relatively easily, or even generate the model so cleverly that the reader hardly recognizes that it is a generated document.

It is important to choose the right level of detail for both models and requirements. This is not so easy and requires a certain amount of manual skill. It is no wonder that there are many training courses on the subject of "formulating requirements correctly". But while there is already a lot of knowledge and experience with requirements, system modeling is a relatively new discipline. (This is also one of the motivations for the Modeling Craftsmanship Camp in Hanover).

Modeling is also popular because some problems can be described much better visually, for example processes. However, this does not apply to all requirements, which is another argument in favor of combining models and requirements. With a requirements-oriented method, it is also not unusual for the models to be just that: Just pictures. Experienced modelers frown at this. However, it is perfectly legitimate to treat the models only as images, as long as everyone involved understands this and maintains these images systematically.

An important class of models are prototypes and mockups - models that are not maintained after use. These only have a supporting role, but can be very valuable: they help to make requirements more precise and identify gaps. The biggest danger here is that nothing lasts longer than a provisional solution. In other words, sometimes prototypes are developed further into the product (especially with software), which can amount to a shaky foundation.

During the discussion, it quickly emerged that, in addition to traditional requirements and models, there are many other things that describe customer requirements. The word "artifact" was suggested here. According to this, requirements and models are only two types of artifacts, to which many others are added, from sketches to PowerPoint slides.

Both requirements and models are used for communication. Accordingly, it can also make sense to focus on communication and look for the most suitable artifact. The aim should be to find the language of the stakeholders. Here, however, models have the advantage that different views can be generated (point 3), the right one for each class of stakeholder.

Step by step with the SYSMOD Intensity Model

According to SYSMOD There is the so-called intensity model: at level 1, the model is only used for communication, while at level 3, the model actually replaces the specification (for the most part). The costs for SYSMOD 3 are of course higher than for SYSMOD 1 - but so are the benefits.

Models instead of requirements? No: models and requirements!

All participants agreed that models and requirements can and should be combined in a meaningful way. Models are powerful constructs that enable a level of precision and consistency that is simply not possible with traditional requirements. On the other hand, we do not know of any models that come close to the expressive power of textual requirements and are so universally accepted. If care is taken to avoid redundancies, then we have the best of both worlds.