RE: [Fwd: [SysML-Evaluators] Re: FW: Requirements Management]

[Michael Latta]

Chris,

 

Thanks for the response.  I agree that the dependency relationship direction makes this type of access control and CM issue easier *IF* the tool makes the *ASSUMPTION* that all such relationships should be managed from the source end of the relationship.  I am aware of at least one (ours of course) that does not make such an assumption in implementation for this reason exactly.

 

The core aspect of the discussion however is not implementation related, but relates to the better semantic for the SE user.  The nature of the relationship is not one of dependency (which is pretty vague), but one of specification. A requirement specifies that certain things exist in a system.  There is a dependency from those things to the requirement, but there is more to it than just that.

 

To me the implementation issue is really that UML defines the arrow to go in one direction (dependency) and provides no concrete association that goes in the other direction, so no Profile can provide such a relationship.  It might be useful to store the relationship in the target object so that the CM issues are handled, but present it to the user in the direction of causality, which is more intuitive.  But, as a Profile we can not change the semantics of Dependency.

 

Michael

 

 

 

---

From: Chris Sibbald [mailto:csib...@istar.ca]
Sent: Monday, December 19, 2005 11:22 AM
To: Michael Latta
Cc: Cris Kobryn
Subject: [Fwd: [SysML-Evaluators] Re: FW: Requirements Management]

Hi Michael,

Another consideration is configuration management (and access rights).

Consider the case where a set of requirements have been specified and agreed.  Assume these are in a controlled unit (part of a model or RM repository) that you do not have write access to.

Using the following conventions:

element A ---verifies---> req B
requrirement A ---derivedfrom--->req B
element C-----satisfies---->req B

does not require write access to req B as the dependency information is stored on the source (client) end of the dependencies.

This is the same paradigm taught by our consultants to new DOORS users.

In DOORS the link information is also stored on the source object.  One requires write access to the source end of a link to create the link, but you do not need write access to the target of the link.  Hence, setting up the traceability schema to trace from the "lower level" (ex. System Requirements) to the "higher level" (ex. User Requirements) is prefered as one would typically only have read access to the "higher level" requirement (i.e. they have been validated and "frozen").

Make sense?

Cheers,
Chris

-------- Original Message --------

Subject:	[SysML-Evaluators] Re: FW: Requirements Management
Date:	Fri, 16 Dec 2005 20:37:03 -0800
From:	Michael Latta <lat...@mac.com>
Reply-To:	SysML-Ev...@googlegroups.com
To:	<SysML-Ev...@googlegroups.com>

Darold,

 

Thank you for your comments.  I agree that it would be far better to have the requirements aspects of SysML be sufficiently "industrial strength" to be viable as a stand-alone requirements representation.  There is nothing to prevent a tool from taking what is in SysML and embellishing on that to form a full requirements management tool, but having it in the language would be better.

 

I can certainly see the value in top-bottom expressions of traceability, rather than the bottom-up notion of dependency.  I also think it is more correct in this case.  The semantics of dependency are weaker than the semantics of definition.  While it is clearly true that a change to a requirement implies a change to what the requirement is traced to, it should be stronger than that.  The truth is that the traced element is not only affected by a change in the requirement, but the element exists because of the requirement.  I think this is better implied by the semantic direction you suggest.  It would be difficult to overlay this onto the UML dependency which has a defined direction that is opposite, and which also has an arrow head.  So, as a profile there is no way to implement your suggestion, without corrupting the defined semantics for dependency in UML.  It is possible to use DirectedRelationship but only as a derived metamodel (since it is abstract).

 

Please raise these issues on the next call.  The question is about priority.  How important is the direction to usability and adoption by practicing SEs?

 

Michael

 

 

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Smith, Darold
Sent: Friday, December 16, 2005 8:01 PM
To: SysML-Evaluators
Subject: [SysML-Evaluators] FW: Requirements Management

 

 

Darold K. Smith: PE, CSEP

Certified Systems Engineering Professional

UGS Corporation: Transforming the Process of Innovation

Teamcenter for Systems Engineering

Systems Engineering Consulting Services

darold...@ugs.com

Office: 903.883.0781

Fax:    903.883.2981

---

From: Smith, Darold
Sent: Fri 12/16/2005 5:54 PM
To: SysML-Evaluators
Subject: Requirements Management

COMMENTS on Requirements. 

 

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

darold...@ugs.com

Office: 903.883.0781

Fax:    903.883.2981

 

[Michael Latta]

I just had an idea for a way to get closer to what would be ideal while living with the UML and implementation issues raised in this discussion.  Rather than calling it a dependency, the SysML relationship between a requirement and the part of the system being defined by the requirement should be something like "definedBy".  This at least has the stronger connotations being requested in the original message.  It would still be better if the relationship could go the other way to show causality, but that is not consistent with a UML Profile.

 

There is a similar issue with Allocation and directionality.  While you would like to say A is allocated to B, the dependency goes in the other direction: B is dependent on A.  This gave rise to the undirected relationship being used in SST with a From and To role name.  One option is a neutral word like <<Allocation>> which is more declarative, which is what was a problem for the original view.  The causality is opposite from the dependency once again.  Possible phrasing: "hasAllocated" or "allocationFrom" or "receivesAllocation".  They are all more awkward than the case with requirements as in the other case there is a reasonable verb for the reverse direction.  If we use a different verb from allocation then we could use "exhibits" or "embodies".  Neither has the strong identification with SEs that allocation does.

 

Michael

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Michael Latta
Sent: Monday, December 19, 2005 12:02 PM
To: chris....@Telelogic.com; SysML-Ev...@googlegroups.com
Cc: 'Cris Kobryn'
Subject: [SysML-Evaluators] RE: [Fwd: [SysML-Evaluators] Re: FW: Requirements Management]