I am confused about use case levels. All I could understand was that use cases that are contained in another use case fall under the level which is below the level of the container use case.
I have identified the following use cases for an e-commerce store and I would like to know if their levels are correctly determined or not. Please provide a description of the differences between levels if I have done something wrong here.
There is no single “correct” way of writing and structuring use cases. First and foremost, your approach has to work for you and the people you work with.
I’d like to suggest that “login” is often not a ‘real’ user goal, thus I’d see this as below the user goal level. From my perspective, “buy products” seems to be a reasonable user goal for a Customer in your example. “Browse products” might not always be a primary user goal, e.g. when you’re browsing through a catalog in order to buy something. On the other hand, the Customer might just want to obtain information without having the intent to buy immediately.
Alistair Cockburn’s “Writing Effective Use Cases” is certainly a great source on use case writing. I also suggest looking at “Lean Architecture for Agile Software Development” by James Coplien and Getrud Bjornvig: this book discusses the idea of a “habit”, i.e. a sequence of tasks that comes up in the context of different use cases but that is in itself not a fully fledged use case. (Search “use cases habits” and you’ll find a relevant section of the book. Then go buy and read the book — it’s great!)
Decomposing use cases into ever smaller use cases is a hotly debated topic with many people being fairly reluctant to do so. Among other issues, the administrative overhead of keeping track of use cases dependencies and keeping related use cases in synch can be very high. Also, fine-grained, highly decomposed use cases are often difficult to work with for non-IT people (and, truth be told, also for IT folks).
Best regards,
Oliver
I’d just like to second Oliver’s answer. To log in doesn’t usually define a business goal: it is an implementation scenario subservient to some business goal. People don’t go home at the end of the day and say, “Honey, I had a great day at work — I logged in 36 times!”
Alistair Cockburn frames his use cases in a goal (hence, “goal-driven use cases”) and most good use case practice follows his vision.
Habits are a developer tool used to remember recurring sequences of implementation (usually code) and to remember how they fit into the overall flow during analysis. They came out of my work together with Gertrud Bjørnvig and Trygve Reenskaug on the DCI paradigm, which is a way to bridge the mental models of both end users and developers into the code.
Our (Gertrud’s and my) own position — based on quite a bit of experience — is that decomposing use cases only confuses those who most need to buy in to what they say: the end user. While Jacobsson’s original vision of formal use case relationships such as “refine” and “extend” have nice formal semantics, requirements acquisition in the end is a necessarily informal activity rife with inconsistency, innuendo and context. Hence, we recommend using use cases not to communicate requirement mandates from some market oracle to the team, but only to structure and document the conversations and decisions that arise between product management and development in an open dialog with very short-loop feedback.