Analysis

1. Analysis Requirement determination (Ch. 6) Requirement structuring Process Modeling ( Ch. 7 Logic Modeling (Ch. 8) Data Modeling (Ch. 9)

2. Chapter 6 Determining System Requirements 7.2 Chapter 6

3. Learning Objectives • Traditional techniques: • Ethnography ( Observation in the work environment) • Collecting facts from existing Procedures and written document • Interviews • Questionnaires • Modern Techniques • Joint Application Design ( JAD) • Group Support Systems • CASE Tools • Prototyping • Apply requirements determination to Internet applications 7.3

4. Performing Requirements Determination • . All these requirements are carefully documented. • Requirement determination and requirement structuring are done simultaneously and iteratively.

5. Performing Requirements Determination • Once the management has granted permission to pursue development of the system, after the initiation and planning phase, the system Analyst determines what the system should do by gathering information from many sources • Users • Reports • Forms • Procedures 7.5

6. Performing Requirements Determination • Characteristics for gathering requirements • Impertinence • Question everything • Impartiality • Find the best organizational solution by considering issues raised by all the stakeholders. • Relaxation of constraints :Assume anything is possible and eliminate the infeasible. Don’t turn traditions (which are different from rules) into habits rather than sensible procedures. 7.6

7. Performing Requirements Determination • Attention to detail • Every fact must fit with every other fact. One element out of place means that the ultimate system will fail at some time. • Reframing • As analysis is a creative process. View the organization in new ways. Consider how each user view his or her requirements. Be careful not to jump on the conclusions.

8. Deliverables and Outcomes • Types of deliverables: • Information collected from conversation with or observation of users • Transcripts of interviews • Notes from observation and analysis of documents • Analyzed responses from the questionnaires 7.8

9. Deliverables and Outcomes • Computer-based information • prototypes, • results from JAD sessions, • transcripts or files from group support system sessions, • CASE repository contents and reports of existing systems.

10. Deliverables and Outcomes • Existing written information • Business mission and strategy statements, • Existing sets of business forms and reports, computer displays, procedure manuals, job description, training manuals, flowcharts and documentation of existing system, consultant reports.

11. Deliverables and Outcomes • Understanding of organizational components • The business objective that drive what and how work is done • The information, people need to do their jobs • The data handled within the organization to support the jobs. • When, how by whom and what data are moved, transformed and stored. • The rules governing how data are handled and processed. • Key events affecting data values and when these events occur.

12. Analysis Paralysis • The time required to collect and structure large information can be extensive. • But too much Analysis is not productive because it will result in “ Analysis Paralysis” which means development work is involved in too much of analysis work and never comes out of this phase.

13. Traditional Methods for Determining Requirements • Interviews • Questionnaires • Ethnography (Observation in the work environment) • Collecting facts from existing Procedures and written document

14. Interviewing and Listening • Interview people about their work, the information they use to do it, the type of information processing that might add to their work. • Interview people to understand organizational direction, policies, expectations managers have on the units they supervise. • Gather facts, opinions and speculations (assumptions) • Observe body language and emotions of what people want and how they assess current system 7.14

15. Interviewing and Listening • Guidelines • Plan the interview • Prepare interviewee: appointment, priming questions • Prepare Checklist: agenda and questions • Listen carefully and take notes (tape record if permitted)

16. Interviewing and Listening • Review notes within 48 hours of interview • Be neutral • Seek diverse views • Do not phrase questions in ways that imply a wrong or right answer • Listen very carefully to what is being said • Do not set expectations about the new system unless you are sure. • Seek a variety of perspective from the interviews such as managers, information system staff, end-users etc. 7.16

17. Interviewing and Listening • Interview Questions • Open-Ended • No pre-specified answers • Facilitates faster interviews • Easily analyzed and compared • Close-Ended • Respondent is asked to choose from a set of specified responses • Not good to put too many closed ended questions

18. Interviewing and Listening • Listen carefully what is being said. Take notes. • Record the interview • Once the interview is over, type your notes within 48 hours. • During the interview, do not set expectations about the new replacement system, unless u are sure these features will be a part of the delivered system. • Seek a variety of perspectives from the interviews.

19. Interviewing and Listening • Involve respondents in the interview as soon as possible. • Don’t asks controversial matters in the beginning • Ask questions about the present before about the future. • The last questions should be open ended to allow the respondents to add their impressions of the interview. • Questions should be worded carefully. • Be careful asking ‘WHY’ questions • Questions should be asked one at a time. • Be careful about the appearance when taking notes • Attempt to remain as neutral as possible • Occasionally verify the tape recorder is working. • Don’t lose control of the interview

20. Administering Questionnaires • More cost-effective than interviews • Choosing respondents • Should be representative of all users, if there are more people to survey than you can handle • Types of samples • Convenient to sample e.g. people at local site • Random group sample e.g. choose every nth person on the list 7.20

21. Administering Questionnaires • Purposeful sample e.g. specify only people who satisfy certain criteria such as users of the system for more than 2 years or users who use the system most often. • Stratified sample e.g. choose a random set from several categories such as users, managers, foreign business unit users • Once the questionnaires are returned, • check for non response bias and • find out the results out of the responded questionnaires.

22. Designing Questionnaires • Questionnaires • usually administered on paper, on websites or diskettes. • closed ended questions as they are easier to complete and define exact coverage required, • more questions than interview and sometimes a few open ended questions are included which adds insights not anticipated by the designer of the questionnaire. • Questions should be clear in meaning • Questions should have logical sequence • Avoid awkward phrasing; instead break the questions in multiple questions • Avoid sloppily (messily) worded questions while composing questionnaire which cannot be identified every time.

23. Questionnaires • Advantages: • Most questionnaires can be answered quickly. • Inexpensive means for gathering data. • Allows individuals to maintain anonymity; can provide the real fats • Responses can be tabulated and analyzed quickly.

24. Questionnaires • Disadvantages • The number of respondents is often low. • There is no guarantee that an individual will answer or expand on all the questions. • Questionnaires tend to be inflexible i.e. questions cannot be reworded that are misinterpreted. • No immediate opportunity to clarify a vague or incomplete answer to any question • Good questionnaires are difficult to prepare.

25. Traditional Methods for Determining Requirements 7.25

26. Collecting Facts from existing Documentation • The documents the analyst should seek out are the following: • Organizational chart • Documents that describe the problem • Customer Complaint, reports that document the problem area. • Accounting records, performance reviews • Information systems project requests

27. Collecting Facts from existing Documentation • Documents that describe the business function being studied or observed. • Organization’s mission statement and strategic plan. • Objectives for the organization • Policy manuals, placing constraints • Standard operating procedures, tasks instructions • Samples of manual and computerized databases • Samples of manual and computerized screens and reports.

28. Collecting Facts from existing Documentation • Documentation of the existing system and designs • Various types of flow charts and diagrams • Project dictionaries and repositories • Design documentation, such as i/p, o/p and databases. • Computer operation manuals and training manuals.

29. Observation • This is a fact-finding techniques wherein the systems analyst either participates in or watches a person perform activities to learn about the system. • This techniques is often used when the validity of data collected through the other method is in question.

30. Observation • Advantages: • Data gathered by observation can be highly reliable. • The SA is able to see exactly what is being done. She can identify tasks that have been missed or inaccurately stated by other fact-finding technique. • Observation is relatively in-expensive compared with other fact-finding technique.

31. Observation • Disadvantages • Because people usually feel uncomfortable when being watched, they may unwittingly perform differently when being observed. • Some system activities may take place at odd times, causing a scheduling inconvenience fro the systems analyst.

32. Observation • Guidelines for observation • The SA must determine how data will actually be captured. • Will special form on which to quickly record data be necessary • Will the individual being observed be bothered by having someone watch and record their actions ? • When are low, normal, peak periods of operations for the task to be observed? • Observations should first be conducted when the workload is normal, afterwards, during peak periods to gather information caused by the increased volume.

33. Traditional Methods for Determining Requirements • Interviewing Groups: Several people are interviewed at a time. • Advantages • More effective use of time • Enables people to hear opinions of others and to agree or disagree with the peers. • Disadvantages • Difficulty in scheduling. (Video Conferencing /phones can minimize it) • Nominal Group Technique • Facilitated process to support idea generation by groups • Individuals work alone to generate ideas which are pooled under guidance of a trained facilitator 7.33

34. Traditional Methods for Determining Requirements • Directly Observing Users • Serves as a good method to supplement interviews • Often difficult to obtain unbiased data • People often work differently when being observed 7.34

35. Analyzing Procedures and Other Documents • Types of information to be discovered: • Problems with existing system • Opportunity to meet new need • Organizational direction • Names of key individuals • Values of organization • Special information processing circumstances • Reasons for current system design • Rules for processing data 7.35

36. Analyzing Procedures and Other Documents • Four types of useful documents • Written work procedures • Describes how a job is performed • Includes data and information used and created in the process of performing the job or task • Business form • Explicitly indicate data flow in or out of a system • Report • Enables the analyst to work backwards from the report to the data that generated it • Description of current information system 7.36

37. Modern Methods for determining System Requirements • Joint Application Design (JAD), group support systems • CASE Tools • Using Prototyping

38. Joint Application Design • A structured process in which users, managers and analyst work together for several days in a series of intensive meetings to specify or review system requirements. Here requirements are collected in an organized manner. • In that respect, JAD is similar to group interview, however it follows a particular structure of roles and agenda that is quite different from a group interview during which analysts control the sequence of questions answered by users.

39. Joint Application Design • With group interviews , having all the people together in one place at one time, allows analyst to see where there are areas of agreement and where there are conflicts. The sessions also allows SA to resolve conflicts or at least understand why a conflict may not be simple to resolve.

40. Joint Application Design • JAD sessions are conducted in allocation other than the place where the people involved normally work, so as to have minimum distraction. • A JAD may lat from 4 hours to an entire week and may consists of many sessions. • A JAD employs thousands of dollars of corporate resources, the most expensive of which is the time of the people involved.Other expenses include cost for boarding and lodging.

41. Joint Application Design • The typical participant are: • JAD session leader • Users • Managers • Sponsor • Systems Analyst • Scribe

42. Joint Application Design • JAD session leader is a trained individual who organizes and runs the JAD. He sets the agenda and sees that it is met. He remains neutral on issues and does not contribute ideas or opinions but rather concentrates on keeping the group on the agenda, resolving conflicts and disagreements and soliciting all ideas.

43. Joint Application Design • The key users of the system under consideration are vital participants in a JAD. They have clear understanding of how the system works on daily basis.

44. Joint Application Design • Managers of the work group who use the existing system provide insight into new organizational directions, motivations for and organizational impacts of systems and support for requirements determined during the JAD.

45. Joint Application Design • Sponsor is one at a relatively high level in the company, who sponsors a JAD session. He attends at the beginning or at the end of any sessions. • Members of Systems Analysis team attend the JAD, who are there to learn from users and managers, not to run or dominate the process.

46. Joint Application Design • The Scribe takes notes during the JAD sessions. This is usually done on a personal computer or laptop. Notes may be taken from a word processor or notes and diagrams may be entered directly into a CASE tool.

47. Joint Application Design • JAD sessions are usually held in special-purpose rooms where participant sits around a U_shaped table. These rooms are equipped with white boards (possibly electronic, with a printer to make copies of what is written on the board). • Other audio-visual tools may be used, such as transparencies and overhead projectors, magnetic symbols that can be easily arranged on the white boards, flip charts and computer generated displays.

48. Joint Application Design • Flip chart paper is typically used for keeping track of issues that can be resolved during the JAD or for those issues requiring additional information that can be gathered during breaks in the proceedings. • Computer may be used to create and display form or report designs, for diagramming existing or replacement systems and for prototyping.

49. Joint Application Design (JAD) • End Result • Documentation detailing existing system • Features of proposed system • CASE Tools During JAD • Upper CASE tools are used • Enables analysts to enter system models directly into CASE during the JAD session • Screen designs and prototyping can be done during JAD and shown to users 4.50

50. Joint Application Design (JAD) • Supporting JAD with GSS • Group support systems (GSS) can be used to enable more participation by group members in JAD • Members type their answers into the computer • All members of the group see what other members have been typing 7.51