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: Requirements Changes by Release
Topic Summary: How to display intersecting release requirements
Created On: 3-Aug-2007 15:41
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.
 3-Aug-2007 15:41
User is offline View Users Profile Print this message


brian mcmenamy

Posts: 2
Joined: 25-May-2007

Hello all,

So I have an issue with editing our very large information architecture in DOORS for a new release.  We use attributes to mark 'release', 'status' and 'types' for our requirements statements (i.e. 4.0/Baseline/Requirement)., and when changing a current requirement for the next release, we run into issues.

Example - Development, QA & Training are implementing r4.0 requirements, the BA team is working on 4.1 requirements.  I have a 4.0 requirement that needs to change for 4.1, but if I change it; the down stream process will fail (Dev, QA looking at the wrong requirement).

I could enter a CP, but the available view to the team to see 4.0 vs 4.1 CP is not comprehensive.  I could add a new requirements statement, but then a new object number is generated any that throws everything out of sync for us.

Any suggestions or experience with this would be great!

Thanks,
Brian.

Report this to a Moderator Report this to a Moderator
 6-Aug-2007 11:35
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

This problem, product line management, was supposed to be addressed by Intelligent Traceability, introduced with DOORS 7.0, but unfortunately Telelogic do not supply the necessary tool support for moving links around between baselines. Also baseline sets are pretty much useless because you have to decide what's in the set before you start and you can't add/remove stuff later.

Linking to baselines in doors is also less than ideal because echoed links cannot be traversed in both directions. If you attempt to traverse a incoming link it takes you to the current version, not the baseline.

Even if you did link to baselines, there is no tool support in doors for selecting a version using the trace wizards etc, so you have to write loads of DXL yourself.

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 6-Aug-2007 12:01
User is offline View Users Profile Print this message


Michael Grimsdale

Posts: 11
Joined: 27-Aug-2003

We have the same problem in that we have to maintain different version at the same time. Since it is required to add/edit applicability matices we cannot use baselines (readonly)i.e. Telelogic solution.
We are now interested in finding a solution and this looks like being KeyChange from the company Integrate in the UK.
I will keep you informed as to our experience.
Perhaps Telelogic should look to a partnership here.
Report this to a Moderator Report this to a Moderator
 6-Aug-2007 18:27
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Brian,

This is not ideal, but it's an idea...

You could change the structure of your modules...so in your example....

Let's say that a version 4.0 requirement is new for this release. You create it.

Instead of updating that requirement, you create a requirement BELOW it for all changes.

So your heirarchy would look as follows:

4.0 Requirement
    4.1 Requirement (and all links and changes for v 4.1 go here)

    4.2 Requirement

    4.3 Requirement


I know, it's ugly, and it may make doc generation a pain, but it is a way to manage this, in light of DOORS' weakness in this area.

Another idea is to have a version 4.1 module that only the BAs can see--it's a copy of the original module. When the testers are done with v4.0, baseline the v4.0, and write DXL to copy object text and other attributes of the v4.1 module to the v4.0 module.

Again, a pain, but once you get it set up, it should be easier to maintain.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts

Edited: 6-Aug-2007 at 18:32 by Kevin Murphy
Report this to a Moderator Report this to a Moderator
 13-Aug-2007 19:03
User is offline View Users Profile Print this message


brian mcmenamy

Posts: 2
Joined: 25-May-2007

Thanks for all of the feedback.  Kevin - Your 1st idea is one we tried but I guess our developers are creating links from the IDE they use to the requirements in DOORS, and indenting will mess up the infrastructure they built.

I do like the 2nd idea and will give it shot.

Thanks Again.
Report this to a Moderator Report this to a Moderator
 15-Aug-2007 13:06
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

One other idea that may be even better.

Let's say you're testing release 4.0 but the BAs need to work on 4.1.

Create an attribute called "4.1 Object Text" or "Next Release Object Text". The 4.1 changes are made in this attribute.

When the time comes, baseline the module, and have DXL look through each object. If "Next Release Object Text" != "", then you copy the value into "Object Text" and clear the "Next Release Object Text".

...in fact, you could do this with every attribute.."Next Release Object Heading," "Next Release Test Status," etc.

You can set up views for the BAs and they can edit things almost as they normally would. New requirements could either go into their respective sections with a blank Object Heading/Text, OR you could put the new requirements in a new section at the end of the module.

This way, you don't have to manage multiple modules. It's all in one place.

Either way you choose, do let us know how it goes!

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 15-Aug-2007 20:47
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Just a random though, but you could have a Text attribute created for each baseline release; 'r3.0 Text', r3.1 Text', 'r4.0 Text' etc. When a released baseline occurs you copy the current Object Text to the newly created 'r4.1 Text' attribute. Only copy Text of Requirements.

When a requirement is deleted, change its text to 'Deleted' or possibly something like 'Deleted (Rescue by boat)' but do not actually delete the object.

CPs to change baselined requirments (e.g. r4.1 Text) require additional RCRB approval.

Notice that Headings don't change. An object is a 'Requirement' for a baseline if its Requirement flag is true AND there its baseine-text attribute is non-empty. Spec generation is a little awkward; you want to skip dumping an object if it has nothing in the rxx Text attribute that you are dumping.

- Louie
Report this to a Moderator Report this to a Moderator
 16-Aug-2007 13:53
User is offline View Users Profile Print this message


Scott Boisvert

Posts: 348
Joined: 14-Apr-2006

quote:

Originally posted by: Michael Grimsdale
We have the same problem in that we have to maintain different version at the same time. Since it is required to add/edit applicability matices we cannot use baselines (readonly)i.e. Telelogic solution. We are now interested in finding a solution and this looks like being KeyChange from the company Integrate in the UK. I will keep you informed as to our experience. Perhaps Telelogic should look to a partnership here.


I've been looking into KeyChange for DOORS as well.  I've spoken, via e-mail, with one of their reps and the product is still in Beta.  Which for me causes a problem, as per our company policy we can not install any product that has not been formally released.......

-------------------------
Scott Boisvert
Engineering Tools Administrator
L-3 Communications - Avionics Systems
scott.boisvert@l-3com.com
Report this to a Moderator Report this to a Moderator
 16-Aug-2007 14:36
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Louie,

I know we're just brainstorming and theorizing here, but the one thing I do not like about your suggestion is that it involves more management from the admin side.

My suggestion really stated that there should be two attributes - one for the "current" release and one for the "next release." So if there are 10 attributes to be tracked for the "current" release, there may need to be 10 attributes to be tracked for the "next" release, for a total of 20 attributes to maintain.

With your suggestion, that 20 goes up, in theory, infinitely, with no boundary. Further, with every baseline, you have to ensure that there is coordination and communication. If 4.0 was baselined and we are now on 4.1, you absolutely need to make sure that the 4.0 attributes cannot be changed!

Easy to do, but LOTS more management work.

And don't forget the law of unintended consequences.

"Lou, I know the next release is 4.2, but we are thinking about 4.3 and 5.0 requirements. Can you put those in as well?"

Maybe you think this is fine, but I think it's a nightmare, because then users start asking for what the 5.0 doc would look like, and they may even want to start linking requirements from 5.0 even though the current release is 4.1!

It's just a good rule of thumb to keep your attribute set as small as possible.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 17-Aug-2007 01:30
User is offline View Users Profile Print this message


Paul Miller

Posts: 376
Joined: 2-Oct-2002

Kevin's need to be able to manage present and future releases at the same time (concurrent management) is where the document centric architecture of DOORS seems to have reached it's use by date.

The data model is pointing more and more away from document centric management to individual object level management. DOORS objects should no longer be encapsulated inside of a module but should be managed outside of modules as objects with their own independent version control. The association, position and viewing of an object as a member of a document should be managed as a separate function.

Try to view DOORS objects like software source code files - software source code files have their own independent version control and are compiled & linked using a MAKE algorithm to form an executable. DOORS objects need their own version control and should be able to be compiled to form a document using a document MAKE algorithm. This would allow objects to be re-used for multiple documents.

The version control also needs to support branch, merge and rebase functions just like software engineers use for managing concurrent change tasks on source code files. A branch would allow DOORS objects to be branched out so that they can be assigned to future upcoming releases and modified accordingly for those releases. The merge function would be used to manage potential change conflicts between branches (i.e. current active versions). The rebase function could be used to help update branches with changes that are being made in branches that contain objects that are still being worked on in earlier related releases that have not been fully closed off yet.

Any agreement?

-------------------------
Paul Miller
Specification Practices Specialist,
EuroCyber,
Melbourne, Australia.
Mobile: +61 (0)418 135 103
Web Site: http://www.eurocyber.biz
E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz
Report this to a Moderator Report this to a Moderator
 17-Aug-2007 14:56
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Paul,

First to clarify, it's not my need. However, I'm surprised I really haven't run into this issue yet, as it seems to be a basic shortcoming of DOORS.

I agree with what you're saying, but Telelogic has a tool that does a really good job at what it does. DOORS strengths are DXL, Requirement Traceability, Requirement History and Word Document generation.

You're suggesting a complete rearchitecture, and Telelogic's model so far has been working very well. I really, really doubt that you'll see a radical redesign such as the one you are proposing in DOORS any time soon. Heck, it sounds like you'd be taking DOORS and making it more relational than Object-Oriented, and I don't think they'll change the name of the tool to DRRS.

Kev

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 19-Dec-2008 15:40
User is offline View Users Profile Print this message


Jeff Winget

Posts: 2
Joined: 18-Dec-2008

This was an excellent discussion, with some very creative solutions. It has been helpful in resolving my problem, posted as "Multiple similar products" on Dec. 18, 2008.

I would however like to revive an intriguing argument, as posted by Paul Miller: Telelogic should consider a more robust solution to this problem, and they may already have the solution.

Paul's idea of treating requirements like software--"compiling" requirements to create multiple versions and product variants--may cause experienced users to quake, but I think the basic concept Paul submitted has considerable merit. Having managed software CM tools for many years, I can see where leveraging some of the basic functionality of Telelogic's Synergy with DOORS would give users tremendous flexibility and power, and would devestate the competition for years to come.

If Telelogic doesn't do it, somebody else will.
Report this to a Moderator Report this to a Moderator
 19-Dec-2008 16:52
User is offline View Users Profile Print this message


Octavian Stanescu

Posts: 39
Joined: 28-Feb-2005

We are using a Version attribute, which is an enumeration of version strings and also multi-valued.
So for the first release would be something like:
Text Version
Req 1 (1.0) <- Test (1.0)
Req 2 (1.0) <- Test (1.0)
Req 3 (1.0) <- Test (1.0)
Req 4 (1.0) <- Test (1.0)
If you start a new version of the product then you would make all common requirements (the ones that not change at all), Version 1.0 + 1.1.
If you want to add a new requirement for version 1.1 just add a new object in the requirement module and set its version to 1.1.
If you want to modify a requirement because the new version is acting differently then you would still add a new object with the version 1.1, the old requirement still has only version 1.0 set.

EX:
Req 1 (1.0, 1.1) <- Test (1.0, 1.1) ----- no change common requirement
Req 2 (1.0) <- Test (1.0) ----- no change for 1.0 but will change in 1.1
Req 5 (1.1) <- Test (1.1) - changed Req 2 for 1.1 therefore Tests changes too
Req 3 (1.0, 1.1) <- Test (1.0, 1.1) ----- no change common requirement
Req 4 (1.0) <- Test (1.0)

The links and Tests can be updated in a similar manner.
Then use the filter Version includes 1.1 (or 1.0) to generate you requirement documents.

Ex document generation from current or baseline with filter Version includes 1.0
Req 1
Req 2
Req 3
Req 4

Ex for doc generation filter: Version includes 1.1
Req 1
Req 5
Req 3
Report this to a Moderator Report this to a Moderator
 19-Dec-2008 16:56
User is offline View Users Profile Print this message


Octavian Stanescu

Posts: 39
Joined: 28-Feb-2005

Oh,
We save the baseline number and description along with the filter used to generate the document, in the document itself.
We generate only read only documents that gets approved in another CMS system.
Report this to a Moderator Report this to a Moderator
 5-Jan-2009 21:43
User is offline View Users Profile Print this message


ron lewis

Posts: 650
Joined: 20-Sep-2004

For additional info check here:
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.