Chapter 5: Requirements Analysis

2. Chapter 5: Requirements Analysis Elicitation from users Project risk Outsourcing

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

4. Meetings Interviews Brainstorming Structured methods Nominal Group Technique Delphi User Requirement Elicitation

5. 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 Caterpillar: Extranet

6. 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 Objectives Meeting

7. Facilitate groups facing unstructured decisions Easy to use Record points discourage conflict, miscommunication, groupthink aid negotiation, compromise Group Support Systems

8. 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 Group Support Systems

9. PC Magazine 14 June 1994 E-Mail Electronic Bulletin Board Products Conferencing Software Whiteboard Software Desktop Videoconferencing Structured Group Discussion Meeting Room Software Group Support System Products

10. Japanese Coordinator visits group participants Privately identifies their needs individually Generates solution acceptable to all Selects plan most likely to be accepted Negotiates and persuades Document circulated Once agreement reached, hold meeting Nemawashi Approach

11. Risk identification - identify, rank Risk analysis convert data into understanding Risk control - measure, implement control Risk reporting NOT step-by-step: continuous process Risk Analysis

12. Brainstorming Nominal Group Technique structured: initial ideas recorded, discuss, evaluate Delphi anonymous input, shared evaluation, cycle Risk Identification Methods

13. 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) State of Washington

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

15. 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 Star*Doc

16. 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 Features Found in Successful Projects

17. the Systems Failure Method Learning from Failure: The Systems Approach Joyce Fortune & Geoff Peters, Wiley, 1995

18. 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 Systems Failure Method

19. 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 Failures in Planning

20. 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) Failures of Projects

21. Some never work others over budget, very late, or both others perform less than design others meet design specifications, but maintenance & enhancement nightmares Failures of Projects

22. 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 Systems Failure Method

23. 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 & environment influence diagrams to explore relationships Modeling Systems

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

25. 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 common results

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

27. failure often due to link missing, inadequate, or not used vicious circle information overload restriction of communication distortion & omission more messages Communication

28. who is responsible for what what is appropriate conduct what information is communicable what is considered fixed & unchangeable how problems are to be solved Human Aspects

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