From the requirement to the model

An important discipline of systems engineering is the analysis of requirements. There are enough studies to prove that solving a problem in the requirements phase is orders of magnitude cheaper than in later phases. Requirements analysis is therefore of particular importance. In this article, I present a method for going from requirements to a solid model.

The Cimatti method

This is based on the scientific work of Alessandro Cimatti et al, but that shouldn't put anyone off. In his paper From Informal Requirements to Property-Driven Formal Validation Cimatti aims to formalize the requirements completely. I will limit myself here to the first step of a practical requirements analysis, which is an excellent preparation for subsequent modeling - regardless of which modeling language is chosen.

The method is realized by a chain of tools based on de facto industry standards (such as Rational RequisitePro and Software Architect), together with an extended version of the NuSMV Model Checker. (Cimatti et. al.)

Cimatti deals with four challenges: Firstly natural language is inherently vague. Secondly there are often requirements that apply to the entire system and are therefore not easy to model. Thirdly often lack clear criteria for evaluation during validation. Less relevant for this article is the fourth Challenge: Formal modeling languages are not necessarily suitable for formal verification.

Cimatti divides the work into three phases: In the first phase the requirements are broken down into sentence fragments and classified. I will describe this here.

In the second phase the fragments are formalized in different ways, depending on the classification. In the third phase a formal analysis is carried out to detect problems such as inconsistencies and others.

Classification of request fragments

It is not uncommon to classify requirements. A classic is the division into functional and non-functional requirements. But Cimatti's classification is particularly suitable for subsequent modeling. Before we start breaking down the requirements into fragments, let's take a look at the categories. The associated questions help to categorize them:

The tried-and-tested elevator was used as an example and the following requirement was considered (whether this is a good "requirement" remains to be seen):

Requirement: A typical elevator includes call buttons for selecting a floor.

A number of fragments can be extracted from these requirements. Firstly, there are the three glossary fragments "elevator", "call button" and "floor". The fragment "Selecting a floor" is functional. There are more examples in the technical article.

Relationships between fragments

In the next step, Cimatti establishes relationships between the fragments. Since he is aiming for a rigorous approach, this makes sense. When it comes to systems that are not safety-critical, this is certainly not absolutely necessary. Cimatti recognizes the relationships "strong dependency", "weak dependency" and "refinement".

Modeling the fragments

Cimatti is concerned with complete modeling. To achieve this, he uses popular modeling languages such as UML whenever possible. The class diagram in the image above, for example, shows the glossary. However, this is not sufficient for all fragments, which is why he also uses more academic languages such as CNL (Controlled Natural Language) and LTL (Linear Time temporal Logic).

How you proceed now depends on the specific project and the objectives. In my experience, it is difficult enough to gain acceptance for UML in practice. In this respect, I would recommend getting by with a mixture of UML and text. Even the cleanly classified fragments are an excellent basis for any further development.

Here is my recommendation for UML-based development. At the end of the day, every project has different needs that need to be taken into account for the specific modeling approach.

Conclusion

Actually, only two "tools" for requirements analysis were presented here: Breaking requirements down into fragments and classifying them. What is new here is that classification is ideally suited for subsequent modeling.

I can recommend reading the whole Papers by Cimatti et al. recommend. For really security-critical systems, the effort may even be worthwhile. For everything else, you have to cherry-pick - for example, the ones just presented.

Image source: Alessandro Cimatti