WRSPM? Excuse me? Or: What lies between the world and the system

Last week I reported on the Keynotes of the ReConf 2018. I was pleased that Thorsten Weyer went into the work of Michael Jackson. (The professor, not the musician). Together with Carl and Elsa Gunther, as well as Pamela Zawe, he has established a simple relationship between five artifacts, abbreviated as WRSPM.

Even though the authors take a formal approach, it is not necessary to have any prior mathematical knowledge. The aim of this article is to explain WRSPM with as little math as possible. And that is important for us systems engineers: because, as Thorsten Weyer rightly points out, it is more important than ever to understand the system in the world.

The paper by the authors cited is entitled "A Reference Model for Requirements and Specifications" and is a recommended read. Let's first take a look at what the letters actually stand for:

• W - World: In other words, the environment in which the system operates. However, this is a vague concept for several reasons: because where should we stop? If we want to be precise, we would have to consider the entire universe. In practice, we only take into account the system's relevant part of the world.
• R - Requirement: Requirements (R) have an impact on the world (W). Accordingly, we use the requirements to describe how the world should behave if the system is successfully implemented. For example, without the "heating" system, it is cold in the room. After successful implementation, the requirement "Room is warm" is realized.
• S - Specification: The specification (S) describes how the system intends to implement the requirements (R). It must necessarily refer to elements of the system to be developed (such as a radiator and thermostat).
• PM - Program and machine: WRSPM originally refers to software systems, which is why the program (P) and the actual machine (M) are considered separately. In the context of systems engineering, we can simplify this by considering them as a unit. Incidentally, Weyer also did this in his presentation. PM implements the specification in concrete terms.

So what?

What do we gain from this approach? Let's take a look at the formula that is listed both in the paper and by Weyer;

W, S ⊢ R

The symbol ⊢ is called "Turnstile" and the formula can be translated as:

From W and S follows R

Or to put it colloquially:

If the environment behaves as we expect and the specification is valid, then the requirements are met.

Here again, the heating is a good example: We may have made the assumption that it is no colder than -5°C outside. However, if it is particularly cold, perhaps -15°C, then the heating cannot cope with the cold. The requirement can therefore only be guaranteed if the world behaves according to the operating conditions of the system. Otherwise we cannot guarantee this.

Variables

So far so good. It should be clear to readers that the above relationships are not just about one requirement, but that R is a set of requirements, i.e. a vector. This also applies to W and S.

The individual elements can be expressed colloquially, as I have just done. But in order to have real added value in the analysis, the artefacts must be formalized. To do this, variables are introduced that are divided into four categories: There are variables of the world and variables of the system. For example, the room temperature is a variable of the world. The measured value of the temperature sensor, on the other hand, is a variable of the system. These two sensors are normally in a clearly defined relationship, unless the sensor is broken or is used outside the permitted operating parameters. Furthermore, variables can be classified as visible or invisible, which gives us the four categories.

Here it may become clear that these variables can be used for systematic analyses, for example to investigate different types of system failure.

What is different today?

The cited paper was published 20 years ago, so it's not exactly new. However, as Weyer noted in his presentation, one important thing has changed: Until recently, this approach was used in development to develop systems correctly. With the advent of self-learning systems, it will be necessary in the medium term to continuously evaluate this relationship during operation. Activities that were previously carried out by humans during development will be performed by machines at runtime in the future:

• Select an implementation (S) between various options for fulfilling the requirements (R).
• Responding to changes in the world (W) and ensuring that the requirements (R) are still implemented optimally.
• If the requirements (R) can no longer be implemented safely, react accordingly. This can result in an alternative implementation (S) or adapted requirements (R).

Conclusion

Anyone who has understood WRSPM can certainly confirm that the concept makes sense and is intuitive. And good engineers may say that we have always understood this relationship without giving it a name. But with the advent of autonomous systems, it becomes necessary to understand the formalization of this relationship. As Thorsten Weyer correctly pointed out, requirements engineering will experience a renaissance that is quite something.

Photo by Ishan @seefromthesky on Unsplash