requirement analysis with use case

REQUIREMENT ANALYSIS

WITH USE CASE

By Rapeepan Thawornwanchai

Nov 26, 2010

Agenda

The Trouble with Requirement

What is Requirement

Why requirement is so important

The challenges of requirement gathering

Issues with standard approaches

Moving to Use Cases

– Traditional modes of expressing functionality to users

– Introducing Use Cases (Diagrams and Template)

Requirement Analysis Example

Workshop

What is Requirement

A software capability needed by the user to solve a

problem to achieve an objective

A software capability that must be met or

possessed by a system or system component to

satisfy a contract, standard, specification, or other

formally imposed documentation.

WHEN FACED WITH WHAT THEY BELIEVE IS A PROBLEM, MOST OF

ENGINEERS RUSH INTO OFFERING SOLUTIONS

Alan M. Davis

Technical people often pay more attention to an entity

relationship diagram or class diagram than a

requirement list

The Goal

To develop quality software that meets customers’

real needs.

on time and

on budget

Questions & Doubts

Is this a desire or a requirement?

Is this a nice-to-have or a must-have?

Is this a statement of the problem or a statement

of the solution?

Is this a goal of the system or a contractual

requirement?

Do we have to program in Java? Says who?

Who is it that doesn’t like the new system, and where

was that person when we visited here before?

Function Points Probability of Termination Prior to Completion

100 6%

1,000 17%

10,000 45%

100,000 80%

Probability of Project Failure

Sources: Jones, C., Applied Software Measure: Assuring Productivity and Quality,

Second ed. McGraw Hill, 1996

Root Causes of Project Success and Failure

Standish Group asked survey respondents to identify the most significant factors that contributed to projects that were rated “success”, ”late and did not meet expectations”, and “fail”, respectively are related to requirements.

The Standish Group study noted the three most commonly cited factors that caused projects :-

To be “late and did not meet expectations” :

Lack of user involvement,

Incomplete requirements and specifications,

Changing requirements and specifications,

To be “fail” :

Unrealistic schedule or time frame,

Inadequate staffing and resources,

Inadequate technology skills,


The Standish Group found that

9% of the projects in large companies were delivered

on time and on budget;

16% of the projects in small companies enjoyed a

similar success.

33% of the software projects fail;

40% of the software projects come in late or over

budget.


What were the primary “success factors” for those

projects?

According to the Standish study, the three most

important factors were.

User involvement

Executive management support

Clear statement of requirements

It seems clear that requirements deserve their place

as a leading root cause of software problems.

Coding issues were a “nonproblem”

Why requirement is so important

Without requirements, there is no way to

validate a program design; that is, no way to

logically connect the program to the customer’s

desires.

BENJAMIN L. KOVITZ

Why is requirement management

important?

Requirements errors top the delivered defects and

contribute approximately one third of the total

delivered defects to the defect pile.

Requirements errors are likely to be:-

the most common class of error.

the most expensive errors to fix.

The High Cost of Requirements Errors

Two reasons for requirement errors turn out to be

particularly expensive,

1. The true nature of the error may be disguised;

everyone assumes that they’re looking for design errors

during the testing or inspection activities, and

considerable time and effort may be wasted.

2. By the time the requirements-oriented error is

discovered, the development group will have invested

time and effort in building a design from those erroneous

requirements or reworked.

The High Cost of Requirements Errors

Confirming the details of the requirements error

means tracking down the user who provided the

requirements details in the first place.

These problems associated with “leakage” of

defects from one lifecycle phase to the next are fairly

obvious when you think about them, but most

organizations haven’t investigated them very

carefully.

% of discovered the

requirements-oriented defects

Phase % of

discovered

Requirement Analysis 74%

Preliminary Design 4%

Detailed Design 7%

Coding and Testing 11%

Maintenance 4%

% of discovered the

requirements-oriented defects

Requirement Analysis phase

is the formal phase during which customers and systems analysts are

discussing,

brainstorming,

negotiating, and

documenting the project requirements.

is the ideal time and place to discover such errors, and it’s likely to be the most inexpensive time and place.

Example costs to repair the defect

Respecification.

Redesign.

Recoding.

Retesting.

Change Requests.

Corrective action.

Scrap

Code, Design, Test cases that had to be thrown away when they were based on incorrect requirements.

Recall of defective versions of shrink-wrapped software and associated manuals from users.

Warranty costs.

Product liability

If the customer sues for damages caused by the defective software.

Service costs for a company representative to visit a customer’s

field location to reinstall the new software.

Documentation.

Overview of problem/solution domains

Needs

Features

Software Requirement

Problem

Domain

Solution

Domain

What

How What

How

The Problem Domain

Most successful requirement journeys begin with a trip

to the land of the problem.

Problem domain is the home of real users and other

stakeholders, people whose needs must be

addressed in order for us to build the perfect system.

Stakeholder Needs

To build systems that meet user needs, it becomes our problem

to understand

their problems

their culture and

their language.

It is our responsibility to understand the needs of users and

other stakeholders whose lives will be affected by our solution.

As we elicit those needs, we’ll stack them in a little pile called

stakeholder needs, which we represent as a pyramid.

Needs

Moving the problem domain

toward the solution domain

In this solution space, we focus on defining a solution

to the user’s problem.

This is the domain of computers, programming,

operating systems, networks, and processing nodes.

Here, we can apply the skills we have learned much

more directly

Features of the System

Features of the system as

A service that the system provides to fulfill one or more

stakeholder needs.

This is not a very long list and consists of such items

as

“The car will have power windows.”

“Defect-trending charts will provide a visual means of

assessing progress.”

“Web-enabled entry of sales order.”

Features of the System

Features of the system are

simple descriptions,

in the user’s language,

used as labels to communicate with the user how our system addresses the problem.

These labels will become part of our everyday language, and much energy will be spent in

defining them,

debating them, and

prioritizing them.

Software Requirements

After the feature set has been established gained agreement with the customer, we can move on to defining the more specific requirements that we will need to impose on the solution.

These more specific requirements are the software requirements.

We also note that these appear pretty far down on the pyramid,

If we build a system that conforms to those requirements, we can be certain that they system we develop will deliver the features we promised.

Typical Way of Getting Off Track

with Requirement

Design consideration

Vagueness

The use of computer industry language

Not relating to the business goals

Example of Requirement List

ระบบสามารถจัดเก็บขอ้มลูการท า Transaction ของลกูคา้ได ้

ระบบสามารถจ ากดัสทิธิใ์นการเรยีกดรูปูภาพและขอ้มลูผา่นระบบ dial-in

The system must maintain a list of current, open work processes and identify the

work process to be executed and the workflow queue for the process. When

particular documents are scanned, the system will determine whether there is a

process open for that SSN. If there is an open process, the system will route the

document to the appropriate workflow queue, display the work process script, and

highlight the current work process.

The Challenges of Requirements

Gathering

Finding out what the users need

Documenting users’ needs

Avoiding premature design assumptions

Resolving conflicting requirements

Eliminating redundant requirements

Reducing overwhelming volume

Ensuring requirement traceability

Moving to Use Case

M anage O rder

M anage C ustom er R egister

O rder A dm inistrator

E xecute O rder

M anage A rticles

S tore A dm inistrator

Traditional Modes

Prototype were long to be elixir for good requirements capture, but now we

realize that they can help much more with proof-of-concept

Diagrams

A diagram is a view into a model

Presented from the aspect of a particular stakeholder

Provides a partial representation of the system

Is semantically consistent with other views

In the UML, there are nine standard diagrams

Static views: use case, class, object, component,

deployment

Dynamic views: sequence, collaboration, state chart,

activity

Introducing Use Cases

Two people see a motorcycle in two ways: as the

subsystems that make up the bike and as the

things a person can do with the bike

The Goals of Use Cases

Accountant

Enter Order Details

Account Manager

View Customer Portfolio

Interactions that provide value to Actors

The Goals of Use Cases

No Implementation-Specific Language

Specific people (instead of roles)

Specific department in the organization

User Interface widget (button, menu navigation, etc.)

Assumption about where the work is being done physically

IF-THEN-ELSE statement in use case text

The use of any kind of constraint language

User-appropriate level of detail

Start in general before jumping to the details

Use case always be in user’s vocabulary

User-appropriate volume

– Very large system should have no more than 70 to 80 use cases

Use Case is SMART

Specific

Measurable

Assignable

Realistic

Testable

Use Case Diagram

Photographer

Photographer

The Use Case Template

Use Case Name:

Summary:

Basic Course of Events:

Alternative Paths:

Exception Paths:

Triggers:

Assumptions:

Preconditions:

Postconditions:

Relate Business Rules:

Author:

Date:

Use Case Name/ID#

Use Cases are numbered according to subsystem. Use the

format XXX-###, where XXX is the subsystem acronym, and

### is always three digits and starts at 001.

Use Case Domain/Package

Actors

List the actors who require or interact with this use case.

Description

Describe the use case (1-2 paragraphs).

Preconditions

Describe the conditions assumed to be true before the use case

begins.

Postconditions

Describe the conditions assumed to be true after the use case

ends.

Relationships with other Use Cases

Include

Extend

Main Flow (Main Success Scenario)

Describe the normal flow of events for this use case. Use a

hierarchical numbering system. Do not put too many

requirements in a single numbered requirement. Always use

subject-verb-object for consistent sentence structure, as in “The

system shall verify the customer code”. Use a future tense while

describing requirements.

Alternate Flows

Describe the different ways the interaction described in the Main

Flow above can be carried out. Relate back to specific points in

the Main Flow. As well, the Main Flow should contain a

reference forward to the Alternate Flow List each variation on

the use case as a separate sub section of the Alternate Flows as

A1, A2. Don’t be too concerned if you can’t decide if something

is an Alternate or Exception Flow (below), just use your own

discretion.

Exception Flows

List each error condition as a subsection of the Exceptional Flow.

As with the Alternate Flows, exceptions may refer back to steps

within the Main Flow or they may refer to events that aren’t

specific to a single step.

Architecturally Significant

Indicate Yes or No. Architecturally significant could mean any of

the following - a lot of users using this use case, high concurrency

for users hitting this use case, data-fetching or data displaying

issues. If in doubt, indicate it as “Architecturally Significant” and

then review it with the Software Designer

Supplemental Documentation

Activity Diagram, Decision Table/Tree and State Diagrams may

be given as an easy to understand explanation of the Main,

Alternate or Exception Flows

Requirement Traceability

Traceability => Clarify of linkage

between artifacts

Traceability => Provide assurance that the

software at the end of lifecycle matched

what the stakeholders stated they want

Team member

change

Stakeholder needs

change during

lifecycle

Traceability is hard

Things are passed

from team to team,

not hands-on

knowledge

Delivery cycle is too

long, and get off

track

Linkage is not easy

between artifacts

Analysis Model

Design Model Test Model

Test Plan

Test Scenario

Test Cases

User Interface

Design

Application Architecture

Project Management

Documentation

and Training

Product Marketing

Security Profiles

Release Planning

Use Cases

Classic Mistakes

Perspective

Creating inside-out use case, Including user interface details, Expanding the system boundary

Thriftiness

Skipping interview notes that don’t fit, Holding on to use case that don’t belong

Messiness

– Keeping temporary requirement lists, Grouping use cases poorly, Having use case without an owner, Having use case with too many owners, Including too many cross-reference in use case text, Not keeping use cases in database, trying to build extensive exception into basic course of events

Classic Mistakes

Over-engineering

– Neglecting useful tools within use case, Using computer terminology in use cases, Writing pseudocode for use case text, Assuming that the extend relationships between use cases dictate class inheritance in design, Confusing actors with specific people or organization positions, Putting everything into one use case diagram/one use case, Using IF-THEN-ELSE, Creating hierarchy of use cases.

Mismanagement

– Allowing an imbalance between experience and inexperience, Packaging use cases too late, Using packages to hide complexity that you’re trying to avoid.

Context

– Confusing include, extend, Confusing precondition and assumption