Adrian,
Good answer.
Some questions for you:
I. find that having business rules precludes a need for exceptions. Tend to push exceptions down to design as UI validations. Do you see a need for business rules and exceptions?
2. To add to your package how about the Vision Document? Don't really do them myself. Tend to use either a list of textual requirements or a process definition and explanation.
Kimbo
Hi Kimbo,
1. It depends how each organization defines the line between business rules and exception flows. In my view, for example, if the use case is Withdraw Money (from ATM) an exception flow might be "Account Has Been Locked". This is not desired by the actor/user nor is it a business rule, nor is it a UI/Design issue. I realize it's splitting hairs a bit.
2. The Vision document has its place. I did not include it in the set of "use case" family since use cases capture functional requirements whereas the Vision Document comes much earlier in the process. Check out: What is a Vision Document? (it's a short read).
- Adrian
Please can you explain in more detail about the Use Case Model Survey. Also, my other question is how do you manage use case diagrams when the actor has a lot of use cases to deal with. I know packaging is one way but were wondering if there is any others.
Thanks.
Vandy
Vandy,
I guess you are using Rational software for requirements management and modeling, because I have seen the Use Case Survey in the list of SoDA documents.
At the time (couple of years ago) it was a single document that organized in a document all use case diagrams for the project out of Rational Rose including the documentation text (if nay) that I have added to the diagrams. I remember updating the word document automatically generated by SoDA and adding there the use case description because I had to keep all use cases for that particular project in one document and separate from the other requirements.
-Vessela
Hi Vandy,
The Use Case Model Survey describes (at high-level) all the significant/main use cases for a given project. It will contain the Use Case Diagram(s) and it will have a short textual description of each use case (not the details). This type of document provides high-level executives and new project members with a quick and easy to understand overview of the features supported by the given system.
On your other questions, if the same actor truly interacts with many use cases, then braking down your model into packages by logical functional areas is probably a good solution. Another thing to consider when an actor uses many, many use cases is whether your actor is too generic.
Example:
Remember that there is rarely a one to one mapping between the job titles in an organization and the actors in the use case model.
brought to you by enabling practitioners & organizations to achieve their goals using: