15 Requirements Modeling: An Overview
This chapter introduces Part III, a series of chapters dedicated to specific requirements modeling techniques. It outlines the role of modeling in requirements engineering, defines what a model is, and lists the modelling languages covered in the subsequent chapters.
15.1 The Role of Modelling
Models used extensively throughout all phases of the requirements process. Their roles are:
- to facilitate communication with stakeholders and other software engineers;
- to facilitate reasoning about domain goals, domain assumptions, and machine requirements
By using models, we can describe and analyze complex situations much more effectively than with natural language and ad hoc figures alone.
Much like geographical maps enhance our ability to communicate and analyse journeys or places—by selecting the right level of detail, showing only what is relevant, and making complex terrain easier to understand—requirements models enhance our ability to communicate and analyze requirements.
Given the scale and complexity of modern software systems, defining high-quality requirements would be extremely difficult—if not impossible—without modeling. It would be akin to trying to plan a long journey without consulting any map.
15.2 What is a Model?
To create effective models, it is essential to understand what they are and what they are used for.
A model is always a simplified description of a more complex reality. The purpose of simplifying reality is to make it easier to understand, communicate, and reason about. This idea is captured by the well-known aphorism:
“All models are wrong, but some are useful”.
All models are wrong in the sense that they are never entirely accurate representations of the reality they describe, but some models are useful because they help us understand, communicate, and reason about that reality.
A well-known example is the London Underground map. Most of you are probably familiar with it; if not, you can view it here: London Underground Tube Map.
The London tube map is not a geographically accurate representation of the London Underground system. In reality, the lines twist and turn; they are not neat straight segments with 45- or 90-degree corners as depicted on the map. The distances between stations are also not accurately represented. Some stations are much closer to each other than they appear on the map. For example, Lancaster Gate is very close to Paddington (about 300 meters) but looks much farther away on the map.
The London Underground map is wrong but useful. It has been designed for one purpose: to help travelers identify what trains to take to go from any station to any other station. Designing the map involved deciding what to include and not include so that the map would be as useful as possible for travellers. The key decision was to focus on the connectivity between stations and to ignore unnecessary geographic details.
In the same way, when we create requirements models, we need to decide what to include and not include in our models so as to make them as useful as possible for their intended audiences. A model is always a simplified representation of a more complex reality, and it is created for a specific purpose and audience. Knowing the model’s purpose and audience is therefore essential to decide what to include and not include in a model.
A common beginner’s mistake is to treat modelling as an end in itself, while losing sight of the model’s purpose and audience.
15.3 Multiple Views
Another crucial point is that describing and reasoning about complex systems usually requires multiple models that represent different views on the system. The models describe the same reality but from different perspectives.
To continue with our London Underground example, the tube map is useful to passengers planning a route from one station to another, but it is useless to passengers on a platform who want to know when the next train will arrive. For that purpose, passengers rely on another model: the real-time departure boards on each platform. We thus have two views: the tube map is a static view of all lines and their connections, the departure boards are dynamics views on the next train arrivals. Each serves a different purpose, and they complement each other. They are also consistent with each other: they both refer to the same tube lines. It would be confusing if the tube map and departure boards used different names for the tube lines. The London Underground has many more models to serve the needs of other stakeholders: the London Underground operation staff rely on other models such as signalling diagrams, train timetables, and maintenance schedules, each tailored to support their specific operational, planning, or safety tasks.
In the same way, when we create requirements models, we often create multiple models, where each model serves a specific purpose for a specific audience. The multiple models complement each other and must be consistent one with another.
Table 15.1 lists requirements modelling relevant to each phase of the requirements engineering process. Most of these techniques have been covered in Part II.
| Phase | Main models used in the phase |
|---|---|
| Foundation | Goal models, context diagrams, stakeholder onion diagram. |
| Exploration | Domain scenarios, context diagrams, domain conceptual models, process models, goal models, impact maps, user story maps. |
| Decision | Cost-value based models, goal models, impact maps. |
| Formulation & Quality Assurance | Requirements patterns, use cases, Given-When-Then scenarios, goal-oriented requirements specifications, temporal logics. |
| Evolution | Goal models, traceability links. |
15.4 Requirements Models in Part III
The objective of Part III is to provide detailed guidance and definitions for specific requirements modelling languages, focusing on those that are most fundamental, well-defined, and useful in practice.
| Requirements Models | Brief description |
|---|---|
| Context diagram | A context diagram shows the machine inputs and outputs with the world, together with the set of actors composing the world and their shared phenomena. |
| Domain conceptual model | A domain conceptual model defines the main entities, associations, and attributes in the world. It is represented using a subset of the UML class diagram notation. |
| Domain scenarios | A domain scenario is a real or imaginary sequence of events happening in the world. Domain scenarios can be represented in text, as in UML use case definitions, or graphically as domain stories or message sequence charts. |
| Goal models | A goal model describe stakeholders goals and their refinements into subgoals, domain assumptions and software requirements. |
| Requirements patterns | Requirements patterns are reusable templates for writing requirements in clear, structured natural language. |
| Specification-by-Example | A specification-by-example consists of scenarios that provide concrete examples of how the machine is expected to behave in specific situations. These scenarios illustrate more general requirements and can be used as automated acceptance tests. |
| Formal Specification of Properties | Temporal logic specification of behavioural properties like domain goals, domain assumptions, and machine requirements. |
Note that a modelling technique is not limited to its visual representation, and that some modelling techniques are entirely textual (e.g. requirements patterns, specification by example, formal specification of properties). A requirements model is not just a diagram. Requirements models have precise semantics, are related through inter-model consistency rules, and can have multiple graphical and textual representations.
Each of the following chapters in Part III serves as a short introduction and reference guide to a specific requirements modelling technique. Each chapter begins with a brief, informal overview of the technique, followed by a more detailed presentation of the modelling language, including practical guidance, common mistakes, and ways to avoid them.
15.5 Notes and Further Readings
The quote that “all models are wrong but some are useful” is attributed to the statistician George Box.
Jim Woodcock and Jim Davies’ book on the Z specification language (Woodcock and Davies 1996) provides a more comprehensive discussion of modelling principles, illustrated on the London Underground map. Our discussion is based on theirs. You can also read how the modern tube map replaced an earlier geographic map on the London Transport Museum website.