Writing effective use cases
Download
1 / 34

Writing Effective Use Cases - PowerPoint PPT Presentation


  • 236 Views
  • Updated On :

Writing Effective Use Cases. Presenter Name: Marcia Stinson [email protected] Presented by Marcia Stinson Senior Consultant Ravenflow. Are Projects Really So Different?. All projects are different Different needs Different users All projects are the same

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Writing Effective Use Cases' - vance


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Writing effective use cases l.jpg

Writing Effective Use Cases

Presenter Name: Marcia Stinson

[email protected]

Presented by Marcia Stinson

Senior Consultant

Ravenflow


Are projects really so different l.jpg
Are Projects Really So Different?

  • All projects are different

    • Different needs

    • Different users

  • All projects are the same

    • All need clear requirements

    • All need a way to trace user requirements to the delivered product

    • The success of all projects is measured by the results the product provides


What are requirements l.jpg
What are Requirements?

  • A contract between development and users

    • What will be provided by the product

      • i.e. features or capabilities

      • What standards or regulations will be followed

    • How the user will use the product

      • User interactions with the system (use cases)

    • What will NOT be provided by the product

      • What is out of scope

NOTE: there is no mention here of format

or structure of the requirements.


Some say it s getting better but l.jpg
Some Say It’s Getting Better But…

  • Statistics published in 2006 and 2007 indicate that as “few” as 1/3 of projects are classified as failures (Communications of the Association for Computing Machinery, Nov 2007).

  • If true, this is certainly a big improvement over the 2004 Standish report that 2/3 of projects were classed as “challenged”.

  • However that is small comfort if you are part of the 1/3 or your company reallocated resources from your successful project to one that is failing.

  • The list of culprits is still familiar:

    • Lack of user input

    • Incomplete requirements and specifications

    • Changing requirements and specifications

    • Lack of executive support

    • Technology incompetence

    • Et al

  • Many systems claim to provide solutions to these problems but if we truly are still seeing 1/3 failure rates, we’re far from perfect.


The payoff for getting requirements right upfront l.jpg
The Payoff for Getting Requirements Right Upfront

  • Application projects that either fail or are considered less than successful

60%

More Successful Projects

  • Application projects that fall short of the intended return on investment

40%

Higher Project ROI

  • Application projects that are cancelled outright prior to completion

30%

Fewer Cancelled Projects

  • Percentage of total project cost due to rework resulting from poorly defined business requirements

Less Rework Costs

20%

  • Annual business cost (US) associated with requirements induced project delays

$30B

Higher Profitability

Source: Gartner, NIST, SEI, Standish Reports & Ravenflow analysis


The requirements lifecycle l.jpg
The Requirements Lifecycle

Inception

Mission

Analysis

System

Analysis

Development

Deployment

User

Acceptance

Testing

System

Capability

Testing

Unit Testing

Usually created by a

customer. Descriptive text,. Must be analyzed

and turned into requirements. (Word)

Requires discussions with end users. Defines high level user capabilities to be created or transformed by the system. Traced to user tests. (word, Visio, RM tool, RAVEN)

Defines how the system will perform the required functions. Traced to system tests. (Rhapsody, Word, RM Tool, Visio)

Detailed design to determine code modules and hardware components tha t need to be built. (Rational Rose, TAU, design tools)

A final set of requirements is archived and saved for future reference.

Requirements Artifacts

Concept of Operations

Business Request

Vision Document

System

Requirements

System models

Allocation tables

Technical Requirements

Detailed Design Database Design

Finalize all

Requirements

User

Requirements

Use Cases

Activity Diagrams


Some current development methodologies l.jpg
Some Current Development Methodologies

  • Water Fall Development

  • Iterative Development

  • Rational Unified Process (RUP)

  • Spiral Development

  • Rapid Application Development (RAD)

  • Agile Software Development

All methodologies go through the same phases of development.

Some are more formal than others.


Different views of a system l.jpg
Different Views of a System

System view

User/stakeholder view

A more technical and detailed view

of the system.

A view of the functions the system

must perform.

User’s perspective of the system.

Limited to what the user sees.

A very technical and detailed view of the items

that are built to create the system.

There is overlap

in the views.

There must be

some understanding

of other views at

all levels.

Technical view

More technical detail is added as each view of the system is developed.


Types of use cases l.jpg
Types of Use Cases

  • Business Use Cases

    • Describe how actor(s) perform a business process

      • Bomb threat procedure

      • Actors are typically organizations or departments

  • Application Use Cases

    • Describe how a user interacts with a system to perform a user process

      • Registering a credit card online

      • Actors are typically an end user and a system

  • System Use Cases

    • Describe how a system performs a function or how a system interacts with other systems

      • Validate ATM PIN

      • Actors are systems or subsystems

  • Technical Use Cases

    • Describe how a subsystem behaves to perform a system function or how a subsystem interacts with other subsystems

      • Communication between a cell phone and the cell tower


Types of use cases10 l.jpg
Types of Use Cases

Business Analyst

System Analyst

Business Use Cases

Detailed Use Cases

System/System Interactions

Details of System Functions

User/System Interactions

Bank Customer/ATM Machine

Driver/Automobile

Photographer/Camera

Caller/Cell Phone

ATM Machine/Bank

Automobile/GPS System

Camera/Memory card

Cell Phone/Cell Tower

Developer

Technical Use Cases

Subsystem/Subsystem Interactions

ATM Processor/Money Dispenser

Engine/Power Train

Autofocus/Light Metering System

Display/Internal Memory


What s so great about use cases l.jpg
What’s so great about use cases?

  • Technique for eliciting vaguely understood and unspoken requirements

  • Users can read and understand

  • Integrates with screen prototyping, user testing, system testing

  • Used to schedule incremental development

  • Inherent traceability

  • Facilitate reuse – developed and shared


Use cases are a form of requirements l.jpg
Use Cases are a Form of Requirements

  • User shall…..

  • User shall…..

  • User shall…..

The system displays the login screen

to the user.

The user sends login information to

the system.

.

Describes user interaction with the system

(Textual model)

List of formal requirements

(Textual representation)

User

System

Activity diagram

(Visual representation)


What is visual requirements definition l.jpg
What is Visual Requirements Definition?

Visual Requirements Definition (RD) complements Requirements Management (RM) solutions by enabling better:

  • Analysis of Customer RequirementsIdentify core processes and elicit the customer needs and requirements for optimizing the processes

  • Specification of Requirements Describe, organize, analyze and document processes & requirements in a consistent, business-oriented way

  • Validation of Requirements Share, collaborate, review and verify processes & requirements with all stakeholders from customers to development.



The flow diagram process l.jpg
The Flow Diagram Process

  • Identify all actors

  • Create one Flow Diagram for each Actor

    • List each capability the Actor will perform

    • Describe how capabilities fit in to the overall system design

      • Use arrows to indicate flow between capabilities

      • Add conditionals if they help understand how the system will work


From flow diagram to use cases l.jpg
From Flow Diagram to Use Cases

Each capability requires

at least one use case.

Log in

Register account

View account list

View Estatements

Transfer funds

Withdraw funds

Log off

YES

Is user

registered?

NO

Log in

Register

account

View

account

list

View

Estatement

Transfer

funds

Withdraw

funds

Log

off


Use case details l.jpg
Use Case Details

  • Defined through a sequence of steps

  • Each step produces a result

  • Are realistic representations of how the user will use the system

    • Give developers direct insight into how stakeholders envision using the system

    • Provide a basis for technical requirements

    • Provide a basis for acceptance testing

NOTE: Use cases are a form of requirements.


Basic use case guidelines l.jpg
Basic Use Case Guidelines

  • Active voice

  • Complete simple sentences

  • Clear transfer of control

  • Complete conditionals

  • Looping (Alternates)

  • Early termination of a use case (Exceptions)

  • Consistent level of detail


A poorly written use case why l.jpg
A Poorly Written Use Case – Why?

The Crisis Management Team sends an Emergency Alert. (to?)

The IT Team sends Emergency Alert Email to the Entire Organization!

The Crisis Management Team sends an Emergency Alert to the Security Organization.

The Security Organization performs a walk through of the facility.

If employees are found, (who looks for employees?)

then the Security Organization escorts the employees out of the building.

Otherwise, if the Security Organization finds no employees, then building is locked. (not active voice?)

(Otherwise, what happens if employees are not found?)

The Crisis Management Team sends an Emergency Alert to the Local Police.

RAVEN identifies requirements errors for you.


Keys to developing business use cases l.jpg
Keys to Developing Business Use Cases

  • Start with the simplest path (no problems)

    • Determine what can occur at each step and document the results

    • Document the other paths that can occur

    • Document resulting requirements (if required)

  • Keep the right level of detail

    • User actions only in user column

    • System responses that user sees in system column

      • Do not include system actions that the user does not see unless it is important to document additional steps. These will be developed during the system requirements phase.

  • Be careful to get Pre- and Post-Conditions right


Transitioning to detailed system use cases l.jpg
Transitioning to Detailed System Use Cases

Business

Use cases

Detailed System

Use cases

Business

Use Cases

User System

There is a process for getting from user focused use

cases to detailed system use cases.


Levels of use cases example l.jpg
Levels of Use Cases Example

Bank

Detailed

System

User

Payment

Processor

System

The System validates that payment amount is greater than zero.

The System validates

the payment information.

The user submits the payment to the System.

The System validates that payment amount is at least minimum payment.

The System validates that payment amount is less that current statement

Balance.

The System validates that date is less than 30 days from current date.

The Bank validates the

Account Information.

The System submits account information to the Bank.

The Bank sends account

Approval to the System.

The System submits

the payment.

The System submits the payment information to the Payment Processor.

The Payment Processor

accepts the payment.

The Payment Processor

sends confirmation

received message to the

System.

The System displays a payment confirmation message to the user.

The System displays a payment confirmation message to the user.


A use case example l.jpg
A Use Case Example

  • The user enters username and password. If the password is more than 30 days old, then the system asks the user to enter a new password. The user enters a password. If the password has been used in the last six months, then the password is not valid. The system performs a String function to determine the length of the password. The system loops through each character in the password and calls the TYPE function for each. The system determines if there is at least one character and one number in the password. If these tests all pass, then the password is valid. Otherwise, an error message is displayed. If the login is valid then the user is logged in to the system and views the account summary screen.


Correcting level of detail l.jpg
Correcting Level of Detail

Move these details to a system use case.

Validate Password -

If the password has been used in the last six months, then the password is not valid. The system performs a String function to determine the length of the password. The system loops through each character in the password and calls the TYPE function for each. The system determines if there is at least one character and one number in the password. If these tests all pass, then the password is valid.


Active voice l.jpg
Active Voice

  • The user enters username and password. If the password is more than 30 days old, then the system asks the user to enter a new password. The user enters a password. The system validates the password. If the password is not valid, then an error message is displayed. If the login is valid then the user is logged in to the system and views the account summary screen.

Items in RED indicate passive voice. We will correct these.


Corrected use case l.jpg
Corrected Use Case

  • The user enters username and password. If the system determines that the password is more than 30 days old, then the system displays a new password prompt. The user enters a password. The system validates the password. If the system determines that the password is not valid, then the system displays an error message. If the system determines that the login is valid then the system displays the account summary screen.


Transfer of control l.jpg
Transfer of Control

  • The user enters username and password and submits it to the system. If the system determines that the password is more than 30 days old, then the system displays a new password prompt to the user. The user enters a password in the system. The system validates the password. If the system determines that the password is not valid, then the system displays an error message to the user. If the system determines that the login is valid then the system displays the account summary screen to the user.


Complete conditionals l.jpg
Complete Conditionals

  • The user enters username and password and submits it to the system.

  • If the system determines that the password is more than 30 days old, then the system displays a new password prompt to the user. The user enters a password in the system. The system validates the password. If the system determines that the password is not valid, then t he system displays an error message to the user.

  • Otherwise, the system displays the account summary screen to the user.

  • Otherwise, the system displays the account summary screen to the user.


Test development l.jpg
Test Development

Requirements

Test Plans

Requirements (use cases) and test plans

should be developed together.

Test plans are not an afterthought.


Creating a test plan from a use case l.jpg
Creating a Test Plan from a Use Case

  • Actor steps become the test case step

  • Responses to those steps are the expected results

  • One test case for each “path” through the use case

    • Basic path

    • Conditionals (alternates and exceptions)

  • Use cases provide a good basis for determining:

    • Complexity of a use case

    • Level of effort required to validate the use case


Slide31 l.jpg

When is change embraced?

Pain of current situation

Pain of the change


A solid solution l.jpg
A Solid Solution

Advise

Your

People

  • Business analysis & requirements training certified by IIBA

  • Consulting & advisement from experienced practitioners

Transform

Your

Approach

  • A best practices methodology for getting requirements right

  • Works with both structured and agile development projects

Provide

the

Tooling

  • A suite of products for business & requirements analysis

  • Designed specifically for use during requirements definition phase of projects by all levels of system engineers


It s so complicated l.jpg
It’s so complicated….

Use Case

101

Use Case

Methodology

Use Case

Modeling

Use Case

Best Practices

How to

Write Use Cases

Or is it?? It takes discipline and determination.

Read. Learn. Determine how to fit use cases into your process.


Ravenflow professional services l.jpg
Ravenflow Professional Services

  • Professional Services Team

    • Business requirements experts

    • Best-practice advisory services

    • Specialists & practitioners in:

      • Requirements elicitation & definition

      • Business process improvement

      • Facilitation & stakeholder validation

    • Senior Consultants and Business Analysts

  • Training Services

    • Instructor-led on-site training classes

    • Train-the-trainer programs

    • Training curriculum includes:

      • Writing Effective Business Use Cases

      • Writing and Validating Requirements with RAVEN

      • Requirements Elicitation Techniques

      • RAVEN Administration & Management

      • Advanced Template Customization

  • Consulting Services

    • Requirements facilitation

    • Requirements definition process assessment and project review

    • Business process assessment, analysis, and improvement

    • Merger and acquisition integration

    • Staff augmentation


ad