Download - Iteration DEvpt
-
8/12/2019 Iteration DEvpt
1/67
Systems Analysis and Design5th Edition
Chapter 4. Use Case Analysis
Roberta Roth, Alan Dennis, and Barbara Haley Wixom
4-0 Copyright 2011 John Wiley & Sons, Inc.
-
8/12/2019 Iteration DEvpt
2/67
BBC
4-1
-
8/12/2019 Iteration DEvpt
3/67
British Broadcasting Corporation
Project type : Digital archiveProject name : The Digital Media InitiativeDate : May 2013 Cost : 100MThe BBCs archive of broadcast materials is unparalleledand as production continues to this day since 1922, thecorporation has one of the largest archives of mediamaterials in the world.In 2008, BBC initiated the Digital Media Initiative ( DMI),which was intended to provide a single tool that wouldenable video and radio production from raw materialsthrough to final edit.
4-2
-
8/12/2019 Iteration DEvpt
4/67
Lack of Clarity in Requirements
No tender process Without going through a formal tender process, the contract to
develop DMI was awarded to the BBCs existing technology provider(Siemens) in 2008.
Fixed price contract source of being lack of clarityin requirements
The fixed price contract established a plan that would see the projectcompleted in 18 months at a cost 82M.
In theory, a fixed priced contract protects the buyer from costoverruns.
In practice, this is not always the case as lack of clarity inrequirements, changing needs and other real world complicationsoften leave the door open to continual changes that can impact
delivery dates and costs. 4-3
-
8/12/2019 Iteration DEvpt
5/67
Aftermath
No-fault termination of the contract in Jul2009 end of 18-month contractBecoming an in house project
No accurate picture of the projects true status being given tothe 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
http://calleam.com/WTPF/?p=5998 4-4
http://calleam.com/WTPF/?p=5998http://calleam.com/WTPF/?p=5998 -
8/12/2019 Iteration DEvpt
6/67
New Zealand Ministry ofEducation
4-5
-
8/12/2019 Iteration DEvpt
7/67
New Zealand Ministry of Education
Project type : Payroll systemProject name : NovopayDate : Sep 2012 May 2013 Cost : $30M NZDThe Novopay system was intended to be a tool that would
streamline payments to the 110,000 teachers, administrators andstaff 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 systemand 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
-
8/12/2019 Iteration DEvpt
8/67
Operational Problems
Some school employees reported receivingincorrect payments while others were paidnothing at all.Dubbed the Novopay debacle, at one pointaffected staff had reported more than 18,000payroll errors and the operational staff
supporting the system appear to have beenoverwhelmed by the amount of manualintervention needed to correct those errors.
4-7
-
8/12/2019 Iteration DEvpt
9/67
Failure Factors
Tracking and analysis of the errors identified after thelaunch, identified more than 500 distinct defects in thesystem.Of those 44 were deemed to be very serious.In Aug of 2012 when the system went live reports indicatethat only 147 defects were known meaning that QualityAssurance testing had failed to identify several hundredproblems in the system.Many of those problems were traced back to errors in theoriginal project requirements and the design of the newsystem that allowed incorrect data to be entered into thesystem thereby leading to incorrect payroll payments and
related problems. 4-8
-
8/12/2019 Iteration DEvpt
10/67
Aftermath
Affecting daily life Those problems continued to grow and the issues became headline
news in New Zealand as affected employees struggled to maintaintheir 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 questionsabout the stability of the system and outlined a 1-year remedial planthat needed to be followed to ensure the operational stability of thesystem and that the originally planned business benefits were realized.
Reference: Why Project Fail: New Zealand Ministry of Education, May 28, 2013
http://calleam.com/WTPF/?p=5835
4-9
http://calleam.com/WTPF/?p=5835http://calleam.com/WTPF/?p=5835 -
8/12/2019 Iteration DEvpt
11/67
US DoD US Air Force
4-10
-
8/12/2019 Iteration DEvpt
12/67
US Department of Defense U.S. Air Force
Project type : Integrated supply chain and logisticssystemProject name : Expeditionary Combat Support
System (ECSS)Date : Nov 2012, Cost :$1BIssues:
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
4-11
-
8/12/2019 Iteration DEvpt
13/67
-
8/12/2019 Iteration DEvpt
14/67
Problems
By 2010, signs of major problems had surfaced.Between 2010 and early 2012, the project had beenthrough 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 riskremained.
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.4-13
-
8/12/2019 Iteration DEvpt
15/67
Failure Factors
Failure to baseline existing practices and to establisheffective measures for the desired outcomesFailure to establish an effective governance structure
Selecting an Oracle based Commercial-Off-the-Shelf(COTS) based product that was a poor fit for theproject requirementsLack of experience in large scale, complex integrated
systems development and deploymentOrganizational silosFailure to effectively engage all affected stakeholdersLack of collaboration and a lack of understanding ofchange management 4-14
-
8/12/2019 Iteration DEvpt
16/67
Aftermath
For the $1B spent, nothing could be saved.$1 billion wasted on Air Force computersystem, NBC Nightly News, February 08,2013
http://www.nbcnews.com/video/nightly-news/50749586#50749586
http://www.youtube.com/watch?v=M_x_E4UkgV0 Reference:
Why Projects Fail: US Department of Defense US AirForce
http://www.youtube.com/watch?v=M_x_E4UkgV0 4-15
http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586http://localhost/var/www/apps/conversion/tmp/scratch_9/Air%20Force%20Scraps%20_Expeditionary%20Combat%20Support%20System_%20After%20$1.03%20Billion%20In%20Costs%20Since%202005(360p_H.264-AAC).mp4http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://www.youtube.com/watch?v=M_x_E4UkgV0http://localhost/var/www/apps/conversion/tmp/scratch_9/Air%20Force%20Scraps%20_Expeditionary%20Combat%20Support%20System_%20After%20$1.03%20Billion%20In%20Costs%20Since%202005(360p_H.264-AAC).mp4http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586http://www.nbcnews.com/video/nightly-news/50749586 -
8/12/2019 Iteration DEvpt
17/67
US Census Bureau Field DataCollection Automation (FDCA)
4-16
-
8/12/2019 Iteration DEvpt
18/67
US Census Bureau Field DataCollection Automation (FDCA)
Project type : Field Data CollectionProject name : Field Data Collection
Automation (FDCA)Date : Apr 2008, Cost :$595MIssues:
Due to concerns about escalating costs and questionsabout the accuracy of the data being collected, in2001 the US Census Bureau decided to undertake amajor modernization program in preparation for the
2010 census. 4-17
-
8/12/2019 Iteration DEvpt
19/67
IT Development
Having first attempted to do the project in-house, field testing in 2004 demonstrated thatthe project was more complex than anticipated.As a result the Bureau changed direction andengaged an external provider to complete theproject.
Taking a further year to get the Request forProposal published time remaining before dressrehearsals in 2006 and 2008 was running short.
4-18
-
8/12/2019 Iteration DEvpt
20/67
Failure Factors
Underestimation of complexity.The projects problems continued even after engaging anoutside supplier to complete the work.Lack of due diligence on behalf of the Bureau and failure toestablish effective communications with the supplierresulted in a significant number of missing requirements.Failure to establish and stabilize requirements resulting insignificant requirements volatility (at one point 400 plus
change orders had been raised).Despite warnings from external auditors the problems wereallowed to persist and ultimately time ran out.
4-19
-
8/12/2019 Iteration DEvpt
21/67
Aftermath
The Bureau was left with no choice otherthan reverting back to using pen and paper.The failure of the project resulted in theBureau having to request an addition $3B infunding to complete the work using theexisting 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
http://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/WTPF/?p=1894http://calleam.com/WTPF/?p=1894http://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdfhttp://calleam.com/wp-content/uploads/US_Census_FDCA_Case_Study_V1.0.pdf -
8/12/2019 Iteration DEvpt
22/67
4-21
-
8/12/2019 Iteration DEvpt
23/67
-
8/12/2019 Iteration DEvpt
24/67
System
Advanced Information Based Allocation (AIBA), an intelligentdispatch and fleet management system is utilized to allocate abooking 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 servicelevels they provide, supported by the technology, thus rendering acourier 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, utilizingGPS technology.eCourier.co.uk Demo
http://www.youtube.com/watch?v=92pxg91HYbE
4-23
http://localhost/var/www/apps/conversion/tmp/scratch_9/eCourier.co.uk%20Demo(360p_H.264-AAC).mp4http://www.youtube.com/watch?v=92pxg91HYbEhttp://www.youtube.com/watch?v=92pxg91HYbEhttp://www.youtube.com/watch?v=92pxg91HYbEhttp://localhost/var/www/apps/conversion/tmp/scratch_9/eCourier.co.uk%20Demo(360p_H.264-AAC).mp4 -
8/12/2019 Iteration DEvpt
25/67
eCouriers Success Factors
Building a well structured teamDefining success criteria clearly withstakeholders
Understanding market needs Its especially important for being a first -mover
Understanding and managing technical issuesManaging the project through the proposedcontrol cycleReference:
Case Study of Successful Complex IT Projects - BCS
4-24
http://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdfhttp://www.bcs.org/upload/pdf/casestudy2.pdf -
8/12/2019 Iteration DEvpt
26/67
What Makes Projects Succeed?
How often do projects succeed?
Reference: What M akes Projects Succeed ? Synergy Profe ssional
Services, http://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdf 4-25
http://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdfhttp://www.spspro.com/brochures/9-What%20Makes%20Projects%20Succeed%20070213%20long.pdf -
8/12/2019 Iteration DEvpt
27/67
Common Success Factors
Customer InvolvementAgreement on the goals of the projectFrequent progress checks and coursecorrectionsA plan that shows overall path andresponsibilitiesConstant and effective communicationto everyoneControlled scope
Management support 4-26
-
8/12/2019 Iteration DEvpt
28/67
Common Failure Causes RegardingRequirements Engineering
Lack of formality in the scope definition process results invagueness and different people having differentunderstandings of what is in and what is out of scopeVague or open ended requirements (such as requirementsthat end with etc ) Failure to address excessive scope volatility oruncontrolled scope creepFailure to fully understand the operational context in
which the product being produced needs to function oncethe project is overRequirements are defined by an intermediary withoutdirectly consulting or involving those who will eventually
use the product being produced 4-27
-
8/12/2019 Iteration DEvpt
29/67
Common Failure Causes RegardingRequirements Engineering (cont.)
Individual requirements are never vetted against theprojects overall objectives to ensure each requirementsupports the projects objective and has a reasonable Returnon Investment (ROI)The project requirements are written based on theassumption that everything will work as planned.Requirements to handle potential problems or morechallenging situations that might occur are never considered
Failure to broker agreement between stakeholders withdiffering perspectives or requirements.Reference:
Why Projects Fail: 101 Common Causes,http://calleam.com/WTPF/?page_id=2338
4-28
http://calleam.com/WTPF/?page_id=2338http://calleam.com/WTPF/?page_id=2338http://calleam.com/WTPF/?page_id=2338 -
8/12/2019 Iteration DEvpt
30/67
Five Common Issues inRequirements Analysis
Customers don't (really) know what they wantRequirements change during the course of theproject
Customers have unreasonable timelinesCommunication gaps exist between customers,engineers and project managersThe development team doesn't understand the
politics of the customer's organizationReference:
Five common errors in requirements analysis (and how to avoid them) http://www.techrepublic.com/article/five-common-errors-in-
requirements-analysis-and-how-to-avoid-them/ 4-29
http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them/ -
8/12/2019 Iteration DEvpt
31/67
Solving Issues about CustomersBeing Uncertain
Ensure that you spend sufficient time at the start of the project onunderstanding the objectives, deliverables and scope of the project .Make visible any assumptions that the customer is using, andcritically evaluate both the likely end-user benefits and risks of the
project.Attempt to write a concrete vision statement for the project, whichencompasses both the specific functions or user benefits it providesand 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 alignexpectations and ensure that both parties have a clearunderstanding of the deliverable.
4-30
-
8/12/2019 Iteration DEvpt
32/67
Solving Issues about ChangingRequirements
Have a clearly defined process for receiving,analyzing and incorporating change requests, andmake your customer aware of his/her entry point
into this process.Set milestones for each development phase beyondwhich certain changes are not permissible -- forexample, disallowing major changes once a module
reaches 75 percent completion.Ensure that change requests (and approvals) areclearly communicated to all stakeholders , togetherwith their rationale, and that the master project planis updated accordingly. 4-31
-
8/12/2019 Iteration DEvpt
33/67
Solving Issues aboutUnreasonable Timelines
Convert the software requirements specification into aproject plan , detailing tasks and resources needed at eachstage and modeling best-case, middle-case and worst-casescenarios.Ensure that the project plan takes account of availableresource constraints and keeps sufficient time for testingand quality inspection.Enter into a conversation about deadlines with your
customer , using the figures in your draft plan as supportingevidence for your statements. Assuming that your plan isreasonable, it's quite likely that the ensuing negotiation willbe both productive and result in a favorable outcome for
both parties. 4-32
-
8/12/2019 Iteration DEvpt
34/67
Solving Issues aboutCommunication Gaps
Take notes at every meeting anddisseminate these throughout theproject team.Be consistent in your use of words .Make yourself a glossary of the termsthat you're going to use right at thestart, ensure all stakeholders have acopy, and stick to them consistently.
4-33
-
8/12/2019 Iteration DEvpt
35/67
Solving Issues about Not Familiarwith Politics in Customers Site
Review your existing network and identify both theinformation you need and who is likely to have it.Cultivate allies, build relationships and think
systematically about your social capital in theorganization.Persuade opponents within your customer'sorganization by framing issues in a way that is
relevant to their own experience.Use initial points of access/leverage to move youragenda forward.
4-34
-
8/12/2019 Iteration DEvpt
36/67
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
-
8/12/2019 Iteration DEvpt
37/67
INTRODUCTION
Use cases are a means of expressing userrequirements.Use cases are used extensively in the analysis phase.
A use case represents how a system interacts with itsenvironment by illustrating the activities that areperformed 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 ofprocess models and the data model.
Copyright 2011 John Wiley & Sons, Inc. 4-36
-
8/12/2019 Iteration DEvpt
38/67
USE CASES
A use case depicts a set of activities that producesome output result.Each use case describes how an external user
triggers an event to which the system mustrespond.With this type of event-driven modeling , everything in the system can be thought of as aresponse to some triggering event.Creation of use cases is often done as a part ofinterview session with users or a part of JADsessions.
Copyright 2011 John Wiley & Sons, Inc. 4-37
-
8/12/2019 Iteration DEvpt
39/67
Elements of a Use Case
Basic InformationEach use case has a name and number , and briefdescription.
The priority may be assigned to indicate the relativesignificance.The actor refers to a person, another system, or ahardware device that interacts with the system to
achieve a useful goal.The trigger for the use case the event that causesthe use case to begin.
Copyright 2011 John Wiley & Sons, Inc. 4-38
-
8/12/2019 Iteration DEvpt
40/67
Example
Copyright 2011 John Wiley & Sons, Inc. 4-39
-
8/12/2019 Iteration DEvpt
41/67
Example: Basic Information
Copyright 2011 John Wiley & Sons, Inc. 4-40
-
8/12/2019 Iteration DEvpt
42/67
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 whatneeds to be accomplished before each
use case begins. The preconditions define the state thesystem must be in before the use case
commences. Copyright 2011 John Wiley & Sons, Inc. 4-41
-
8/12/2019 Iteration DEvpt
43/67
Example: Preconditions
Copyright 2011 John Wiley & Sons, Inc. 4-42
-
8/12/2019 Iteration DEvpt
44/67
Normal Course
The next part of a use case is thedescription of the major steps that
are performed to execute theresponse to the event , the inputsused for the steps, and the outputs produced by the steps.The normal course lists the steps.
Copyright 2011 John Wiley & Sons, Inc. 4-43
-
8/12/2019 Iteration DEvpt
45/67
Example: Normal Course
Copyright 2011 John Wiley & Sons, Inc. 4-44
-
8/12/2019 Iteration DEvpt
46/67
-
8/12/2019 Iteration DEvpt
47/67
-
8/12/2019 Iteration DEvpt
48/67
Postconditions
The postconditions section ofdefines the final product of the use
case.These postconditions also serve todefine the preconditions for the nextuse case in the series.
Copyright 2011 John Wiley & Sons, Inc. 4-47
-
8/12/2019 Iteration DEvpt
49/67
Example: Postconditions
Copyright 2011 John Wiley & Sons, Inc. 4-48
-
8/12/2019 Iteration DEvpt
50/67
-
8/12/2019 Iteration DEvpt
51/67
Example: Exceptions
Copyright 2011 John Wiley & Sons, Inc. 4-50
-
8/12/2019 Iteration DEvpt
52/67
Summary of Inputs and Outputs
The final section of the use casesummarizes the set of major inputs
and outputs of the use case, alongwith their source or destination.
Copyright 2011 John Wiley & Sons, Inc. 4-51
E l S f I &
-
8/12/2019 Iteration DEvpt
53/67
Example: Summary of Inputs &Outputs
Copyright 2011 John Wiley & Sons, Inc. 4-52
-
8/12/2019 Iteration DEvpt
54/67
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
-
8/12/2019 Iteration DEvpt
55/67
Chain of use cases an example
Copyright 2011 John Wiley & Sons, Inc. 4-54
-
8/12/2019 Iteration DEvpt
56/67
Alternative Use Case Formats
A full-dressed use case is verythorough, detailed, and highly
structured. The project team may decide that amore casual use case format isacceptable.
Copyright 2011 John Wiley & Sons, Inc. 4-55
Example: An Alternative Case Format
-
8/12/2019 Iteration DEvpt
57/67
Copyright 2011 John Wiley & Sons, Inc. 4-56
U C d h F i l
-
8/12/2019 Iteration DEvpt
58/67
Use Cases and the FunctionalRequirements
Use cases are very useful tools to us to understanduser requirements. However, use cases only conveythe users point of view.
Transforming the users view into the developersview by creating functional requirements is one ofthe important contributions of system analyst.
The derived functional requirements give moreinformation to the developer about what the systemmust do.
Copyright 2011 John Wiley & Sons, Inc. 4-57
Example: Functional Requirements
-
8/12/2019 Iteration DEvpt
59/67
p q
Copyright 2011 John Wiley & Sons, Inc. 4-58
-
8/12/2019 Iteration DEvpt
60/67
St 2 Id tif th j t f
-
8/12/2019 Iteration DEvpt
61/67
Step 2: Identify the major steps foreach use case
Copyright 2011 John Wiley & Sons, Inc. 4-60
-
8/12/2019 Iteration DEvpt
62/67
-
8/12/2019 Iteration DEvpt
63/67
Step 4. Confirm the use case
Copyright 2011 John Wiley & Sons, Inc. 4-62
Revise functional requirements based
-
8/12/2019 Iteration DEvpt
64/67
Revise functional requirements basedon use cases
The functional requirements in therequirements definition may be
modified to reflect the more detailedunderstanding and to provide insightto the development team on some
back -end processing.
Copyright 2011 John Wiley & Sons, Inc. 4-63
Example: Revising Functional Requirements
-
8/12/2019 Iteration DEvpt
65/67
Copyright 2011 John Wiley & Sons, Inc. 4-64
-
8/12/2019 Iteration DEvpt
66/67
SUMMARY
A use case contains all the information neededto build one part of a process model, expressedin 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 everystep,- have the users role-play the use case to verify.
Copyright 2011 John Wiley & Sons, Inc. 4-65
-
8/12/2019 Iteration DEvpt
67/67
Copyright 2011 John Wiley & Sons, Inc.
All rights reserved. Reproduction or translation of this workbeyond that permitted in Section 117 of the 1976 United StatesCopyright Act without the express written permission of thecopyright owner is unlawful. Request for further informationshould be addressed to the Permissions Department, John Wiley& Sons, Inc. The purchaser may make back-up copies for his/herown use only and not for redistribution or resale. The Publisherassumes no responsibility for errors, omissions, or damages,caused by the use of these programs or from the use of theinformation contained herein.
Notes : Each symbol used in this slide set links to a video file downloadedfrom YouTube. However, all locally linked videos are not stored in the classwebsite. They can all be accessed through corresponding YouTube links.