Hello again
Many thanks for your helpful responses.
Kimbo, your suggestion was pretty much what I had gone with so I will continue with that.
Tony, I haven't really had that much experience with DFD's before other than high level context diagrams. It's certainly something I would like to spend some more time looking at as it looks like a very useful technique.
I have another question around finding the right goal level in your use cases. As I mentioned perviously we are buidling a tool for case managment. Now in my company they tend to use the concept of a "Manage" Use case quite regularly to rollup common behaviour such as CRUD into one use case. Im not completely adverse to this concept under the right circumstances.
In this system I have the concept of a "case manager" Actor. One of his main responsibilties is to manage hire car requests from vehicle dealerships while they are repairing a customer's vehicle. For each day that the vehicle is being repaired the dealer must supply information about that repair, and request a hire car for that day on behalf of the customr. For each day of hire the case manager will detimine if the hire is justified, and set it to authorised (paid for by us) , unauthorised (rebilled to the dealer) , or we require more info to make a decision. This is acheived by simply setting a predefiend status agaisnt each day of hire that has occured. The Case Manager may or may not add a note after setting this status, it is completely optional. At the end of the case, the case manager will finalise the hire car, which basically means that the status of each day is now fiixed an cannot be changed prior to this the case manager may chagne the status of any day), this also sends some data to a couple of external systems.
So, I currently have a number of use cases for this case manager: set hire day authority, finalise hire car, add case note.
It was suggested by a colleague that I could roll these up into a "Manage Hire" or" Manage Case" Use Case. My argument, however, was that the goal level is too high since managing the hire is something that typically takes place over the lifecycle of the case, which could be, and often is, weeks. I have alway been taught to write use cases using the single sitting rule, where the goal of the use case should be something that is acheivable in one sitting (eg, apply for a loan, buy goods, withrdraw cash) . and that those goals should provide value to the Primary Actor.
My current thinking is that these use cases are genrally all single, all be it short, one sitting interactions with the system. In the case of set hire authority, a case manage may open a case, review the repair inforamtion associated with 3 days of hire, set those three days to authorised and leave that case, and this is fairly typically.
I would be keen to know your thoughts, and perhaps how you would have approached this or any advice//tips you can offer from your previosu experiences.
Regards
PETE