The Analysis Phase Objective: To study the current system, organization, and problems to determine what changes need to be made in order to achieve the organization’s goals. Thus, the focus of the analysis phase is the CURRENT situation, not the new system that will be implemented.

Steps in Analysis Requirements gathering Requirements structuring using interviews, observations, documents, etc. to learn about the customer’s business, their current systems, and its problems Requirements structuring using DFDs, ERDs, logic models, etc., to represent and organize the information gathered Generation of alternatives based on the requirements, investigate possible changes that would achieve the customer’s objectives

Inputs to Analysis Customer information Technical information from interviews, observations, documents, etc. information about goals, objectives, problems, work processes, current systems, constraints, etc. Technical information from previous experience, web searches, vendor literature, previous education information about what technology is available, what it can do, how it works, and how much it costs

Output of Analysis The Systems Proposal summarizes all the information gathered and structured during analysis presents alternative solutions compares solutions in terms of costs, benefits, feasibility, ability to solve problems, etc. provides all the information the customer needs to make a decision recommends one solution

Steps in Analysis 3 steps: gather requirements structure requirements generate alternatives

Gathering requirements When starting to gather information, you have to decide: what information sources to consult what information gathering methods to use

Choosing information sources Problem: too many information sources for the time and resources available Solution: sampling Convenience - whoever shows up or responds Purposive - each information source individually selected Random - left completely to chance Stratified - randomly picked from specific categories

Sample size Heuristics: make sure all functions are covered make sure both ends of system are covered try to get two sources for each piece of information – triangulation

Information gathering methods Interviewing Questionnaires Observation Documents

Interviewing Focus on getting not facts opinions feelings goals procedures (both formal and informal) not facts

Steps in interview preparation Read background material Establish objectives Decide who to interview Schedule Design interview guide

Interview Guide Logistical info: record name, office#, date, time Organization: How long have you worked on [project]? At [company]? Have you worked with any of the [project] members before on other projects? Who on the [project] team do you interact with most? To whom do you report? To whom are you responsible for your progress on [project]? Inspection process: Who chose the inspectors? How long did it take? Why were those ones chosen in particular? Which inspectors inspected what? Who took care of scheduling? Was it done via email or face-to-face? How much time did it take? What steps were involved in putting together the inspection package? How much time did that take? How are [project] inspections different from inspections in other [company] projects you’ve been on? How was this inspection different from other [project] inspections you’ve been involved with?

Interview questions Open vs. closed Probes Pitfalls: leading questions double-barreled questions judgmental questions

Recording of interviews Audiorecording Notetaking Scribing

Interviewing pointers give clues about the level of detail you want no more than 45-60 minutes end with “anything else I should know?” dispel any notion of the “right” answer feign ignorance let interviewee know next steps say Thank you!

Writing up the interview ASAP!!!!

Questionnaires Most useful when you want an overall opinion from a wide variety of dispersed people Use to get the majority opinion Can be combined with interviews

Questionnaire questions Open (qualitative) richer data must be fairly specific to get comparable answers not useful with a very large number of respondents Closed (quantitative) easier to analyze use when all possible responses can be anticipated and are mutually exclusive Appropriate terminology Pilot use

Administering the questionnaire balance between your convenience and that of your subjects paper-based vs. electronic general availability vs. mail vs. personal delivery mandated vs. voluntary

Accuracy Triangulation => sometimes you’ll get different answers to the same question different perspectives actual practice different from policy sometimes one source clearly more reliable Reconciling answers must be done sensitively ask a third person interview a group observation

Observation When you need to learn: Time sampling vs. event sampling what is actually done, as opposed to what is described what interactions are going on what goes into decision-making Time sampling vs. event sampling Need both typical and atypical situations Very expensive

Observation methods Shadowing Participant observation Think-aloud protocols Prior ethnography

Documents Artifacts of paper-based system Procedure descriptions data collection forms - blank and used reports Procedure descriptions System documentation Policy handbooks Archival documents

Joint Application Design (JAD) Method for doing requirements and UI design with users Requires a 2-3 day meeting with users, analysts, senior people, technical consultants, etc. Useful when innovation is important and it’s feasible to get everyone together Benefits: gets requirements over quickly user ownership creativity Drawbacks: takes a big commitment dependent on administrative effectiveness can be political

Prototyping used iteratively to: pitfalls: clarify what a user has said they wanted show a user what they’ve suggested to compare different ways of implementing a user’s suggestion pitfalls: design can become too tied to one user’s wishes user may be unwilling to give up the prototype later concerns may impact interface design prototyping may never end

Evolutionary vs. Revolutionary System Change SA&D is an evolutionary process processes are changed in small ways changes are based on current practice analysis is of current processes revolutionary approach Business Process Reengineering (BPR) making radical changes without being inhibited by current practice motivated by: drastic changes in the environment need to increase profits dramatically innovative and creative managers