Property-based Requirements in SysML 1.5[RS1]
Author: Manas Bajaj | | Intercax
Date: Apr 9, 2015
Last Updated Apr 25, 2015 (sf)
GoalDocument purpose: Thisegoal of this document is to lists the pros and cons of relaxing the existing constraints on the SysMLrRequirement stereotypes to enable semantically-richer representation of property-based requirements in SysML. more precise expression of text-based requirements (refer to issue 19591). As a simple example, a text requirement that reads 'The system mass shall be less than 100 kg' can be expressed precisely by defining a property m:kg and constraining its value as {m<100}. This in turn is intended to reduce ambiguity and facilitate requirements verification.
The contents are meant to inspire discussion and facilitate resolution among the PBRWG members. In addition, the document is intended to , and to provide some of the rationale for create the draft proposal for SysML 1.5 RTF for inclusion ofto include Property-based Requirements in SysML 1.5.
The SysML v1.4 specification includes the following 6 constraints on the Requirement stereotype:
[1] The property “ownedOperation” must be empty.
[2] The property “ownedAttribute” must be empty.
[3] Classes stereotyped by «requirement» may not participate in associations.
[4] Classes stereotyped by «requirement» may not participate in generalizations.
[5] A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement».
[6] Classes stereotyped by «requirement» may not be used to type any other model element.
- Property ownedOperation must be empty
TBD
Pro's
An owned operation can be used to specify an expression for a property-based requirement.
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.
Cons
A requirement operation could be misused. For example, it may not make sense to invoke certain operations on requirements.
- Property ownedAttribute must be empty
Pros
A property enables requirement to be specified in terms of quantifiable characteristics. This is at the core of making a requirement more precise.
- Note that a property can also be a distributed property with an associated probability distribution
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
Cons:
There are many kinds of properties in SysML such as part properties, ports, and others. This opens up many different ways in which people can use and abuse a pbr.
- Classes stereotyped by «requirement» may not participate in associations
Pros
Enables a requirement to be used in parametrics. This enables the a property of a requirement. such as mass, to be bound to a property of a block. This unambiguously associates the property of the requirement with a particular system or component property. It also enables the value of the property to be computed from an analysis, and then compared with its required value.
- It should be clarified that the requirement relationships including deriveReqt, refine, satisfy, and verify, can apply to a property typed by a requirement.
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.
In addition the requirement decomposition approach above can support the application of logic to the child requirements such as AND and OR. This may be very useful for specifying variants. For example, the required electrical power may be 60 Hz at 110 VAC or 220 VAC.
To investigate:
●Semantics of associations that are navigable at both ends. Check the semantics for blocks.
- Classes stereotyped by «requirement» may not participate in generalizations.
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
- 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.
- 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
- Requirement description should be smart text such that words / phrases can be bound (or refer) to other model elements, e.g. properties, values, expressions) ofn the same requirement or other model elements.
- When the referenced model elements are changed (name change, value change, etc.), then the requirement text should automatically update. Similarly, if the requirement text is changed, the referenced model element should change in a consistent manner.
< TBD >
[RS1]JW suggests adding a need section to each of these constraints. This should be linked/derived from the overall proposal need. An overall need section could also be added.