Hi Chrissy,
Your example for login is really designing the user interface, in my opinion. That shouldn't be done with a use case. Its part of the separate UI specification.
Most of the examples and justification you've given are based around the UI specification which is the solution phase of the project. Use cases are about solution independent functional specifications. The simplest way to differentiate is think whether that function is necessary if your system ends up being implemented as a paper based manual system. There is no justification for a 'login' use case in that case. Therefore I'd argue it is solution and has no basis in being a use case.
Sometimes I feel I'm a voice in the wilderness on this issue but anyway...
Kimbo
Hi Kimbo,
I think your arguments are a narrowing the purpose of a use case.
Use cases are not only meant for solution independent specifications. In my opinion, they are a technique that helps me communicate and understand behaviour both for high level interactions (for example the manufacturing of a toothbrush) and for low level (for example, place an order or withdraw money from an ATM). It depends on what I need to communicate and to whom.
Regarding the Ul specifications... I didn't specify anything about screens, buttons or else, so I think I can be exonerated of the fault of using UI elements in describing the use case. Indeed, the elements are pretty close to UI, but they are still elements of behaviour, so I still think they can be described with a use case.
By the way, "Writing Effective Use Cases" by Alistair Cockburn stresses this aspect, that the scope (perspective) of a use case is relative to what one needs to express.
Hi Crissy,
You're probably right, I am being too pedantic about it.
However I submit that logging on does not do anything of value for the actor initiating the use case and so breaks one of the fundamental tests of what a use case is.
brought to you by enabling practitioners & organizations to achieve their goals using: