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: Managing multiple Releases
Topic Summary:
Created On: 29-May-2006 21:44
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.
 29-May-2006 21:44
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

There's been some chat about managing multiple releases of a product in DOORS. A scenario is this: you've got a big software project and figure to make incremental releases of it. Build 1 will have the core requirements. Build 2 will add more. Build 3 more etc. You want to manage all this in one DOORS module. Here are some thoughts...

Relying on Baselines to represent the builds (i.e. a baseline represents Build 1) is unmanageable; it prevents you from entering Build 2 requirements until Build 1 is released, and prevents you from modifying the Build 1 requirements; such as if it includes a fatal defect.

You have an enumerated attribute "Build" with enumerated values "Build 1", "Build 2", "Build 3" etc. You assign each requiement to a build; and when assigned to a build presumably to all future build's as well (e.g. if its supposed to be build in Build 2 then usually it also applies to Build 3). You can "release" the document for a particular build by using a filter, show all reqs assigned to Build 2. With this approach, presumably all Headings apply to all builds. If a heading has no requirements for a build you could add a "No requirements" object under that heading and assign it to a build.

But you've got a problem. Realistically, early builds may have the same requirements as later builds but may perform at a lesser degree; Perhaps the final delivery has to handle 100 transactions per minute, but build 1 need only handle 20 per minute. I see two options:

[1] Change the requirement text to be able to handle a "build specific" number of transactions. Add new string attributes "Build 1 Parameter", "Build 2 Parameter" etc; this attribute houses the "100" and "20" values. Your "release" procedure needs to know how to extract the parameter from the attribute and stick it into the "build specific" pattern inside the Text; changing "shall handle <Build Specific>..." to "shall handle 100...". I don't like this option.

[2] Add a copy of the requirement sibling to the original. One says "20" and applies to build 1 only; the other says "100" and applies to Build 2 and 3 etc. Again, this option requires filtering to produce a readable spec.

This last option, however, has a couple of significant drawbacks: while normally folks would tend to use the "DOORS Identifier" to be synonomous with the "Requirement ID", this option requires you to manage a separate string attribute featuring the actual Requiements ID, and also requirement managing those IDs. Thus, both the "20" and the "100" requirements would have the same ID, which is desirable. This option also causes some havok in requirements decomposition; where subordinate objects need to link to most or all of the instances of the parents; and that gets confusing. I don't like this option either.

[2a] These limitiations could be mitigated by installing a rule that separate "requirement" will exist with no sibling requirements in its own Heading. Thus, the "20" and the "100" objects could be siblings since they are different versions of the same requirement. The "requirement ID" would thus be the Heading object above these two. Linking would be to and from this Heading object, in this case the "Peak Transaction Load" heading. Traceabilty would need to be adjusted such that it finds the text of objects subordinate to the links.

All in all, I'm not sure which option I like.

The alternative approach of having multiple MODULES for each build looks hopelessly complicated, especially when it comes to making the same change throughout. One of our projects is trying to do just this (they don't want my help) and I'm interested to see how well it works.

- Louie
Report this to a Moderator Report this to a Moderator
 31-May-2006 11:36
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 78
Joined: 6-May-2005

Louie,

I have used your second option in the past. Sometimes you have a mandatory performance level and a 'would be nice' level. If this is expressed as two separate requirements then you can assure that you have met the mandatory level independently of the enhanced spec. This is similar for multiple releases, you have a requirement for 20 per minute for release 1. This is still valid at release 2, but there is an additional requirement for 100 per minute. It is worth keeping both requirements live because you may not meet the higher spec in the early testing for release 2, but you need to know that you have not lost anything from the release 1 performance.
Traceability to customer requirements may be identical for both requirements, you may also want to link the more demanding requirement to the less demanding one as an 'evolves from' relationship.
The tests similarly would be separate for the 20 per minute and the 100 per minute requirements. By the third release you may want to remove the first release tests.


Hazel
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.