Processes, use cases and user stories

Copyright 2014-17 Graham Berrisford.

One of about 300 papers at http://avancier.website. Last updated 15/01/2020 11:47

 

New to the web site above?

This paper supports a short session in our ESA training courses.

Click here for a slide show on use case (aka epic) description.

Contents

Processes in general 1

Use case and user stories. 1

Identifying use cases (in the initiation phase) 1

Describing use cases (in the elaboration and construction phases) 1

Implementing use cases (in the construction and transition phases) 1

 

Processes in general

A use case or user story is process in which an actor uses a computer application.

So what is the difference? It helps to know a little more about processes in general.

 

A system is a collection of repeatable processes that interact to achieve some goal(s).

A process runs from start to end (or cyclically), for example.

 

·       Schedule a train service from station A to station B.

·       Run a scheduled train from station A to B.

·       Book a train seat

·       Enter from and to stations for a train journey.

·       Pay for a train seat.

 

A process is performed by one or more actors.

It usually consumes some input and produces some output.

It meets a goal, or produces a result of value on the way to meeting a higher-level goal.

The convention is to name a process (be it short or long) after its end result, value or goal.

 

Processes are decomposable into shorter processes and composable into longer processes.

A shorter-running process may yield a result of a smaller value, which contributes to the end goal of a longer-running process.

 

Documenting a process in a service contract

Every designed process is describable in the same logical way.

If its preconditions are true, and the process completes successfully, then its post conditions will be true.

Every process has other non-functional quality attributes

These conditions and attributes can be documented in a “service contract” of this kind.

·       Signature (name, inputs, outputs)

·       Functional rules (preconditions and post-conditions)

·       Non-functional requirements (duration, throughput, availability, security, etc.).

 

Documenting the control flow of a process

There are many ways to document the end-to-end step-by-step logic of a process.

There are diagrams, including informal value stream diagrams, flow charts and sequence diagrams.

And narrative forms, including use case templates.

Use case and user stories

The focus here is on enterprise/business application systems used by external entities.

A use case or user story is a process at the boundary between an application and an external entity.

It is a process in which an external entity (human or computer) uses a computer application.

 

In the example below, the same process is documented first as a user story and then as a use case.

In other examples, a user story may correspond to only one step in a longer use case (or epic).

 

Documenting a user story

A user story is typically captured on a card in the form:

As an actor in this role

I want to perform this process

so as to reach or enable this outcome.

 

All of the processes listed above can be expressed in this form, though not all are typical of user stories.

As an actor in this role

I want to perform this process

so as to reach or enable this outcome.

Train scheduler

Schedule a train service

Advertise the service to customers

Train operator

Run a scheduled train

Provide the service customers have ordered

Customer

Book a train seat

Travel from one station to another station

Customer

Enter from and to stations

Book the train journey I want to make

Customer

Pay for a train seat

Get the train ticket emailed to me

 

Documenting a use case

An application use case is a process that captures data from, and/or provides data to, an actor.

The template for a use case description may contain a section for each attribute of the process.

Role

Customer

Use case name

Pay for a train seat

Input data

Valid journey details

Output data

A seat ticket document (pdf) is emailed to the customer

Preconditions

Valid journey details have been stored.

Post-conditions

A ticket sale will be recorded in our database

And recorded in payment service provider database

Duration

30 seconds

Throughput

1,000 per minute

Main path

Enter payment card details

Press “Pay now”.

Save ticket document

 

It looks above as though the use case is an elaboration of a user story.

But processes can be composed and decomposed.

 

Often, the actor is human, but it can be another application.

Typically, a use case supports a one-person-one-place-one-time step in a business process.

This OPOPOT rule of thumb is not scientific or unbreakable, but it is a useful guideline.

And often, a use story is often elaboration of one step in a use case.

 

How use cases and user stories are documented is one differentiator

But the difference between them is more to do with when and why they are defined.

Identifying use cases (in the initiation phase)

The initiation phase is where a system is scoped and development work is estimated.

It is completed before detailed analysis, design or development starts.

 

Uses cases

Naming use cases is a good way to define what is required of a whole application at a high level.

Ivar Jacobsen says an application should have between 1 and 99 use cases (it might have more user stories).

 

Architects, analysts and managers need a list of use cases, with non-functional measures.

Without that information, they cannot reliably estimate the time and cost of application development.

 

A use case diagram shows which user roles engage in which use cases.

It is a good way to show the scope of an application on one page.

It helps stakeholders to understand what the application will be designed to do.

It helps analysts and architects to identify input/output interfaces to human users and other applications.

 

User stories

It is not easy to define user stories in the initiation phase of an application development project.

It is more normal to start by identifying longer processes – aka scenarios or epics.

And to define these longer processes using story boards and/or use case descriptions.

 

Could you scope and estimate application development by capturing user stories?

You’d have to include user stories for non-human users and information provider applications.

And document non-functional requirements also.

And it is difficult to get users to tell their user stories before they can visualise the application in operation.

Describing use cases (in the elaboration and construction phases)

 

Use cases

Click here for a slide show on use case (aka epic) description.

A use case description may be completed during the elaboration phase of an application development project.

Or else, where agile development proceeds apace, uses cases may be documented alongside development in the construction phase.

 

Use case analysis is a step-by-step technique for analysing requirements and designing a human-computer interaction.

The steps could be as shown below.

 

1.     Identify and name the use

2.     Define the trigger, inputs, outputs of the use case

3.     Define the functional rules (preconditions and post-conditions)

4.     Define the non-functional requirements (duration, throughput, availability, security, etc.)

5.     Define the control low (the step by-step logic of the process)

 

The control flow is typically documented in two stages: first the main (happy) path, and then alternative or exception paths.

Often, it takes more time and effort to handle alternative/exception paths than the main path.

 

Use case description is done with application users and other stakeholders.

It may be done alongside a story board or other prototype that enables stakeholders to visualise the user interface

It is not usually concerned with how work might be assigned to developers.

A use case can be short or long; it might take several developers several weeks to complete, or might take one developer a few days.

 

Use stories

It is normal to define user stories in the context of a longer process or user interface.

Given the outline of a longer process, user stories can capture what users want to do at each stage.

Given a story board or user-interface, user stories can capture how users interact with user interface features.

For example, a user story may describe completing the from and to fields in the course of booking a train seat.

 

So, user stories are defined during application development and in application maintenance.

User story cards give developers a way of capturing requirements quickly.

Ideally, a user story can be developed and tested within one agile development “sprint”.

Which means that user stories become work packages assigned to developers.

 

User stories are usually concerned with what human actors want to do

This means automated interfaces between applications have to be specified in other ways.

Implementing use cases (in the construction and transition phases)

Both use cases and user stories are useful in the construction and transition phases of a project,

Use case descriptions are primary inputs to the definition of application system test cases.

User stories may be used for the same purpose, and (since they are simple and user-friendly) also for customer acceptance testing.

 

 

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.