Deliverable #3
Identified Use Cases
Authored Use Cases
Agreed Use Cases
Finish with Requirements…..
Requirements and Analysis



Wish to finish up Requirements
Artifacts: Complete Requirements Specification
Use Cases + Supplementary Specs = Requirements
Specifications

Can drive the entire development process




Through Analysis and Design and Implementation
Through Verification and Acceptance
Use Cases ARE A Requirements Tool
Data Flow Diagrams

Much Older technology – still of immense value though…


Used for Requirements and Analysis (Logical DFDs)
Used to support Design and Implementation (Physical DFDs)
Life Cycle of a Use Case




Use Cases – series of transformations; mature
through development stages.
Different presentation approaches at different
points in the use case’s evolution.
Mistaken impression: Use Cases are a
development (analysis, design, implementation)
artifact rather than a requirements one
Use Cases are used extensively in Analysis and
Design (via Use Case Realizations), but they
are not a Design Artifact.
Will Look At:



1. Software Development: how the use case
is reflected throughout the full software
development cycle
2. Use Case ‘Authoring’ – how the use case
is reflected throughout the maturing process
3. Teamwork – the activities involved in
creating the use cases and how these impact
individual working practices.
1. Software Development Life Cycle using
Use Cases as Driver





Not originally part of traditional object-oriented
software development.
Over time, the importance to OO methods became
apparent.
Now, Use Cases are part of the UML.
“Use Case Driven”  use cases defined for a
system are the basis for the entire development
process.
Use Cases, thus, covers activities such as analysis,
design, implementation, and testing (all phases).
Life Cycle of Use Cases

A. Requirements




B. Development




Identified
Authoring
Agreed to
Analyzed
Designed
Implemented
C. Testing


Verified
Accepted
Use Cases – Life Cycle - Overview

A. Requirements:



Use cases evolve from Identified, Authored to
Agreed.
Evolves the glossary / domain model
Evolves supplementary specifications – contain
system-wide requirements not captured by the
use cases in particular.
Use Cases – Life Cycle - Overview

B. Development (analysis, design, implementation)

Analysis and Design





Use Cases are ‘realized’ in analysis and design models using
analysis and design objects...
Describes ‘how’ the use cases are performed in terms of
interacting objects in the model.
Contains subsystems and objects and how these parts need to
interact to perform the use cases.
Analysis and Design do not change the use cases, but indicate
that the use cases have been realized in the analysis and design
of the system.
Implementation (code and unit test…)

During implementation, the design model is the implementation
specification.


Use Cases are the basis for the design model and are implemented in
terms of design classes.
Once code has been written, the use case can be considered to be in
the implemented state.
Use Cases – Life Cycle - Overview

C. Testing: Verification and Acceptance



Use Cases constitute basis for identifying test
cases and test procedures to be verified.
Tests passed? Use Case can be considered to be
in the verified state.
Acceptance state reached when validated by user
acceptance testing.
2. Authoring Life Cycle - Overview


Many, many descriptions of the maturing of a
use case and many strong adherents to
various approaches
All approaches involve an evolution

Various names; evolve at different rates; various
stopping places depending on the degree to
which the use cases are to be used in the
software development.
Authoring – one approach: series of
‘states’

State 1: Discovered

Placeholder for what is to come


Visual index at most
State 2: Briefly described



E.g. This use case describes how a Customer uses the
system to view and purchase the products on sale. Products
can be found by various methods, including browsing by
product type, browsing by manufactgurer, or keyword
searches.
Sometimes this is as far as we need to go especially if
behavior is easily understood and can be expressed in the
form of a prototype more easily than words.
Other times, if behavior more complex, need more work…
Life cycles states continued

State 3: Bulleted Outline

Outline includes basic flow of events organized
sequentially.


Identify most significant alternatives / exceptions.


5 – 10 simple statements
Shows scale / complexity of the use case
Example:
Example of bulleted outline state:

Basic Flow: - get understanding of use case and complexity







Browse Products
Select Products
Identify Payment method
Identify shipping method
confirm purchase
Notice: verb…object
Alternative Flows












1.
2.
3.
4.
5.
Verifies scope; good for exploring ‘risks.’
1. Keyword search
2. no product selected
3. product out of stock
4. payment method rejected
5. shipping method rejected
6. product explicitly identified
7. order deferred
8. ship to alternative address
9. purchase not confirmed
10. confirmation fails
11, etc.
Notice: noun clauses. Condition.
State…
If use cases are to act as a specification for more formal analysis, design,
and testing, we need more detail.
Life cycles states continued

State 4: Essential Outline


Focus on the most important behavior and leave
out much detail.
Defining characteristic of this format:




Presents a pure, external ‘black box’ view of system.
Intentionally focuses on usability, ensures needs of user
are ‘up front.’ No details of what is ‘inside.’
Generally ignores specifics of the user interface (better
presented in prototypes and UI mock-ups – ahead).
Generally, a two-column format…
Example of essential outline state:

User Action





1. Browse product
offerings
2. Select items for
purchase
3. Provide payment
instructions
4. Provide shipping
instructions
5. Complete transaction

System Response





1. Display product
offerings
2. Record selected
items and quantities
3. Record payment
instructions
4. Record shipping
instructions
5. Record transaction
and provide receipt
Comments at this point

Note: Many uses cases may stop prior to this.


Essential Use Cases are for the most important use
cases in the system.





Some may skip this stage and go to next stage…
These descriptions are likely to evolve.
Essential Use Cases – very effective for facilitating
user-interface and user-experience analysis and
design.
Beware: too much detail can constrain the UI
designers; don’t force designers to a particular
technology or mode of interaction.
As usual, some recommend use case authoring stop
here at the essential outline stage.
But if Use Cases are to drive other aspects of
development, more is needed…
Life cycles states continued

State 5. Detailed Description




Complete the specification of the system.
Description may be in a conversational form or a narrative
form.
In state 5, we add detail to the outline. More and
more detail is added.
IF the use case has a strong sense of dialog
between actor and system, then the description
might be expressed in conversational form;
otherwise, narrative form.
Forms for Detailed Description State

Conversational Form



Great for cases where actor does something and
system does something back in response.
Especially good for where this is a single actor
engaged in interactive dialog.
Difficult to use when there is more than one actor
(frequent in real business systems) or when there
is a single actor and complex responses…
Note the differences in the system response.
(Conversational Form)

User Action

System Response

1. Browse product offerings


2. Select items for purchase


3. Provide payment instructions

4. Provide shipping instructions



5. Complete transaction

1. Display product offerings, showing
categories selected by the user
2. For each selected item in stock, record
selected items and quantities reserving
them in inventory.
3. Record payment instructions capturing
payment terms and credit card type, number,
and expiration date using a secure protocol.
4. Record shipping instructions, capturing
billing address, shipping address, shipper
preferences, and delivery options.
5. Record transaction and provide receipt
containing a list of the products ordered,
their quantity and prices, as well as the
billing and shipping addresses and the
payment terms. The credit card information
should be partially omitted, displaying only
the last four digits of the credit card number.
Notice attributes captured. This is where we are and this is where
We need to go for Deliverable #3 – among other things. More details
(attribute capture) and elaboration on alternate paths, as appropriate.
Forms for Detailed Description State

Narrative Form:


Here, outline can be expanded by adding detail
but the tabular format is replaced by a more
narrative description.
Most common form and more flexible, as it
supports ongoing evolution of the use case, with
additional subflows….
Note the differences in the system response.
(Narrative Form)

The narrative form of the use case Browse Products and Place Orders

1. The use case starts when the Customer selects to browse the catalogue of the
product offerings. The system displays the product offerings showing the
categories selected by the Customer

2. The Customer selects the items to be purchased. For each selected item that
is in stock, the system records the items and quantity required, reserving them in
inventory.

3. The system prompts the Customer to enter payment instructions. Once
entered, the system records payment instructions, capturing payment terms and
credit card type, number, and expiration date using a secure protocol.

4. The system prompts the Customer to enter shipping instructions. Once
entered, the system records the shipping instructions, capturing billing address,
shipping address, shipper preferences, and delivery options.

5. The system prompts the Customer to con firm the transaction. Once
confirmed, the system records the transaction details and provides a receipt
containing a list of the products ordered, their quantity and prices, as well as the
billing address, shipping address, and payment terms. Credit card information is
partially omitted, displaying on the last four digits of the credit card number.
Comments on Detailed Description




Most common ‘last’ state – as use case
efforts ‘run out of steam.’
Unfortunately, detailed description loses
benefits of brevity and succinctness offered
by bulleted and essential outline.
Also lacks details required of ‘fully-featured’
requirement specifications.
Last state: not fully specified:
Life cycles states continued

State 6 – Fully Described




Use Case has complete flow of events, has all terminology fully
defined in supporting glossary, and unambiguously defines all of the
inputs and outputs involved in the flow of events.
Fully described use cases are:
 Testable – sufficient info to enable test formation
 Understandable – can be understood by all stakeholders
 Unambiguous – Use case has only one interpretation
 Correct – All information is actually requirements information
 Complete – Nothing missing from the use cases.
 All terminology used is defined. Flow of events and all other
use cases properties are defined.
 Attainable – System can be actually created.
Support other software development activities: analysis, design, and
testing.
Test: Pass onto analysis/design team for analysis and design, and to
the test team for test design. If teams are satisfied, your use cases
contain sufficient detail.
Example of Fully-Described state:


An extract from the fully described use case Browse Products and
Place Orders
Basic Flow:


{Display Product Catalogue}



3. The Customer selects a product to be purchased entering the number of
items required.
4. For each selected item that is in stock, the system records the product
identifier and the number of items required, reserving them in inventory and
adding them to the Customer’s shopping cart.
{Out of Stock}


2. The system displays the product offerings highlighting the product
categories associated with the Customer’s profile
{Select Products}


1. The use case starts when the actor, Customer, selects to browse the
catalogue of product offerings.
5. Steps 3 and 4 are repeated until the Customer selects to order the
products.
{Process the Order}




6.
7.
8.
9.
The system prompts the Customer to enter payment instructions.
The Customer enters the payment instructions.
The system captures the payment instructions using a secure protocol
Perform Sub-flow Validate Payment Instructions.
Use Case Modeling Process – Team Efforts
1 of 2


Use Case model cannot be fully developed by doing all
as a group – quite the contrary.
Do a lot together in the beginning to establish the project
vision - scope and identify and describe use cases. Get
agreement on the problem to be solved.





Get the use cases identified and briefly described.
Complement this with an initial draft of the key supplementary
specifications and an outline glossary or domain model.
At this time – no need to fully detail any of the use cases,
although it is a good idea to have identified a majority of
significant alternative flows for each.
Need to scope the project – this is what we are doing...
This can be done in workshops….
 Most healthy projects can then break up for individual
authoring
Use Case Modeling Process – Team Efforts
2 of 2

Prioritize use cases based on
 Customer priority – value placed on use cases by stakeholders…- rank
them!
 Architectural significance - to reduce risk; and drive the architecture.
 Initial Operational Capability – set of use cases that would provide initial
functionality to enable the system to be used.
 Normally, the basic functionality of the majority of the use cases will
be needed to provide a working system – not necessarily true for all
of the alternative flows…
 Used to order the work – break use cases into Packages (subsystems
containing use cases or parts of use cases…)
 Again, helps to order development; controls scope; might be
needed for confidentiality …
 No need to wait for all to stabilize to ‘press on’ with certain
packages…
 Those packages having greatest risk should be up front!