SYSMLR — Precise expression of requirements

Property Based Requirements Background Information

1. Challenge / Needs
Action: provide a clear statement of the modeling capabilities and end user wants from SysML requirements modeling

1.1 BASIC NEED as stated in 'criteria for an enhanced text based requirement' document (below): CURRENT USERS OF TEXT BASED REQUIREMENTS NEED AN ENHANCED CAPABILITY TO EXPRESS TEXT BASED REQUIREMENTS MORE PRECISELY, TO REDUCE AMBIGUITY AND FACILITATE VERIFICATION BY ANALYSIS AND OTHER METHODS.

Amplification: The enhanced text requirement is used in conjunction with the overall system model to assist in specifying and architecting systems. Sometimes, the system model is used as a model-based specification, such as when block instances with specific property values represent the requirement. In this case, the model-based specification further refines the enhanced text based requirements.

1.2 Primary needs derived from the basic need:
1.2.1 PROPERTIES OF REQUIREMENTS (see also issue SYSMLR-34): Requirements in SysML need to specify properties with quantitative values. These properties and their values must be relatable to other model elements or properties for the purpose of design refinement, analysis, and verification.
RATIONALE: The most fundamental way to add precision to requirements is the addition of properties and values.

1.2.2 MINIMIZING REDUNDANCY and AMBIGUITY: A requirement in SysML should be expressed with the minimum number of model elements and relationships.
RATIONALE: Refinement of textual requirements into other model elements has the potential to add redundancy and ambiguity. For example, the maximum acceptable weight for a system should appear as a single number within a requirement, and that number should be linked directly to both design values and verification methods. Redundant textual and numerical versions of the weight requirement add redundancy, and requirement relationships at a parent level instead of a value level add ambiguity.

1.3 Other needs derived from basic and primary need:
1.3.1 MIXED EXPRESSIONS (see also issue SYSMLR-34): Requirements in SysML should be able to be written as "The top speed of this car shall be greater than <x>. And there be a compartment of the requirement where the current value of <x> is given, such as <x> = 200mph." <x> in this case is a property of a requirement, mentioned in 1.2.1 above.
RATIONALE: This explicitly and unambiguously ties the numerical/variable property of the requirement (1.2.1) to the textual expression of the requirement. Also, by using this mixed expression as a transformation or replacement for the plain text expression, redundancy and ambiguity are reduced (1.2.2).

1.3.2 VALUE TYPES: Numerical value/variable properties of requirements in SysML need to have quantity kind and units applied to them. (The implementation of this need leads to Value Properties of requirements)
RATIONALE: This is consistent with the quantity kind/units need that led to Value Properties of blocks and parts.

1.3.3 VALUE DISTRIBUTIONS: Numerical value properties of requirements in SysML need to be able to be expressed as distributions, meaning an acceptable distribution of values.
RATIONALE: Requirements are often expressed as having an acceptable range of values

1.3.4 DIRECTION/CAUSALITY OF REQUIREMENT PROPERTIES: (this need is controversial) Numerical value/variable properties of requirements in SysML need to be able to have direction associated with them.
RATIONALE: In order for requirements to specify input/output relationships, direction must be able to be applied to various values or variables in order to indicate if they are inputs or outputs.

1.3.5 REQUIREMENT RELATIONSHIPS TO PROPERTIES OF REQUIREMENTS: Properties of requirements in SysML need to be able to participate in requirement relationships (satisfy, verify, etc) directly, and not solely through the requirement that types it.
RATIONALE: This capability removes potential ambiguity (1.2.2) and enables one to reuse requirements in different contexts.

1.4 Other derived needs from the above needs:
1.4.1 TEXT PARSING (see also issue SYSMLR-40): There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements.
RATIONALE: This capability is a mechanism for transforming pure-text statements into mixed expression statements.

1.4.2 MATHEMATICAL EXPRESSIONS: There is a need for requirements to own or contain mathematical expressions that elaborate and clarify textual or mixed expressions so they can be evaluated as being satisfied and verified.
RATIONALE: Mixed and textual expressions can't be evaluated. A slightly more rigorous formalism, such as -

, provides a potentially evaluatable format for expressions.

1.5 Needs that have been discussed but are not directly related to the basic need in issue 19591:
1.5.1 REQUIREMENT REUSE: A requirement needs to be able to be reused in different contexts. This implies a property can be typed by a requirement so that it can give the requirement context. It also supports the intent of specializing requirements.
RATIONALE: Treating requirement like other classifiers in SysML adds symmetry to the language and adds modeling efficiencies through reuse.

1.5.2 RULES FOR HIERARCHICAL REQUIREMENT RELATIONSHIPS: Consider adding precision to the current text based requirement relationships as follows: a) One or more properties are asserted to satisfy a requirement when the input/output parametric relationships and/or constraints are satisfied, b) A test case that verifies a requirement proves the parametric relationship and/or constraint is satisfied through a verification method (e.g., inspection, analysis, test), c) A requirement is derived from another requirement when the parameters of one requirement are derived from the parameters of another requirement typically through some form of analysis, d) A requirement refines one or more other requirements when it expresses the requirement more precisely, e) The requirement can contain other requirements, which reflects the logical AND of those requirements unless stated otherwise
RATIONALE: When requirement relationships are provided at both the requirement level, and the requirement property level (1.3.5), the relationship between the parent relationship and the property relationships need to be semantically understood.

2. Current Solution / Workaround
Action: how are users currently addressing this today and what are the issues with the workarounds?

This has been demonstrated in various presentations at the PBRWG

3. Proposed Solution for SysML 1.5
Action: How are we proposing to do this in SysML 1.5?

1. Enable the following
a. include properties in requirements
b. include expressions in requirements (e.g., derived, constraint, opaque)
c. enable text to refer to other model elements
d. enable a property to be typed by a Requirement so that it can be used in context
e. enable a requirement to be specialized

2. Ensure users can continue to model requirements as they have in SysML v1.4

Note 1: For specification consistency, refer to how the constraint block stereotype is specified in the specification, which may have similar characteristics to the requirement stereotype proposal. In particular, the specification of the constraint block stereotype includes the constraint property that is typed by a constraint block. Also, ensure consistency with the diagram extensions for constraint block and constraint property.

See 'Relaxing Constraints Rationale' document, and most recent

4. References:
4.1. Source Document (issue filed by Sandy): http://solitaire.omg.org/secure/attachment/10829/sysml%20issue-precise%20expression%20of%20requirements-sf-c.doc
4.2. PBRWG meeting minutes (PBRWG wiki): http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf5:groups:require:requirements

Updated Proposal for PBR

Rationale for making a change to SysML:
The current SysML specification inadvertently inhibits the creation of user profiles to extend «requirement». This kind of user profile was envisioned from the inception of SysML to not only be allowed, but encouraged… see the final paragraph in section 16.1 of the SysML 1.0 specification. Annex C.2 in the SysML 1.0 specification provides an example of a non-normative extension to «requirement», the initial intention to be able to add useful properties to requirements (e.g. source, risk, verifyMethod, verifyMethodKind), and add constraints on specific requirement relationships based on the indicated subtype of requirement. See original issue for a more detailed problem statement: http://issues.omg.org/browse/SYSMLR-155

Priorities in developing the resolution to SYSMLR-155:
▪ Retain the current constraints on «requirement» and meaning, and require no change or transformation of existing user models.
▪ Provide a capability for user profile development of requirement-related capabilities. This was an oversight in the original specification, and was always an expected capability. Note that extension of requirement capabilities is completely consistent with non-normative Annex E.3, which has extended «requirement» from SysML 1.0 onwards.
▪ Make all existing requirement relationships available for any new «requirement» user profile, since it would be confusing to add new relationships with different names to express essentially the same meaning.

This proposal refactors the «requirement» model element such that it retains all the previous constraints, but creates a new abstract stereotype «abstractRequirement» that retains ID, Text, and the requirement relationships. This new abstract stereotype may be used as a mix-in on new user-defined, non-normative profiles to meet the agreed initial scope of PBR as discussed above. Note that the new «abstractRequirement» model element, being abstract, can only be used in a user profile and NOT directly in a user model.

Refactoring of this kind is a well-established and accepted method of maintaining software and databases, and the normative change required is well within the authority of the SysML Revision Task Force.

The proposal consists of two distinct parts:
1. The normative change to the specification (restricted to Chapter 16) including refactoring of «requirement» into «abstractRequirement», and associated changes to references and paragraph numbers.
2. A non-normative appendix (Annex E.8) that describes
a. the purpose and basic guidance for use of «abstractRequirement» in custom user profiles, and
b. an example of a user profile based on «abstractRequirement» & «constraintBlock», as well as a user model example employing the profile, and
c. an example of a user profile based on «abstractRequirement» & «constraint», as well as a user model example employing the profile.