1.
FROM USE CASE to USER STORIES

2.
Use Case Introduction

4.
Why are Requirements important <ul><li>1/3 budget to correct errors originate from requirements </li></ul><ul><li>Defining requirements is crucial to all project stakeholders </li></ul><ul><li>Many techniques and models available </li></ul>USE CASE MODEL

5.
Why should you be interested ? <ul><li>IDEO Story: </li></ul><ul><ul><li>Biker water bottle – heart valve </li></ul></ul><ul><ul><li>Multidiscipline cooperation </li></ul></ul>

6.
What are Requirements <ul><li>It covers : </li></ul><ul><li>Functional requirements </li></ul><ul><ul><li>User requirements </li></ul></ul><ul><li>Nonfunctional requirements </li></ul><ul><ul><li>Quality attributes: performance, security, archiving, database </li></ul></ul>defined operational capabilities business needs satisfy

7.
Software Requirements <ul><li>Three perspectives: </li></ul><ul><ul><li>Business level </li></ul></ul><ul><ul><li>User level </li></ul></ul><ul><ul><li>Technical level </li></ul></ul>

8.
Business Level <ul><li>Define the vision </li></ul><ul><li>Build the right software </li></ul><ul><li>Define project stakeholders: </li></ul><ul><ul><li>including direct users (actors) </li></ul></ul>

9.
User Level <ul><li>Use cases : </li></ul><ul><ul><li>“ voice of customers” </li></ul></ul><ul><ul><li>consists of : </li></ul></ul><ul><ul><li>interaction </li></ul></ul><ul><ul><li>has name </li></ul></ul><ul><ul><li>step-by-step </li></ul></ul><ul><ul><li>exception conditions </li></ul></ul><ul><ul><li>variant paths </li></ul></ul>

10.
Technical Level <ul><li>Technical requirements: </li></ul><ul><ul><li>Functional requirements based on user requirements </li></ul></ul><ul><ul><li>Nonfunctional requirements </li></ul></ul>

11.
Use Case Concepts and Definitions

12.
Use Case <ul><li>Describes how the system should respond under various conditions to a request from one of the stakeholders to deliver a specific goal . </li></ul><ul><ul><ul><li>stakeholder = primary actor </li></ul></ul></ul>

13.
Use Case <ul><li>The use case is primarily done in the form of a scenario that describes a sequence of steps . </li></ul><ul><li>Each use case captures a ‘contract’ for the behavior of the System under Discussion (SuD) to deliver a single goal . </li></ul>

14.
Actors <ul><li>Anyone or anything with behavior. </li></ul><ul><li>Generally is a role (rather than a specific person, job title or a thing) </li></ul><ul><li>Not every stakeholder will show up </li></ul><ul><li>Important to discover these ‘hidden’ actors </li></ul>

15.
Primary Actor <ul><li>Stakeholder that interacts with the SuD to achieve a specific goal </li></ul>

16.
Supporting Actor <ul><li>An (external) actor that needs to provide a service to the SuD </li></ul><ul><li>A primary actor for one use case can become a supporting actor for another </li></ul>

17.
Scenario <ul><li>sequence of steps </li></ul><ul><li>fulfill a goal </li></ul>

18.
Scenario <ul><li>Must be easy to read </li></ul><ul><li>Avoid more than nine steps </li></ul><ul><li>Use active voice </li></ul><ul><li>Stating who or what is doing what </li></ul><ul><li>Approver approve a task </li></ul><ul><ul><li>The approver open My Tasks </li></ul></ul><ul><ul><li>The approver choose a task </li></ul></ul><ul><ul><li>The approver approves the task </li></ul></ul><ul><ul><li>The system returns the approver to My Tasks list </li></ul></ul>

19.
Main Success Scenario <ul><li>Everything goes as planned </li></ul><ul><li>Happy Path </li></ul>

20.
Extensions <ul><li>Exceptions that requires a deviation from the planned scenario </li></ul><ul><li>Exceptions documented as extension </li></ul>

21.
Extensions <ul><li>Approver approve a task </li></ul><ul><li>Main Success Scenario </li></ul><ul><ul><li>The approver open My Tasks </li></ul></ul><ul><ul><li>The approver choose a task </li></ul></ul><ul><ul><li>The approver approves the task </li></ul></ul><ul><ul><li>The system returns the approver to My Tasks list </li></ul></ul><ul><li>Extensions </li></ul><ul><li>3a The task has been approved by another approver </li></ul><ul><ul><li>3a1 The system returns error message to the approver </li></ul></ul><ul><li>3b The approver decides to postpone the approval process </li></ul><ul><ul><li>3b1 The approver click the ‘Back’ button </li></ul></ul><ul><ul><li>3b2 The system returns the approver to My Tasks list </li></ul></ul>

22.
Use Case Properties <ul><li>Design Scope </li></ul><ul><li>Stakeholder </li></ul><ul><li>Primary Actor </li></ul><ul><li>Description </li></ul><ul><li>Level </li></ul><ul><li>Pre-conditions </li></ul><ul><li>Post-conditions </li></ul><ul><li>Trigger </li></ul>

23.
Design Scope <ul><li>Definition of the boundary of the System Under Discussion (SuD) </li></ul><ul><li>Set of systems that will be designed </li></ul>

24.
Design Scope <ul><li>A business use case has enterprise as its scope and focus on business flow </li></ul><ul><li>A system use case has computer system as its scope and focus on how actors communicate with the system </li></ul><ul><li>A component use case has subsystem or component of the system as its scope </li></ul>

25.
Use Case Level <ul><li>Summary (cloud level or kite level) </li></ul><ul><ul><li>outlines the context of a set of User Goal use cases </li></ul></ul><ul><li>User Goal (sea level) </li></ul><ul><ul><li>addresses “Can the primary actor go away happily after the use case finished ?” </li></ul></ul><ul><li>Subfunction (under water level) </li></ul><ul><ul><li>created to move out an isolated part of a scenario to a separate use case </li></ul></ul>source : Alistair Cockburn, Writing Effective Use Cases

26.
Use Case level <ul><li>Summary </li></ul><ul><li>User Goal </li></ul><ul><li>Subfunction </li></ul>

27.
Stakeholder & Primary Actor <ul><li>Stakeholder: </li></ul><ul><ul><li>someone / something that has an interest in the goal of the use case delivers </li></ul></ul><ul><li>Primary Actor: </li></ul><ul><ul><li>the stakeholder who or which initiates the use case to achieve a goal </li></ul></ul>

28.
Description <ul><li>Brief description of the goal the use case supposed to deliver </li></ul>

29.
Preconditions <ul><li>conditions that must hold true before the scenario of the use case starts </li></ul><ul><li>will not be checked again after that </li></ul>

30.
Post conditions <ul><li>Minimal Guarantees </li></ul><ul><ul><li>What at least should hold true when the goal is not met </li></ul></ul><ul><ul><ul><li>Example: </li></ul></ul></ul><ul><ul><ul><li>“ All entered information have been stored.” </li></ul></ul></ul><ul><li>Success Guarantees </li></ul><ul><ul><li>What must have been achieved at the end of the main success scenario or any alternate route. </li></ul></ul><ul><ul><ul><li>Example: </li></ul></ul></ul><ul><ul><ul><li>“ The task is approved” </li></ul></ul></ul>

31.
Trigger <ul><li>event or sequence of events that initiate the use case </li></ul>

32.
Use cases Process Flow

33.
Develop in Iterations <ul><li>Identify all actors and their goals </li></ul><ul><li>Use MoSCoW list to define the scope of the project. </li></ul><ul><li>Set up Actor-Goal List </li></ul>

34.
MoSCoW List <ul><li>Must Have : The requirement is essential, key stakeholder needs will not be satisfied if this requirement is not delivered and the timebox will be considered to have failed </li></ul><ul><li>Should Have : This is an important requirement but if it is not delivered within the current timebox, there is an acceptable workaround until it is delivered during a subsequent timebox </li></ul><ul><li>Could Have : This is a ‘nice to have’ requirement; we have estimated that it is possible to deliver this in the given time but will be one of the requirements de-scoped if we have underestimated </li></ul><ul><li>Won't Have : The full name of this category is ‘Would like to have but Won’t Have during this timebox’; requirements in this category will not be delivered within the timebox that the prioritisation applies to </li></ul>

35.
Actor-Goal List L Find unfinished task and reject it Reject unfinished task Support H Receive request and approve it Approve Request Approver H Make change in edit group and send it Submit Change Request Requestor Prio Brief Descriptions Goals Actor

36.
Recipe <ul><li>Identify the actors </li></ul><ul><li>List their goals </li></ul><ul><li>Add brief descriptions to the goals </li></ul><ul><li>Create an initial use case for each goal </li></ul><ul><li>Describe the main success scenario for each use case </li></ul><ul><li>Identify the exceptions to the main success scenario and work them out as extension </li></ul><ul><li>Validate the use cases </li></ul><ul><li>Optimize the use cases </li></ul>

37.
Cheat Sheet <ul><li>http://www. slingcode .com/ref/ UseCaseQuestions . pdf </li></ul><ul><li>by Alistair Cockburn </li></ul><ul><li>author of a popular use case book: “Writing Effective Use Cases”, ISBN 0-201-70225-8, ISBN 978-0201702255 </li></ul>

38.
Use Case Best Practices

39.
7 Best Practices <ul><li>Scope the domain </li></ul><ul><li>Scope your use cases </li></ul><ul><li>Validate use cases </li></ul><ul><li>Define the requirements models </li></ul><ul><li>Determine the strategy to elicit requirements </li></ul><ul><li>Settle on a standard format for your uses cases </li></ul><ul><li>Develop a project glossary </li></ul>

40.
1. Scope the Domain <ul><li>Manage avoidable scope creep </li></ul><ul><li>Be flexible on unavoidable market and business condition changing </li></ul>

41.
How to name a Use Case <ul><li>Well named use cases </li></ul><ul><ul><li>enable business customers (or any readers) to easily infer who the actor is </li></ul></ul>What’s in a name ?

42.
Best practices (1) <ul><li>action verb + [qualified] object </li></ul><ul><ul><li>place order, request product or service </li></ul></ul><ul><li>avoid vague verbs, such as do or process </li></ul><ul><li>avoid low-level, database oriented verbs, such as create, read, update, delete </li></ul><ul><li>The “object” part of the use case name can be a noun, (such as inventory), or a qualified noun (such as in-stock inventory ) </li></ul>

43.
Best Practices (2) <ul><li>make sure the project glossary defines the object </li></ul><ul><li>Add each object to the domain model (as a class, entity, or attribute) </li></ul><ul><li>Bring forth actors and use cases concurrently and associate them </li></ul>

44.
2. Scope Your Use Cases <ul><li>A use case </li></ul><ul><ul><li>addresses a single actor goal </li></ul></ul><ul><ul><li>is not overly complex </li></ul></ul><ul><ul><li>avoid partial processes in the business </li></ul></ul><ul><ul><li>avoid CRUD (create-read-update-delete) </li></ul></ul><ul><ul><li>avoid separate use cases for alternative courses </li></ul></ul>

45.
2. Scope Your Use Cases <ul><li>Frame each use case with: </li></ul><ul><ul><li>triggering events </li></ul></ul><ul><ul><li>event responses </li></ul></ul>

46.
2. Scope Your Use Cases <ul><li>Different kind of events: </li></ul><ul><ul><li>Business Events: </li></ul></ul><ul><ul><ul><li>subject + verb + object </li></ul></ul></ul><ul><ul><ul><li>for eq: “Customers requests book” </li></ul></ul></ul><ul><ul><li>Temporal Events: </li></ul></ul><ul><ul><ul><li>time to <verb + object> </li></ul></ul></ul><ul><ul><ul><li>for eq: “ Time to generate report” </li></ul></ul></ul>

47.
2. Scope Your Use Cases <ul><li>Context diagram: </li></ul><ul><ul><li>simple diagram </li></ul></ul><ul><ul><li>system as a single ‘black box’ </li></ul></ul><ul><ul><li>actors “give” or “get” something to or from the system </li></ul></ul>

48.
3. Validate Use Cases <ul><li>Questions to validate: </li></ul><ul><ul><li>help achieve goals and visions ? </li></ul></ul><ul><ul><li>address the problem ? </li></ul></ul><ul><ul><li>key differentiator ? </li></ul></ul><ul><ul><li>address all stakeholders ? </li></ul></ul><ul><ul><li>priority for initial release ? </li></ul></ul>

49.
4. Define the Requirements Model <ul><li>acts as a blueprint </li></ul><ul><li>primary purpose to communicate </li></ul><ul><li>discovery process </li></ul><ul><li>emphasize on one view </li></ul><ul><li>multiple model => separation of concerns </li></ul>

50.
4. Define the Requirements Model <ul><li>Multiple views: </li></ul><ul><ul><li>use cases: behavioral </li></ul></ul><ul><ul><li>class diagram: structural </li></ul></ul><ul><ul><li>statechart diagram: dynamic (lifecycles) </li></ul></ul><ul><ul><li>business rules: control </li></ul></ul>

51.
5.Determine Your Elicitation Strategy <ul><li>One-on-one or groups interviews </li></ul><ul><li>Facilitated workshops </li></ul><ul><li>Generate list of scenarios </li></ul><ul><li>Reuse existing requirements </li></ul><ul><li>Prototype user interface </li></ul><ul><li>Observe end users </li></ul><ul><li>Focus groups </li></ul><ul><li>Market surveys </li></ul><ul><li>Regulations and procedures </li></ul><ul><li>Customer complaints, help desk logs </li></ul><ul><li>Competitive analyses </li></ul>

52.
5. Determine Your Elicitation Strategy <ul><li>Commercial software: market surveys, on-site visits, facilitated workshops </li></ul><ul><li>In-house business system with large user base: review help desk logs, reusing existing requirements, workshops </li></ul><ul><li>Smaller user base: facilitated workshops and observation. </li></ul>

53.
6. Settle on Standard Format <ul><li>use case name only (“verb + [qualified] object”) </li></ul><ul><li>use case name and a single-sentence goal statement </li></ul><ul><li>use case brief description (2 to 5 sentences) </li></ul><ul><li>use case outline (bulleted or numbered list of use case steps, with alternative flows outlined separately or not listed at all) </li></ul>

54.
6. Settle on Standard Format <ul><li>Use case conversational format (use case header information plus two columns – one for actors and one for system responses – written in a conversational style) </li></ul><ul><li>Use case description (a sequential, conversational, or narrative text description that includes normal path, alternative, exceptions and extensions) </li></ul>

56.
7. Develop Glossary <ul><li>communication gaps between software vs business people </li></ul><ul><li>each side has its acronyms and jargon </li></ul><ul><li>glossary should be a living, vital part </li></ul>

57.
USE CASE Modeling

58.
Use case Modeling <ul><li>Use case is a text form </li></ul><ul><li>Use case diagram provides an index to use cases </li></ul>

59.
Actor <ul><li>Someone or something outside the scope of the use case that initiate the use case </li></ul><ul><li>May trigger or recipient of the use case </li></ul>

60.
Actor / Use case Associations <ul><li>relationship between an actor and a use case </li></ul><ul><li>actor initiates the use case </li></ul><ul><li>use case provides the actor with results </li></ul>

61.
Generalization <ul><li>To express some high-level functional need of a system </li></ul><ul><li>“ a kind of” relationship </li></ul>

62.
Inclusion <ul><li>Higher-level use cases may call ( includes) lower-level use cases </li></ul>

63.
Extension <ul><li>An alternate route to the main success scenario. </li></ul><ul><li>Extension point: the point it exits the originating use case </li></ul><ul><li>Return point: the point at which it returns </li></ul>Abort Transaction Trigger : any time in Buy Ticket the Car Driver can abort the trans. Main Success Scenario 1. The Ticket Machine returns the coins that have been entered

64.
User Stories Scrum methodology

65.
What is a User Story ? <ul><li>A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software </li></ul>

66.
User Story Description <ul><li>As a [user role] I want to [goal] so I can [reason] </li></ul><ul><li>For example: </li></ul><ul><li>As a registered user I want to log in so I can access subscriber-only content </li></ul>

67.
How detail should a User Story be ? <ul><li>Detailed enough </li></ul><ul><li>Detailed enough for the team to work from, and further details to be established and clarified at the time of development. </li></ul>

68.
User Stories Summary <ul><li>User Stories combine written and verbal communications, supported with a picture where possible. </li></ul><ul><li>User Stories should describe features that are of value to the user, written in a user’s language. </li></ul><ul><li>User Stories detail just enough information and no more. </li></ul><ul><li>Details are deferred and captured through collaboration just in time for development. </li></ul><ul><li>Test cases should be written before development, when the User Story is written. </li></ul><ul><li>User Stories need to be the right size for planning. </li></ul>

69.
Use Case vs User Stories When to use What

70.
Structured Requirements <ul><li>Goals are achieved through use cases </li></ul><ul><li>Use cases are enabled by functional requirements </li></ul><ul><li>Functional requirements lead to design and implementation. </li></ul><ul><li>Non-functional requirements characterize how functional requirements must work. </li></ul><ul><li>Constraints restrict how functional requirements may be implemented </li></ul>source: Software Requirements, 2 nd Edition, Karl E Wiegers

71.
Documentation Overhead source : http://tynerblain.com

72.
What are the differences ? <ul><li>Formal use cases require the most effort </li></ul><ul><ul><li>Describe all permutations </li></ul></ul><ul><li>Informal use cases are pretty much the same - just less formal </li></ul><ul><ul><li>Need the right level of detail </li></ul></ul><ul><li>Use case briefs have almost no overhead </li></ul><ul><ul><li>Same challenges “how much is enough ?” </li></ul></ul><ul><li>User stories have the least overhead, and provide the least context. </li></ul>

73.
Level of Details captured source : http://tynerblain.com

74.
Level of Reader expertise source : http://tynerblain.com

75.
References <ul><li>Ellen Gottesdiener, “Use Cases: Best Practices”, IBM, 6/11/2003 </li></ul><ul><li>Jan Kettenis, Getting Started With Use Case Modelling, An Oracle White Paper, March 2005 </li></ul><ul><li>Dan Pilone, UML 2 in A Nutshell, O’Reilly </li></ul><ul><li>http://tynerblain.com/blog </li></ul>

76.
Q&A