I'm a new BA who is having trouble trying to figure out how detailed I should go when creating use cases. I am using the Object-Oriented Analysis and Design textbook from my college days as a guide. The book uses an order management system as its example and one of the use cases is "Create a new order".
The system I am trying to create use cases for tracks patients who have tested positive for HIV and their partners. So I could go with "Create a new record." But there are two kinds of main records; an index patient record and a partner record. While each has common fields entered (name, adddress, phone number etc), they also each have their own fields that are different from the other. So do I create an index patient use case and a separate partner record use case?
To make it even more confusing, it is possible to break both index patients and partners into even more detail. For instance an index patient could have been tested in the state and live in the state; tested in the state but moved out of state; tested out of state but moved to the state. The same for partners. Also, an index patient could also be a partner him or herself or multiple partners; a partner of an index patient could also be an index patient themselves or partner to multiple index patients. So should I creatre a use case for each of these scenarios?
Is there a best practice or rule of thumb for use cases to help us figure out how much detail to take into account? I performed an event decomposition and created an event table. When I did that I only came up with Create a record, update a record, close a record, retrieve a record, and run a report. Doing that didn't really answer the question though since I could easily break up create a record into the scenarios I described above.
I'd appreciate any advice on this matter.
There are certainly several sources that describe the construction and utilization of use cases (e.g., BABOK 2.0 Technique). Time permitting, seek a resource and study the material. Otherwise, in the interim...
1) Consider creating a use case diagram - complete with stick figures! Also, strive to understand any rela'ships among the use cases (e.g., dependencies).
2) Recognize that a use case represents a task, and its details typically contain sequential steps - complete with exception and condition paths.
3) Consider creating a process flow to assist you with the use case flow.
4) Also, consider using a dialog map to support you with exception and condition paths.
5) Last but not least, have fun!
brought to you by enabling practitioners & organizations to achieve their goals using: