From Use case to User Story

From Use Case to User Stories

FROM USE CASE
to USER STORIES

discuss background, and explain about segments and at the end of each segments I will pause for any discussions

Use Case

Introduction

Here is how we visualize a software project

Why are Requirements important

1/3 budget to correct errors originate from requirements

Defining requirements is crucial to all project stakeholders

Many techniques and models available

USE CASE MODEL

Typical software projects spend roughly one-third of their overall budget correcting errors that originate in requirements

project stakeholders such as clients, end users, develoeprs, testers and managers

Years of experience led to development of a number of techniques and models to assist the process

Use case model is the most well-known

Why should you be interested ?

IDEO Story:

Biker water bottle heart valve

Multidiscipline cooperation

You might say that this is more for the IT folks, that is not completely true.Example is IDEO story.How innovation is produced from multidiscipline cooperationYou will also be involved from .

What are Requirements

It covers :

Functional requirements

User requirements

Nonfunctional requirements

Quality attributes: performance, security, archiving, database

definedoperationalcapabilities

businessneeds

satisfy

To understand Use Case, first lets take a look at Requirements.Requirements are the defined operational capabilities of a system or process that must exist to satisfy a business need.User requirements: tasks that users need to achieve using the software.

Software Requirements

Three perspectives:

Business level

User level

Technical level

Requirements dont come out of thin air.They are products of systematic discovery and definition process where analyst plays a key role.Software requirements came from process of thinking through three perspectives of requirements.

Business Level

Define the vision

Build the right software

Define project stakeholders:

including direct users (actors)

At the highest level (or business level), you begin by understanding and clarifying the business goals and objectives. Then you define the vision on how to achieve it. You ensure that you will build the right software. In addition, you also define the correct project stakeholders.

User Level

Use cases :

voice of customers

consists of :

interaction

has name

step-by-step

exception conditions

variant paths

This is where use cases come in.Use cases is the interaction between an external actor and the system

Technical Level

Technical requirements:

Functional requirements based on user requirements

Nonfunctional requirements

Technical requirements include functional requirements based on user requirements and nonfunctional requirements

Use Case

Concepts and Definitions

Use Case

Describes how the system should respond under various conditions to a request from one of the stakeholders to deliver a specific goal.

stakeholder = primary actor

Use cases are fundamentally a text form. The scenario describes how the system should respond to a request of a primary actor to deliver a specific goal of that actor.

Use Case

The use case is primarily done in the form of a scenario that describes a sequence of steps.

Each use case captures a contract for the behavior of the System under Discussion (SuD) to deliver a single goal.

Actors

Anyone or anything with behavior.

Generally is a role (rather than a specific person, job title or a thing)

Not every stakeholder will show up

Important to discover these hidden actors

(bullet points first)Incidentally actor can be a person, job title or a thing, although generally it is a role The SuD is also an actor.

Primary Actor

Stakeholder that interacts with the SuD to achieve a specific goal

Supporting Actor

An (external) actor that needs to provide a service to the SuD

A primary actor for one use case can become a supporting actor for another

Scenario

sequence of steps

fulfill a goal

A scenario describes a sequence of steps that are executed in order to fulfill the goal the use case is supposed to deliver.

Scenario

Must be easy to read

Avoid more than nine steps

Use active voice

Stating who or what is doing what

Approver approve a task

The approver open My Tasks

The approver choose a task

The approver approves the task

The system returns the approver to My Tasks list

Main Success Scenario

Everything goes as planned

Happy Path

Extensions

Exceptions that requires a deviation from the planned scenario

Exceptions documented as extension

Extensions

Approver approve a task

Main Success Scenario

The approver open My Tasks

The approver choose a task

The approver approves the task

The system returns the approver to My Tasks list

Extensions

3a The task has been approved by another approver

3a1 The system returns error message to the approver

3b The approver decides to postpone the approval process

3b1 The approver click the Back button

3b2 The system returns the approver to My Tasks list

Use Case Properties

Design Scope

Stakeholder

Primary Actor

Description

Level

Pre-conditions

Post-conditions

Trigger

We just discussed about some of the use cases components, now well look into the detail of different properties of the each use case

Design Scope

Definition of the boundary of the System Under Discussion (SuD)

Set of systems that will be designed

Design Scope

A business use case has enterprise as its scope and focus on business flow

A system use case has computer system as its scope and focus on how actors communicate with the system

A component use case has subsystem or component of the system as its scope

There are different scope depends on the type of use cases

Use Case Level

Summary (cloud level or kite level)

outlines the context of a set of User Goal use cases

User Goal (sea level)

addresses Can the primary actor go away happily after the use case finished ?

Subfunction (under water level)

created to move out an isolated part of a scenario to a separate use case

source: Alistair Cockburn, Writing Effective Use Cases

From Alistair Cockburn.

Use Case level

Summary

User Goal

Subfunction

Stakeholder & Primary Actor

Stakeholder:

someone / something that has an interest in the goal of the use case delivers

Primary Actor:

the stakeholder who or which initiates the use case to achieve a goal

Description

Brief description of the goal the use case supposed to deliver

Preconditions

conditions that must hold true before the scenario of the use case starts

will not be checked again after that

Post conditions

Minimal Guarantees

What at least should hold true when the goal is not met

Example:

All entered information have been stored.

Success Guarantees

What must have been achieved at the end of the main success scenario or any alternate route.

Example:

The task is approved

Trigger

event or sequence of events that initiate the use case

Use cases

Process Flow

How do we develop use cases

Develop in Iterations

Identify all actors and their goals

Use MoSCoW list to define the scope of the project.

Set up Actor-Goal List

MoSCoW List

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

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

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

Won't Have: The full name of this category is Would like to have but Wont Have during this timebox; requirements in this category will not be delivered within the timebox that the prioritisation applies to

Actor-Goal List

LFind unfinished task and reject itReject unfinished taskSupportHReceive request and approve itApprove RequestApproverHMake change in edit group and send itSubmit Change RequestRequestorPrioBrief DescriptionsGoalsActor

example is shown in the table

Recipe

Identify the actors

List their goals

Add brief descriptions to the goals

Create an initial use case for each goal

Describe the main success scenario for each use case

Identify the exceptions to the main success scenario and work them out as extension

Validate the use cases

Optimize the use cases

Cheat Sheet

http://www.slingcode.com/ref/UseCaseQuestions.pdf

by Alistair Cockburn

author of a popular use case book: Writing Effective Use Cases, ISBN 0-201-70225-8, ISBN 978-0201702255

Use Case

Best Practices

7 Best Practices

Scope the domain

Scope your use cases

Validate use cases

Define the requirements models

Determine the strategy to elicit requirements

Settle on a standard format for your uses cases

Develop a project glossary

1. Scope the Domain

Manage avoidable scope creep

Be flexible on unavoidable market and business condition changing

scope creep: scope of the projects expands as the work proceeds

requirements may change because of changing market and business conditions -> unavoidable

manage the avoidable scope creep

How to name a Use Case

Well named use cases

enable business customers (or any readers) to easily infer who the actor is

Whats in a name ?

The first step is to just name the use cases, and not the details

Best practices (1)

action verb + [qualified] object

place order, request product or service

avoid vague verbs, such as do or process

avoid low-level, database oriented verbs, such as create, read, update, delete

The object part of the use case name can be a noun, (such as inventory), or a qualified noun (such as in-stock inventory)

best practice on how to give a name

Best Practices (2)

make sure the project glossary defines the object

Add each object to the domain model (as a class, entity, or attribute)

Bring forth actors and use cases concurrently and associate them

elicit: to draw or bring out or forth; educe; evoke: to elicit the truth; to elicit a response with a question.

2. Scope Your Use Cases

A use case

addresses a single actor goal

is not overly complex

avoid partial processes in the business

avoid CRUD (create-read-update-delete)

avoid separate use cases for alternative courses

This is different than the Design Scope


Frame each use case with:

triggering events

event responses

trigger: customer wants money, responses: ATM gave out the money


Different kind of events:

Business Events:

subject + verb + object

for eq: Customers requests book

Temporal Events:

time to

for eq: Time to generate report


Context diagram:

simple diagram

system as a single black box

actors give or get something to or from the system

a context diagram is a simple diagram that represents the system as a single black box surrounded by its major interfaces, thus showing the system in its environment.

3. Validate Use Cases

Questions to validate:

help achieve goals and visions ?

address the problem ?

key differentiator ?

address all stakeholders ?

priority for initial release ?

Ensure that each one is necessary to meet the business opportunities in your product vision.

To validate, answers the following questions;

How does this uc help us achieve our goals and visions

Does this use case address some aspect of the problem in our problem statement ?

Does this use case differentiate our product in some way ?

Do we have use cases to address all the stakeholder and user groups we identified in our vision statement

Which use cases will be implemented in our initial release ?

4. Define the Requirements Model

acts as a blueprint

primary purpose to communicate

discovery process

emphasize on one view

multiple model => separation of concerns

A requirement model is a set of models which acts as a blueprint for a software product.Example are: event lists, use cases, context diagrams, data models, business rules, actor maps, storyboardsDefining requirement is a discovery process for users and customers. It evolve from the process of users trying out their requirements through models.Using multiple views (behavior, structure, dynamics, or control) gives a rich context for eliciting user requirements and aligns with separation of concerns.

4. Define the Requirements Model

Multiple views:

use cases: behavioral

class diagram: structural

statechart diagram: dynamic (lifecycles)

business rules: control

5.Determine Your Elicitation Strategy

One-on-one or groups interviews

Facilitated workshops

Generate list of scenarios

Reuse existing requirements

Prototype user interface

Observe end users

Focus groups

Market surveys

Regulations and procedures

Customer complaints, help desk logs

Competitive analyses

5. Determine Your Elicitation Strategy

Commercial software: market surveys, on-site visits, facilitated workshops

In-house business system with large user base: review help desk logs, reusing existing requirements, workshops

Smaller user base: facilitated workshops and observation.

6. Settle on Standard Format

use case name only (verb + [qualified] object)

use case name and a single-sentence goal statement

use case brief description (2 to 5 sentences)

use case outline (bulleted or numbered list of use case steps, with alternative flows outlined separately or not listed at all)

The list is with order of increasing complexity

6. Settle on Standard Format

Use case conversational format (use case header information plus two columns one for actors and one for system responses written in a conversational style)

Use case description (a sequential, conversational, or narrative text description that includes normal path, alternative, exceptions and extensions)

A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?" The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field." "You must be a software developer," says the balloonist. "I am," replies the man. "How did you know?" "Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone." The man below says, "You must work in business as a manager." "I do," replies the balloonist, "but how did you know?" "Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."

7. Develop Glossary

communication gaps between software vs business people

each side has its acronyms and jargon

glossary should be a living, vital part

USE CASE

Modeling

Use case Modeling

Use case is a text form

Use case diagram provides an index to use cases

Actor

Someone or something outside the scope of the use case that initiate the use case

May trigger or recipient of the use case

Actor / Use case Associations

relationship between an actor and a use case

actor initiates the use case

use case provides the actor with results

conventionally you read use case diagrams from left to right, with actors initiating use cases on the left and actors that receive use case results on the right. Also put primary actor on the top.

Generalization

To express some high-level functional need of a system

a kind of relationship

When use case A specializes use case B (or B generalizes A) you express that A is a kind of B, implying that whatever applies to B also applies to A. A adds to or may override behavior of B.

Inclusion

Higher-level use cases may call (includes) lower-level use cases

A typical example is a Summary use case that includes User Goal use cases, or User Goal use case that includes some reusable Subfunction use case. The included use case is typically not complete on its own and is required part of the larger use cases.

Extension

An alternate route to the main success scenario.

Extension point: the point it exits the originating use case

Return point: the point at which it returns

Abort TransactionTrigger: any time in Buy Ticket the Car Driver can abort the trans.Main Success Scenario1. The Ticket Machine returns the coins that have been entered

User Stories

Scrum methodology

What is a User Story ?

A concise, written description
of a piece of functionality
that will be valuable to a user
(or owner) of the software

User Story Description

As a [user role] I want to [goal]
so I can [reason]

For example:

As a registered user I want to log in
so I can access subscriber-only content

How detail should a User Story be ?

Detailed enough

Detailed enough for the team to work from,
and further details to be established and clarified
at the time of development.

User Stories
Summary

User Stories combine written and verbal communications, supported with a picture where possible.

User Stories should describe features that are of value to the user, written in a users language.

User Stories detail just enough information and no more.

Details are deferred and captured through collaboration
just in time for development.

Test cases should be written before development,
when the User Story is written.

User Stories need to be the right size for planning.

Use Case vs User Stories

When to use What

Structured Requirements

Goals are achieved through use cases

Use cases are enabled by functional requirements

Functional requirements lead to design and implementation.

Non-functional requirements characterize how functional requirements must work.

Constraints restrict how functional requirements may be implemented

source: Software Requirements, 2nd Edition, Karl E Wiegers

Karl Wiegers Structured Requirements Software Requirements, 2nd Edition, Karl E. Wiegers.

Documentation Overhead

source: http://tynerblain.com

See next screen. Formal and informal use cases describes different permutations. Use case brief may use single paragraph. User stories provides the least context.http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/comment-page-1/#comment-497898

What are the differences ?

Formal use cases require the most effort

Describe all permutations

Informal use cases are pretty much the same - just less formal

Need the right level of detail

Use case briefs have almost no overhead

Same challenges how much is enough ?

User stories have the least overhead, and provide the least context.

http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/Use case briefs may be a single paragraph use case

Level of Details captured


User stories, as it has less overhead of documentation, it also captures less detail. It is ok with assumption the communication is high. At some point it becomes inefficient.

Level of Reader expertise


The level of conversation will be influenced by the level of the reader domain expertise. If the reader already understand the requirements, user stories might be enough. When the developer team struggles to implement the stories, then a more structured documentation is needed. Can the writer trust the reader will understand with brief information ?

References

Ellen Gottesdiener, Use Cases: Best Practices, IBM, 6/11/2003

Jan Kettenis, Getting Started With Use Case Modelling, An Oracle White Paper, March 2005

Dan Pilone, UML 2 in A Nutshell, OReilly

http://tynerblain.com/blog

Q&A

Technology

From Use case to User Story