Whether agile or V-model – a driver for effectiveness
Author: Dr. Michael Jastram, Formal Mind
Contribution – Embedded Software Engineering Congress 2017
Requirements modeling is a technique that is either not practiced at all or only partially implemented in many companies, yet it can be introduced relatively easily and iteratively. Given the enormous cost and time pressures in many organizations, this technique represents a significant opportunity to improve development efficiency. Because there are many different approaches, this course will present both the concepts that best suit your specific work and concrete tactics that deliver results with minimal effort.
motivation
Modeling is becoming increasingly prevalent in development and is already being used successfully in many areas. Often, people think of graphical modeling languages like UML or simulations. But the spectrum is much broader, as we will see shortly.
Requirements can also be modeled. This often involves constructs like use cases, but that's just one approach among many, and the modeling of use cases can take different forms.
But regardless of how the modeling is done, it must not become an end in itself; it must have a clear benefit. A model can offer added value in many ways. In the context of systems engineering, these include, among others [SET18]:
- Communicate
- Generate documents
- Create views
- Generate test cases
- Generate code
- Track progress
- Check for completeness
- Summarize information
- Perform automatic verification
- Understanding the impact of changes
- Assess risk
- Recognizing conflicts
- Identifying inconsistencies
- Animate the model (simulation)
- Use the model as a specification
- Use the model to structure the system description
- Managing knowledge
- Enable reuse
However, these possibilities are often offset by increased effort. For example, generating code from the model requires considerable effort that is not always justified.
What is a model?
A model is an abstraction of reality for a specific purpose. The model only needs to be accurate in the parts necessary for that purpose. For example, a wooden model of a ship is suitable for checking the arrangement of its components (purpose), even if the interior is made of solid wood. Similarly, a mathematical formula can be a model that is only meaningful in terms of drag.
The Unified Modeling Language (UML) is a graphical modeling language frequently used for requirements modeling (and more). UML has many model elements that can be used for requirements modeling, with the use case being perhaps the most well-known.
However, requirements can also be modeled without UML. Natural language itself is a model, albeit not a particularly formal one. Without a certain degree of formalism, the advantages of modeling listed above are hardly noticeable. The other spectrum of modeling consists of formal modeling languages that are based on a solid mathematical foundation. These include languages such as Event-B (EB), in which some requirements can be mathematically proven, thus eliminating the need for verification.
Requirements modeling classifies
The above is meant to illustrate that there are many other approaches to requirements modeling besides UML. These will be presented below. Afterwards, we will look at what should be considered when introducing requirements modeling.
Requirements can be modeled at different levels:
Specification level:
Traditionally, requirements are structured in documents. Viewing the chapter structure as a model might be a bit of an overstatement. However, the transition from document-based to element-based work requires a data model in which the requirements are categorized and the relationships between the types are clearly defined. This can be achieved using simple entity-relationship diagrams (see accompanying figure)., PDF) can be visualized.
Requirement level:
A requirement itself can also be modeled. One of the simplest approaches here is the use of sentence templates, as suggested, for example, by standards (29148). If a data model is used, then each element type can be further modeled, for example, using different sets of attributes. Here, too, the term "modeling" is rather an overstatement. True modeling, however, only occurs when semi-formal languages like UML or formal languages like Event-B are used. A requirement for a traffic light system could look like this in Event-B (RH; see accompanying figure, PDF).
Modeling depth:
So far, we've only spoken informally about requirements. However, requirements appear at different levels, such as user requirements, system requirements, etc. If the model is created down to the lowest level, it's theoretically possible to derive the implementation without any manual intervention. In practice, this is really only possible for software. We're talking about code generation from the model.
Languages that enable code generation include Event-B, UML, and SysML, to name just a few.
Introduce requirements modeling
The idea of generating an implementation from a model at the push of a button is tempting, but dangerous, because modeling is a skill that needs to be learned. Teams that attempt to jump directly from document-based work to code generation without the necessary experience are highly likely to fail. Therefore, the following section presents loosely connected approaches to requirements modeling. My recommendation if you want to introduce requirements modeling: Find out where you stand in your organization and take one, maybe two steps further, but no more.
Sensible document-based work
Before we can even think about modeling, we need to be able to handle requirements effectively. The previously cited IEEE 29148-2011 (29148) provides a good foundation here. While the standard certainly permits model-based work, it can also be easily applied to document-based work. It describes how to formulate sensible requirements (e.g., using text templates), how to structure the requirements document, and how the various specifications/documents relate to each other.
Data models
If a structured approach to requirements management is ensured, then a data model should be used instead of a document-based approach. Data models in requirements management have existed for over 20 years and are well-established – at least in developments involving functional safety. To work with data models, suitable tools are needed, such as IBM Rational DOORS or JAMA software.
Implementing a data model is generally not complex, as the existing (document-based) workflow requires minimal changes – at least if the tools are good. However, the benefits are immense. A simple data model was shown above. Such a model can, for example, ensure that every epic is covered by at least one test. Handling changes also becomes more reliable. When an epic changes, the tool should ensure that all derived test cases are checked for correctness.
Introduction of a modeling language
While the data model described above is usually fully customized, a (semi-)formal modeling language uses predefined elements. In UML, for example, classes and use cases are used. This has the advantage of allowing you to build on many years of best practices. However, it also means that there are many language features that you don't necessarily need. And it can tempt you to delve into a level of detail that you might not yet be comfortable with.
Therefore, it is important to severely restrict the language elements used during the introduction and to adapt the language (or the tool) as much as possible to guide the users. Furthermore, it is important to provide users with sufficient training.
In training sessions, it's helpful to differentiate between authors and readers. In practice, only a small percentage of users create the models, while significantly more people need to be able to interpret them. Offering two separate training sessions for these two groups saves costs and prevents users from becoming frustrated by too much—or too little—training.
And finally, a very important point: During the initial implementation, modeling should not be more in-depth than necessary. Here's a practical example. In a project for a logistics service provider, UML was used for the first time (IREB). Only the model elements "Class" and "Use Case" were used. But more importantly: Beyond a certain level of detail, the formalisms of UML were ignored and natural language was used (see the accompanying figure)., PDF).
Although the team was ridiculed by some UML experts, acceptance was high, as all stakeholders were able to understand the generated documents within a short time.
Formalization
With such a foundation, the formality of the requirements model can be gradually increased. It is advisable to adhere to well-known and well-documented approaches as much as possible. For example, the ICONX process (ICONIX) is considerably more formal than the one just described, but still manages with only four UML diagrams.
Another recommended approach to phased expansion is the use of modeling in specific sub-areas. For example, in the railway sector, formal languages such as Event-B, Z, or VDM are used, but never across the entire system; rather, they are used for specific parts of the system where functional safety plays a particularly important role.
Conclusion
There are many different approaches, from simple information models to formal languages like VDM or B. But regardless of what is used: modeling must have a purpose.
Therefore, the benefits of modeling must be weighed against the costs. This is best done through a phased implementation.
When used correctly, requirements modeling can offer enormous added value, as redundancies disappear and the handling of changes is drastically improved, to name just a few of the advantages. And the ability to handle changes is precisely one of the major advantages that is valued in our fast-paced times.
Literature and sources
[29148] The IEEE 29148-2011 standard lists simple examples of sentence templates.
[ICONIX] https://se-trends.de/iconix-methode/
[IREB] https://re-magazine.ireb.org/issues/03-an-eye-for-detail/modeling-requirements-with-constraints
[SET18] Michael Jastram: „18 things you can do with systems models“
[RH] Michael Jastram (Editor): Rodin Handbook
[UML] https://www.omg.org/spec/UML/
Download the article as a PDF
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
To the specialist information
You can find expertise on other topics in our portfolio here. here.
EN 
DE 
