Transitioning from static diagrams to executable models in requirements engineering enhances precision and testability in system design. Unlike conventional diagrams, executable models can simulate system behavior, clarify requirements, help to reveal defects, and communicate stakeholder's understanding. The itemis CREATE Player allows you to embed executable models directly into your requirements engineering tool of choice using a URL to an unmodifiable model version.
Adding diagrams to requirement sets is state of the art in requirements engineering, as you can read in the INCOSE Guide to Writing Requirements. However, using static diagrams that are not executable has some major drawbacks. These drawbacks are especially important when it comes to modeling the system's behavior, for example with state machines.
State machines can be of great use for bridging the error-prone gap between specification and implementation. Specifications often come as a collection of formal or informal requirements written in natural language, or as diagram sketches. The implementation on the other hand is done in strictly formal modeling or programming languages. The translation from one to the other can be tricky and software issues often result from missing, incomplete, contradictory or misinterpreted requirements. This is where state machines can come in as a valuable tool for bringing everyone on the same page.
Embedding an executable model instead of a diagram has the advantage that the model can be simulated, ideally directly within the requirement's management tool.
Let us take a look at a simple example: a light switch system with optional motion detection. The requirements for such a system could be something like this:
Requirement 01: The light switch system shall have the 3 states
Requirement 02: In the “Light Off” state, the brightness of the light shall be set to 0.
Requirement 03: The system shall transition from the "Light Off" state to the "Manual Mode" state when the “On” button is pressed.
Requirement 04: In the “Manual Mode” state, the brightness of the light shall initially be set to 1 and incremented by 1 every time the “On” button is pressed.
Requirement 05: The system shall transition from the "Manual Mode" state to the "Motion Detection Mode" state when the “Mot” button is pressed.
Requirement 06: In the “Motion Detection Mode” state, the brightness of the light shall be set to 0 when no motion is detected and it shall be set to 3 when motion is detected.
Requirement 07: The system shall transition from the "Manual Mode" state or the "Motion Detection Mode" state to the “Light Off” state when the “Off” button is pressed.
These are all perfectly sound requirements and they might be translated into or accompanied by the following sketch:
Somewhat experienced engineers will quickly notice that the requirements do not cover all the details necessary for a robust and user-friendly implementation. But let us put that aside and create an executable Statechart Player strictly based on the specification:
This system looks fine and the requirements are fulfilled. Every state can be activated and the brightness is set as specified.
From a user point-of-view though, when interacting with the system, one will notice that it is not possible to directly enter the “Motion Detection Mode”, because the “Manual Mode” has to be activated first. Also, there is no direct transition from the “Motion Detection Mode” to the “Manual Mode”. This might be intended, but it certainly makes sense to double-check if the specification should be adjusted.
In addition, the behavior of the “Manual Mode” is questionable: the brightness can be incremented up to the maximum value of the variable “brightness”, whatever that might be. There is no limit or guard specified and it is unclear whether the brightness should toggle back to one afterward.
Let us continue with the “Motion Detection Mode”: apparently there is no hysteresis/delay time taken into account. Depending on the definition of the interfaces “motion_detected” and “no_motion_detected”, the system might toggle between the two states.
And finally, when setting up a state machine, one has to define an entry or “init” point. It is very likely that the initial state should be “Light Off”, but it is not specified and therefore up to the software developer.
This is a very simple example, but it clearly demonstrates the advantages of being able to interact with a system design at a very early stage.
itemis CREATE integrated a feature named Statechart Player, which enables public (or private) sharing of an executable version of a state machine and even integration in commonly used collaboration tools like IBM Doors, PTC Codebeamer, Atlassian Confluence, or Atlassian Jira. This way, the system behavior can easily be shared with project members in-house or even beyond corporate boundaries.
A Statechart Player is read-only, so it is not possible to change the shown model anymore. If the model needs to be modified, this must be done outside the player. When done, a new version of the Statechart Player needs to be created, which will get a different URL. Unmodifiable URLs have the advantage that when used in a requirements set, baselines of the requirement set remain valid over time without the need to consistently baseline the model together with the requirements set. Of course, this applies not only to requirement sets, but to all artifacts in which Statechart Player URLs are stored.
In our example, we modeled the state machine “by hand”, created the Statechart Player, and added the player URL as a link to the requirement set.
Depending on the way the requirements are specified, there are different options to derive the executable models from the requirements. If the requirements are specified in natural language, this can be done by using AI support. You can read more about this topic on LinkedIn.