Use Case Workshop 101 
By Andreas Hägglund
Primary objectives 
•Get the ball rolling 
•Have fun 
•Get the team to commit 
•Scratch the surface
Prepare yourself 
Read, study and interview 
•Feasability studies 
•Old backlogs 
•Help desk requests 
•Bug reports 
•Business process models
Setting the Scope 
What problem are we trying to solve? 
What opportunity are we trying to take advantage of?
Result – Setting the Scope
Identify Actors (given the scope) 
•Who will say the system is valuable and useful? 
•Who will be interacting with the system? 
–Who do we need to provide information to the system? 
–Who will be receiving information from the system 
Who, as in who or what!
Identify Actors by using the actor star 
Maintenance 
Business/Managers 
Customers 
Staff 
Government and laywers 
Unknown... 
Criminals & 
Journalists 
Uncle Time
Actor 
Actor 
Actor 
Actor 
Result – Identifying Actors 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor
Why you always should start with the Actors! 
1.Once you’ve identified use cases your mind is trapped! You’ve unintentionally limited your possible actors to the ones related to the use cases you’ve found 
2.You won’t forget the use cases you’ve already found 
3.It forces you to not think about the solution
Identify Use Cases 
For every actor: 
•What does ”this one” want to do with the system
What is a Use Case?
Tell your girl-/boyfriend about it! 
A use case is so valuable that when you’ve executed it, you want to tell your loved ones about it! 
Or your boss...
A Use Case should be executed by one person, at one point in time
An interaction 
A use case is an interaction, a discussion, between the system and something/-one else
Something complete 
A use case holds all the pieces that’s needed to create value
Actor 
Actor 
Actor 
Actor 
Result 1 – Identifying use cases 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Use Case 1
Actor 
Actor 
Actor 
Actor 
Result 2 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Use Case 1 
Use Case 2
Actor 
Actor 
Actor 
Actor 
Result 3 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Use Case 3 
Use Case 2 
Use Case 1
Actor 
Actor 
Result 4 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor
Use the Use Cases to identify more Actors 
For every use case: 
1.”Ok, take this use case, that we said was used by Actor X, are there any other actors that also wants to use it?” 
2.”Is there someone that’s needed to provide information to the use case?” 
3.”Is there someone that gets notified about anything by the use case?”
Actor 
Actor 
Result 5 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor
Use the new actors to identify more use cases... 
For every new Actor: 
•”Ok, how about this Actor, that we said was involved in use case X, does (s)he/it wants to do something else/more with the system? 
•”Is (s)he/it involved in any of the other use cases as well?”
Actor 
Actor 
Final Result 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor 
Actor
Naming the Use Cases 
•Use at least Verb + Noun (i.e. ”purchase book” not ”purchase”) 
•Use undetermined numbers (i.e ” purchase book” not ”purchase 1 book”) 
•Use active tense (” purchase book” not ”purchase of book”) 
•Use simple wording (i.e. ”buy book” not ”purchase book”) 
•Make the name descriptable (i.e. ”buy book” not ”commit transaction”) 
•Show the value (i.e. ”buy book” not ”commit transaction”) 
•Initially it’s better with names that are ”too long”, than too short (i.e. ”log on to system, buy books and print receipt” is better than ”log on”)
Review the model 
•Test the names by reading Actor and Use Case name together – E.g. ”Customer buy book”. It should make sense. 
•Do all Use Cases have an Actor? 
•Do all Actors have a Use Case? 
•Is it overviewable? 
•Do we have an agreement?
Short Use Case description creates break-trough discussions! 
•1-5 Sentences that helps making it clear to the team what each Use Case contains. 
•Expect lots of discussion about the purpose and content of each use case. 
•Expect to discover more Actors. 
•If you get details, great! But don’t get stuck looking for them...
What’s in a short description? 
Some or all of: 
•The value 
•Tell how it start and ends 
•Include possible preconditions 
•Highlight major crossroads 
•Highlight important and/or complex parts
Result – Short Descriptions 
”The use case lets the Customer find and buy books (s)he likes, select payment methods (credit, invoice, COD) and delivery options. The Use Case ends when the Customer has confirmed the purchase and received an electronic receipt. Purchases of books that are out of stock is put on a waiting list for later delivery.”
Get your priorities right! 
•Prioritize the actors 
•Prioritize what use cases to detail first 
•Identify the minimum marketable system
Detail the main flow 
Do the teenage use case disco dance 
Use verbs and nouns 
Use active tense 
Pay attention to spelling and grammar 
Don’t get stuck!
Do the following 12 slides fast and you’ll learn the teenage use case disco dance... 
System
Actor
Actor
System
System
Actor
Actor
System
System
Actor
Actor
System
System
Result – Main Flow 
The Use Case starts when the [Book lover] select to search for a book. 
1.The [Book lover] enter one or many search criterias (title, author, genre, character) [Book Found] 
2.The System presents information (cover, average review, description, publisher, publishing year, category, genre, synopsis) about the book 
3.The [Book lover] selects the book and proceeds to check out. 
4.The System asks for payment method and delivery options. 
5.The [Book lover] selects invoice and overnight delivery. 
6.The System ask [Book lover] to identify him/herself to access billing adress. 
7.The [Book lover] identifies him/herself. 
8.The System asks the [Book lover] to confirm billing and shipping adress together with the purchase. 
9.The [Book lover] confirms 
10.The system generates and stores order details (orderId, purchasing date, productId, CustomerId, amount) and generates and displays a receipt.
What is a ”main flow” 
•The most often executed? 
•The one most valuable to the business? 
•The shortest one? 
•The shortest one that still delivers value? 
•The most valuable to the user? 
•The one first identified? 
You decide!
Add pre- and postconditions 
A Precondition must be true before it’s possible to enter the Use Case. 
Two types of Postconditions: 
1. Minimum guarantee: This will be true no matter what happens 
2. Success guarantee: This will be true if the Use Case ends ”as planned”
Result – Pre- and post conditions 
Precondition: The identity of the Customer must be known before this Use Case can be triggered 
Postcondition 
Minimum Guarantee: The transaction is logged and the System is ready for another transaction. 
Success Guarantee: The purchase is registered and the Customer has confirmed it.
Identify Alternatives 
For every step in the main flow 
•Ask if the Actor can choose to do something else 
•Ask if something can go wrong? 
•Ask if someone ”else” can send information/interrupt the flow
Quality Attributes 
For every identified flow: 
•Ask how often it will be executed 
•Ask how long it may take 
•Ask how important it is 
•Ask how difficult it is to understand 
•Ask how sensitive the information is
Result – Alternative Flows 
A1 Buy multiple books 
A2 Book not in stock 
A3 Book not available 
A4 Book on sale/campaign – 2 for 1 
A5 Buy book from wishlist 
A6 Book not for sale 
A7 Book discounted 
A8 ...
Review Model 
•Rename use cases to better reflect content of use case 
•Add Actors that have been discovered ”within” a Use Case 
•Reprioritize 
•Structure model if necessary 
–Include 
–Extend
Restructure to improve 
Use the 7+/-2 Principle for Restructuring 
•7 +/- 2 Use Cases in the model? 
•7 +/- 2 Alternatives and Error Flows? 
•7 +/- 2 Steps in the main flow? 
•7 +/- 2 Sentences in a step? 
Readability 
Overview 
Comprehensability 
Acceptance
You made it!
Now What?
Add details 
•Add details to existing flows – Verbs & Nouns 
•Add Alternative flows 
•Add Quality Attributes 
•Break up Use cases that are too big 
•Add details 
•Add details 
•Add details
Want to stay updated? 
Ahab1972 
/andreashagglund 
Systemvaruhuset.net (personal site) 
Systemvaruhuset.se (corporate site)

How to run a great requirements workshop with Use Cases

  • 1.
    Use Case Workshop101 By Andreas Hägglund
  • 2.
    Primary objectives •Getthe ball rolling •Have fun •Get the team to commit •Scratch the surface
  • 3.
    Prepare yourself Read,study and interview •Feasability studies •Old backlogs •Help desk requests •Bug reports •Business process models
  • 4.
    Setting the Scope What problem are we trying to solve? What opportunity are we trying to take advantage of?
  • 5.
  • 6.
    Identify Actors (giventhe scope) •Who will say the system is valuable and useful? •Who will be interacting with the system? –Who do we need to provide information to the system? –Who will be receiving information from the system Who, as in who or what!
  • 7.
    Identify Actors byusing the actor star Maintenance Business/Managers Customers Staff Government and laywers Unknown... Criminals & Journalists Uncle Time
  • 8.
    Actor Actor Actor Actor Result – Identifying Actors Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor
  • 9.
    Why you alwaysshould start with the Actors! 1.Once you’ve identified use cases your mind is trapped! You’ve unintentionally limited your possible actors to the ones related to the use cases you’ve found 2.You won’t forget the use cases you’ve already found 3.It forces you to not think about the solution
  • 10.
    Identify Use Cases For every actor: •What does ”this one” want to do with the system
  • 11.
    What is aUse Case?
  • 12.
    Tell your girl-/boyfriendabout it! A use case is so valuable that when you’ve executed it, you want to tell your loved ones about it! Or your boss...
  • 13.
    A Use Caseshould be executed by one person, at one point in time
  • 14.
    An interaction Ause case is an interaction, a discussion, between the system and something/-one else
  • 15.
    Something complete Ause case holds all the pieces that’s needed to create value
  • 16.
    Actor Actor Actor Actor Result 1 – Identifying use cases Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Use Case 1
  • 17.
    Actor Actor Actor Actor Result 2 Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Use Case 1 Use Case 2
  • 18.
    Actor Actor Actor Actor Result 3 Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Use Case 3 Use Case 2 Use Case 1
  • 19.
    Actor Actor Result4 Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor
  • 20.
    Use the UseCases to identify more Actors For every use case: 1.”Ok, take this use case, that we said was used by Actor X, are there any other actors that also wants to use it?” 2.”Is there someone that’s needed to provide information to the use case?” 3.”Is there someone that gets notified about anything by the use case?”
  • 21.
    Actor Actor Result5 Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor Actor
  • 22.
    Use the newactors to identify more use cases... For every new Actor: •”Ok, how about this Actor, that we said was involved in use case X, does (s)he/it wants to do something else/more with the system? •”Is (s)he/it involved in any of the other use cases as well?”
  • 23.
    Actor Actor FinalResult Actor Actor Actor Actor Actor Actor Actor Actor Actor
  • 24.
    Naming the UseCases •Use at least Verb + Noun (i.e. ”purchase book” not ”purchase”) •Use undetermined numbers (i.e ” purchase book” not ”purchase 1 book”) •Use active tense (” purchase book” not ”purchase of book”) •Use simple wording (i.e. ”buy book” not ”purchase book”) •Make the name descriptable (i.e. ”buy book” not ”commit transaction”) •Show the value (i.e. ”buy book” not ”commit transaction”) •Initially it’s better with names that are ”too long”, than too short (i.e. ”log on to system, buy books and print receipt” is better than ”log on”)
  • 25.
    Review the model •Test the names by reading Actor and Use Case name together – E.g. ”Customer buy book”. It should make sense. •Do all Use Cases have an Actor? •Do all Actors have a Use Case? •Is it overviewable? •Do we have an agreement?
  • 26.
    Short Use Casedescription creates break-trough discussions! •1-5 Sentences that helps making it clear to the team what each Use Case contains. •Expect lots of discussion about the purpose and content of each use case. •Expect to discover more Actors. •If you get details, great! But don’t get stuck looking for them...
  • 27.
    What’s in ashort description? Some or all of: •The value •Tell how it start and ends •Include possible preconditions •Highlight major crossroads •Highlight important and/or complex parts
  • 28.
    Result – ShortDescriptions ”The use case lets the Customer find and buy books (s)he likes, select payment methods (credit, invoice, COD) and delivery options. The Use Case ends when the Customer has confirmed the purchase and received an electronic receipt. Purchases of books that are out of stock is put on a waiting list for later delivery.”
  • 29.
    Get your prioritiesright! •Prioritize the actors •Prioritize what use cases to detail first •Identify the minimum marketable system
  • 30.
    Detail the mainflow Do the teenage use case disco dance Use verbs and nouns Use active tense Pay attention to spelling and grammar Don’t get stuck!
  • 31.
    Do the following12 slides fast and you’ll learn the teenage use case disco dance... System
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
    Result – MainFlow The Use Case starts when the [Book lover] select to search for a book. 1.The [Book lover] enter one or many search criterias (title, author, genre, character) [Book Found] 2.The System presents information (cover, average review, description, publisher, publishing year, category, genre, synopsis) about the book 3.The [Book lover] selects the book and proceeds to check out. 4.The System asks for payment method and delivery options. 5.The [Book lover] selects invoice and overnight delivery. 6.The System ask [Book lover] to identify him/herself to access billing adress. 7.The [Book lover] identifies him/herself. 8.The System asks the [Book lover] to confirm billing and shipping adress together with the purchase. 9.The [Book lover] confirms 10.The system generates and stores order details (orderId, purchasing date, productId, CustomerId, amount) and generates and displays a receipt.
  • 45.
    What is a”main flow” •The most often executed? •The one most valuable to the business? •The shortest one? •The shortest one that still delivers value? •The most valuable to the user? •The one first identified? You decide!
  • 46.
    Add pre- andpostconditions A Precondition must be true before it’s possible to enter the Use Case. Two types of Postconditions: 1. Minimum guarantee: This will be true no matter what happens 2. Success guarantee: This will be true if the Use Case ends ”as planned”
  • 47.
    Result – Pre-and post conditions Precondition: The identity of the Customer must be known before this Use Case can be triggered Postcondition Minimum Guarantee: The transaction is logged and the System is ready for another transaction. Success Guarantee: The purchase is registered and the Customer has confirmed it.
  • 48.
    Identify Alternatives Forevery step in the main flow •Ask if the Actor can choose to do something else •Ask if something can go wrong? •Ask if someone ”else” can send information/interrupt the flow
  • 49.
    Quality Attributes Forevery identified flow: •Ask how often it will be executed •Ask how long it may take •Ask how important it is •Ask how difficult it is to understand •Ask how sensitive the information is
  • 50.
    Result – AlternativeFlows A1 Buy multiple books A2 Book not in stock A3 Book not available A4 Book on sale/campaign – 2 for 1 A5 Buy book from wishlist A6 Book not for sale A7 Book discounted A8 ...
  • 51.
    Review Model •Renameuse cases to better reflect content of use case •Add Actors that have been discovered ”within” a Use Case •Reprioritize •Structure model if necessary –Include –Extend
  • 52.
    Restructure to improve Use the 7+/-2 Principle for Restructuring •7 +/- 2 Use Cases in the model? •7 +/- 2 Alternatives and Error Flows? •7 +/- 2 Steps in the main flow? •7 +/- 2 Sentences in a step? Readability Overview Comprehensability Acceptance
  • 53.
  • 54.
  • 55.
    Add details •Adddetails to existing flows – Verbs & Nouns •Add Alternative flows •Add Quality Attributes •Break up Use cases that are too big •Add details •Add details •Add details
  • 56.
    Want to stayupdated? Ahab1972 /andreashagglund Systemvaruhuset.net (personal site) Systemvaruhuset.se (corporate site)