Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Linking Philosophy
Topic Summary:
Created On: 3-Oct-2002 21:53
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 3-Oct-2002 21:53
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 4-Oct-2002 16:01
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 4-Nov-2002 15:32
User is offline View Users Profile Print this message


Jeremy Eble

Posts: 30
Joined: 20-Sep-2002

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
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.