SysML allows the representation of requirements as model elements, and can be related to other model elements. Hence requirements become an integral part of the product architecture. The language offers a flexible means to represent
Figure 7-2 shows a requirement diagram for the Rain Sensing Wiper (RSW) system. Note that it contains both functional and non-functional requirements.
Requirements in SysML are abstract classifiers (that is, they cannot be instantiated) without operations or attributes. They cannot participate in associations or generalizations, however, a set of predefined relationships help to characterize the relationships between the requirements and other model elements. We review these relationships next.
Figure 7-2 some of the sub-requirements of the requirement Automatic Wiping are connected to it using the cross-hair. The parent requirement is a package for the embedded requirements. In that sense, deleting the parent requirement will automatically delete all the embedded ones. Another example of a requirement acting as a package for other requirements is the
requirement Core Functions, which contains two sub-requirements. For readability in the model, a user-defined keyword package is rendered next to the Requirement stereotype.
During requirements analysis (system decomposition and operational analysis) new requirements are created by derivation. These new requirements can be connected to the initial ones with the <<deriveRqt>> dependency. For example, in Figure 7-2 a set of core functions for the product are derived from the set of requirements under Automatic Wiping. The name <<deriveRqt>> was chosen to avoid any confusion with the standard <<Derive>> dependency in UML 2.0.
Other examples of derived requirements are the technical choices for each function (see the box Technical choices in Figure 7-2). Note that in Figure 7-2 the designer captures a <<rationale>> comment to explain his choice for using a sensor fixed on the windshield.
A last example of derived requirement is the quality requirement System
Calibration stating that the system should be calibrated. This is the requirement added to the product after the RSW failure was identified.3 The satisfaction of this requirement insures that the product will be resilient to changes in the sensor and windshield characteristics.
3See Balmelli, An overview of the systems modeling language for product and systems development
--Appendix A, http://www.ibm.com/developerworks/rational/library/aug06/balmelli/appendixa.html
