![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Managing Multiple Releases with 1 SRS Module Topic Summary: How to update an older release without effecting a latest release Created On: 7-Mar-2006 21:45 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
We have one requirements module with different views and baselines established for older releases. The problem is we do not know how to make a change to an older release without it effecting the latest release.
A few months ago, we were working of Release 9 and we needed to make a emergency release for Release 8 for some issues found during a test. In order to do this we deleted all the Release 9 changes made the Release 8 change. Released our requirements document. Then rentered the Release 9 requirement changes. This is not something we want to do again, but we know this problem will occur again, since we have to support our older releases as well as develop newer releases concurrently. I would like to get some suggestions on some clever ways to fix this problem. We have thought about adding an extra attribute for each release. For instance for Release 9 add a True/False attribute for the Release 9 and again for Release 10. This could get rather ugly adding an attribute for each release. I don't think it is an option for us to have different modules. We need to stay with just the one requirements module. Any ideas? |
|
![]() |
|
![]() |
|
In each of our modules, we have a 'Release' attribute of type text. Then we can filter for the release that we are currently working on and ignore any other releases.
Bob ------------------------- Bob Mathis Robert.S.MATHIS@odot.state.or.us |
|
![]() |
|
![]() |
|
As Bob replied, create one Release attribute. It can be either text type, or enumerated list. The simplest case is to use this attribute value to show from which release onwards the specific requirement has been as specified. If you have to change an existing requirement for a new release, create a copy of that requirement and set the release values to be correct.
------------------------- Pekka.Makinen@softqa.fi SoftQA Oy -http://www.softqa.fi/ |
|
![]() |
|
![]() |
|
Thanks for the replies. I did in fact see the other post about the similiar topic, and probably should have just posted to that topic, sorry.
Right now we are supporting two releases, and I hope we will never work on anymore than that at the same time. So in this one attribute, you could have: Release 9 only Release 11 only Both Releases. And then I would assume when we move to Release 12, we would remove the Release 9 only requirements and use the attribute to say: Release 11 only Release 12 only Both Releases. |
|
![]() |
|
![]() |
|
We use the same basic idea that has been brought out here, except our list is Legacy, Current, and Future. Some of our projects have added to that with version numbers, and one project has their enumeration set so that they can select more than one release.
------------------------- David A. Rose TSgt USAF NCOIC System Administration |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.