Systems Analysis and Design

ANALYSIS PHASE

Chapter 3
Requirements Determination
 Chapter 3 Outline

• The analysis phase.

• Requirement determination.
• Requirement elicitation
techniques.
• Requirement analysis
strategies.
 THE ANALYSIS PHASE

• Analysis refers to breaking

a whole into its parts with
the intent of understanding
the parts’ nature, functions,
and interrelationships.

• The planning phase

deliverables are the key
inputs into the analysis
phase.
The basic process of analysis
involves three steps:

• Understand the existing

situation (the as-is system)
• Identify improvements
• Define the requirement for
the new system (the to-be
system).
❖ The final deliverables of the analysis
phase is the system proposal.

❖The system proposal is presented to

the approval committee in the form of
a system walk-through to explain the
system in moderate detail.

❖The deliverables from the analysis

phase are the first step in the design of
the new system.
 REQUIREMENTS
DETERMINATION
➢Requirements determination is
performed to transform the
system request’s high-level
statement of business
requirements into a more
detailed, precise list of what the
new system must do to provide
the needed value to the business
What is a Requirement?
• A requirement is a statement of what the system must do or what
characteristics it needs to have.
• Requirements describe
- what the business needs
(business requirements)
- what the users need to do (user requirements)
- what the software should do
(functional requirements)
- characteristics the system should have
(non-functional requirements), and
- how the system should be built
(system requirements)
FUNCTIONAL REQUIREMENTS
NONFUNCTIONAL REQUIREMENTS
 Both business and IT perspectives are needed
to determine requirements during the analysis
phase.

The most effective approach is to have both

businesspeople and analysts working together
The Process of to determine requirements.

Determining
Requirements The analyst must also consider how best to
elicit the requirements from the stakeholders.

The process of determining requirements

continues throughout the analysis phase, and
the requirements definition evolves over time.
REQUIREMENTS ELICITATION TECHNIQUES
Requirements Elicitation in Practice

• The analyst should recognize that important side effects of the process of
determining requirements include building political support for the project
and establishing trust between the project team and the users.
• The analyst should carefully determine who is included in the process of
determining requirements.
 • The most commonly used requirements
elicitation technique

• Basic steps:
• Selecting Interviewees
Interviews • Designing Interview Questions
• Preparing for the Interview
• Conducting the Interview
• Post-Interview Follow-up
SELECTING INTERVIEWEES
• Interview schedule

• Including people at different levels of the organization

• Managers
• Users
• Other key stakeholders
DESIGNING INTERVIEW QUESTIONS
• Unstructured interview
• for a broad and roughly defined set of information

• Structured interview
• for very specific information
• Top-down vs. bottom-up interview
 Preparing for
the interview
• Prepare a general interview
plan
• Confirm areas of knowledge
• Set priorities in case of time
shortage
• Prepare the interviewee
• Schedule
• Inform of reason for
interview
• Inform of areas of
discussion
Conducting The
Interview
• Appear to be professional and
unbiased.
• Record all information.
• Be sure you understand the issues
that are discussed.
• Separate facts from opinions.
• Give interviewee time to ask
questions, and brief explain what
will happen next.
 Post-interview follow-up

• After the interview, the analysts needs to

prepare an interview report.
• The report includes interview notes.
• The report is sent to interviewee with a
request to read it and inform the analyst
of clarification and updates.
Joint Application Development (JAD)
• JAD is an information gathering technique that allows the project
team, users, and management to work together to identify
requirements for the system.

• It can reduce scope creep by 50%,

• JAD is a structure process in which 10 to 20 users meet under the

direction of a facilitator skilled in JAD techniques.
Selecting participants
• Selecting JAD participants in the same basic way as selecting interview
participants.

• Facilitator
• Expert in JAD and e-JAD techniques
• In many cases, the JAD facilitator is a consultant external to the organization.
Designing the JAD session and
Preparing for the JAD sessions

• JAD sessions can run from a half day

to several weeks depending upon the
size and scope of the project.
• JAD success depends upon a careful
plan.
• Most JAD sessions are designed to
collect specific information from users.
• It is important to prepare the analyst
and participants for the JAD session.
CONDUCTING THE JAD SESSION
• Most JAD sessions follow formal agenda and
ground rules.
• The JAD facilitator performs three key functions:
• Keep session on track, following the agenda.
• Help the group understand the technical
terms and jargon.
• Record group’s input on a public display area.

▪ The facilitator must remain neutral at all time

and help the group through the process.
Post JAD Follow-up
• Post session report is prepared and
circulated among session attendees

• The report should be completed

approximately a week to two after
the JAD session
QUESTIONNAIRES

A questionnaire Selecting Designing the Administering Questionnaire

is a set of written participants - questionnaire the follow-up –
questions for using a sample of – following questionnaire developing a
obtaining people who are good practice – improving the report.
information from representative of
guidelines. response rates.
individuals. the entire group.
GOOD QUESTIONNAIRE DESIGN
DOCUMENT ANALYSIS

• Document analysis is used to understand the as-is system.

• Forms, reports, policy manuals, organization charts
describe the formal system that the organization uses.
• The “real” or informal system differs from the formal one,
and reveals what needs to be changed.
• The indication that system needs to be changed is when
users create new forms or make changes to the existing
forms/reports.
Observation
➢ Observation – the act of watching
processes being performed.

➢ It is a powerful tool to gain insight

into the as-is system, and to check
the validity of information gathered
from other sources.

➢ Nonetheless, people tend to be

extremely careful in their behaviors
when they are being watched.
 Selecting the
Appropriate Techniques

• Type of information
• Depth of information
• Breadth of information
• Integration of information
• User involvement
• Cost
• Combining techniques
Comparison of Requirements Elicitation Techniques
REQUIREMENTS
ANALYSIS STRATEGIES
Problem Analysis

▪ Asking users to identify problems and

solutions

▪ Improvements from problem analysis

tend to be small and incremental

▪ This type of improvements often is very

effective at improving a system’s
efficiency or ease of use; however, it
provides minor improvements in
business value.
 • Root cause analysis focuses on problems first rather than solutions.

Root Cause
Analysis
Duration Analysis
• Duration analysis requires a detailed examination of amount of time it takes to perform each process
in the as-is system.

• Compare the total time to complete basic steps and the total time for the overall process – a significant
difference indicates that the process is badly fragmented.

• Potential solutions:
• Process integration
• Parallelization
Activity-Based Costing
• Activity-based costing examines the cost of each major process or
step in a business process.
• Both direct and indirect costs are considered.
• The analysts identify most costly steps and focus improvement efforts
on them.
Informal Benchmarking
• Benchmarking refers to studying how other organizations perform a
business process.
• Informal benchmarking is common for “customer-facing” processes.
• The analysts visit other organizations as customers to watch how the
business process is performed.
Outcome Analysis
• Outcome analysis focuses on understanding fundamental outcomes
that provide value to customers.

• Think what the organization could enable the customer to do

Technology Analysis
• Technology analysis involves two steps:
1. The analysts and managers list important and interesting
technologies.

2. Then, the group identifies how each and every technology might be
applied to the business and how the business would benefit.
Activity Elimination
The analysts and managers work together to identify
• how the organization could eliminate each and every activity in the
business process,
• how the function could operate without it, and
• what effects are likely to occur.
COMPARING ANALYSIS STRATEGIES
• Each of the requirement analysis
strategies has its own purpose.

• No one strategy is inherently better that

the others.

• The requirement analysis strategy should

be chosen to fit the nature of the project.
SUMMARY
✓Analysis focuses on capturing the
business requirements for the system
✓Requirement Determination is the
part of analysis in which the project
team turns the business
requirements stated in the system
request into a precise list of
requirements.
✓Five Requirements Elicitation
Techniques can be used to elicit
business requirements.
✓Requirements Analysis Strategies are
useful for analysts to help the
business users think critically about
the new system requirements.