Systems Analysis and Design

5th Edition

Chapter 4. Use Case Analysis

Roberta Roth, Alan Dennis, and Barbara Haley Wixom

Copyright 2011 John Wiley & Sons, Inc.

4-0

BBC

4-1

British Broadcasting Corporation

Project type : Digital archive Project name : The Digital Media Initiative Date : May 2013 Cost : 100M The BBCs archive of broadcast materials is unparalleled
and as production continues to this day since 1922, the corporation has one of the largest archives of media materials in the world. In 2008, BBC initiated the Digital Media Initiative (DMI), which was intended to provide a single tool that would enable video and radio production from raw materials through to final edit.
4-2

Lack of Clarity in Requirements

No tender process Fixed price contract source of being lack of clarity
in requirements
The fixed price contract established a plan that would see the project completed in 18 months at a cost 82M. In theory, a fixed priced contract protects the buyer from cost overruns. In practice, this is not always the case as lack of clarity in requirements, changing needs and other real world complications often leave the door open to continual changes that can impact delivery dates and costs.

Without going through a formal tender process, the contract to develop DMI was awarded to the BBCs existing technology provider (Siemens) in 2008.

4-3

Aftermath

No-fault termination of the contract in Jul

2009 end of 18-month contract Becoming an in house project
No accurate picture of the projects true status being given to the BBC Trust Failure to deliver a working system Project being abandoned in May 2013 100M being written off Why Projects Fail: British Broadcasting Corporation, Sept 2, 2013
http://calleam.com/WTPF/?p=5998
4-4

Results:

Reference:

New Zealand Ministry of Education

4-5

New Zealand Ministry of Education

Project type : Payroll system Project name : Novopay Date : Sep 2012 May 2013 Cost : $30M NZD The Novopay system was intended to be a tool that would streamline payments to the 110,000 teachers, administrators and staff throughout New Zealands educational system. 2005 Decision
The project had its origins in a 2005 decision.

2010 Being Implemented, Originally

Following a bid process, Australias Talent2 was selected to both implement the new system and then operate it on a service contract basis until 2020.

Delay till Aug 2012

The original project called for the system to be implemented in 2010, but following a number of delays the project only reached operationally status in Aug of 2012.

4-6

Operational Problems

Some school employees reported receiving

incorrect payments while others were paid nothing at all. Dubbed the Novopay debacle, at one point affected staff had reported more than 18,000 payroll errors and the operational staff supporting the system appear to have been overwhelmed by the amount of manual intervention needed to correct those errors.
4-7

Failure Factors
Tracking and analysis of the errors identified after the
launch, identified more than 500 distinct defects in the system. Of those 44 were deemed to be very serious. In Aug of 2012 when the system went live reports indicate that only 147 defects were known meaning that Quality Assurance testing had failed to identify several hundred problems in the system. Many of those problems were traced back to errors in the original project requirements and the design of the new system that allowed incorrect data to be entered into the system thereby leading to incorrect payroll payments and related problems. 4-8

Aftermath
Affecting daily life
Those problems continued to grow and the issues became headline news in New Zealand as affected employees struggled to maintain their personal finances in the face of the cash flow problems the systems failures were causing.
A Mar 2013 review performed by Deloitte raised serious questions about the stability of the system and outlined a 1-year remedial plan that needed to be followed to ensure the operational stability of the system and that the originally planned business benefits were realized. Why Project Fail: New Zealand Ministry of Education, May 28, 2013
http://calleam.com/WTPF/?p=5835
4-9

Result:

Reference:

US DoD US Air Force

4-10

 Project type : Integrated supply chain and logistics

system Project name : Expeditionary Combat Support System (ECSS) Date : Nov 2012, Cost :$1B Issues:
The Air Force IT environment consisting of over 700 systems Many being duplicative, stand-alone and ineffective A multitude of metrics with competing goals Non-standardized reporting causing credibility issues and timeinefficiencies Limited visibility across the supply chain
4-11

US Department of Defense U.S. Air Force

IT Plan

US Air Force decided to integrate their systems

into a single Enterprise Resource Planning (ERP) system.
Expeditionary Combat Support System (ECSS) was intended to streamline processes and bring billions of dollars in savings.

Originally estimates indicated that the project

would take 8 years to reach full deployment and would cost $3B. Work was to be started in 2004 and was to be completed by 2012.
4-12

Problems
By 2010, signs of major problems had surfaced. Between 2010 and early 2012, the project had been
through no less than three project resets. No results even spending more time & money
By 2012, the Air Force had determined that the $1B spent to date had yielded negligible benefits and if they proceeded they would need $1.1B more to deploy just 25% of the original scope. Even with such a scaled back proposal, deployment would be pushed back to 2020 meaning that significant additional work and risk remained. Recognizing that a partial solution negated the overall vision of an integrated system, the Air Force scrapped the Project in Nov 2012.
4-13

Deciding to scrap it

Failure Factors
Failure to baseline existing practices and to establish
effective measures for the desired outcomes Failure to establish an effective governance structure Selecting an Oracle based Commercial-Off-the-Shelf (COTS) based product that was a poor fit for the project requirements Lack of experience in large scale, complex integrated systems development and deployment Organizational silos Failure to effectively engage all affected stakeholders Lack of collaboration and a lack of understanding of 4-14 change management

Aftermath

For the $1B spent, nothing could be saved. $1 billion wasted on Air Force computer
system, NBC Nightly News, February 08, 2013
http://www.nbcnews.com/video/nightlynews/50749586#50749586 http://www.youtube.com/watch?v=M_x_E4UkgV0 Why Projects Fail: US Department of Defense US Air Force
http://www.youtube.com/watch?v=M_x_E4UkgV0
4-15

Reference:

US Census Bureau Field Data Collection Automation (FDCA)

4-16

Project type : Field Data Collection Project name : Field Data Collection
Automation (FDCA) Date : Apr 2008, Cost :$595M Issues:

US Census Bureau Field Data Collection Automation (FDCA)

Due to concerns about escalating costs and questions about the accuracy of the data being collected, in 2001 the US Census Bureau decided to undertake a major modernization program in preparation for the 2010 census. 4-17

IT Development

Having first attempted to do the project inhouse, field testing in 2004 demonstrated that the project was more complex than anticipated. As a result the Bureau changed direction and engaged an external provider to complete the project. Taking a further year to get the Request for Proposal published time remaining before dress rehearsals in 2006 and 2008 was running short.
4-18

Failure Factors
Underestimation of complexity. The projects problems continued even after engaging an
outside supplier to complete the work. Lack of due diligence on behalf of the Bureau and failure to establish effective communications with the supplier resulted in a significant number of missing requirements. Failure to establish and stabilize requirements resulting in significant requirements volatility (at one point 400 plus change orders had been raised). Despite warnings from external auditors the problems were allowed to persist and ultimately time ran out.
4-19

Aftermath

The Bureau was left with no choice other than reverting back to using pen and paper. The failure of the project resulted in the
Bureau having to request an addition $3B in funding to complete the work using the existing manual procedures. Reference:
US Census Field Data Collection Automation Case Study Why Project Fail: US Census Bureau Field Data Collection Automation (FDCA) Case Study
http://calleam.com/WTPF/?p=1894
4-20

4-21

eCourier
eCourier are a same day 24/7 courier service based
in London, UK. The company was formed in 2003 with the aim of providing a courier service that is focused on delivery transparency and automated customer interaction. Parcels are collected from any London address and taken to any final destination requested by the client. Although the company originally only delivered parcels to London addresses, they now deliver parcels to any global location requested by corporate clients.
4-22

System

Advanced Information Based Allocation (AIBA), an intelligent dispatch and fleet management system is utilized to allocate a booking to the most appropriate vehicle (including bicycles, motorbikes and vans of varying sizes) and sends a message to the courier to alert them to the job through their handheld terminal. Couriers are rewarded and motivated with high pay for the service levels they provide, supported by the technology, thus rendering a courier service that is reliable, trustworthy and transparent. In addition to systems for employees, the customer has been provided with a real time tracking of their parcel on a map, utilizing GPS technology. eCourier.co.uk Demo
http://www.youtube.com/watch?v=92pxg91HYbE

4-23

eCouriers Success Factors

Building a well structured team Defining success criteria clearly with

stakeholders Understanding market needs

Understanding and managing technical issues Managing the project through the proposed
control cycle Reference:
Case Study of Successful Complex IT Projects - BCS
4-24

Its especially important for being a first-mover

What Makes Projects Succeed?

How often do projects succeed?

Reference:

What Makes Projects Succeed? Synergy Professional Services, http://www.spspro.com/brochures/9What%20Makes%20Projects%20Succeed%20070213%20lo ng.pdf 4-25

Common Success Factors

Customer Involvement Agreement on the goals of the project Frequent progress checks and course corrections A plan that shows overall path and responsibilities Constant and effective communication to everyone Controlled scope Management support

4-26

Common Failure Causes Regarding Requirements Engineering

Lack of formality in the scope definition process results in
vagueness and different people having different understandings of what is in and what is out of scope Vague or open ended requirements (such as requirements that end with etc) Failure to address excessive scope volatility or uncontrolled scope creep Failure to fully understand the operational context in which the product being produced needs to function once the project is over Requirements are defined by an intermediary without directly consulting or involving those who will eventually use the product being produced 4-27

Common Failure Causes Regarding Requirements Engineering (cont.)

Individual requirements are never vetted against the
projects overall objectives to ensure each requirement supports the projects objective and has a reasonable Return on Investment (ROI) The project requirements are written based on the assumption that everything will work as planned. Requirements to handle potential problems or more challenging situations that might occur are never considered Failure to broker agreement between stakeholders with differing perspectives or requirements. Reference:
Why Projects Fail: 101 Common Causes, http://calleam.com/WTPF/?page_id=2338
4-28

 Customers don't (really) know what they want Requirements change during the course of the
project Customers have unreasonable timelines Communication gaps exist between customers, engineers and project managers The development team doesn't understand the politics of the customer's organization Reference:
Five common errors in requirements analysis (and how to avoid them) http://www.techrepublic.com/article/five-common-errors-inrequirements-analysis-and-how-to-avoid-them/

Five Common Issues in Requirements Analysis

4-29

Solving Issues about Customers Being Uncertain

Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project. Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project. Attempt to write a concrete vision statement for the project, which encompasses both the specific functions or user benefits it provides and the overall business problem it is expected to solve. Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.

4-30

 Have a clearly defined process for receiving,

Solving Issues about Changing Requirements

analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process. Set milestones for each development phase beyond which certain changes are not permissible -- for example, disallowing major changes once a module reaches 75 percent completion. Ensure that change requests (and approvals) are clearly communicated to all stakeholders, together with their rationale, and that the master project plan 4-31 is updated accordingly.

Solving Issues about Unreasonable Timelines

Convert the software requirements specification into a
project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios. Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection. Enter into a conversation about deadlines with your customer, using the figures in your draft plan as supporting evidence for your statements. Assuming that your plan is reasonable, it's quite likely that the ensuing negotiation will be both productive and result in a favorable outcome for both parties. 4-32

Take notes at every meeting and

disseminate these throughout the project team. Be consistent in your use of words. Make yourself a glossary of the terms that you're going to use right at the start, ensure all stakeholders have a copy, and stick to them consistently.
4-33

Solving Issues about Communication Gaps

Solving Issues about Not Familiar with Politics in Customers Site Review your existing network and identify both the
information you need and who is likely to have it. Cultivate allies, build relationships and think systematically about your social capital in the organization. Persuade opponents within your customer's organization by framing issues in a way that is relevant to their own experience. Use initial points of access/leverage to move your agenda forward.
4-34

Chapter 4 Outline
Use Cases

Elements of a use case. Alternative use case formats. Use cases and functional requirements. Use cases and testing. Building use cases.
Copyright 2011 John Wiley & Sons, Inc. 4-35

INTRODUCTION
Use cases are a means of expressing user
requirements. Use cases are used extensively in the analysis phase. A use case represents how a system interacts with its environment by illustrating the activities that are performed by the users and the systems responses. The text-based use case is easy for the users to understand, and also flows easily into the creation of process models and the data model.

Copyright 2011 John Wiley & Sons, Inc.

4-36

USE CASES
A use case depicts a set of activities that produce
some output result. Each use case describes how an external user triggers an event to which the system must respond. With this type of event-driven modeling, everything in the system can be thought of as a response to some triggering event. Creation of use cases is often done as a part of interview session with users or a part of JAD sessions. Copyright 2011 John Wiley & Sons, Inc.

4-37

Elements of a Use Case

Each use case has a name and number, and brief
description. The priority may be assigned to indicate the relative significance. The actor refers to a person, another system, or a hardware device that interacts with the system to achieve a useful goal. The trigger for the use case the event that causes the use case to begin.
Copyright 2011 John Wiley & Sons, Inc. 4-38

Basic Information

Example

Copyright 2011 John Wiley & Sons, Inc.

4-39

Example: Basic Information

Copyright 2011 John Wiley & Sons, Inc.

4-40

Preconditions

It is common practice to create smaller,

more focused use cases breaking the whole process down into parts. It is important to define clearly what needs to be accomplished before each use case begins. The preconditions define the state the system must be in before the use case commences.
Copyright 2011 John Wiley & Sons, Inc.

4-41

Example: Preconditions

Copyright 2011 John Wiley & Sons, Inc.

4-42

Normal Course

The next part of a use case is the

description of the major steps that are performed to execute the response to the event, the inputs used for the steps, and the outputs produced by the steps. The normal course lists the steps.
Copyright 2011 John Wiley & Sons, Inc. 4-43

Example: Normal Course

Copyright 2011 John Wiley & Sons, Inc.

4-44

Alternative Courses

Alternative courses depict branches

(alternative paths of the steps) in logic that also will lead to a successful conclusion of the use case.

Copyright 2011 John Wiley & Sons, Inc.

4-45

Example: Alternative Courses

Copyright 2011 John Wiley & Sons, Inc.

4-46

Postconditions

The postconditions section of

defines the final product of the use case. These postconditions also serve to define the preconditions for the next use case in the series.
Copyright 2011 John Wiley & Sons, Inc. 4-47

Example: Postconditions

Copyright 2011 John Wiley & Sons, Inc.

4-48

Exceptions

A use case should describe any error

conditions or exceptions that may occur as the use case steps are performed. These are not normal branches in decision logic, but are unusual occurrences or errors that could potentially be encountered and will lead to an unsuccessful result.
Copyright 2011 John Wiley & Sons, Inc.

4-49

Example: Exceptions

Copyright 2011 John Wiley & Sons, Inc.

4-50

Summary of Inputs and Outputs

The final section of the use case

summarizes the set of major inputs and outputs of the use case, along with their source or destination.

Copyright 2011 John Wiley & Sons, Inc.

4-51

Example: Summary of Inputs & Outputs

Copyright 2011 John Wiley & Sons, Inc.

4-52

Additional Use Case Issues

Additional sections may be included,

e.g., - Frequency of use - Business rules - Special requirements - Assumptions - Notes and issues
Copyright 2011 John Wiley & Sons, Inc. 4-53

Chain of use cases an example

Copyright 2011 John Wiley & Sons, Inc.

4-54

Alternative Use Case Formats

A full-dressed use case is very

thorough, detailed, and highly structured. The project team may decide that a more casual use case format is acceptable.
Copyright 2011 John Wiley & Sons, Inc. 4-55

Example: An Alternative Case Format

Copyright 2011 John Wiley & Sons, Inc.

4-56

Use Cases and the Functional Requirements

Use cases are very useful tools to us to understand

user requirements. However, use cases only convey the users point of view. Transforming the users view into the developers view by creating functional requirements is one of the important contributions of system analyst. The derived functional requirements give more information to the developer about what the system must do.
Copyright 2011 John Wiley & Sons, Inc. 4-57

Example: Functional Requirements

Copyright 2011 John Wiley & Sons, Inc.

4-58

Use Cases and Testing

Building Use Cases

Step 1: Identify the major use cases

Copyright 2011 John Wiley & Sons, Inc.

4-59

Step 2: Identify the major steps for each use case

Copyright 2011 John Wiley & Sons, Inc.

4-60

Step 3: Identify elements within steps

Copyright 2011 John Wiley & Sons, Inc.

4-61

Step 4. Confirm the use case

Copyright 2011 John Wiley & Sons, Inc.

4-62

The functional requirements in the

Revise functional requirements based on use cases

requirements definition may be modified to reflect the more detailed understanding and to provide insight to the development team on some back-end processing.
Copyright 2011 John Wiley & Sons, Inc. 4-63

Example: Revising Functional Requirements

Copyright 2011 John Wiley & Sons, Inc.

4-64

SUMMARY

A use case contains all the information needed

to build one part of a process model, expressed in an informal, simple way. When writing a use case, - identify the triggering event, - develop a list of the major steps, - identify the input(s) and output(s) for every step, - have the users role-play the use case to verify.
Copyright 2011 John Wiley & Sons, Inc. 4-65

Copyright 2011 John Wiley & Sons, Inc.

All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express written permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for redistribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein.
Notes: Each symbol used in this slide set links to a video file downloaded from YouTube. However, all locally linked videos are not stored in the class website. They can all be accessed through corresponding YouTube links.
Copyright 2011 John Wiley & Sons, Inc. 4-66