![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() |
|
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? |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.