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: Parallel Projects on same requirements base
Topic Summary:
Created On: 17-May-2006 19:03
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.
 17-May-2006 19:03
User is offline View Users Profile Print this message


Tricia Glidewell

Posts: 1
Joined: 14-Apr-2005

I have a Doors project that contain the requirements for one of our products. We currently have a team that is working on the first release 1.0 and another team that is ready to start work on release 2.0. There is a baseline set definition and the 1.0 release is currently on baseline set 11. What are my options in regards to the 2.0 release being able to update/add/delete requirements for the 2.0 release where there is still a possibility that the 1.0 team may need to make changes without incorporating any 2.0 additions/changes?

Thanks,
Tricia

Report this to a Moderator Report this to a Moderator
 24-May-2006 22:27
User is offline View Users Profile Print this message


Kevin James

Posts: 32
Joined: 12-Dec-2005

Tricia,

I don't know if this is what you're looking for, but I think the best option is to keep requirements in a single module and use a multi-select field called "Effectivity" or "Release" or some other option that indicates when the requirement becomes effective.  Then use DOORS filters/views to create views for your various releases.

I put links to two related posts below.  I actually posted the original message for the 2nd one, "Effectivities and SRD Structure," so it would be good to add that we our in the process of retreating from our original decision to keep the structure of our SRD the way it was (that will make more sense if you read the postings).  If you're going to use an approach where you store all requirements in a single module and tag them with an effectivity attribute, you really need to make sure your requirements are atomic and that they are leaves in the tree.  (i.e., no requirements that are children of other requirements.)  Again, see the second posting for more information.

Hope this helps.

Kevin

Managing Multiple Releases with 1 SRD Module
https://support.telelogic.com/en/doors/forums/messageview.cfm?catid=58&threadid=3098&highlight_key=y&keyword1=release

Effectivities and SRD Structure
https://support.telelogic.com/en/doors/forums/messageview.cfm?catid=58&threadid=2957&highlight_key=y&keyword1=effectivities
Report this to a Moderator Report this to a Moderator
 29-May-2006 16:03
User is offline View Users Profile Print this message


Hubertus Grobbel

Posts: 58
Joined: 3-May-2005

Hi Tricia,

Generally I suggest following to allow reuse of the documentation:

- try to identify the _functional_ differences (variability)
- try to identifiy common parts
- name the functional differences and describe them, put it in an attribute to distinguish
- make this attribute multivalued or even more clear singlevalued, use "talking" enums

Splitting off a requirement from common to a variable part means basically to copy the object, modify the copy, setting its attribute to the new "functionality" and e.g. to set a link from the copy to the original requirement with a link classification like "derived from". You then always know if the requirement is split off and where it is from.

The common part has the advantage, that you can identify reusable parts! and has the disadvantage, that you need a clear change process to identify, whether a requirement can be changed or has to be split off into a avariant. If it still remains common functionality after change all projects using the spec have to be informed (let yourself support by "suspect link feature", if requirements are linked to and impact analysis). Rejoining requirements from a variant back into the common part is also possible.

Changes within a variant can be done freely.

When you extract your requirements from the module you need to know the baseline and the supported functions. The tupel is e.g. to be described within the baseline annotation.

Hope there is a new idea in for you.

Bye
Hubertus
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.