Requirements Analysis Lesson 3 · System Procurement Invite tenders: – Detailed, precise system...
22
Transcript of Requirements Analysis Lesson 3 · System Procurement Invite tenders: – Detailed, precise system...
ObjectivesTo make you aware of:
– Importance of effective requirements engineering– Range and types of problems which arise– Leading edge research and practice
To give you:– Practical skills in leading-edge methods and techniques– Practical knowledge of requirements engineering tools– Outside speakers
To make you think about:– Requirements engineering is part of a wider design
process– Free your mind - be prepared to do creative design as
well as systematic requirements engineering
Reading MaterialTwo good overall text books to use are:
– Robertson S. & Robertson J., 1999, ‘Mastering the Requirements Engineering Process’, Addison-Wesley Longman;
– Sommerville I. & Kotonya G., 1998, ‘Requirements Engineering’, John Wiley.
Other useful textbooks are:– Sommerville I. & Sawyer P., 1997, "Requirements
Engineering: a Good Practice Guide", John Wiley.– Davies A.M., 1993, 'Software Requirements: Objects,
Functions, States', Prentice-Hall.
The London Ambulance Service (LAS) Computer-Aided Despatch (CAD) System Case Study
Lessons learned for requirements engineering
OverviewThe Original LAS CAD system
– The existing system and its context– The radical new system– How the new system was developed– System collapse– Serious requirements failures: what should have been– What has been fixed
Requirements definitions and attributes– Definitions of requirements– The VOLERE requirement shell– A requirements taxonomy– Think about solutions when expressing requirements
“just a typical everyday system”
AMBULANCE
The LAS-CAD SystemIt is:
– Large– Real-time– Mission-critical– Data rich– Embedded– Distributed– Mobile components
How the Original System WorkedTypical of many systems:
– Socio-technical system– Evolved system– Using loosely-defined management procedures– Using talented and experienced individuals
LAS-CAD SystemIn 1992:
– Move towards decentralised management and cost centre accounting
– Lack of prior investment– Severe resource pressures– Political concern over cost effectiveness– Public concern over service quality– Poor labour relations
Despatch System
calltaking
resourcemanagement
resourceidentification
resourcemobilisation
LondonAMBULANCE
The Ambulance Despatch System
Despatch Systemcall taking
resource management
resource identification
resourcemobilisation
LondonAMBULANCE
telephone operators pass incident to
control assistant who uses map book to complete incident
form
resource controller passes incident form to resource allocators
who allocate ambulance to
incident
all incident forms for current
incidents held in the allocations
box
despatcher and radio operator use incident
form details to despatch and control
ambulance
The Manual Despatch System
Despatch Systemcall taking
resource management
resource identification
resourcemobilisation
LondonAMBULANCE
computerised incident recording, computer-
based gazetteerresource identification and resource proposal
systems
resource management system, AVLS management
system
computerised resource mobilisation, mobile data terminals
in ambulances
single operator
The New CAD System
System ProcurementInvite tenders:
– Detailed, precise system requirements specification (SRS)
– Developed by system manager (non-IT) & contract analyst
– Did not consider working practices– Needed fixed timetable and cost
17 suppliers responded– Functional requirement, load/response time, ease of
use, resilence, flexibility, delivery by timetable, costJust 1 supplier met criteria
– System Option/Apricot/Datatrak (SO)– SO prepared full system design specification
Piecemeal over 9 monthsPhase 1
– Call-taking software and gazetteer with printed formsPhase 2
– Resource proposal software– Track vehicles and take call details– Allocation remains manual
Phase 3– Full implementation: automatic allocation
Pandora’s Box
Pandora’s Box
Pandora’s Box
System Implementation
System Collapse (26th October 1992)Call traffic increasedData base became incorrect
– AVLS did not keep track of ambulance location and status
– Ambulance crews could not use MDTs– Ambulance crews failed to notify status
Poor system performance– Non-optimal allocation, multiple units to single calls
Large number of exception messages– Unresponded messages generate more messages– Public kept calling when no ambulance arrives
Lists of incidents scrolled off operator screens
The System CollapseChaos broke out
– One ambulance arrived to find patient dead and take away by undertakers
– Another answered a ‘stroke’ call after 11 hours, 5 hours after patient made own way to hospital
CAD system was partly removed– Seized up 8 days later– Operators used tape recordings of calls to discover
incidents– Reverted to manual system
Chief executive resigns
Serious Requirements Failures ThroughoutSome critical failures - no particular order
➻ Failure to talk to users to determine current work practices or future system requirements
➻ SRS specification was not formally signed off➻ SRS requirements were not measurable➻ Did not look at other emergency service CAD systems➻ SRS omitted key stakeholder & technical requirements➻ SRS was over-specified w.r.t. available solutions➻ Inept requirements prioritisation and negotiation
Performance requirements over usability requirements➻ The wrong package was bought with cost as only driver➻ No stakeholder validation of requirements or user
requirements testing
Requirements: Some Basic “Do’s”A good process should do (at least) the following
➼ Involve stakeholders throughout to understand how they work and to determine future system requirements
➼ Agree and sign off all requirements periodically➼ All requirements must be measurable and testable➼ Assume concurrent engineering - parallel requirements
engineering and design work, without committing➼ Ensure complete stakeholder requirements➼ Keep requirements solution-independent➼ Prioritise and negotiate requirements with stakeholders
prior to sign-off➼ Select candidate solutions using requirements that are
ranked and costed➼ Involve stakeholders until user requirements testing
Other FailuresProject management
– Confusion over who was managing the project– Unfamiliar method (PRINCE) not used corrrectly– Poor change control– Supplier misled the customer about progress
System design– Insufficient communications capacity– Unproven development tool– No dedicated network management
System testing– System untested under realistic loads– No staff training or backup system !
And Since… from Tighe (1996)1994
– New networks in HQ complexApril 1995
– Digital PABX/Automatic call distribution system– DAT recording of all calls/communications
May 1995– Change radio scheme and crew rosters– Gave control room staff confidence in technologies
1996– Prototype system taking emergency calls, new control
room, hand-held radiosBCS award for good practice awarded in 2000
50
25
75
100
within 8 mins within 14 mins
7/1/9611/1/96
After introduction of prototype system taking emergency calls, January 1996
Now they’ve received a British Computer Society award.....
System Improvements, January 1996
Tutorial:The Wide Range of Stakeholders and Requirements
Tutorial Week 3 & 4Learning objective
– To uncover the range of stakeholders and their requirements for the LAS-CAD system
Work in small groups– Choose one of group of stakeholders to be– Imagine/brainstorm requirements that you might have
for the system. Write them down using VOLERE snow cards
– Types are performance, look-and-feel, device, usability, training, availability, maintainability, recoverability, portability, reliability, security, safety, contract, supplier
Class discussion– Groups present requirements– Others compare/critique these requirements!!
