Filter
Top Products
Chapter 7. MDSD and SysML 149
Another relationship between requirements is <<refine>>. An example of
requirement refinement is shown in Figure 7-2 on page 148. The requirement
on speed actuation is refined by the possible selection for speed (slow,
medium or fast.) Lastly, a generic <<trace>> dependency can be used to
emphasize that a pair of requirements are related in some way or another. In
Figure 7-2 the requirement for Manual Disablement is traced to the one about
Automatic Disablement.
Requirements have a number of derived attributes to store the status of the
relationships reviewed in the above paragraphs. We will see later in this
chapter that these attributes become particularly handy when requirement
relationships are represented outside requirements diagrams.
Often requirements are elicited during the whole product life cycle and
additional requirement diagrams are used to represent them. Hence the
product requirements are typically laid out on a set of requirement diagrams.
SysML provides a generic model for requirements that allows the modeling of
both functional and non-functional requirements. A non-normative set of
requirement types are proposed in the appendix of the OMG SysML
specification.
4
Specific types of requirements (for example related to timing or
scheduling) are handled by language extensions. SysML (like UML) supports
a profile mechanism to extend the language. The Object Management Group
(OMG) has released a series of modeling standards that address specific
needs: for the modeling of non-functional requirements related to
performance and quality [quality of service (QoS), software test plan (STP)],
and for the modeling of test cases [testing profile]. These profiles can be used
in SysML without restriction.
It should be noted that while SysML allows for requirements decomposition and
allocation of requirements to design elements, MDSD does not encourage this.
In general, MDSD promotes the derivation of requirements (as opposed to their
allocation) through system decomposition and operations analysis.
5
Additionally, much of the manual labor of creating requirements related diagrams
can be automated, and should be, based on the artifacts resulting from following
the MDSD process. For example, each use case or operation realization in a
model represents the derivation of requirements on the participating
collaborators. The functional requirements (operations) on each of the
collaborators are derived from the use case or operation being realized.
4
SysML 1.0 Specification (ptc/06-05-04), OMG final adopted specification, available at
http://www.omgsysml.org/
5
See discussion in Chapter 2 concerning requirements decomposition and Cantor’s article on
Functional Decomposition: Thoughts on Functional Decomposition, Rational Edge, June 2003,
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/apr03/Functiona
lDecomposition_TheRationalEdge_Apr2003.pdf