Filter
Top Products
Chapter 7. MDSD and SysML 147
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 text-based requirements of any nature (for example, functional or
non-functional) as well as the relationships between them.
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.
Sub-requirements are related to their parent requirement using the cross-hair
relationship (that denotes namespace embedding). For example, in
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.
3
See 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