System Analysis and Design

CT026-3-1

Analysis
 Topic & Structure of the lesson

• Systems Analysis
– List FIVE (5) questions which could be used
in an interview to determine user
requirements
– List and describe the SEVEN (7) interview
steps
– List SIX (6) fact-finding techniques

CT026‐3‐1 Systems Analysis and Design System Requirements Page 2 of 45

 Learning Outcomes

By the end of this lecture, YOU should be

able to know about:
• Requirement Gathering Techniques
– Interview
– Document review
– Observation
– Surveys and questionnaires
• Types of Requirements

CT026‐3‐1 Systems Analysis and Design System Requirements Page 3 of 45

 Key Terms you must be able to use

• If you have mastered this topic, you should

be able to use the following terms correctly
in your assignments and exams:

– Fact-finding
– Interview
– Sampling
– Questionnaire
– Observation

CT026‐3‐1 Systems Analysis and Design System Requirements Page 4 of 45

 Questions asked in search of facts
are :

• WHO
• WHAT
• WHERE
• WHEN
• HOW
• WHY

CT026‐3‐1 Systems Analysis and Design System Requirements Page 5 of 45

 Fact-finding techniques

• Interview
• Document review
• Observation
• Sampling
• Research
• Surveys and questionnaires

CT026‐3‐1 Systems Analysis and Design System Requirements Page 6 of 45

 Interview

• planned meeting during which you can obtain

information from another person.

• Skills are required to plan, conduct and document

interviews.

• An information-gathering which is a directed

conversation with a specific-purpose that uses a
question and answer format.

• Most important is seek the opinion of the person you are

interviewing as opinion are more important than facts

CT026‐3‐1 Systems Analysis and Design System Requirements Page 7 of 45

 Interview
• Step 1: Determine the people to interview
– Select the right people and ask the right questions
– Don’t rely on just an organisation chart
– Decide on group and/or individual interviews
• Step 2. Establish objectives for the interview
– Determine the areas to be discussed
– List the facts you need to gather
– Upper management provides the big picture
– Users can give you specific details

CT026‐3‐1 Systems Analysis and Design System Requirements Page 8 of 45

 Interview
• Step 3. Develop interview questions
 Decide what to ask and how to phrase the question
 The same question to different people - for comparison
 Open ended questions encourage spontaneous and unstructured
responses
 Close ended questions limit the response - used to verify facts
 Range of response questions limit the response – uses a scale
– On a scale of 1 to 10, with 1 the lowest and 10 the highest,
how effective was your training?

CT026‐3‐1 Systems Analysis and Design System Requirements Page 9 of 45

 Interview
• Step 4. Prepare for the interview
– Careful preparation is essential because an
interview is an important meeting and not just a
casual chat
– Limit the interview to no more than one hour
– Verify time, place, length, and topics via e-mail
– Ask the interviewee to have samples available

CT026‐3‐1 Systems Analysis and Design System Requirements Page 10 of 45

 Interview
• Step 5. Conduct the interview
– Develop a specific plan for the meeting
– Begin by introducing yourself, describing the
project, and explaining your interview
objectives
– Engaged listening
– Allow the person enough time to think about the
question
– After an interview, you should summarize the
session and seek a confirmation

CT026‐3‐1 Systems Analysis and Design System Requirements Page 11 of 45

 Interview
• Step 6. Document the interview
– Note taking should be kept to a minimum
– After conducting the interview, you must record
the information quickly
– After the interview, send memo to the
interviewee expressing your appreciation
– Note date, time, location, purpose of the
interview, and the main points you discussed
so the interviewee has a written summary and
can offer additions or corrections

CT026‐3‐1 Systems Analysis and Design System Requirements Page 12 of 45

 Interview
• Step 7. Evaluate the interview
– In addition to recording the facts obtained in an
interview, try to identify any possible biases

CT026‐3‐1 Systems Analysis and Design System Requirements Page 13 of 45

 Interview

• Unsuccessful Interviews
– No matter how well you prepare for
interviews, some are not successful
– Misunderstanding or personality conflict could
affect the interview negatively, or the
interviewee might be afraid that the new
system will eliminate or change his or her job
– Find a way to conclude an unsuccessful
meeting
– Consider alternatives
CT026‐3‐1 Systems Analysis and Design System Requirements Page 14 of 45
 Quick Review Question

• You are asked to develop a student registration

system, what are the questions that you may ask
in search of facts? (Hint: use following inquiry
expressions )
– WHO
– WHAT
– WHERE
– WHEN
– HOW
– WHY

CT026‐3‐1 Systems Analysis and Design System Requirements Page 15 of 45

 Summary of Main Teaching Points

• Systems Analysis
– Questions asked in search of facts
– Fact-finding techniques
• Interviews

CT026‐3‐1 Systems Analysis and Design System Requirements Page 16 of 45

 Document Review

• Review existing system documentation

• Obtain copies of actual forms and
documents
• Review blank copies of forms
• Review samples of completed forms
• Review software documentation

CT026‐3‐1 Systems Analysis and Design System Requirements Page 17 of 45

 Observation
• Ask questions about present system
operation
• Observe all steps in the processing cycle
• Examine each form, record and report
• Consider each person working with the
system
• Talk to people who receive current reports
• Consider the Hawthorne Effect
 Productivity seemed to improve whenever workers
knew they were being observed
CT026‐3‐1 Systems Analysis and Design System Requirements Page 18 of 45
 Observation – Hawthorne
Effect

Figure 7-1 :Hawthorne Effect

Systems Analysis & Design (4th Edition) – Shelly Cashman Series

CT026‐3‐1 Systems Analysis and Design System Requirements Page 19 of 45

 Questionnaires and Surveys

• Brief and user-friendly

• Clear instructions
• Questions in logical order
• Simple wording to avoid misunderstanding
• Avoid leading questions
• Open-ended questions are difficult to tabulate
• Limit questions raising concern / negative issues
• Section for general comments
• Test the questionnaires in advance

CT026‐3‐1 Systems Analysis and Design System Requirements Page 20 of 45

 Questionnaires and Surveys

FIGURE 4-23 Online version of a sample questionnaire. Does it follow

the suggested guidelines?
CT026‐3‐1 Systems Analysis and Design System Requirements Page 21 of 45
 Sampling

• process of collecting examples of actual

documents
• There are several techniques of sampling:-
– Systematic sample : Select every tenth customer for
review
– Stratified sample : Select five customers from each of
four postal codes
– Random sample : Any 20 customers
• Main objective : to ensure representation of the
overall population accurately
• Should be considered for interviewing or
questionnaires
CT026‐3‐1 Systems Analysis and Design System Requirements Page 22 of 45
 Research

• Journals, periodicals, books

• Internet sites
– Hardware and software vendors
– Independent firms that provide information
– Newsgroups
• Professional meetings, seminars,
discussions
• Site visits to observe a system in use

CT026‐3‐1 Systems Analysis and Design System Requirements Page 23 of 45

 Interviews vs. Questionnaires

Figure 7.3 – Comparison of Interviews and Questionnaires

Modern Systems Analysis and Design, 3/e - Jeffrey A. Hoffer Joey F. George Joseph S. Valacich

CT026‐3‐1 Systems Analysis and Design System Requirements Page 24 of 45

 Observation vs. Document
Analysis

Figure 7.4 – Comparison of Observation and Document Analysis

Modern Systems Analysis and Design, 3/e - Jeffrey A. Hoffer Joey F. George Joseph S. Valacich

CT026‐3‐1 Systems Analysis and Design System Requirements Page 25 of 45

 Recording Facts

• Keeping accurate records of interview, facts,

ideas and research is important to successful
systems development
• Basic rule is to write it down
• Principles to follow when recording facts are:-
– Record all information as soon as you obtain it.
– Use simplest recording method
– Record findings properly so that it can be understood
by someone else – not a member of the IS dept
– Arrange documentation so that information can be
brought together and coordinated

CT026‐3‐1 Systems Analysis and Design System Requirements Page 26 of 45

 Software tools for recording the
facts

• CASE Tools (Computer-aided systems

engineering) tools
– Powerful programs that help systems analysts
develop and maintain information systems
– Provide an overall framework for systems
development
– Support a wide variety of design methodologies
– Two CASE categories :
• Upper CASE tools : support modeling process and produce a
logical design of the information system
• Lower CASE tools : speed the development process by
generating source code based on the logical model

CT026‐3‐1 Systems Analysis and Design System Requirements Page 27 of 45

 Software tools for recording the
facts

• Word processing
– Create reports, summaries, tables and forms
– Prepare standard documentation
– Organize presentation with templates,
bookmarks, annotations, revision control,
index
– Create fill-in forms to conduct surveys and
questionnaires

CT026‐3‐1 Systems Analysis and Design System Requirements Page 28 of 45

 Software tools for recording the
facts

• Spreadsheet
– Track and manage numerical data or
financial information
– Generate graphs and charts that display
the data and show possible patterns
– Use statistical functions to tabulate and
analyze questionnaire data

CT026‐3‐1 Systems Analysis and Design System Requirements Page 29 of 45

 Software tools for recording the
facts
• Spreadsheets

Figure 7-5 : Sample Pie Chart

Retrieved from : http://www.lboro.ac.uk/computing/info/images/web-imp.jpg

CT026‐3‐1 Systems Analysis and Design System Requirements Page 30 of 45

 Software tools for recording the
facts

• Spreadsheets

Figure 7-6 : Sample Histogram

Retrieved from : http://www.library.tufts.edu/tisch/bibliotech/btc34.htm

CT026‐3‐1 Systems Analysis and Design System Requirements Page 31 of 45

 Software tools for recording the
facts

• Database
– To manage information about events, observations
and samples
– To manage the details of a complex project, create
queries to retrieve specific information, and generate
reports
• Presentation graphics
– For organizing and developing formal presentations
– To create organization charts which can be included
in written reports and management presentations

CT026‐3‐1 Systems Analysis and Design System Requirements Page 32 of 45

 Software tools for recording the
facts

• Personal Information Managers

– To keep track of meetings, interviews,
appointments, and deadlines that are weeks
or months in the future
– To manage tasks and provide a personal
calendar and a To-Do list, with priorities and
the capability to check off completed items

CT026‐3‐1 Systems Analysis and Design System Requirements Page 33 of 45

 System Requirement
Specifications (SRS)
• Structured collection of information that contains the
finalized requirements of a system
• Contains finalized requirement for System Design
• Popular Requirement groups;
– Functional Requirements
– Non-Functional Requirements
– Architecture Requirements
– Business Requirements
– System / Technical Requirements
– User / Stakeholders Requirements
– Security Requirements
– User Interface Requirements, etc

CT026‐3‐1 Systems Analysis and Design System Requirements Page 34 of 45

 Types of Requirements

• Functional (solution) requirements

– Usually detailed statements of capabilities, behavior, and
information that the solution will need.
– Examples include formatting text, calculating a number,
modulating a signal. They are also known as capabilities.

• Non-Functional Requirements
– specifies criteria that can be used to judge the operation of a
system, rather than specific behaviors.
– Often considers the quality aspects of the new system, such as
testability, maintainability, extensibility and scalability
– Example: Availability

CT026‐3‐1 Systems Analysis and Design System Requirements Page 35 of 45

 Downtime per
Availability % Downtime per year
month
90% ("one nine") 36.5 days 72 hours
95% 18.25 days 36 hours
97% 10.96 days 21.6 hours
98% 7.30 days 14.4 hours
99% ("two nines") 3.65 days 7.20 hours
99.5% 1.83 days 3.60 hours
99.8% 17.52 hours 86.23 minutes
99.9% ("three nines") 8.76 hours 43.8 minutes
99.95% 4.38 hours 21.56 minutes
99.99% ("four nines") 52.56 minutes 4.38 minutes
99.995% 26.28 minutes 2.16 minutes
99.999% ("five nines") 5.26 minutes 25.9 seconds

99.9999% ("six nines") 31.5 seconds 2.59 seconds

262.97
99.99999% ("seven nines") 3.15 seconds
milliseconds
26.297
99.999999% ("eight nines") 315.569 milliseconds
milliseconds
2.6297
99.9999999% ("nine nines") 31.5569 milliseconds
milliseconds
CT026‐3‐1 Systems Analysis and Design System Requirements Page 36 of 45
 Types of Requirements

• Architectural requirements
– explain what has to be done by identifying the necessary
systems structure and systems behavior
• Business requirements
– High-level statements of the goals, objectives, or needs of an
organization.
• Systems / Technical Requirements
– The infrastructure that the new system needs to run on.
– Minimum Hardware requirements such as server, storage space,
processing power, etc.
– Software needs such as OS, applications, plug-ins, etc.
– Networking needs such as bandwidth, protocols etc.

CT026‐3‐1 Systems Analysis and Design System Requirements Page 37 of 45

 Architectural requirements

CT026‐3‐1 Systems Analysis and Design System Requirements Page 38 of 45

 Types of Requirements

• User (stakeholder) requirements

– Mid-level statements of the needs of a particular stakeholder or
group of stakeholders.
– They usually describe how someone wants to interact with the
intended solution.

CT026‐3‐1 Systems Analysis and Design System Requirements Page 39 of 45

CT026‐3‐1 Systems Analysis and Design System Requirements Page 40 of 45
 Types of Requirements

• Security Requirements
– The types and levels of security that the new system needs.
– Authorization levels, Encryptions, etc.
• User Interface Requirements
– Specific design criteria for the user interface.
– Color, language, etc.

CT026‐3‐1 Systems Analysis and Design System Requirements Page 41 of 45

 Quick Review Question

• Named some techniques for requirement

elicitation?
• What is the Hawthorne Effect?

CT026‐3‐1 Systems Analysis and Design System Requirements Page 42 of 45

 Summary of Main Teaching Points

• Systems Analysis
– Fact-finding techniques
• Document review
• Observation
• Surveys and questionnaires
• Sampling
• Research
– Recording facts
• Principles to follow
• Software tools used

CT026‐3‐1 Systems Analysis and Design System Requirements Page 43 of 45

 Question and Answer Session

Q&A

CT026‐3‐1 Systems Analysis and Design System Requirements Page 44 of 45

 What we will cover next

• System Analysis – Feasibility Study

CT026‐3‐1 Systems Analysis and Design System Requirements Page 45 of 45