Welcome, who I am, my bona fides…

First three are from the UML 1.3, the fourth is from Booch, Rumbaugh, Jacobson: “the Unified Modeling Language User Guide” Cockburn: A Use Case expresses the behavioral portion of a contract between the Stakeholders of a system. It expresses the system's behavior and interactions under various conditions as it responds to a request on behalf of one of the Stakeholders, the Primary Actor, showing how the goal gets delivered or fails.

This is actually called a “Usage Narrative”, which is a particular instance of a use case. These are also called Scenarios, Scenario instances, Concrete scenarios, and the like. These are very useful for a starting point and for developing test cases…

Multiple Actors, multiple Systems, multiple Goals

System being interacted with has to deal with other systems to get the job done. This is typical, especially when the other systems are subsystems of the original one…

Users, CTOs, Dev VP, etc. live at Business Level. What we find there are terms like Business Value, Needs, Wants, Fears, and so on… Product Level is where business analysts, business architects, product managers, sales people, and so on, live. What you get here are functionality requirements, acceptance tests, integration, and so on

Casual Use Case. Steps aren’t numbered, the story is told in a simple paragraph. One step up in formality from the Concrete (Usage) Scenario we saw before.

The Fully Dressed version. Is more formal, and even more stuff can be added. Note the precondition and Context…

Note: this is not legitimate UML, but it should be…

Note: this is not legitimate UML, but it should be…

Tell story of kicking the ball down the field. You don’t document the guy kicking the ball around himself, only getting it down the field.

Note that two use cases were determined to be high priority, that's why they were explored and decomposed. Of the elements of those use cases, some of them provided the priority, some didn't Also note some stories from the technical guys. Perhaps infrastructure storied, or a better build process…

Note that two use cases were determined to be high priority, that's why they were explored and decomposed. Of the elements of those use cases, some of them provided the priority, some didn't Also note some stories from the technical guys. Perhaps infrastructure storied, or a better build process…

Note that two use cases were determined to be high priority, that's why they were explored and decomposed. Of the elements of those use cases, some of them provided the priority, some didn't Also note some stories from the technical guys. Perhaps infrastructure storied, or a better build process…

Note that two use cases were determined to be high priority, that's why they were explored and decomposed. Of the elements of those use cases, some of them provided the priority, some didn't Also note some stories from the technical guys. Perhaps infrastructure storied, or a better build process…

I use the terms “story” here to tie into XP. If you use XP practices to develop these stories you have a built in set of documentation on how to do this – the XP library. Each organization must determine its own “magic constants” for estimation – it will take a couple of projects to do this…  You can also look at a couple of previous projects, and count the use cases found in the system (this is fairly easy) and compare it to the actual cost to develop it. Then use Yesterday’s Weather to determine how much to budget for each use case. Then run with it as if it were true until it proves not to be… Numbers: 5 TTs in MSS, 6 steps in MSS, 2 alternatives per step, 3 TTs per alternative For example, in XP we would Use Story which further decomposes to Engineering Task…

And we do this by prioritizing the alternative scenarios to our use cases, and by managing the robustness level of how we solve them, from CUMABO (Clean Up Mess And Bail Out) to a complete “search these other DBs, do this algorithm, figure out how to supply this info…” approach.