This is the second part of the mini-series “requirements modeling”. In this article, we create a common understanding on what modeling is in general, and a requirements model in particular.

Models in General

Models are used everywhere in life, not just for systems and requirements. It is generally considered a “small copy of something that exhibits some features of the original.” To mind come physical objects like model ships.

There are also more formal definitions of a Model (What is a Model? by Thomas Kühne). But for now, let’s focus on a more important aspect: Even with this simple definition above, all requirements already represent a model of the product to be built.

Requirements are Always Modeled

Requirements are a pragmatic description of the system to be built. They should focus on the problem that this system solves (and not the specific implementation), and are therefore only a partial description. But per definition, this is a model, even if it’s just a few lines of plain text.

A model usually has a modeling language, which can be textual or graphical. And again, with a few lines of plain text, the modeling language is… English.

So in the context of requirements modeling, the question is not whether to model or not: We always model. Instead, the questions are:

• On what level does the modeling language structure the model?
• What modeling Language do we use?
• How formal do we want the model to be?

At this point, we are ready for a simple definition:

A requirements model is a structured representation of requirements, using a specific modeling language.

Let’s look at the three questions, one by one.

Level of Modeling

There are broadly three levels to which modeling can be applied more formally:

Specification Level: The structure of the specification as a whole can be formalized. A trivial but useful example of this is the chapter structure. This has even be standardized: IEEE 29148-2011 (formally IEEE 830-1998) provides possible chapter structures for system requirements specifications (SRS).

Requirement Level: The individual requirement as whole can be made part of a requirement model by enriching it with metadata. For instance, a requirement could be classified as functional or non-functional. A more sophisticated classification scheme has been suggested by Cimatti or Gunter.

Requirements-Text Level: The actual requirements text can also be modeled, for instance by using text templates. Some of the better-known ones are provided by the Sophist Group (Master-Schablonen, German), but there are many others to choose from.

Modeling Languages

People usually think of graphical languages like UML or SysML, when the topic of requirements modeling or system modeling comes up. And indeed these can be used as well.

Graphical languages take advantage of the fact that humans are incredibly good at capturing visualized information. It is important to note, however, that the models typically contain a lot of information that is not shown on the pictures. The pictures act as a map for orientation that helps to find additional information. This information is usually found in tables that accompany the pictures.

Levels of Formality

Independently on whether a textual or graphical representation is used, the requirements can be quite informal or extremely formalized.

Plain English (or any other natural language) is informal, but can be made more formal with text templates. Depending on the sophistication of the tools, quite a bit of information can be extracted automatically from the text (e.g. automatic glossary management).

The extreme are specification languages that are textual, but resemble programming languages, rather than text. Examples of this category include Event-B or Z. These languages have such a high level of formality, that certain properties of the description can be mathematically proven.

Things are similar with graphical languages. On the informal spectrum are “boxes and lines” that are drawn on an ad-hoc basis. But even these can be great communication tools. Next up is UML that is used “just as a drawing”, i.e. not part of a larger model.

Modeling the system as a whole is more formal than the previous approach and allows checking of the model integrity. And of course, there are modeling languages that are more formal than UML and SysML, like Petri-Nets or the Scade-dialect of the Lustre language.

Bottom Line

Even textual requirements represent a requirements model. So the questions to ask are:

• Should I switch to a graphical representation of my requirements?
• Should I make my textual requirements more formal?
• Should I apply modeling on the specification, requirements or requirements text level?

Before these questions are answered in part four of this series, we will look at the advantages and disadvantages of more formal requirements modeling in the next article.