BK, This is my personal view... but as always, Business Analyis is extremely subjective... As per my other post regarding GUIs and Use Cases, Use Cases aren't designed for UIs. The reason is that for UIs you're usually describing functions of the system for a given screen or component of the system. Use Cases derived from goals can span multiple functions, screens and components. I believe this is why you are struggling on the granularity of your use cases. You're trying to describe functions as single use cases, when functions don't map directly to use cases. I think that there's a comfort in using Use Cases for interactions because it's nice and structured. However, in practice, user _interface_ *design* is more complex, and can't always be packaged nicely into use cases. When a developer develops a system, they aren't particularly interested in how a user uses the system, they're interested in how they're going to develop it. You'd be better off describing the functions of each screen individually, using models/decision trees etc to describe complex functionality, then validating your functions against your non-GUI Use Cases and goals. At the end of the day it's important to keep it simple. Too much structure can be a bad thing. Graham
I agree with Graham. Use cases shouldn't be used to describe screen design. Its probably the most common misuse of use cases. A use case, as with anything in Business Analysis, is solution free. Your use case should be valid if it is realised by one or more screens, a manual process, perhaps a mobile solution or whatever.
What you are doing is documenting screen design, so you need different artefacts to do this. Not sure what you're looking to do but perhaps something like a state diagram might work with a transition being the action (e.g. pushing a button) and the result is entry of some other stuff. Or alternatively an activity diagram.
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using: