Chapter 5: Requirements Analysis

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

2. Determine resources needed to build project, it is the initial phase of system development specific identification of what system is to do expand upon proposal specifications Requirement analysis processes: conceptual design, model of what the system should do logical design, strength and weakness of the design are assessed. Validation, ensure that a valid requirement has been developed formal specification, identify a complete set of information requirements, includes inputs, outputs… Analysis of user needs

3. Brainstorming: Brainstorming sessions are used to let the stakeholders come up with creative ideas or new approaches to a problem Requirement workshops (JAD): Workshops are facilitated meetings with multiple stakeholders to draw out and document requirements. Some of the benefits of this techniques are: - Costs are lower than multiple interviews - Gives a structure to the capture and analysis of the requirements process - Dynamic, interactive, cooperative - Involves users and cuts across organization boundaries - Helps to identify and prioritize needs and resolve contentious issues - Helps to manage user’s expectations and attitude towards change Interviewing: Interviews are in-person meetings where the business analyst asks questions to get information from the stakeholder. Surveys/questionnaire: Surveys are used to gather information anonymously from the stakeholders. Documentation Review and analysis: This is the process of obtaining requirements from written documentation such as manuals. Prototyping: This is the use of partially finished versions of the software that have been created to help validate requirements Focus Groups: Focus Groups are group interviews where the business analyst raises issues and questions to obtain information from the stakeholders. Observation: Observation is when the business analyst watches the users performing their daily tasks and asks questions about the tasks and work. Requirements ElicitationTechniques Include: 

4. Most people agree that one of the most important ingredients of a meeting is an "agenda" and that a meeting is successful if the agenda is adhered to and completed. Without a doubt, a meeting with an agenda that serves as a focal point is more successful than a meeting that without an agenda or a time schedule. However, an agenda is not enough. It usually includes only a list of topics to be covered, a time schedule, and the name of the presenter for each item … The way to avoid problems is to establish one or more clearly stated objectives for the meeting. An agenda can then be created to support the objectives. Simply speaking: - Objectives are focused, agendas are not. - Objectives define the desired outcome of the meeting; agendas define only the topics to be covered. - Objectives give teams and groups something to strive for; agendas give them something to endure. - Objectives call for active participation; agendas permit passivity. Objectives and Agendas

5. Facilitate groups facing unstructured decisions, in batch mode or interactively. Easy to use, need a little investment in software, but yield time saving. Record points. (whiteboard can be used to post opinions and comments at their convenience) discourage conflict, miscommunication. aid negotiation, compromise Group Support Systems

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

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

8. Nemawashi - literally meaning 'going around the roots' (ne = roots; mawasu = go around), is a Japanese word which is quite difficult to interpret effectively, although it may be often translated as "laying the groundwork". Sometimes difficult for foreigners to understand, it is deeply embedded into the Japanese (work) culture. Nemawashi is kind of a semi-formal consensus building technique, wherein the person who has a new proposal informally talks to the key stakeholders and decision makers and gathers support and feedback beforehand, much before everybody actually goes into a formal meeting to discuss the proposal. Japanese (emphasis on team effort, relying on everyone in the organization to work toward the same goal) Coordinator visits group participants Privately identifies (collect) their needs individually Generates solution acceptable to all data analysis and plan generation Selects plan most likely to be accepted Negotiates and persuades Document circulated Once agreement reached, hold meeting Nemawashi Approach

9. Better quality decisions Implementation will be much easier Higher morale Risk taking is shared Each Individual’s wishes are considered Nemawashi Approach advantage

10. If you do not attack the risk, the risk will attack you Risk identification - identify, rank Risk analysis convert data into understanding Risk control - measure, implement control Risk reporting NOT step-by-step: continuous process Remember: the riskier the project, the more diverse a project team you need. Risk Identification and Analysis

11. Brainstorming, To achieve the desired outcome it is essential to select participants that are familiar with the topics discussed Nominal Group Technique, (NGT) is a decision making method for use among groups of many sizes, who want to make their decision quickly, as by a vote, but want everyone's opinions taken into account. First, every member of the group gives their view of the solution, with a short explanation. Then, duplicate solutions are eliminated from the list of all solutions, and the members proceed to rank the solutions, 1st, 2nd, 3rd, 4th, and so on. Delphi, The Delphi method (  /ˈdɛlfaɪ/del-fy) is a structured communication originally developed as a systematic, interactive method which relies on a panel of experts. The Delphi method is based on the assumption that group judgments are more valid than individual judgments. anonymous opinion and ideas, shared by others to evaluate, cycled many times until reach a consensus. Risk Identification Methods

12. Initially budgeted at $ 16 M, the project cost climbed to $ 41.8 M in 1992, $51 M in 1993 and was last estimated (March 1997) at $67.5 M of which $40 M had been spent without result. 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 change some of the functions of the system Spent $40 million before cancelled (would have taken an additional $27.5 million) Lesson learned – keep project small and incremental State of Washingtonscrap an IS project

13. Computer systems developed in 1960s spend $hundreds of millions annually upgrade efforts, about 50 projects current modernization program $8 billion (design to boost tax collection from 87 to 90 percent) lose up to $50 billion/year in lost revenue 2000 staff on upgrade, 10 outside contractors for every staff Outsourced to 7 vendors in 1999, expected cost 8 billion IRSanother project Failure

14. Oz (1994) joint venture, 2 international air freight firms US, Japan reduce data redundancy, better tracking 18 month project, $3.3 million specifications for packaging only users not informed until system installed management passive massive failure An example of Project Failure Star*Doc

15. 1. A positive relationship with an active, intelligent client 2. Strong project management 3. Clear requirements, well managed 4. Ruthless change management 5. Persistent and constant process focus 6. Effective controls and communication 7. Technical leadership and excellence The Seven Characteristics Of Highly Successful Projects

16. Habit 1: Be Proactive (كن مبادرا ) Habit 2: Begin with the End in Mind (ابدأ والغاية فى ذهنك ) Habit 3: Put First Things First ( ابدأ بالاهم ثم المهم ) Habit 4: Think Win/Win (فكر بالمنفعة للجميع ) Habit 5: Seek First to Understand, Then to Be Understood ( اسع الى فهم الاخرين اولا ثم اسع الى ان يفهموك ) Habit 6: Synergize ( تكاتف مع الاخرين ), is the concept that the whole is equal to more than the sum of its parts. Habit 7: Sharpen the Saw (اشحذ المنشار ) when you practice sharpening the saw, you take time to renew yourself physically, spiritually, mentally, and socially. The 8th habit is "Find your voice and inspire others to find theirs”. اكتشف صوتك والهم الاخرين باكتشاف اصواتهم - ويتم اكتشاف الصوت الداخلى للانسان باكتشاف واستغلال الهدايا التى منحها الله للانسان وهى : حرية الاختيار بين المثير والاستجابة والذكاءات الاربع العاطفية والعقلية والجسمية والروحية - ثم تقوم بالتحلى بالصفات الاربع وهى الرؤية والحماس والنضباط والضمير وبالابتعاد عن سرطانات سلوكية سلبية مثل الانتقاد والشكوى والمقارنة والمنافسة والمعارضة - ولكى تلهم الاخرين ليعثروا على اصواتهم تحتاج الى التحلى بادوار القيادة وهى تتمثل فى اربع اداور تتلخص فى كلمتين هما التركيز والتنفيذ - فالتركيز معناه التحلى بالقدوة الحسنة ووتحديد المسار ( اشراك الاخرين فى الرؤية وتحديد الاهداف ) والتنفيذ يكون بالتوفيق فى وضع الانظمة والسياسات المناسبة لتحقيق الاهداف والتمكين بالهام الاخرين وشحذ حماسهم وهمتهم ومواهبهم وقدراتهم للعمل وتحقيق النتائج The 7 Habits of Highly Effective People

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

18. 1.  Effective Project Managers Are Lifelong Learners 2.  Effective Project Managers Are Clear Communicators 3.  Effective Project Managers Are Analytical 4.  Effective Project Managers Are Focused 5.  Effective Project Managers Value Planning 6.  Effective Project Managers Are Empathetic 7. Effective Project Managers Are Self-Starters 8.  Effective Project Managers Are Good Listeners The 8 Habits of Highly Effective Project Managers

19. the Systems Failure Method Learning from Failure Failure analysis is the process of collecting and analyzing data to determine the cause of a failure and how to prevent it from recurring.

20. Information systems are particularly prone to failure. Some never materialize, others appear late and/or over budget. Even those that are implemented often fail to deliver the promised levels of performance. The emphasis will be on 'learning by doing‘. The Systems Failures Method for the analysis of failures: - Gathering information - Pre-analysis, including diagramming techniques - Representing a failure situation as a system - Using the formal system model form - Further analysis System Failure Method

21. The approach begins with gathering as many similar cases as possible. 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

22. “The most Successful people are good at plan B”

23. A disaster recovery plan (DRP) is a documented process or set of procedures to recover and protect a business IT infrastructure in the event of a disaster It is "a comprehensive statement of consistent actions to be taken before, during and after a disaster” It is a plan put in place to recover from a disaster or interruption of key services. The business continuity plan includes: Creating of business continuity and disaster recovery policy Business impact analysis Classification of operations and criticality analysis Development of a business continuity plan and disaster recovery procedures Training and awareness, Testing Ongoing Monitoring Disaster Recovery Plan

24. backups made to tape and sent off-site at regular intervals backups made to disk on-site and automatically copied to off-site disk, or made directly to off-site disk replication of data to an off-site location, Hybrid Cloud solutions that replicate to both on-site 'appliances' and off-site data centers. the use of high availability systems which keep both the data and system replicated off-site, enabling continuous access to systems and data, even after a disaster (often associated with cloud storage) In addition organization may include: local mirrors of systems and/or data and use of disk protection technology. surge protectors — to minimize the effect of power surges on delicate electronic equipment use of an uninterruptible power supply (UPS) and/or backup generator to keep systems going in the event of a power failure fire prevention/mitigation systems such as alarms and fire extinguishers anti-virus software and other security measures Most common strategies for data protection include

25. Pre analysis, gather source material, include different viewpoints and perspectives. Identify significant failures of similar systems which require modeling the system in detail. Modeling, see next slide for software system methodology. Comparison, gain understanding Analysis, use model output to draw conclusion (inference) about the relationship of actions within the system and expected outcomes. Synthesis, (creation) is obtained when the analyst feels the learning about the system has been gained. Systems Failure Method Process

26. Identify the problem Structure the problem situation Identify human activities. Conceptualize models of human activity systems. Compare models Identify feasible desire changes, evaluate alternatives. Take action Software system methodology stages:

27. “He who fails to plan, plans to fail” “Failure is the tuition you pay for success.” “Failure is a detour, not a dead-end street.” Negative disasters: decision culminating (ending) in physical result, later substantially modified, reversed or abandoned after heavy resource commitment FoxMeyer ERP Positive disasters: decision culminating in physical results implemented despite heavy criticism, subsequently felt by many informed people to have been a mistake Failures in Planning

28. 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 standards) The problem was not so much one of excessive budgets or project delays. The issue was rather the usability of the system that leads to its final failure reported as follows: "...at 2AM on Wednesday, Nov 4, 1993, the system slows down considerably and then locks up altogether. Rebooting does not solve the problem. The automatic back-up system also fails to come on-line. A decision is made to revert to purely manual methods". Failures of Projects

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

30. 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 Reasons of Failures

31. Lack of Change Management Poor Communications Inadequate Resources Poorly Defined Requirements Inaccurate Estimates Poor Risk Management Poorly Defined Deliverables Over Optimism No Time for Project Management Improved PM Skill set Needed 10 Primary Causes of Project Failure…

32. Cost & Time Overruns Quality degradation Frustration, sometimes resulting in people quitting Stress, sometimes resulting in people quitting Low job satisfaction Low corporate market value Low public opinion May even force the company into closure Impacts of Project Failures

33. Model, represent the theory of the analyst about the result of available actions on the system. 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 MethodModels

34. Involves identifying what you think would happen with model of system under study, given the model based on similar systems. The focus of comparison is on decision making and control. Relationships between the system and wider system are needed, as well as understanding the effect of external environment. Comparison

35. Everyday is a gift, that's why they call it the present. Public speaking is the art of diluting a two-minute idea with a two-hour vocabulary. Communication--the human connection--is the key to personal and career success. He who knows, does not speak. He who speaks, does not know. To listen well is as powerful a means of communication and influence as to talk well The tongue is the only tool that gets sharper with use If you have nothing to say, say nothing. Quotes

36. Is an action to reach or maintain desired state feedback control - if output doesn’t match target, adjust, example is a thermostat. Feed forward control - predict outcome before the problem actually occurs, a chip in the refrigerator that monitor conditions and contact the manufacturers to send repair person before the damage is done common problem - misreading output Systems Control

37. Many system failures are the result of problems with communications links among system components. failure often due to link missing, inadequate links, or linked not used vicious circle in organization communication: information overload (filter communication which leads to distortion and omission) restriction of communication distortion & omission more messages Systems Communication

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