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: 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
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.
 2-Nov-2004 23:24
User is offline View Users Profile Print this message


Greg Lacefield

Posts: 13
Joined: 23-Oct-2003

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:
  • Whether to include more than one checklist in a module. We have a need to maintain a history of
    the checklists against a module, as it undergoes modifications and additional reviews.

  • How to implement the checklist. Options we've enumerated are:

    1. A DOORS table;

    2. An embedded Word file as an OLE object, so that a single Word-based checklist is contained in
      one DOORS object, with additional attributes as needed for sorting, filtering, etc;

    3. Build the checklist in DOORS such that each checklist line item is a separate DOORS object, with
      attributes for Pass/Fail status, etc.

    4. One DOORS object per checklist, with an attribute for each line item.

  • Whether to link the checklist to each object under review, section headers, or what? Or to simply
    use an additional attribute? This is required to provide proof that each section in a module or module(s)
    has been reviewed, but there is a concern that the number of links can become unwieldy.
Is anyone doing this with success already? If so, what approach have you undertaken and/or how would
you address the issues I've described?

Regards,

Greg Lacefield

Edited: 4-Nov-2004 at 23:44 by Greg Lacefield
Report this to a Moderator Report this to a Moderator
 3-Nov-2004 11:16
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 38
Joined: 4-Oct-2002

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
Report this to a Moderator Report this to a Moderator
 3-Nov-2004 11:28
User is offline View Users Profile Print this message


Ross Morgan

Posts: 74
Joined: 15-Apr-2004

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.

Report this to a Moderator Report this to a Moderator
 3-Nov-2004 12:15
User is offline View Users Profile Print this message


Roy Bond

Posts: 39
Joined: 25-Mar-2003

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
Report this to a Moderator Report this to a Moderator
 4-Nov-2004 10:13
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002



-------------------------
Tony Goodman
http://www.smartdxl.com

Edited: 5-Nov-2004 at 13:53 by Tony Goodman
Report this to a Moderator Report this to a Moderator
 4-Nov-2004 19:42
User is offline View Users Profile Print this message


Greg Lacefield

Posts: 13
Joined: 23-Oct-2003

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:

  • What do you do with these attributes when the review is completed? Are the cleared out or do they persist across baselines?

  • How do you manage a re-review of the same section, e.g. after action items have been addressed or subsequent changes are made to the requirements therein? Do you add new attributes for reviewer comments/responses (sequencing them in the process somehow), or just reuse the same fields?

  • Did you consider adding these fields to the checklist rather than the MUR? On the surface, that seems like a logical place for them, since they are only relevant for the duration of that particular review.

Regards,

Greg

Edited: 4-Nov-2004 at 23:46 by Greg Lacefield
Report this to a Moderator Report this to a Moderator
 4-Nov-2004 23:29
User is offline View Users Profile Print this message


Greg Lacefield

Posts: 13
Joined: 23-Oct-2003

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:

Each object is a discrete review checkpoint or comment linked to a requirement object.

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
Report this to a Moderator Report this to a Moderator
 4-Nov-2004 23:35
User is offline View Users Profile Print this message


Greg Lacefield

Posts: 13
Joined: 23-Oct-2003

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
Report this to a Moderator Report this to a Moderator
 5-Nov-2004 09:06
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 38
Joined: 4-Oct-2002

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
Report this to a Moderator Report this to a Moderator
 5-Nov-2004 10:00
User is offline View Users Profile Print this message


Ross Morgan

Posts: 74
Joined: 15-Apr-2004

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.
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.