1. Information Systems System Analysis 421 Class Four

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

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

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
7.4

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

6. Study Phase Survey Analyze Summarize What is done Where is it done
Who does it
How is it done
Analyze
Why is it done
Why is it done there
Why does this person do it
Summarize
What should be done
Where should it be done
When should it be done
How should it be done

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

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

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

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

11. 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?

12. Performing Requirements Determination
Gather information on what system should do from many sources
Users
Reports
Forms
Procedures
7.12

13. System Initiation Pieces Performance Information Economics
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

14. System Initiations Controls Efficiency Service
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

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
7.15

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

17. Data Gathering May save time and effort 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

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

19. 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 the problem area.
Accounting records, performance reviews, work measurement reviews, and other scheduled operating reports.
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.

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

21. 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.]

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

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
7.23

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

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

26. Data Gathering - 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
7.26

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

28. Data Gathering - 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

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

30. Data Gathering - 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 in 1964 by the United States Department of Defense to create a national military communications network that would be imperious to attacks.

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

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

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
7.33

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
4.34

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

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

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

38. JAD Session

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

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

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

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

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

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

45. Summary Interviews Questionnaires 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.45

46. Summary Other means of gather requirements
Observing workers
Analyzing business documents
Joint Application Design (JAD)
Prototyping
Business Process Reengineering (BPR)
Disruptive technologies
7.46