The Excellent Use Case

1. The Excellent Use Case Daryl Kulak Perficient, Inc.

2. The Excellent Use Case • Getting to Good • Excellence from 5 Perspectives

3. The Good Use Case • Definition of a use case • A set of interactions between a system and an external person or system that achieves a goal. Pay Bill

4. A Good Use Case Is… • Well-named • Verb-Noun • A tennis match • Back and forth between actor and system • Devoid of user interface specifications • No buttons, drop downs, navigation, Web pages • Devoid of internal design specifications • Doesn’t document what happens “inside the box” • Achieves business value • The actor accomplishes a goal with the system • A story • Matches how business people think of their interactions with software

5. A Good Use Case System

6. The Excellent Use Case

7. The Excellent Use Case (2) • Alastair Cockburn says “Good Enough” • Excellence doesn’t mean overly detailed • Excellence doesn’t mean analysis-paralysis

8. Five Perspectives +1 • The Right Size • Tested on Paper • Tested in Code • Independence of Requirements • Outside-In • A Word about Non-IT Use Cases

9. The Right Size • What is the right size for a use case? • Number of pages, number of paths, blah-blah-blah • Down the Road Rule - One team of 3-4 people should be able to design/develop/test the use case in 3-4 weeks. • One Brain Rule – One person should be able to do all the work associated with the single use case. • One Sitting Rule – The use case should be something an actor or actors can accomplish in one sitting.

10. Size – Let’s Talk about Batch • “Batch use cases??” • Two situations • Period-end processing done for business purposes • Processing pushed off-hours for technical reasons Requests report Report is delivered next morning

11. Tested on Paper • Use Case “Scenarios” • Meeting room with a projector • Invite business analyst, tester, SMEs • Substitute real data for the generic references in the use case • “Supply clerk” becomes “Sam Turner” • “Customer number” becomes “AR577341-1” • “Number of items in the order” becomes “8” • Take the data from a real set of information • Makes the use case “real” for the business people • Don’t have to keep the scenarios

12. Tested in Code • Iterative/Incremental Lifecycle • Two problems • Business people “I’ll know it when I see it” • Technical people “I’ll know how to code it after I’ve coded it” • The use case ain’t done until you’ve seen it running in code • Living document • Weekly demonstrable deliverables • Use the weekly feedback to improve the use case and the design and the code

13. Research at MIT • Dr. Nam Suh of MIT • A Decade to Find Design Axioms • An Axiom is “a fundamental truth that is always observed to be valid and for which there are no counterexamples or exceptions.” • Axiom #1 • The Independence Axiom • A good design always maintains the independence of functional requirements. • Axiom #2 • The Information Axiom • The best design among several is a functionally uncoupled design that has the minimum information content.

14. Independence of Functional Requirements • Preconditions, Postconditions • BUT NOT THESE • Use Case Flow Diagram • Go-To’s • Uses/Includes/Extends • Hierarchies of Use Cases • Resist making use cases dependent on one another

15. Outside-In • Each Use Case Must Address an Actor’s Goal • What are the Goals of a Stove? • Make eggs and bacon for breakfast • Boil water for tea • Make spaghetti sauce • Clean the stove before parents come over • Look impressive for the neighbors • Turn burner on • Turn burner off • Read clock • Turn heat up • Turn heat down

16. You-Know-Who Versus Guess-Who

17. A Word About Business Use Cases Business Unit • Car • Clock Radio • Robot • Tree

18. Questions? Daryl Kulak Perficient, Inc. 401 N Front Street, #240 Columbus OH 43215 (614) 306 6137 daryl.kulak@perficient.com www.perficient.com