Use Cases in DOORS

Using use cases in DOORS is often a case of selecting the least worst case. The possibilities which I see in writing a use case in a DOORS module (without customizations) are as follows:

1. One use case in one object

• The whole of use case text is placed in one DOORS object, maybe copy pasted from a word processing document
• Pro: you can link to the use case object, you can have the same attribute values for the use case
• Con: can be unwieldy for long use case

2. One use case in one object with specific attributes

• Maybe only the use case ID and name is in DOORS main column, all the other content (Actors, Assumptions, Steps etc.) are in other attributes
• Pro: you can link to the use case object, you can have the same attribute values for the use case
• Con: may be hard to collect data for the whole use case, needs view with scrolling to see the content

3. Use case split into DOORS object hierachy

• The use case ID and name is highest level object, other content is placed as child objects of this use case name object
• Pro: text content per object is manageable, you can link to individual steps if needed
• Con: hard to collect data for the whole use case

4. Use case list module with linked detailed use cases

• Use case list contains the ID and name, detailed use case contents are linked from other modules to the use case name object
• Pro: allows the user to work either on the use case name level or at the detailed level, use case list works as a switching boad to link use cases to other objects
• Con: hard to collect data for the whole use case, needs working in different modules

With DXL customizations using use case in DOORS might be easier, but it is not easy to sidestep the problems mentioned above. What to select from these possibilities is dependent on what kind of use cases are managed, how long they are and what is the process for managing them.

Advertisement