![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Is anyone managing requirements reviews directly in DOORS? Topic Summary: Created On: 2-Nov-2004 23:24 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hello all,
We are establishing process for formal requirements reviews. Because of DOORS' traceability features, we are leaning toward performing the reviews directly in DOORS, i.e. review checklists would be in DOORS and map to the corresponding requirements modules under review. However, there are a number of issues we've identified:
you address the issues I've described? Regards, Greg Lacefield Edited: 4-Nov-2004 at 23:44 by Greg Lacefield |
|
![]() |
|
![]() |
|
I have managed reviews directly in DOORS, but not using checklists. Our standard review process works with MS Word based review records.
I created a DOORS review module per project, with attributes for all the admin information such as date, reveiwers, status, etc. One object per review is then created in this module. In the module under review, two new attributes are created, one for review comments and one for review responses. A link is made from the first object in the module under review, to the review record object. Having the review comments in the module under review makes life much easier when actioning the comments. To manage the additional information of a checklist, I would suggest a checklist module, with an attribute for each item, and an object for each review, linking a single object to the reveiw record module. DOORS tables are unwieldy, embedded Word document has issues with lack of history and visibility. ------------------------- Hazel Woodcock |
|
![]() |
|
![]() |
|
The trouble with using DOORS tables for this sort of thing is that it limits what you can do with attributes and views - even though it can look smarter. As a general principle, I wouldn't want to constrain the data structure by the way I want it to look. If I want to improve the presentation I can write some custom DXL.
The trouble with embedding word documents is that you lose traceability. The trouble with one DOORS object per checklist is the multiplicity of attributes you need, and you lose granularity of linkage and traceability. everyone's information architecture is different, but we use a review register and an issues register. we consider reviews as discrete formal events and so have a separate module for each review. Each object is a discrete review checkpoint or comment linked to a requirement object. A placeholder object at the top of the reviews module links to the module or section under review. A review may be concluded if each review point has been closed off or an entry raised in the issues register. the issues register is a dynamic record owned by the convenor of the changed board, so is stored in a single module. the number of links only becomes unwieldy if they are used inconsistently. |
|
![]() |
|
![]() |
|
We do not use DOORS directly for the review process.
We have Validation attributes for each object in a formal module which must be completed by the User. When completed, we have a tool which checks through the formal module and reports any errors wrt required attributes, use of abbreviations like TBD, and any entries which may contradict each other. The formal module is then placed under configuration control in PVCS Dimensions, and the formal review takes place under config management, with all reports and checklists being placed into Dimensions with the formal module. Any future changes to the formal module must also then be initiated from Dimensions with Change Requests, which again are reviewed through Dimensions before the changes are applied. Hope all this helps! Roy Bond MTU Aero Engines Munich |
|
![]() |
|
![]() |
|
------------------------- Tony Goodman http://www.smartdxl.com Edited: 5-Nov-2004 at 13:53 by Tony Goodman |
|
![]() |
|
![]() |
|
Hazel,
Thank you for your quick response. The idea of having your reviewer comments and responses in the module under review (MUR) is an interesting one. I can definitely see the benefit to having them in the MUR, but a few follow-up questions come to mind:
Regards, Greg Edited: 4-Nov-2004 at 23:46 by Greg Lacefield |
|
![]() |
|
![]() |
|
Ross,
Thank you for your timely response. I agree with your assessment of DOORS tables and embedded Word documents - in fact, with embedded documents, you lose not only traceability, but searchability. What is unclear to me is how you link your reviews, where you state quote: In our checklists, a review checkpoint would apply to the entire section under review, e.g. "Are the requirements verifiable?" Do you link a checkpoint to each and every requirement in the section, or just the section header? It seems you already have linked the placeholder to the section, so that's unnecessary. Do you only add these checkpoint links if there are comments or action items on the requirement object? That I could understand. Regards, Greg |
|
![]() |
|
![]() |
|
Roy,
Thanks for your response. Like you, we are looking at placing our modules under formal CM once they've been baselined for review. We're using SYNERGY/CM and SYNERGY/Change for our CM and CR systems, respectively. Could you provide examples of your Validation attributes, and define who the User is--is that the requirement author, the reviewer, the project engineer, the end user...? Thanks again for your insights. Regards, Greg |
|
![]() |
|
![]() |
|
Greg,
The issue of what to do with the attributes after the review is one of appropriateness. I have been working with small projects and few reveiws, and I have a natural aversion to throwing things away, so the attributes persist. On a large project with many reviews over an extended period, I would suggest deleting them, as they are in the baseline and therefore accessible if you really want them. For re-review I have been able to manage with just hte two attributes so far, as things have not been too complex. If you add the attributes to the checklist you do not get the comment side by side with the object being commented on. The attribute names are in the review module, so that you can see which attributes cover which review. The two main benefits to having the attributes in the module under review are; 1 the review is easy, because you only have to deal with one module, and comments are placed beside the text being commented on. 2 actioning of the comments is easy, because you can filter the module to show just those parts which have comments, or which objects have comments and no response. Depending on the formality and complexity of your process you could add an attributes for reveiw comment status. This would require a little discipline to complete, but would allow for more useful filtering. I have used an enumerated type attribute for this, and coloured the review comments from the status attribute. This allows the reviewer to easily see which comments were contentious. Good luck with coming up with a workable process Hazel ------------------------- Hazel Woodcock |
|
![]() |
|
![]() |
|
Greg,
I misunderstood what you were wanting. Hazel W has the right idea w.r.t creating a module with attributes for each checkpoint, and link each object to the section or object it applies to (consequently one link per section/object). We do this for checkpoints with simple states (e.g YES, NO, complete, 100), but we normally enter this sort of thing as attributes in the requirements module itself without creating a separate module. We use the review module to manage observations e.g comments on completeness, consistency, correctness, testability. The review observation object might be linked against a review criterion held in another module. The benefit of this approach is that we are recording the exceptions rather than commenting on every object for every criterion (which quickly becomes unmanageable). Also, it keeps things tidy if there are several reviews during the life of the requirements document. Ross. |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.