Issue 19591: Precise expression of requirements (sysml-rtf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Enhancement Severity: Significant Summary: Current requirements in SysML are expressed as text strings, which limit the ability to precisely express requirements that can be evaluated and verified. A more formal expression of requirements is needed that includes the ability to specify required input/output parameter relationships and/or constraints. A simple example is the specification of the required stopping distance of a vehicle as a function of the initial speed and the road conditions. The requirement can be specified in text, and augmented with an input/output parameter relationship as follows: The Vehicle stopping distance shall not exceed the values in Table 1 as a function of initial speed and pavement condition. Table 1 displays discrete values of start speed from 0-100 mph, pavement condition as wet or dry, and required stopping distance in feet. TABLE 1 (not included) An alternative expression in plot format can be: The Vehicle stopping distance shall not exceed the values in Figure 1 as a function of initial speed and pavement condition. Figure 1 shows plots of required stopping distance as a function of start speed and pavement conditions. (NOT INCLUDED) The input/output parameter relationship or constraint can be specified by an equation such as is the case for this example as follows: Stopping distance <= (1/(2*32.174*alpha)*(5280*Initial Speed/3600)^2) Start Speed = 0 …100 where: alpha dry 0.8 wet 0.6 More generally, the input and output parameter values may be complex functions of other parameters, and may have probability distributions associated with them. A solution to this issue shall satisfy the following requirements: 1) A requirement can be expressed in terms of input/output parameter relationships and/or constraints. a) The parameters can by typed by value types with units and quantity kinds b) The parameters can have direction to reflect whether they are inputs or outputs or no direction. The direction applies to a particular requirement context. c) The parameters can be specified over a range of values d) The parameters can have probability distributions e) There can be any number of parameters with directions of input, output, or none f) The relationship between the parameters can be expressed as a mathematical equation and presented in formats that include a mathematical or programming language, tables, and plots g) The parameters and parameter relationships and/or constraints can be expressed using parametrics 2) A requirement can include an id and text statement consistent with current SysML requirements to elaborate the requirement specification. a) The text can be parsed and linked to the parameters, values, and units 3) A requirement can be reused in different contexts (this is subject to further debate) 4) Consider adding precision to Tthe current text based requirement relationships apply 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. 5) Maintain backward compatibility with current text based requirements, and or provide clear transformation rules for consistent vendor implementations Initial Concept: A possible solution that has been proposed is to define a property based requirement as an extension of a constraint block. This stereotype includes and id and text property and other user defined properties, and incorporate other features that SysML requirements currently provide (e.g. notations, requirements relationships). The constraint expression reflects the required stopping distance equation above, and can be expressed like any other constraint using a mathematical or programming language. In the parametric diagram below (2nd figure), the black box analysis on the right side of the figure is intended to be executed by an analysis tool, return an estimated stopping distance, and compare this result with the required values for stopping distance to determine a verdict of pass/fail. Resolution: 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: [1]http://issues.omg.org/browse/SYSMLR-155 Priorities in developing the resolution to [2]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. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/SYSMLR-155 [2] http://issues.omg.org/browse/SYSMLR-155 Revised Text: See attached .doc files for changes to Chapter 16 and the addition of Annex E.8. Figures referenced in .doc files are provided as .svg files for inclusion in the specification. Actions taken: August 28, 2014: received issue January 3, 2017: Resolved April 6, 2017: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 28 Aug 2014 21:40:51 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Employer: mailFrom: safriedenthal@gmail.com Terms_Agreement: I agree Specification: OMG Systems Modeling Language (OMG SysMLâ„¢) Section: Chapter 16/Section 16.3.2.4 FormalNumber: ptc/2013-12-09 Version: 1.4 Doc_Year: 2013 Doc_Month: November Doc_Day: 01 Page: 147 Title: Precise expression of requirements Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: 63.139.4.253 Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Time: 09:40 PM Description: Current requirements in SysML are expressed as text strings, which limit the ability to precisely express requirements that can be evaluated and verified. A more formal expression of requirements is needed that includes the ability to specify required input/output parameter relationships and/or constraints. A simple example is the specification of the required stopping distance of a vehicle as a function of the initial speed and the road conditions. The requirement can be specified in text, and augmented with an input/output parameter relationship as follows: The Vehicle stopping distance shall not exceed the values in Table 1 as a function of initial speed and pavement condition. Table 1 displays discrete values of start speed from 0-100 mph, pavement condition as wet or dry, and required stopping distance in feet. TABLE 1 (not included) An alternative expression in plot format can be: The Vehicle stopping distance shall not exceed the values in Figure 1 as a function of initial speed and pavement condition. Figure 1 shows plots of required stopping distance as a function of start speed and pavement conditions. (NOT INCLUDED) The input/output parameter relationship or constraint can be specified by an equation such as is the case for this example as follows: Stopping distance <= (1/(2*32.174*alpha)*(5280*Initial Speed/3600)^2) Start Speed = 0 …100 where: alpha dry 0.8 wet 0.6 More generally, the input and output parameter values may be complex functions of other parameters, and may have probability distributions associated with them. A solution to this issue shall satisfy the following requirements: 1) A requirement can be expressed in terms of input/output parameter relationships and/or constraints. a) The parameters can by typed by value types with units and quantity kinds b) The parameters can have direction to reflect whether they are inputs or outputs or no direction. The direction applies to a particular requirement context. c) The parameters can be specified over a range of values d) The parameters can have probability distributions e) There can be any number of parameters with directions of input, output, or none f) The relationship between the parameters can be expressed as a mathematical equation and presented in formats that include a mathematical or programming language, tables, and plots g) The parameters and parameter relationships and/or constraints can be expressed using parametrics 2) A requirement can include an id and text statement consistent with current SysML requirements to elaborate the requirement specification. a) The text can be parsed and linked to the parameters, values, and units 3) A requirement can be reused in different contexts (this is subject to further debate) 4) Consider adding precision to Tthe current text based requirement relationships apply 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. 5) Maintain backward compatibility with current text based requirements, and or provide clear transformation rules for consistent vendor implementations Initial Concept: A possible solution that has been proposed is to define a property based requirement as an extension of a constraint block. This stereotype includes and id and text property and other user defined properties, and incorporate other features that SysML requirements currently provide (e.g. notations, requirements relationships). The constraint expression reflects the required stopping distance equation above, and can be expressed like any other constraint using a mathematical or programming language. In the parametric diagram below (2nd figure), the black box analysis on the right side of the figure is intended to be executed by an analysis tool, return an estimated stopping distance, and compare this result with the required values for stopping distance to determine a verdict of pass/fail.