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: Does anyone use links to propagate requirements?
Topic Summary:
Created On: 22-Feb-2005 19:48
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.
 22-Feb-2005 19:48
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Does anybody use links to propagate requirements from high level to low level documents? An example would be: When decomposing System level requirements to Software requirements, sometimes the requirement is already decomposed to it's lowest form so it gets repeated in the Software requirements. It is fairly easy to create a DXL attribute that displays this higher level System Requirement directly into the Software requirements module without having to repeat typing the requirement into the Software Requirement module.
This is nice because the requirement shows up in both documents but only really exists at the highest level. My dilemma is... how do I 'baseline' the Software requirements such that I can always reproduce the document even if the System level document changes or, worse, what if the link is lost...
One solution is that the System level and Software requirements modules must both be baselined when one of them is released. This works if the links remain intact.
Another solution is to make a copy of the propagated Software requirements into an attribute during a baseline via a trigger.
Or, I am hoping, someone has a much better solution than these two.
Anybody else doing this type of requirements propagation? Any sound ideas or even general musings gladly accepted...
Thanks,
Dan


Edited: 23-Feb-2005 at 13:43 by Dan Hopping
Report this to a Moderator Report this to a Moderator
 24-Feb-2005 15:49
User is offline View Users Profile Print this message


Peter Seager

Posts: 32
Joined: 10-Feb-2003

This is not a procedure I would use. My golden rule is to never allow the heading/object text of a module to be change without an agreed Change Note. (You can store proposed changes in the DOORS CPS, that is a different matter.) You can never change two modules at the same, there is always some very good reason why they need to be phased. Remember, if you are using DOORS to advantage, there is a lot more data stored against each object and work has to be finished on these other attributes before you move on to the next phase.

We do seperate Requirement Specifications and Qualification Specs into seperate modules. This leads to linking like you suggest. We always baseline Requirement and FQ spec issues with a major baseline and use minor baselines for VCRIs etc where several modules have to be baselined.

If you are using DOORS Version 7.1 Baseline sets are an option but I have not had great success so far. The first time I tried we had legacy Attribute DXL and this did not understand baseline sets and so did not work. Once you have made a baseline you can't change Attribute DXL and so I was snookered. I have now updated the DXL and made new baselines. Some modules now work in baseline sets but other still don't.
Report this to a Moderator Report this to a Moderator
 24-Feb-2005 20:48
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Peter,

I am seeing your point here. I definitely would not want the actual content of the Software Module to change ‘automatically’. I am still hoping to be able to make the ‘idea’ work. The following doesn’t absolutely prohibit the ‘automatic’ change, but it would clearly show that the System level module had changed baseline since the last time this Lower Level (Software Requirements) document was output. All modules are output to Word for release then (if they will be used for test) are compared and design reviewed against the last official release using a product called Workshare. This would highlight the Delta baseline of the System specification (if the System spec changes) and make it appear in the Software Spec, even if the Software module remains ‘untouched’.

My implementation is looking like the following:

System Level Requirements Module would look like: (High Level Requirements)
{SyR.121} bla bla bla.
{SyR.124} System speed shall be less than 50 RPM.
{SyR.125} bla bla bla.

The Software Requirements Module (Lower Level Requirements) would be physically written in DOORs as follows…

{SR.303} bla bla bla.
{SR.305} System speed shall be as specified in SyR.124 as follows: {{follow link}}
{SR.306} bla bla bla.

The thought is to use a DXL Attribute in a view’ that gets ‘printed’ as the final document. This document would display the Object text of each object in the Software Requirements (as one would expect). However, it would also look for the identifying text string {{follow link}} in the requirement Object text. If it appears, then the DXL Attribute would also display the linked Object ID from the System level module, the Current Baseline Version from the System level module, and the Object text from the System level module.

IN this view… the Software requirements document would then look like:

{SR.303} bla bla bla.
{SR.305} System speed shall be as specified in SyR.124 as follows: [from SyR Baseline Ver 2.1 {SyR.124} System speed shall be less than 50 RPM]
{SR.306} bla bla bla.

There are still details to be worked out and I am sure it’s not ready for prime time but I am going to pursue it a bit further and see if I can take advantage of the benefit while still maintaining module output integrity. Our system level requirements tend to be about 30% - 35% very specific requirements which get passed straight down to the lower level docs. (It’s inherent in the type of products we make). That’s a lot of requirements to be ‘repeating’ in lower level docs so the effort should be worth it. I was hoping someone else had already blazed this trail.

ALSO: Thanks for the warning on the ‘legacy Attribute DXL’s’. Getting ‘snookered ‘ by that one could smart!









Edited: 24-Feb-2005 at 20:53 by Dan Hopping
Report this to a Moderator Report this to a Moderator
 25-Feb-2005 09:18
User is offline View Users Profile Print this message


Peter Seager

Posts: 32
Joined: 10-Feb-2003

When I first became involved with Requirements Management there were thoughts around of constructing sets of documents from stored blocks of text. It has not caught on which tells you something. Two other things I have leant:

With Requirements Management the exception is the rule,

When you get to the end you know exactly where you should have started from.

Hence think carefully. Can you idea handle exceptions to your procedure? These may be as simple as timing variations between module updates as already suggested.

Try and work your proposal through quickly to producing sample documents (specs, VCRIs etc) and views your QA people might use to populate test results.

Experience has taught me there is no substitute for solid text. There are enough problems even then.
Report this to a Moderator Report this to a Moderator
 28-Feb-2005 13:03
User is offline View Users Profile Print this message


Ian Kirwan

Posts: 25
Joined: 17-Jun-2004

Hi Dan,

I think you and I are in the same position in that we both need to have a simple way to update propagated requirements from their source, yet maintain the integrity of document versions (baselines). I have started a new thread on this subject called 'Copy with links then update'. I hope to get some useful responses soon.

Regards
Ian Kirwan

-------------------------
Principle Software Engineer
Electrical Engineering
Product Development
MG Rover Group
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 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 0 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.