1. Separate Requirement
Management Tools: Several reviewers have expressed the opinion
that systems engineers expect that requirements management will be
done in a separate requirements management tool. Keep in mind that at the
heart of successful systems engineering is capturing stakeholder needs and
assuring that they are satisfied by the product.
Unless a separate requirements management tool is
seamlessly integrated with the system engineering management process, separating
requirements management from the rest of systems engineering is a strategic
error. It makes the whole systems engineering process more difficult
and less efficient by isolating related information into separate data
repositories. An important part of allocation is allocation of
requirements to various architectures and other SE entities. The
allocation relations enable accurate assessments of elements that may be
affected by changes, either from the requirements end or from the implementation
end. The current lack of this capability is a major resource and schedule
obstacle in many large systems and organizations admit that they can't
accurately evaluate the effects of changes on stakeholders and other
important aspects of the system, such as safety, reliability, unanticipated side
effects, etc.
2. Intuitive for Non-UML Expert
Systems Engineers: Human understandability is the ability of a
user to readily and correctly comprehend what is presented as what the author
intended. UML has too many nuances for those that aren't proficient in
UML- speak and it is difficult to see the forest (understanding) for the
trees (details).
Systems Engineers are accustomed to using diagrams
with "relations" that are from a top-down or output-input perspective, i.e., the
directions that the arrows point in a diagram. Further the arrow
represents either the flow of some property or a relation. Names for flows
are noun phrases. Relations are descriptive verbs or verb-phrases so that one
can construct a noun-verb-noun sentence. It appears that UML convention is
to use a simple verb form that, unfortunately, fails to clearly state the
relation being defined. For example requirement1 derive
requirement2 is vague. The derive relation is reverse of
a top-down relation or output-input, i.e., the direction the arrow is
pointing. A clearer relation is defines, e.g.,
requirement1 defines requirement2, i.e., requirement1 is the
higher level requirement.
All of the relation names (dependencies) in both
proposals are backwards from the top-down direction, i.e., they are from the
bottom-up. It is much easier for the reader to understand if they are
top-down, as in the derive vs defines example above. The
SSL proposal alludes to the interpretation problems of this convention by
presenting three different ways of expressing the dependencies, all with
different relation symbols (dashed arrow, dashed line, and semi-circle start of
dashed line) and in some cases clarifying labels (Derived and Derived
From). Three line symbols for the same information, especially if
intermixed in a system, seriously detracts from understandability. The
naming used by the SSL team also tries to make it clearer by expanding on the
dependency names, e.g., deriveReq, so that the object type the derive is being
applied to is more obvious on a diagram. This still doesn't fix the
backwardness. What is needed is an inverse sense of dependency, a
defining relationship, so that the arrow points from top-down.
Another issue is whether one cares if a requirement
is derived or not. All requirements are derived from somewhere. If
the intent is to differentiate from a customer dictated requrement to one that
was internally derived, a clearer way is to create a subtype of derived
requirement.
For requirements, all of the dependency relations
are trace between objects, so I see no need for a such a dependency
except as a base for more specific trace types, as stated in by the SP
definitions and implied by the label in Figure 14-7 Requirements
Traceability. To me, defines should be the generic trace
type. Thus "obj1 defines obj2" where obj1 is
usually but not necessarily a requirement and obj2 can be anything that
makes sense within the context, e.g., an activity, another requirement, a
function. However, if this presents a tool implementation issue, then
defines could be restricted to requirement object
types.
For understandability, I suggest that all
dependency relation names be reevaluated so that the name is consistent with a
defining arrow direction and is in the top-down direction:
For both proposals, with a defining relation
replacing the dependency relation:
deriveReq
defines
Requirement1 defines requirement2.
satisfy (is)satisfiedBy
Requirement1 satisfiedBy activity1 or function1 or
blackbox1
verify (is)verifiedBy Requriement1
verifiedBy testCase1
refineReq
(is)refinedBy Requirement1
refinedBy obj1
traceReq
defines
Requirement1 defines obj1
Regards,
Darold K. Smith: PE,
CSEP
Certified Systems Engineering
Professional
UGS Corporation: Transforming the Process of
Innovation
Teamcenter for Systems Engineering
Systems Engineering Consulting
Services