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
Identifying
use cases (in the initiation phase)
Describing
use cases (in the elaboration and construction phases)
Implementing
use cases (in the construction and transition phases)
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.
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.
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.
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.
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.