![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Linking Philosophy Topic Summary: Created On: 3-Oct-2002 21:53 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I'm writing the DOORS policies document and am stuck on some exact language.
I'm concerned now ONLY about "trace" links, where requirements in child specs "satisfy" requirements in parent specs. I'm not concerned about "verification" links where section 4 links to section 3 requirements; not concerned about "test procedure" links where test procedure objects link to the requirements they test; not concerned about "reference" links where objects that reference other objects link to them. I'm trying to write a couple paragraphs to help guide the engineers in choosing which requirements to trace together. I'm trying to avoid the fiasco where child requirements are linked to any parent requirement that is vaguely related, thus resulting in a useless spaghetti pile of links. So far, I've got: I THINK Engineers should trace child requirements to parent requirements when: o The child's existence is "justified" by the parent. o The child "satisfies" part or all of the parent. o When the parent requirement changes or is deleted, the child may also change or be deleted. I THINK requirements should NOT be traced just because: o There appears to be a relationship between child and parent. o We may often wish to view the parent when we view the child, or visa versa. Any of you other policy makers got any ideas here? - Louie |
|
![]() |
|
![]() |
|
This is a very difficult issue and I do not know the answer.
I agree with the points you mention and think the most important of these is the justification for the exixtence of the lower level requirement. When engineers link a lower level requirement to a parent requirement they will often have the justification for this in their heads, but this justification does not generally get documented. One solution is to use rich traceability. This enforces the engineer to record the rational or justification for the links they are creating. The down-side to this is that without DXL customisation this makes the linking task much more complicated (and prone to errors) for your users. Ultimately, the only way to ensure that linking is peformed correctly and consistently is by peer review. Definitely food for thought. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
I think that some thought for the justification depends on whether or not you're dealing with top-down, bottom-up, or even concurrent design. Since what I see is all very regulated top-down design, I'll speak of what we do from that viewpoint.
Parent requirements are essentially split up and assigned to either groups or individuals. They are then reviewed and a decision is made on whether or not they can be satisfied by one child or many. Based on that decision the child requirements are written and linked back to the parent. This is what is done no matter how deep into the system we go. It allows for a sort of "pre-justification", if you will, and seems to work quite well. Of course, as Tony pointed out, all of this is under constant review. It seems to me that bottom-up design wouldn't be that much different as far as the philosophy goes. It's concurrent design that really poses a problem. Tracking requirements in an environment of concurrent design is just as hard, if not harder, as writing those requirements. If that's what your looking at, I would focus on just what Tony said: the justification. I hope that helps. Good Luck! ------------------------- Jeremy Eble Software Engineer Teragon Consulting LLC jeremy.r.eble@lmco.com |
|
![]() |
Telelogic DOORS
» Administration
»
Linking Philosophy
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.