I'm new to DOORS and joined a project part way through that used DOORS 8.1. However, I never really got to grips as to why DOORS was being used and what advantages it provided. The DOORS project consisted of just two formal modules: the user requirements as provided by the client; and the accepance test procedures. The requirements were linked to the test procedures. The were just over 150 requirements.
After the project, when I had time to think about why DOORS didn't seem useful, I came up with the following reasons:
1. Because the project was basically a COTS/MOTS project there were no design or architecture requirements. Normally there would be traceability links between these requirements and the user requirements, but in this project they were not needed. That is, the number of links needed was limited to those between the requirements and the test procedures.
2. We generated an Acceptance Test procedure document and a Traceability Matrix document using WEXP and the in-built export function respectively. This was a timeconsuming and error prone process, because so much post processing of the documents was required to get it into a standard company format.
3. Not all of the content of the Test Procedure and Traceability Matrix was stored in DOORS, preliminary sections were developed in Word and stored in out Document management system. In other words we had to maintain the document is two places.
DOORS wasn't useful because the overhead in using it (the effort required to generate and maintain documents) did not outweigh the advangtages (managing traceability - there weren't that many links anyway).
We have just upgraded to DOORS 9.5 with RPE and I'm about to start a new project and would like to use DOORS in a way that provides benefits to the project. Does anyone know of any white papers or other resource that provides information on DOORS best practice. In particular, I would like to know which documents should be developed in DOORS. I understand that requirements documents and specifications should be developed in DOORS, but what about Test Procedures, Test Plans, and Design documents - these all trace back to the requirements. Also, is there a point (number of requirements, number of links) below which the use of DOORS is NOT worthwhile?
Thank you
SystemAdmin - Sun Mar 03 20:49:34 EST 2013 |
|
Re: What documents should be developed in DOORS?
DOORSWizard - Wed Mar 06 17:53:19 EST 2013
I think a lot of it has to do with how you architect your projects in DOORS, figuring out a template and starting from it. As far as Test Plans, Test Procedures, etc... if you are starting with nothing I would certainly not recommend trying to invent a way of doing it in DOORS. I can tell you from experience it can be done if you get the right people and some experts in DXL, but again starting out I highly recommend you just look to another tool such as Rational Quality Manager which is designed to help manage your test information and trace back to your requirements in DOORS. As far as white paper's and talks, there should be references to some off my profile page, take a look.
|
|
Re: What documents should be developed in DOORS?
BillTidy - Fri Mar 08 09:15:22 EST 2013
The answer is, "it depends."
Just think of a parallel scenario. You run a small shop with not much inventory and not too many customers and you and your wife are the only employees. If there's some questions about what's in stock or how much it costs you can just look on the shelf yourself or lean over and ask the mrs. Same is true in a development project at work - if you're a small team sitting in one room and building a small product with known tech you probably don't need a lot of documentation. MS Word or Excel will probably do.
Fast forward a few years and your business has grown. You now have several stores across the country or maybe even in other countries. Your amount and lines of stock have increased. It's probably time to put a better system in place to manage your business and keep it under control. You usually first start to notice this when you get calls from customers who didn't get the goods delivered on time (or at all), stock levels are unknown, reordering is not taking place... you get the picture. Same with your systems development team - the products you're developing now need more people, with dedicated roles (architect, designer, developer, tester) and they don't all sit around the same coffee machine every day any longer because they're the other side of the country or even somewhere else in the world in a different timezone....
Nobody can tell you that "Once you hit requirement #501 in your excel spec you need to port it all to DOORS" but there's a breakpoint in your organization where just using excel or word is preventing your business from functioning effectively and you need to move to a dedicated requirements management tool. You need to do some business modelling though, to decide which bits of data need to be in DOORS and which in some other tool (eg: Excel). The answer to that is specific to your business. I can only tell you that at my Co we put Requirements Specs, Test Specs and Test Plans+Pass/Fail Results into 3 types of DOORS module all linked together. DOORS is then the central data source for project monitoring & control which either feeds data to or is fed data from other tools.
|
|
Re: What documents should be developed in DOORS?
DOORSWizard - Fri Mar 08 10:33:31 EST 2013 BillTidy - Fri Mar 08 09:15:22 EST 2013
The answer is, "it depends."
Just think of a parallel scenario. You run a small shop with not much inventory and not too many customers and you and your wife are the only employees. If there's some questions about what's in stock or how much it costs you can just look on the shelf yourself or lean over and ask the mrs. Same is true in a development project at work - if you're a small team sitting in one room and building a small product with known tech you probably don't need a lot of documentation. MS Word or Excel will probably do.
Fast forward a few years and your business has grown. You now have several stores across the country or maybe even in other countries. Your amount and lines of stock have increased. It's probably time to put a better system in place to manage your business and keep it under control. You usually first start to notice this when you get calls from customers who didn't get the goods delivered on time (or at all), stock levels are unknown, reordering is not taking place... you get the picture. Same with your systems development team - the products you're developing now need more people, with dedicated roles (architect, designer, developer, tester) and they don't all sit around the same coffee machine every day any longer because they're the other side of the country or even somewhere else in the world in a different timezone....
Nobody can tell you that "Once you hit requirement #501 in your excel spec you need to port it all to DOORS" but there's a breakpoint in your organization where just using excel or word is preventing your business from functioning effectively and you need to move to a dedicated requirements management tool. You need to do some business modelling though, to decide which bits of data need to be in DOORS and which in some other tool (eg: Excel). The answer to that is specific to your business. I can only tell you that at my Co we put Requirements Specs, Test Specs and Test Plans+Pass/Fail Results into 3 types of DOORS module all linked together. DOORS is then the central data source for project monitoring & control which either feeds data to or is fed data from other tools.
|
|