the excellent use case
DESCRIPTION
The Excellent Use Case. Daryl Kulak Perficient, Inc. The Excellent Use Case. Getting to Good Excellence from 5 Perspectives. 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. - PowerPoint PPT PresentationTRANSCRIPT
The Excellent Use Case
Daryl KulakPerficient, Inc.
2
The Excellent Use Case
Getting to GoodExcellence 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.
PayBill
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 detailedExcellence doesn’t mean analysis-paralysis
8
Five Perspectives +1
The Right SizeTested on PaperTested in CodeIndependence of RequirementsOutside-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
1. Down the Road Rule - One team of 3-4 people should be able to design/develop/test the use case in 3-4 weeks.
2. One Brain Rule – One person should be able to do all the work associated with the single use case.
3. 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 projectorInvite business analyst, tester, SMEsSubstitute 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 informationMakes the use case “real” for the business peopleDon’t have to keep the scenarios
12
Tested in Code
Iterative/Incremental LifecycleTwo 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 codeLiving documentWeekly demonstrable deliverablesUse the weekly feedback to improve the use case and the
design and the code
13
Research at MIT
Dr. Nam Suh of MITA Decade to Find Design AxiomsAn 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, PostconditionsBUT 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 GoalWhat are the Goals of a Stove?
1. Turn burner on2. Turn burner off3. Read clock4. Turn heat up5. Turn heat down
1. Make eggs and bacon for breakfast
2. Boil water for tea3. Make spaghetti
sauce4. Clean the stove
before parents come over
5. Look impressive for the neighbors
16
You-Know-Who Versus Guess-Who
17
A Word About Business Use Cases
Business Unit
• Car• Clock Radio• Robot• Tree
18
Questions?
Daryl KulakPerficient, Inc.401 N Front Street, #240Columbus OH 43215
(614) 306 [email protected]
www.perficient.com