Chapter 5: Requirements Analysis

Elicitation from users

Project risk

Outsourcing

Analysis of user needs

• 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…

Requirements Elicitation Techniques Include: 

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

Objectives and Agendas

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

Group Support Systems

• 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

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 Products

PC Magazine 14 June 1994

• E-Mail• Electronic Bulletin Board Products• Conferencing Software• Whiteboard Software• Desktop Videoconferencing• Structured Group Discussion Meeting Room

Software

Nemawashi Approach• 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 participants1. Privately identifies (collect) their needs individually2. Generates solution acceptable to all3. data analysis and plan generation4. Selects plan most likely to be accepted5. Negotiates and persuades6. Document circulated

• Once agreement reached, hold meeting

Nemawashi Approach advantage

• Better quality decisions

• Implementation will be much easier

• Higher morale

• Risk taking is shared

• Each Individual’s wishes are considered

Risk Identification and Analysis

• 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 reportingNOT step-by-step: continuous process

Remember: the riskier the project, the more diverse a project team you need.

Risk Identification Methods

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

State of Washingtonscrap an IS project

• 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

IRSanother project Failure

• 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

An example of Project Failure Star*Doc

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

The Seven Characteristics Of Highly Successful Projects

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 7 Habits of Highly Effective People

• 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”. والهم اكتشفصوتك

باكتشاف - لالنسان الداخلى الصوت اكتشاف ويتم باكتشافاصواتهم االخرينواالستجابة : المثير بين االختيار حرية وهى لالنسان الله منحها التى الهدايا واستغاللبالصفات - بالتحلى تقوم ثم والروحية والجسمية والعقلية العاطفية االربع والذكاءاتعنسرطاناتسلوكية وباالبتعاد والضمير والحماسوالنضباط الرؤية وهى االربعاالخرين - تلهم ولكى والمعارضة والمنافسة والمقارنة والشكوى االنتقاد مثل سلبيةاداور اربع فى تتمثل وهى القيادة بادوار التحلى الى تحتاج اصواتهم على ليعثرواالحسنة - بالقدوة التحلى معناه فالتركيز والتنفيذ التركيز هما كلمتين تتلخصفىيكون ( ) والتنفيذ االهداف وتحديد الرؤية فى االخرين اشراك المسار ووتحديدبالهام االهدافوالتمكين لتحقيق المناسبة والسياسات االنظمة فىوضع بالتوفيق

النتائج وتحقيق للعمل وقدراتهم ومواهبهم وهمتهم حماسهم وشحذ  االخرين

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

The 8 Habits of Highly Effective Project Managers

• 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 Systems Failure MethodLearning 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.

System Failure Method

• 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

Systems Failure Method

• 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

• “The most Successful people are good at plan B”

Disaster Recovery Plan

• 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

Most common strategies for data protection include

• 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

Systems Failure Method Process

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

Software system methodology stages:

• 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

Failures in Planning

• “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 of Projects

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

• Some never work• others over budget, very late, or both• others perform less than design• others meet design specifications, but

maintenance & enhancement nightmares

Reasons of Failures

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

10 Primary Causes of Project Failure…

• 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

Impacts of Project Failures

• 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

Systems Failure MethodModels

• 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

Comparison

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

Quotes

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

Systems Control

• 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 Communication

• 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

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