Hi,
I am looking at generating use cases for an existing system with a view to rewrite and I know the system and gui very well. Being new to use case modelling/writing I am thinking about how to create use case(s) for this example. Its a gui screen that has many different functions that a user can perform, all in a different order to manipuate the figures on the screen, like an excel pivot table. The requirements include the ability to use filters, create sub levels of figures (like a pivot table), drill down on figures to pull up trades, sort, change the view of figures from one set of calculated figures to another, the list goes on.
I am struggling to logically think of how I contruct a use case for this as there are a lot of activities the user may perform but not necessarily in any order or even related so I cannot think of a basic flow for this. I do know that the main functionality of this screen is to reflect realtime updates of trades that update figures on the screen, so any new / amend / cancel of trades change the figures real-time. Anything else the user performs is to help him/her visualise what they want to see, so could this be the basic path? ie. real time updates to the figures as thats what I feel is the main aim of this gui, everythign else is a manipulation of the screen. There are other users that view the same screen without realtime updates though, ie. a snapshot.
Do I break this down to sub-level use cases for each function I listed above? or put them all in one use case as alternative flow which would be very long if I have about 30 different functions that can be performed, again all unconnected.
It would be great to hear some opinions on this from people who have had similar issues, it may be that I am too close to the current system and gui and not necessarily looking at this from a Use Case perspective.
Consider your actors; it sounds like your update case is initiated by an external source or system, so a different actor then your user.So, I would suggest at leasts two use cases, the other being user manipulation of existing data.
If what the user can do is several unrelated actions with the data, I would consider a separate use case for each, but see if that works for you. Starting with at least the above two cases should get you going.
David,
Appreciate your comments. You are right, if other events update the figures then that must be a different use case I guess. As for the multiple functions that are unrelated, im having a hard time thinking about breaking them down, ie. decomposition as I keep thinking is there an end goal for the user? I guess there is, if the user wants to see a different set of calculated figures then teh user chooses that option and expects that result, end goal i guess.
What about complex calcs shown to the user, without thinking about the design, ie. if done on client or server, its shown to the user. If other GUIs or processes need similar calcs, should these be under business rules? or a standalone UC that describes all the different calcs?
thanks,
Binny
"What about complex calcs shown to the user..."
I would capture them as business rules and xref them to the UC steps that use them.
I see information display and re-display as not the same as use cases that do something, change the state of the business; if you get the calcs, how the results are shown is not as crucial.
Hi
thanks for that, makes sense for these to be in the business rules section.
I am still struggling with where I put all that unrelated complex screen manipulation functions ..separate UCs or all in one, if in one then are these really alternative flows? If separate UCs then im in danger of breaking a UC down into "functions" which isnt the right thing to do?
Is there another way to model all the various functions / options of a complex gui which may or may not be used by a user? activity? I cannot find examples anywhere. I realise this is subjective but the more I think about it the more I am confused.
brought to you by enabling practitioners & organizations to achieve their goals using: