![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: DOORS Structure for a new roll-out Topic Summary: Choosing an appropriate structure for future-proofing Created On: 25-May-2006 16:18 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Advice sought!! Each project is a system integration of numerous (20+) systems. Essentially we wish to have a "core" integrated system that we can tailor to new customers in the future. We need a structure that ties the following: Regulation Documents The supplier specifications are particular to each system and contain every requirement for that system. The customer specification is particular for each project (includes all systems for that project) but only contain certain requirements that we wish to provide to a customer. These requirements must be the same as quoted to supplier. We have thought off two methods of implementing this: One: All requirements stored in single module with filtering techniques used to produce the supplier and customer specs. (i.e attributes include: "supply to", system, project etc...) The test schedules and regulations are then linked to this mamouth requirements module Advantages: Attributes easily trackable across projects (because they are the same). Filtering is an easy way to produce the end deliverables (Customer and Supplier specs) Disadvantages: Single requirements module large and unwieldy Two: Have seperate modules for each individual system and combine them together to produce the project specifications. Advantages: Breaks project into more manageable chunks Disadvantages: How to get DOORS to produce a document based on requirements stored in different modules.
|
|
![]() |
|
![]() |
|
Martin, I would suggest that you go with your second option. You could use the link modules to create your relationships and then create views that show your requirements traceability matrix.
I would take your each of your requirements documents and set them up in a hierarchy that broke down each of the requirements down into more specific requirements with each breakdown being in a different module. Then I would establish descriptive link modules that flow back up the hierarchy (in reverse from requirements flow) so your requirements would look like this: Customer Specifications (regulatory standards and supplier specs would be a level 1 items in here) | - Satisfied Requirement Link Module (BD1 to Customer Specs) Breakdown Document 1 (BD1) | - Satisfied Requirement Link Module (BD2 to BD1) Breakdown Document 2 (BD2) | - Satisfied Requirement Link Module (BD3 to BD2) Breakdown Document 3 (BD3) | - Test Link Module Test Reports Lastly I would look at creating modules that are for documentation/action items. These could be linked for "proof" if an action is questioned. To get requirements to show up on a single document from different modules is a matter of views, filters, and sorts. Creating a requirements traceability matrix (RTM) would probably get a lot of what you need shown on a single report. Creating an RTM is a relatively simple process using layout DXL. I hope this helps. ------------------------- David A. Rose TSgt USAF NCOIC System Administration |
|
![]() |
|
![]() |
|
David,
Thanks for your input. Certainly provided some "food for thought". I must admit to still getting to grips with DOORS but basic playing around with the structure you suggested seems to be working well with our project model. regards Martin |
|
![]() |
Telelogic DOORS
» General Discussion
»
DOORS Structure for a new roll-out
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.