Information Systems System Analysis 421 Class Four

7.2

Learning Objectives

   Describe options for designing and conducting interviews and develop a plan for conducting an interview to determine system requirements Design, distribute, and analyze questionnaires to determine system requirements Explain advantages and pitfalls of observing workers and analyzing business documents to determine requirements

7.3

Learning Objectives

     Explain how computing can provide support for requirements determination Learn about Joint Application Design (JAD) Use prototyping during requirements determination Select the appropriate methods to elicit system requirements Apply requirements determination to Internet applications

7.4

Deliverables and Outcomes

• Types of deliverables: – Information collected from users – Existing documents and files – Computer-based information – Understanding of organizational components • Business objective • Information needs • Rules of data processing • Key events

System Analysis

• System Analysis – What - System analysis is a general systematic process of developing a solution to a problem – Why - The focus of systems analysis is on the analysis of the problem and the systematic approach to developing a solution – How - System analysis is essentially a decision making process - requirements

Study Phase

Survey • What is done • Where is it done • Who does it • How is it done Analyze

Summarize

• Why is it done • Why is it done there • Why does this person do it • Where should it be

done

• When should it be done • Why is it done • What should be done • How should it be done

System Analysis

• Requirements – Studying the current business system to find out how it works and where improvements can be made – Features that may/must be included in the new system – Helps define the scope of the project – Not an order taking process

Define Requirements

• Requirements are not supposed to dictate any details regarding the implementation of a solution.

• We commonly define differing levels of necessity (priorities) for our requirements, such as “absolutely must be satisfied”, “nice to have”, and “optional”. • Some requirements may apply to an entire system, while others apply only to part of the system .

• Compromise is often necessary for conflicting requirements from different user(s).

• Some requirements are static, while others are dynamic and evolve or emerge over time.

• Requirements are not always easy to explain (communicate), understand, or document

Define Requirements

• One very common way to document requirements is a text document containing a list of bulleted items, i.e., the requirements. • Each requirement is (ideally) stated in the form of a single sentence.

• The document contains a way of differentiating requirements that are essential/demanded from requirements that are optional/suggested .

• Included but missed often, security, controls and system interfaces • Develop a business solution not a technical solution 1 of 2

Define Requirements

• Both product and project requirements may have associated priorities and constraints.

• A priority is a level of importance assigned to an item - helps define which items take precedence over other items.

• A constraint is a limit or a restriction placed on an item or situation - helps define the scope (boundaries) of an item or situation .

Case Study

Management has approached you to develop a new system. The project will last seven months. Management wants a budget next week. You will not be allowed to deviate from that budget. Explain why you shouldn't overcommit to early estimates. Defend the creeping commitment approach as it applies to cost estimating. What would you do if management insisted on the up-front estimate with no adjustments?

7.12

Performing Requirements Determination

• Gather information on what system should do from many sources – Users – Reports – Forms – Procedures

System Initiation

 Pieces  Performance    Throughput – the amount of work performed over some period of time.

 Response time – the average delay between a transaction or request and a response to that transaction or request Information  Lack of any information  Lack of necessary information  Lack of relevant information Economics • Costs are unknown • Costs are untraceable to source • Costs are too high • N Profits Hew markets can be explored

System Initiations

• Controls – Too little security or control – Decision making errors are occurring – Processing errors are occurring • Efficiency – Effort is manual or excessive – Duplication • Service – Inaccurate results – Inflexible to business changes – Not coordinated with other systems – Difficult to use

7.15

Performing Requirements Determination

• Characteristics for gathering requirements – Impertinence • Question everything – Impartiality • Find the best organizational solution – Relaxation of constraints – Attention to detail – Reframing • View the organization in new ways

Fact Finding

• Fact-finding is the formal process of using research, interviews, questionnaires, sampling, and other techniques to collect information about systems, requirements, and preferences..

• Tools, such as data and process models, document facts, and conclusions are drawn from facts. – – If you can't collect the facts, you can't use the tools. Fact-finding skills must be learned and practiced.

– Systems analysts need an organized method of collecting facts.

Data Gathering

       Historical data Organization Charts Structure and key decision makers Present job descriptions - Standard operating procedures (SOPs), job outlines, or task instructions for specific day-to-day operations.

Volume Statistics Total volume; peak loads Current Written Procedures Exactly what each person does; when; where; and time required Policies governing the area Formal and informal Past reviews and studies May save time and effort

Data Gathering

• Gather Current System Documents – Input provided – Completed forms that represent actual transactions at various points in the processing cycle.

– Manual and computerized databases and screens – Output produced and distribution of output – Information flow – Controls – System documentation – Flowcharts and diagrams.

– Project dictionaries or repositories – Design documentation, such as inputs, outputs, and databases.

– Program documentation.

– Computer operations manuals and training manuals.

Data Gathering

– Trace the history that led to this project. • Collect and review documents that describe the problem. These include: – Interoffice memoranda, studies, minutes, suggestion box notes, customer complaints, and reports that document – Accounting records, performance reviews, work measurement reviews, and other scheduled operating – Information systems project requests – past and present • As you review documents, take notes, draw pictures, and model what you are learning or proposing for the system.

• It would be impractical to study every occurrence of every form. Use sampling techniques.

• Don’t sample blank forms -- they tell little about how the form is used, not used, or misused. • When studying documents or records from a database table, study enough samples to identify all possible processing conditions and exceptions.

Data Gathering - Interview

    Most popular data gathering techniques Interviews should be conducted with people from all levels within the organization Considerable preparation must be done State the objective of the interview Prepare for the interview Set up the interview Conduct the interview Document the interview Interview tips Be on time Don't ask 'yes' or 'no' questions Explore questions Converse don't interrogate

Data Gathering - Interview

• Advantages: • Opportunity to motivate the interviewee to respond freely and openly to questions.

• Opportunity to probe for more feedback from the interviewee.

• Opportunity to adapt or reword questions for each individual.

• Opportunity to observe the interviewee's nonverbal communication.

• Disadvantages: • Interviewing is a very time-consuming, and therefore costly, fact-finding approach.

• Success of interviews is highly dependent on the analyst's human relations skills.

• Interviewing may be impractical due to the location of interviewees. [Telephone interviews are useful, but not nearly as good.]

7.22

Data Gathering - Interview

• Interviewing and Listening – Gather facts, opinions and speculations – Observe body language and emotions – Guidelines • Plan – Checklist – Appointment • Be neutral • Listen • Seek a diverse view

7.23

Data Gathering - Interview

• Interviewing (Continued) – Interview Questions • Open-Ended – No pre-specified answers • Close-Ended – Respondent is asked to choose from a set of specified responses – Additional Guidelines • Do not phrase questions in ways that imply a wrong or right answer • Listen very carefully to what is being said • Type up notes within 48 hours • Do not set expectations about the new system

Data Gathering - Questionnaires

• Questionnaires are documents that allows the analyst to collect information and opinions from respondents.

– can be mass produced and distributed to respondents, who then complete the questionnaire on their own time. • Questionnaires allow the analyst to collect facts from a large number of people while maintaining uniform responses. – When dealing with the large audience, no other fact finding technique can tabulate the same facts as efficiently.

Questionnaires should be pilot

7.25

Data Gathering - Questionnaires

• Administering Questionnaires – More cost-effective than interviews – Choosing respondents • Should be representative of all users • Types of samples – Convenient – Random sample – Purposeful sample – Stratified sample

7.26

Data Gathering - Questionnaires

• Questionnaires – Design • Mostly closed-ended questions • Can be administered over the phone or in person – Vs. Interviews • Interviews cost more but yield more information • Questionnaires are more cost-effective • See table 7-4 for a complete comparison

Data Gathering - Questionnaires

• Advantages: • Most questionnaires can be answered quickly. HA!

– People can complete and return questionnaires at their convenience.

• Questionnaires provide a relatively inexpensive means for gathering data from a large number of individuals.

• Questionnaires allow individuals to maintain anonymity.

– Individuals are more likely to provide the real facts, rather than telling you what they think their boss would want them to.

• Responses can be tabulated and analyzed quickly • Disadvantages: • The number of respondents is often low.

• There's no guarantee that an individual will answer or expand on all of the questions.

• Questionnaires tend to be inflexible. – no opportunity to obtain voluntary information from individuals or to reword misinterpreted questions.

• It's not possible to observe and analyze the respondent's body language.

• There is no opportunity to clarify a vague or incomplete answer to any question.

• Good questionnaires are difficult to prepare

Data Gathering - Observation

 Observation  Increase analyst understanding of the process   Observation is a fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system.

This technique is often used when the validity of data collected through other methods is in question or when the complexity of certain aspects of the system prevents a clear explanation by the end-users.   Serves as a good method to supplement interviews Often difficult to obtain unbiased data  People often work differently when being observed

Data Gathering - Observation

• Observation Advantages: • Data gathered by observation can be highly reliable.

• You can’t infer causality from observation.

• You see what is actually being done, rather than what they are supposed to do.

• Observation is relatively inexpensive compared with other fact-finding techniques. • Observation allows the systems analyst to do work measurements.

• Observation Disadvantages: • Because people usually feel uncomfortable when being watched, they may unwittingly perform differently when being observed. • If people have been performing tasks in a manner that violates standard operating procedures, they may temporarily perform their jobs correctly while you are observing them.

• The work being observed may be very different at different time periods. [observe accountants in May?] • The tasks being observed are subject to various types of interruptions.

Data Gathering - Research

– Research • Computer trade journals and reference books are a good source of information. • Exploring the internet and world wide web (WWW) via your personal computer can provide you with a immeasurable amounts of information. – Internet is a global network of networks. Conceived

7.31

Data Gathering - Interview

• Interviewing Groups – Advantages • More effective use of time • Enables people to hear opinions of others and to agree or disagree – Disadvantages • Difficulty in scheduling – 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.32

Analyzing Procedures

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

Analyzing Procedures

• 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

4.34

Modern Methods for Determining Requirements

• Joint Application Design (JAD) – Brings together key users, managers and systems analysts – Purpose: collect system requirements simultaneously from key people – Conducted off-site • Prototyping – Repetitive process – Rudimentary version of system is built – Replaces or augments SDLC – Goal: to develop concrete specifications for ultimate system

Joint Application Development

• Joint application design (JAD) is a process whereby highly structured group meetings or mini-retreats involving system users, system owners, and analysts occur in a single room for an extended period of time (four to eight hours per day, anywhere from one day to a couple weeks).

• JAD-like techniques are becoming increasingly common in systems planning and systems analysis to obtain group consensus on problems, objectives, and requirements. • Therefore, it is more commonly referred to as joint application development to appropriately reflect that it includes more than simply systems design.

JAD - People

• Any successful JAD session requires a single person, called the sponsor, to serve as its champion. • The JAD leader is usually responsible for leading all sessions that are held for a systems project • The role of the users is to effectively communicate business rules and requirements, review design prototypes, and make acceptance decisions.

• A JAD session also includes one or more scribes who are responsible for keeping records pertaining to everything discussed in the meeting • A JAD session may also include a number of IS personnel who are primarily in attendance to listen and take notes regarding issues and requirements voiced by the users and managers

JAD Planning

• Before planning a JAD session, the analyst must work closely with the executive sponsor to determine the scope of the project that is to be addressed through JAD sessions.

• It is also important that the high-level requirements and expectations of each JAD session is determined • JAD sessions should be conducted at a location that is away from company workplace.

• An agenda for each JAD session should be prepared and distributed prior to each session • The agenda should contain three parts: – The opening. – The body.

– The conclusion.

JAD Session

Food & Refres hm ents 41' - 0" IS Profes s ionals & Other Obs ervers Us ers and Managers Flipchart Overhead Projector Com puter Projection Device JAD Leader Blackboard Scribe Works tation Printer

JAD Benefits

 An effectively conducted JAD session offers the following benefits:  JAD actively involves users and management in the development project (encouraging them to take own more an “ownership” in the project).

  JAD reduces the amount of time required to develop systems. When JAD incorporates prototyping as a means for confirming requirements and obtaining design approvals, the benefits of prototyping are realized.

7.40

Prototyping

• Quickly converts requirements to working version of system • Once the user sees requirements converted to system, will ask for modifications or will generate additional requests • Most useful when: – User requests are not clear – Few users are involved in the system – Designs are complex and require concrete form – History of communication problems between analysts and users – Tools are readily available to build prototype

7.41

Prototyping

• Drawbacks – Tendency to avoid formal documentation – Difficult to adapt to more general user audience – Sharing data with other systems is often not considered – Systems Development Life Cycle (SDLC) checks are often bypassed

7.42

Business Process Reengineering (BPR)

• Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services • Goals – Reorganize complete flow of data in major sections of an organization – Eliminate unnecessary steps

7.43

Business Process Reengineering (BPR)

• Goals (Continued) – Combine steps – Become more responsive to future change • Identification of processes to reengineer – Key business processes • Set of activities designed to produce specific output for a particular customer or market • Focused on customers and outcome • Same techniques are used as were used for requirements determination

7.44

Business Process Reengineering (BPR)

• Identify specific activities that can be improved through BPR • Disruptive technologies – Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes

7.45

Summary

• Interviews – Open-ended and close-ended questions – Preparation is key • Questionnaires – Must be carefully designed – Can contain close-ended as well as open-ended questions

7.46

Summary

• Other means of gather requirements – Observing workers – Analyzing business documents • Joint Application Design (JAD) • Prototyping • Business Process Reengineering (BPR) – Disruptive technologies