Property-based Requirements in SysML 1.5
Author: Manas Bajaj | manas@intercax.com | Intercax
Date: Apr 9, 2015
Goal: The goal of this document is to list the pros and cons of relaxing the existing constraints
on SysML requirements to enable semantically-richer representation of property-based
requirements in SysML. The contents are meant to inspire discussion and resolution among the
PBRWG members, and to create draft proposal for SysML 1.5 RTF for inclusion of Propertybased Requirements in SysML 1.5.
1. Property ownedOperation must be empty
TBD
Relaxing this constraint is consistent with making «requirement» a classifier, like any other. Signal
reception, for example, doesn’t make sense for a requirement. Would it actually be desirable to keep this
constraint?
Relieving this constraint may be necessary for including verification operations/tests. Further discussion
needed before tightly integrating test concepts with requirements.
Analogous to constraint
blocks/constraint properties, which are disallowed from having behaviors.
2. Property ownedAttribute must be empty
Relaxation of this constraint would provide semantically richer representation of primitive
properties (~value properties) of requirements, reuse of requirements (~shared/reference
properties), decomposition of requirements (~part properties), and mathematical definition of
requirement (~constraint properties). In this section, we will address value and constraint
properties on requirements. Refer to discussion in constraint 3 below for reuse and
decomposition.
With property-based requirements, requirements can have primitive properties, as shown in
diagram fragments on Figure 1. The Wheel Requirement has value properties - diameter and
max diameter. It also has a constraint property dia constraint that is elaborated using
parametrics, as shown below in Figure 1. The parametric model provides a math representation
of the typical shall statement in requirement text.
Figure 1 - Properties on requirements
3. Classes stereotyped by «requirement» may not participate in associations
Relaxation of this constraint would provide semantically richer representation of requirement
reuse in the context of other requirements, and requirements decomposition.
Figure 2 shows requirement decomposition and reuse today with SysML 1.4.
Requirement decomposition is done using nesting of child requirements in the parent
requirement. The Power Requirement has 2 nested requirements - Max Power Requirement
and Min Power Requirement. This is how we create requirement structures in SysML 1.4. So,
we use namespaces to represent requirement structure which is not correct semantically since
we mix the idea of location of an element with the composition of the element.
Figure 2 - Requirement decomposition and reuse today
Requirement reuse is very challenging with SysML 1.4. Consider that we need to reuse the
Power Requirement in 2 different requirement specifications - Customer Specification and
Design Specification. This is very common in system engineering projects. When a project is
initiated and the customer specifications are created, the Power Requirement surfaces as one
of the key requirements from the customer. When the design specification is created (based on
the Customer Specification) for the internal design team to start system development, the
Power Requirement is used as-is since it is well-defined.
To reuse the Power Requirement in both the Customer Specification and Design Specification,
we have to create a dummy child (nested) requirements in both and then create a copy
relationship to the Power Requirement, as shown in Figure 3. Obviously, the “copy” relationship
is a qualitative relationship (dependency) and hence we cannot do much with it, such as
defining parametrics at the Customer Specification and Design Specification that would use the
properties of the Power Requirement.
Figure 3 illustrates requirement reuse and decomposition using Property-based Requirement
concept.
For reuse, we can use reference/shared association relationship (white/no diamond), and for
decomposition we can use composite association relationship (black diamond). As shown in
Figure 3, the reuse of Power Requirement is enabled by the shared association relationship
from the Customer Specification and Design Specification to the Power Requirement. No more
dummy requirements need to be created as we do in SysML 1.4. This will also allow us to define
parametrics at the Customer Specification and Design Specification requirement that can use
properties of the Power Requirement.
Figure 3 - Requirement decomposition and reuse with PBR
Requirement decomposition is enabled by using the composition relationships from the Power
Requirement to the Max Power Requirement and Min Power Requirement. Now, there is a
clear distinction between requirement structure and nesting. The Max Power Requirement and
Min Power Requirement may or may not be nested in the Power Requirement. Their location in
the model does not imply usage. So, requirements can start following the same reuse and
structure pattern that have for the rest of SysML elements, e.g. blocks and activities.
To investigate:
● Semantics of associations that are navigable at both ends. Check the semantics for
blocks.
4. Classes stereotyped
generalizations.
by
«requirement»
may
not
participate
in
Relaxation of this constraint would enable semantic representation of requirement reuse by
defining generalization hierarchies. In general, one can define a taxonomy of requirements in a
domain once this constraint is relaxed.
The Snow Wheel Requirement shown in Figure 4 extends the Wheel Requirement by defining
additional value properties - chain thickness and spike height. The Snow Wheel Requirement
inherits the diameter and max diameter value properties, dia constraint constraint property,
and the strength requirement for the material of the wheel.
Figure 4 - Requirement generalization
5. A nested classifier of a class stereotyped by «requirement» must also be
stereotyped by «requirement»
This constraint should also be replaced by something that implies the following in effect.
Requirements can participate in association relationships only with other requirements and
constraint blocks. For the latter, the association must be a directed association from a
requirement to a constraint block.
The primary rationale for the existing constraint in SysML has been that nested requirements
represent requirement decomposition. So, it did not make sense for a requirement to have
non-requirements (e.g. blocks) in the structures.
However, with the property-based requirement approach, we are making a clear distinction
between nesting (for namespaces) versus associations (for reuse and decomposition). It is
possible to nest constraint blocks (used for defining constraints on requirements) in the
requirement. In the future, if requirements are represented (refined) using activities or other
SysML elements, then these elements may also be nested in the requirement.
6. Classes stereotyped by «requirement» may not be used to type any other
model element.
This constraint must be relaxed since it will allow us to represent requirement reuse and
decomposition, as shown in Figures 3 and 4.
Additional capabilities needed for PBR beyond relaxing constraints for
requirement in SysML 1.4
1. Requirement description should be smart text such that words / phrases can be bound
to other model elements, e.g. properties on the same requirement or other model
elements.
2. When the referenced model elements are changed (name change, value change, etc.),
then the requirement text should automatically update.
< TBD >