• Methods

Discovering System Requirements through SysML

1 Requirement, requirement model & requirement diagram

The SysML’s requirement type element serves as a basis to specify text-based requirements. In fact, its true value relies on the ability to link it to many SysML modeling element types: requirement but also block, actor, use case, activity, interaction, state machine, etc. The requirements and the requirement relationships form the requirement model which is fully depicted with the SysML requirement diagram i.

With SysML, System Analysts can relate the individual text-based system requirements to the elements that model the system and thus show where the requirements originate from. Surprisingly, this traceability capacity is rarely shown in articles and books dealing with requirement modeling.

2 Case study

The case study is inspired by the Network Pump®. Information about the device is taken from documents [REF05], [REF06] and [REF07]. The Pump enables software applications operating on a lower security network to pass information to software applications onto a higher security level network automatically, in a secure and reliable manner. These applications are later denoted “Low App” and “High App” in the Pump’s SysML model ii.

In this paper, the SysML model does not attempt to depict exactly the Pump. It rather illustrates how SysML can be used in the analysis phase of a system which is seen as a black box. The outcome of the phase is a comprehensive and consistent set of requirements that the system must fulfill.

3 SysML models initiated during the requirement elicitation phase

3.1 Requirement models

The business and user needs, business rules, system performances and constraints found out during the elicitation phase are modeled as SysML requirements, each defined by an identifier and a textual specification:

Figure 1: Requirement model. Some requirements from the elucidation phase.

The SysML requirement diagram is the « place » where requirements can be related. SysML offers 7 requirement relationships [REF01]. The semantics of these relations is not controlled: a requirement can be related to another requirement by any type of requirement relationship. However, links between requirements enforce the consistency of the requirement set:

Figure 2: Traceability model. The “deriveReq” relationship is used to relate a requirement to its source - the “refine” relationship can be used instead -. The general purpose “trace” relationship is used to state that a business rule applies to a requirement.

3.2. Context models

The stakeholders of the Pump can be depicted in a SysML block definition diagram (BDD):

Figure 3: Stakeholder model. According to ISO 29148, low and high applications which are external systems connected to the Pump are not stakeholders even if they are sources of requirements - interface requirements -.

The operational environment of the Pump is depicted by a block definition diagram together with an internal block diagram (IBD):

Figure 4: Operational environment model. Top: structure model [BDD]; Bottom: interface model [IBD]

The BDD shows the structural elements of the system operational environment i.e. who (person) and what (system) can interfere with the Pump. Cardinalities indicate the possible configurations of the operational environment (i.e. how many applications can be connected to the Pump). The IBD shows on a concrete environment model what can flow into and out of the Pump through its interfaces.

4 SysML models initiated during the analysis phase

4.1 Use case model

Given the findings obtained during the elicitation phase, use cases come first when analysing a system. For the Pump, two use cases are identified:

Figure 5: Use case model. Left side: primary actors; right side: secondary actor

At the system level, the intent of the use case model is to capture the capabilities (services) the Pump must provide in order to fulfill the requirements of the stakeholders. Among these stakeholders are the actors interacting with the Pump.
The “Transfer Data” use case is triggered by a low application (primary actor) in order to send data to a high application (secondary/supporting actor) over the Pump in the context of a session. Multiplicities on the association ends mean [REF03] that:

  • Data are passed from one low application to one high application (actor end)
  • Low App and High App participate in only one session (use case end)
  • The Administrator can act upon the course of the sessions.

The “Update NP” use case is triggered by the Administrator. This use case develops the user stories “Pump configuration update” and “Pump security update”.

4.2 Modeling the “Transfer data” use case

Generally, use cases are described using a structured, text-based specification defining: 1) the necessary conditions that must hold to start the use case (trigger and preconditions), 2) the outcomes of the use case (postconditions, minimal guarantees), 3) the steps iii of the scenarios (main, alternatives, exceptions) [REF08].

In practice, the main difficulty is to efficiently describe the combinations of the steps forming the various scenarios contained in a use case. The issue can be overcome by a modeling approach.

In a Model-Based Requirements Engineering approach, each step of a use case can be modeled by a SysML activity, an interaction or a state and the scenarios contained in a use case can be captured in an activity or a state machine. Modelers must make choices iv, one criterion being the nature of the use case (is it device-driven or human-driven?).

Transferring data from Low App to High App over the Pump is basically an automatic, message-driven process triggered by Low App. Thus, a relevant choice is to model the steps of the transfer data use case by a state and to capture the use case dynamics in a single state machine:

Figure 6: Modeling the Transfer Data use case with a state machine and interactions.

States are time slots where preconditions hold or interactions are performed:

Figure 7: Modeling the steps of a use case with interactions depicted by sequence diagrams. Top down: Step 1 “Open session”, Step 2 ”Transfer Data”, Step 3 “Close session”, Step 3.1 “Exit session”

Transitions between states are triggered by message reception events. Each scenario is modeled by a specific set of transitions between states, leading to one final state from the initial pseudo-state.

Step (state) 2 is repeated for each data message sent by Low App to the Pump. The state is left:

  • If the Pump receives a Close Connection message from Low App (use case main scenario)
  • If the Pump receives a Connection Exit message from the Administrator (alternate scenario)
  • Upon Low App or High App timeout events (exception scenarios)

5 Specifying textual system requirements from models

Specifying requirements with models does not eliminate the need for text-based requirements:

  • Models can still be ambiguous. “Customers” of the models must have a basic knowledge of SysML, be informed about the modeling methodology used (if it exists) and the intention of each model to get the appropriate understanding of the overall system model.
  • Models can still be incomplete. Not everything can be efficiently expressed with models. From the business rule “Pump update” [figure 1], it follows that the use cases “Transfer Data” and “Update NP” must not run simultaneously. Modeling conflicts between use cases is tricky. This situation is efficiently specified by means of the text-based requirements “Preclude connection request” and “Preclude Pump update”.
  • Models mainly highlight the functional aspects of the modeled system.

Textual system requirements derived from models should supplement, where necessary, what the models themselves state. They should include condition and/or quality (performance) items [REF10], [REF11]:

Figure 8 : Requirement model. Some system requirements from the analysis phase

6 Requirement traceability

The SysML requirement diagram is flexible. Any model element that has a name can be a node on it; nodes can be related by the requirement relationships. During the system analysis phase, the derive, refine and trace relationships are appropriate to link the model elements. In fact, the semantics of the relationships does not really matter: the resulting network aims to trace the system requirements back to the business needs through the model elements resulting from the system analysis:

Figure 9 : Traceability model. The “deriveReq” relationship is used to relate a requirement to its source whatever the type of the element source [requirement, state machine, interaction]. The “refine” relationship can be used instead, meaning that the system requirements refine model elements.

7 Conclusion

The Network Pump provides a relevant case study to illustrate how SysML can be used by System Analysts to discover, specify and relate the textual system requirements to their sources. System requirements do not only derive from parent requirements but also from models which, in turn, are sources of requirements.

So far, we have not mentioned the parametric diagram, introduced by SysML in addition to the requirement diagram. The parametric diagram works together with the SysML constraint block. The intent is to build and run models that capture constraints of the modeled system in order to perform engineering analyses, such as trade-off analysis [REF03]. These modeling elements do not really help System Analysts to discover and specify requirements, even non-functional ones. These performance (quality) requirements need to be discovered during the elicitation phase [REF12].

8 References


  • i A model is a physical, mathematical or otherwise logical representation defined for a given objective of a system, entity, phenomenon or process. A SysML model is a logical representation of a system consisting of interrelating modeling elements. The SysML diagrams depict the SysML model from viewpoints.
  • ii The SysML model of the Pump is built under Enterprise Architect version 13 without any extra extensions (stereotypes). EA is a modeling tool, not a requirement management tool.
  • iii Steps of a system level use case are usually either an interaction between the actors and the system, or a validation or a state change by the system [REF09].
  • iv System modeling is all about methodology and choice. Even if an activity is widely used to model the various scenarios contained in a use case, a state-machine is also suitable for that purpose: - Use case preconditions and steps can really be viewed as states i.e. situations that hold over a period of time - Transitions in state machine are more expressive than control flows in activity to model the course of the use case steps - States and transitions are effective to model what must be achieved to run the use case.

Comments (3)

  • From: Keith Collyer
  • Date: 23. September 2021

Hi Gildas

Yes, stereotypes can be used, and if used properly in a modelling tool they can support requirements attributes. But they get very messy if there is a large number of useful attributes. For example, the following set is typical:

  • Owner (who wants this, who needs to be involved in discussions)
  • Priority
  • Planned release
  • Type
  • Source (where did this requirement come from
  • Acceptance status (draft, in review, approved, ...)
  • Urgency
  • Verifiable?
  • Verification approach
  • Verification status (generally better shown by linking to verification objects, but often useful to summarize)
  • Satisfaction status (has it been delivered?)
  • Constraints
  • Questions
  • Comments
  • Owner (who will implement)

Gilb's Planguage tags can also be implemented as attributes:

GIST: A short description to help understanding
PLAN: The level at which success can be claimed
SCALE: The scale of measurement used to quantify the statement
METER: The process or device used to measure using the SCALE
MUST: The minimum level required to avoid failure
STRETCH: The best if everything goes perfectly
WISH: A desirable level of achievement
RECORD: The best-known achievement
PAST: Previous results that may be used for comparison
TREND: A set of historical data or extrapolation of this
STAKEHOLDER: A person or organisation materially affected
AUTHORITY: The person, group or level of authorization allocated
DEFINED: The official definition of a term

Once defined, these can be used in a requirements management tool for searching, filtering (show me all the security requirements for release 3.4 that will be implemented by Team B), sorting, etc. While not impossible in a modelling tool, these are not easy to do or visualize.

In terms of relationships, as you mention, the most common are satisfies and verifies (usually overloaded to include validates, but that's generally OK). Other common relationships include:

  • Dependency (this requirement depends on another to be delivered)
  • Justification (used to show how a particular element satisfies a requirement. Strictly this is an attribute on the satisfies relationship, but is often better implemented as a separate relationship)
  • Constrains (in a sense a form of satisfaction but is often used for regulatory requirements)
  • Has-Risk, Has-Assumption (relationships as the same risk or assumption might apply to several requirements)
  • Mitigates (there to mitigate a risk, not because it comes from the higher-level requirements)

In addition, many of the attributes mentioned above might in some cases be better implemented as linked elements with appropriate relationship names.

A former colleague of mine, Jeremy Dick, used a diagram that had a multi-layer sandwich, with the requirements as the bread and models as the filling. The analogy is that requirements are a bit dull on their own, but provide the solid foundation that makes the filling digestible and satisfying.

  • From: Keith Collyer
  • Date: 15. September 2021

SysML gives a very limited view of requirements

Incorporating requirements into SysML can be incredibly useful in the right context. For example, in relating requirements to design elements as in the article, and I fully support that.

Using a SysML representation as the only means of viewing requirements is, however, not the right thing to do. There are a few reasons for this:

  • The SysML representation does not truly support very large structured sets of requirements. Although this is anathema to modellers, these are, in practice, much better visualized as documents.
  • The SysML representation does not allow for attributes on requirements, for example, priority, value ranges, owner, status.
  • The requirements cluster pattern tries to account for the second issue but at the expense of turning the attributes into requirements in their own right when they are really properties of the individual requirements. This makes the diagram unnecessarily cluttered.
  • The standard relationship types allowed for requirements are very limited, in practice users tend to need to define their own relationships in addition to "traces" (which in itself is meaningless), "satisfies", and "verifies".

Thank You Keith for Your comment.

Professional modelling tools seem to overcome the lacks you notice:

  1. Stereotypes can be used to add attributes (status, owner) to the requirement type of SysML. We do not really need to display them on the requirement diagram when used to show the traceability links relating the requirements,
  2. Structured requirement documents can be generated from templates

We certainly need to use modeling tools in conjunction with requirement managing tools when facing to a large amount of requirements and dealing with their unavoidable change.
Could You tell me what are those relationships practice user tend to create?

Author's profile
Related Articles
Innovation Arena

An agile and collaborative prioritization technique

Read Article
Think Like a Scientist

Using Hypothesis Testing and Metrics to Drive Requirements Elicitation

Read Article
A key technique

Delegation of requirement verification. A key technique for more mature requirements management.

Read Article