![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() |
|
Hello all, |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
quote: 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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
For additional info check here:
|
|
![]() |
Telelogic DOORS
» Change Management
»
Requirements Changes by Release
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.