Presentation is loading. Please wait.

Presentation is loading. Please wait.


Similar presentations

Presentation on theme: "BBC."— Presentation transcript:

0 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.


2 British Broadcasting Corporation
Project type : Digital archive Project name : The Digital Media Initiative Date : May Cost : £100M The BBC’s 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.

3 Lack of Clarity in Requirements
No tender process Without going through a formal tender process, the contract to develop DMI was awarded to the BBC’s existing technology provider (Siemens) in 2008. 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. 

4 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 project’s true status being given to the BBC Trust Results: Failure to deliver a working system Project being abandoned in May 2013 £100M being written off Reference: Why Projects Fail: British Broadcasting Corporation, Sept 2, 2013

5 New Zealand Ministry of Education

6 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 Zealand’s educational system. 2005 Decision The project had its origins in a 2005 decision. 2010 Being Implemented, Originally Following a bid process, Australia’s 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.

7 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.

8 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.

9 Aftermath Affecting daily life Result: Reference:
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. Result: 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. Reference: Why Project Fail: New Zealand Ministry of Education, May 28, 2013

10 US DoD – US Air Force

11 US Department of Defense – U.S. Air Force
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 time- inefficiencies Limited visibility across the supply chain

12 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. 

13 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. Deciding to scrap it Recognizing that a partial solution negated the overall vision of an integrated system, the Air Force scrapped the Project in Nov 2012.

14 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 “change management”

15 Aftermath For the $1B spent, nothing could be saved.
“$1 billion wasted on Air Force computer system,” NBC Nightly News, February 08, 2013 Reference: Why Projects Fail: US Department of Defense – US Air Force

16 US Census Bureau – Field Data Collection Automation (FDCA)

17 US Census Bureau – Field Data Collection Automation (FDCA)
Project type : Field Data Collection Project name : Field Data Collection Automation (FDCA) Date : Apr 2008, Cost :$595M Issues: 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. 

18 IT Development Having first attempted to do the project in-house, 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.

19 Failure Factors Underestimation of complexity.
The project’s 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. 

20 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


22 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.

23 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. Demo

24 eCourier’s Success Factors
Building a well structured team Defining success criteria clearly with stakeholders Understanding market needs It’s especially important for being a first-mover Understanding and managing technical issues Managing the project through the proposed control cycle Reference: Case Study of Successful Complex IT Projects - BCS

25 What Makes Projects Succeed?
How often do projects succeed? Reference: “What Makes Projects Succeed?” Synergy Professional Services,

26 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

27 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

28 Common Failure Causes Regarding Requirements Engineering (cont.)
Individual requirements are never vetted against the project’s overall objectives to ensure each requirement supports the project’s 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,

29 Five Common Issues in Requirements Analysis
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)

30 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.

31 Solving Issues about Changing Requirements
Have a clearly defined process for receiving, 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 is updated accordingly.

32 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.

33 Solving Issues about Communication Gaps
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.

34 Solving Issues about Not Familiar with Politics in Customer’s 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.

35 © Copyright 2011 John Wiley & Sons, Inc.
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.

36 © Copyright 2011 John Wiley & Sons, Inc.
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 system’s 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.

37 © Copyright 2011 John Wiley & Sons, Inc.
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.

38 © Copyright 2011 John Wiley & Sons, Inc.
Elements of a Use Case Basic Information 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.

39 © Copyright 2011 John Wiley & Sons, Inc.
Example © Copyright 2011 John Wiley & Sons, Inc.

40 Example: Basic Information
© Copyright 2011 John Wiley & Sons, Inc.

41 © Copyright 2011 John Wiley & Sons, Inc.
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.

42 Example: Preconditions
© Copyright 2011 John Wiley & Sons, Inc.

43 © Copyright 2011 John Wiley & Sons, Inc.
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.

44 Example: Normal Course
© Copyright 2011 John Wiley & Sons, Inc.

45 © Copyright 2011 John Wiley & Sons, Inc.
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.

46 Example: Alternative Courses
© Copyright 2011 John Wiley & Sons, Inc.

47 © Copyright 2011 John Wiley & Sons, Inc.
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.

48 Example: Postconditions
© Copyright 2011 John Wiley & Sons, Inc.

49 © Copyright 2011 John Wiley & Sons, Inc.
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.

50 © Copyright 2011 John Wiley & Sons, Inc.
Example: Exceptions © Copyright 2011 John Wiley & Sons, Inc.

51 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.

52 Example: Summary of Inputs & Outputs
© Copyright 2011 John Wiley & Sons, Inc.

53 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.

54 Chain of use cases – an example
© Copyright 2011 John Wiley & Sons, Inc.

55 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.

56 Example: An Alternative Case Format
© Copyright 2011 John Wiley & Sons, Inc.

57 Use Cases and the Functional Requirements
Use cases are very useful tools to us to understand user requirements. However, use cases only convey the user’s point of view. Transforming the user’s view into the developer’s 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.

58 Example: Functional Requirements
© Copyright 2011 John Wiley & Sons, Inc.

59 © Copyright 2011 John Wiley & Sons, Inc.
Use Cases and Testing Building Use Cases Step 1: Identify the major use cases © Copyright 2011 John Wiley & Sons, Inc.

60 Step 2: Identify the major steps for each use case
© Copyright 2011 John Wiley & Sons, Inc.

61 Step 3: Identify elements within steps
© Copyright 2011 John Wiley & Sons, Inc.

62 Step 4. Confirm the use case
© Copyright 2011 John Wiley & Sons, Inc.

63 Revise functional requirements based on use cases
The functional requirements in the 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.

64 Example: Revising Functional Requirements
© Copyright 2011 John Wiley & Sons, Inc.

65 © Copyright 2011 John Wiley & Sons, Inc.
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.

66 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.

Download ppt "BBC."

Similar presentations

Ads by Google