chapter 5: requirements analysis
DESCRIPTION
Chapter 5: Requirements Analysis. Elicitation from users Project risk Outsourcing. Determine resources needed to build project specific identification of what system is to do expand upon proposal specifications Business requirements conceptual design logical design validation - PowerPoint PPT PresentationTRANSCRIPT
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-1
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-2
Chapter 5: Requirements Analysis
Elicitation from users
Project risk
Outsourcing
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-3
definition
• Determine resources needed to build project– specific identification of what system is to do– expand upon proposal specifications
• Business requirements– conceptual design– logical design– validation– formal specification
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-4
User Requirement Elicitation
• Meetings
• Interviews
• Brainstorming
• Structured methods– Nominal Group Technique– Delphi
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-5
Caterpillar: Extranet
• Important to get product modifications to customers quickly
• EXTRANET: linked 18 outside organizations– semi-private access– customers can track part delivery status– shortened delivery cycle (place order quicker)
• was 50 days, became 5
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-6
Objectives Meeting
• All relevant document read beforehand
• Each team member produces keyword list
• List of agreed keywords produced
• Agreed keywords combined - deliverables
• NEED: whiteboard to focus attention
• NEED: sufficient time
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-7
Group Support Systems
• Facilitate groups facing unstructured decisions
• Easy to use
• Record points
• discourage conflict, miscommunication, groupthink
• aid negotiation, compromise
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-8
Group Support Systems
FORTUNE magazine 23 March 1992
• Managers spend 30% to 70% of their time in meetings
• GSSs provide a way for PCs to pay off• BOEING - cut team project times an
average of 91%• Using TeamFocus took 35 days (15
electronic meetings) - normally 1 year
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-9
Group Support System Products
PC Magazine 14 June 1994
• E-Mail• Electronic Bulletin Board Products• Conferencing Software• Whiteboard Software• Desktop Videoconferencing• Structured Group Discussion Meeting Room
Software
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-10
Nemawashi Approach
• Japanese• Coordinator visits group participants
1. Privately identifies their needs individually2. Generates solution acceptable to all3. Selects plan most likely to be accepted4. Negotiates and persuades5. Document circulated
• Once agreement reached, hold meeting
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-11
Risk Analysis
• Risk identification - identify, rank
• Risk analysis– convert data into understanding
• Risk control - measure, implement control
• Risk reporting
NOT step-by-step: continuous process
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-12
Risk Identification Methods
• Brainstorming
• Nominal Group Technique– structured: initial ideas recorded, discuss,
evaluate
• Delphi– anonymous input, shared evaluation, cycle
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-13
State of Washington
• 1992 - To unify driver’s license, vehicle registration databases - $16 million
• residents fill out only one change-of-address form– initial estimate of required scope too low– new laws
• spent $40 million before cancelled (would have taken an additional $27.5 million)
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-14
IRS
• Computer systems developed in 1960s• spend $hundreds of millions annually
– upgrade efforts, about 50 projects– current modernization program $8 billion– lose up to $50 billion/year in lost revenue
• 2000 staff on upgrade, 10 outside contractors for every staff
• outsourced
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-15
Star*Doc
Oz (1994)
• joint venture, 2 international air freight firms– US, Japan
• reduce data redundency, better tracking• 18 month project, $3.3 million
– specifications for packaging only– users not informed until system installed– management passive
• massive failure
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-16
Features Found in Successful Projects
Ingram (1994)
• No loss to third parties• Objectives agreed upon early• Needed skills available• Objectives clear throughout project• No loss to platform issues• Technical approach sound• Software issues top priority
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-17
the Systems Failure Method
Learning from Failure: The Systems Approach
Joyce Fortune & Geoff Peters, Wiley, 1995
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-18
Systems Failure Method
• systematic method for analysis of failure• successfully applied - wide variety of situations• by reviewing past failures, avoid future failure• as organizations rely more on computers, there
is a corresponding increase in significant business interruptions
• yet of 300,000 large & mid-sized computer system installations, <3% had disaster recovery plans
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-19
Failures in Planning
• negative disasters: decision culminating in physical result, later substantially modified, reversed or abandoned after heavy resource commitment– Edsel; FoxMeyer ERP
• positive disasters: decision culminating in physical results implemented despite heavy criticism, subsequently felt by many informed people to have been a mistake– Anglo-French SST; BART in San Francisco
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-20
Failures of Projects
• information technology• 1992 - London Ambulance Service
– 1.5 million pound system on line 26 Oct 1992– immediately lost ambulances– <20% of dispatched ambulances reached
destinations within 15 minutes of summons– (before system, 65% met 15 minute standard)
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-21
Failures of Projects
• Some never work• others over budget, very late, or both• others perform less than design• others meet design specifications, but
maintenance & enhancement nightmares
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-22
Systems Failure Method
• model• manipulate model to better understand system• compare planned system with
– robust system capable of working without failure
– past failed systems• GOAL: systematic interpretation of failure
leading to corrective action
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-23
Modeling Systems
name & define system; describe components; describe relationships; identify wider system; describe inputs & outputs; identify system variables; establish structural relationships that describe system
behavior
tools: systems diagrams (input-output)
systems maps snapshot of system & environmentinfluence diagrams to explore relationships
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-24
Comparison
• formal system model– compare what you think happened with model
of system
• formal system– decision-making subsystem– performance-monitoring subsystem– task performing subsystems– continuous purpose, connectivity of components,
environment & boundaries, resources
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-25
common results
failure commonly a result of• organizational structure deficiencies
– lack of performance-measuring, control• no clear statements of purpose• subsystem deficiencies• lack of effective communication between subsystems• inadequate design• insufficient consideration of environment; insufficient resources• imbalance of resources production quantity; test quality
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-26
Control
• action to reach or maintain desired state• classical feedback control - if output doesn’t
match target, adjust• modern feedback control - if output bad, model
output & effects of changes• feedforward control - predict outcome before
production• common problem - misreading output
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-27
Communication
• failure often due to link missing, inadequate, or not used
• vicious circle– information overload– restriction of communication– distortion & omission– more messages
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-28
Human Aspects
• who is responsible for what• what is appropriate conduct• what information is communicable• what is considered fixed & unchangeable• how problems are to be solved
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson5-29
Summary
• Requirements analysis needed to identify what system is to do– Functionality best obtained from sponsor– Technical requirements best from IT
• Group systems can aid reaching consensus– Nemawashi approach one alternative– Brainstorming another– Delphi yet another
• Systems failure approach a systematic way to deal with project complexity and risk