Managing Relationships Between Requirements

Requirements management is an important element of the software development process. One of its elements is building and managing relationships between requirements. The most common is the approach used or even promoted by Sparx Systems. Enterprise Architect in its documentation proposes that the requirements be combined with each other using aggregation or composition.

This is a good, though simplistic approach to this issue, which is not compatible with the standards I know. Sparx Systems has adopted a UML language relationship for the management of relationships between requirements. Nevertheless, if someone knows UML, these relationships are not difficult to decipher. This is the most commonly used method.

In many projects, with a tight schedule and quite often budget, there is no space to manage the relationships between requirements in a more sophisticated way. It’s good that sometimes requirements are defined at all J.

Managing relationships between requirements is not only the solutions offered by the documentation for Enterprise Architect. One of the known formal descriptions of the relationship management process between requirements is SysML. SysML offers a range of relationships. Here they are:

What do the individual relationships mean?

The Containment is a relationship that allows the combination of parent and subordinate requirements, which creates a multi-level, hierarchical structure of system requirements. The superior requirement is considered to be met only if all its sub-requirements are met. This approach is shown in the documentation of Enterprise Architect in the form of an aggregation relation.

The Derive dependence allows to derive the target requirement from the source requirement. Typically, a single source requirement is supported by a number of target requirements related to separate output dependencies. System features represented by the target requirement are derived from system features represented by the source requirement. The relation is marked with the stereotype «deriveReqt». In the drawing below I used elements from the SysML dedicated toolbox.

The Satisfy dependency means that a given element has to meet the given requirement. These elements may be use cases, classes, components and other entities. The change of the requirement affects the replacement of the element. The relation is marked with the stereotype of satisfy. The implementation of this approach is the equivalent of this relationship offered by Sparx Systems.

The Copy relation applies when one requirement is identical to one or more requirements. An example is the security requirement, which is copied to several systems. When the dependence of duplication between two requirements is guided, it is assumed that the target requirement is read-only, i.e. it adopts the same content in relation to the source requirement. The relation is marked with the stereotype of “copy”.

The Verify relationship is a relationship that theoretically goes beyond the scope of requirements, because it serves to indicate those entities that verify the requirement. Verifying individual requirements in terms of whether they were implemented during the coding of the system is good or even very good practice. One element that can be verified are test cases. In SysML, test cases are related to requirements using the verification dependency, marked with the «verify» stereotype.
A series of test use cases can be assigned to a single requirement.

The Refine allows the introduction of numerous system details into the system requirements. These details are various artifacts such as an activity diagram presenting the process of calculating the premium, GUI user screen, etc. This dependence creates the possibility to explain the general text written in the source requirement. The relationship is marked with the stereotype of «refine».

The Trace is my favorite relationship. Favorite probably because I use it most often. The trace dependency, marked with the “trace” stereotype, allows to present an informal relationship between the requirement and any element of the system model, including another requirement. Personally, I use the trace relationship, tracking relationships between requirements, to combine use cases with application services and combine use cases with activities on the BPMN diagram.

It would be worth to manage the relationships between requirements in each project. In my opinion, it is not worth using all types of relationships offered by SysML. Perhaps what Enterprise Architect offers in the default toolbox will be enough. Describing the relationships used will not only limit their scope, but also allow you to answer two questions – what is the purpose of using a given relationship and what will be the cost of maintaining a model with many types of relationships.

The point is not to fall into addiction to the mutual dependence of requirements :-).

More from my site

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top