ANALYSIS PHASE

Introduction

 The term analysis refers to breaking a whole

into its parts with the intent of understanding
the parts’ nature, function, and
interrelationships.
Introduction
 The work performed in the analysis phase involves
expanding the vision described in the system request
into a thorough, detailed understanding of exactly
what the new system needs to do.
 In the context of the SDLC, the outputs of the planning
phase (the system request, feasibility study, and
project plan), outline the business goals for the new
system, define the project’s scope, assess project
feasibility, and provide the initial work plan.
Introduction

 In the analysis phase, the systems analyst works

extensively with the users of the new system to
understand their needs from the new system.
The basic process of analysis involves three steps:
1. Understand the existing situation (the as-is system).
2. Identify improvements.
3. Define requirements for the new system (the to-be
system).
Understand the existing situation
(the as-is system).
 Sometimes this step is skipped or done in a limited
manner.
 This happens when no current system exists, if the
existing system and processes are irrelevant to the
future system, or if the project team is using a RAD or
agile development methodology in which the as-is
system is not emphasized.
 Traditional methods such as waterfall and parallel
typically allot significant time to understanding the as-
is system and identifying improvements before
moving to capture requirements for the to-be system.
Understand the existing situation
(the as-is system).
 Newer RAD and agile methodologies, such as iterative
development, system prototyping, throwaway
prototyping, and extreme programming, focus almost
exclusively on improvements and the to-be system
requirements, and they devote little time for
investigating the current as-is system.
 Experience shows that it is useful to study the current
situation whenever possible.
 The insights gained from reviewing the existing
system can be quite valuable to the project team.
Understand the existing situation
(the as-is system).
 To move the users “from here to there,” an analyst
needs strong critical thinking skills.
 Critical thinking is the ability to recognize strengths
and weaknesses and recast an idea in an improved
form.
 These skills are needed in order for the analyst to
understand issues and develop new and improved
business processes that are supported by information
system technologies.
 These skills are essential in examining the results of
requirements discovery and translating those
requirements into a concept for the new system.
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.
 This detailed list of requirements is supported,
confirmed, and clarified by the other activities of the
analysis phase: creating use cases, building process
models, and building a data model.
Requirements determination

 A requirement is simply a statement of what the

system must do or what characteristics it needs to
have.
 During a systems development project, requirements
will be created that describe:
1. The business needs (business requirements)
2. What the users need to do (user requirements)
3. What the software should do ( functional
requirements)
4. Characteristics the system should have
(nonfunctional requirements)
Requirements determination

 Examples of business requirements

 “Increase market share; “Shorten order processing
time”; “Reduce customer service costs”; “Lower
inventory spoilage”; “Improve responsiveness to
customer service requests”; and “Provide account
access to mobile customers.”
Requirements determination

 When the systems development project is complete,

success will be measured by evaluating whether the
stated business requirements have actually been
achieved; therefore, they provide the overall direction
for the project
Requirements determination

 User requirements are written from the perspective of

the business, and they focus on what the system
needs to do in order to satisfy business user needs.
 A good starting place is to concentrate on what the
user actually needs to accomplish with the system in
order to fulfill a needed job or task.
 These user requirements describe tasks that the users
perform as an integral part of the business’ operations
Requirements determination

Examples of user requirements

 “Schedule a client appointment”; “Place a new
customer order”; “Re-order inventory”; “Determine
available credit”; and “Look up account balances.”
 Use cases are tools used to clarify the steps involved
in performing these user tasks.
 By understanding what the user needs to do in terms
of tasks to perform, the analyst can then determine
ways in which the new system can support the users’
needs.
Requirements determination

Functional requirements
 Focuses on defining how the system will support the
user in completing a task.
 Determining ways in which the new system can
support user needs leads to statements of the
system’s functional requirements.
 A functional requirement relates directly to a process
the system has to perform as a part of supporting a
user task and/or information it needs to provide as the
user is performing a task.
Requirements determination
 Functional requirements
 For example, assume the user requirement is
“Schedule a client appointment.”
 The functional requirements associated with that task
include: “Determine client availability,” “Find available
openings matching client availability,” “Select desired
appointment,” “Record appointment,” and “Confirm
appointment.”
 These functional requirements expand upon the user’s
task to describe capabilities and functions that the
system will need to include, allowing the user to
complete the task.
Requirements determination
Functional Requirements
Functional Description Examples
Requirement

Process- A process the • The system must allow

oriented system must registered customers to review
perform; a process their own order history for the
the system must do past three years.
• The system should allow
students to view a course
schedule while registering for
classes.

Information- Information the The system must retain customer

oriented system must order history for three years
Requirements determination

 Nonfunctional requirements
Refers to “the quality attributes, design, and implementation
constraints, and external interfaces which a system must have.”
Although the term “nonfunctional” is not very descriptive, this
requirement category includes important behavioral properties that
the system must have, such as performance and usability.
Requirements determination

 The nonfunctional requirements describe a variety of system

characteristics: operational, performance, security, and cultural
and political.
 These characteristics do not describe business processes or
information, but they are very important in understanding what
the final system should be like
 Requirements determination
Nonfunctional Requirements
Nonfunctional Description Examples
Requirement
Operational The physical and technical • The system can run on
environments in which the system handheld devices.
will operate • he system should be able to
work on any Web browser.

Performance The speed, capacity, and reliability • Any interaction between the
of the system user and the system should
not exceed 2 seconds
• The system supports 300
simultaneous users from 9–
11 A.M.; 150 simultaneous
users at all other times.

Security Who has authorized access to the Only direct managers can see
system under what circumstances personnel records of staff.
The Process of Determining
Requirements
 Both business and IT perspectives are needed to
determine requirements during the analysis phase.
 Systems analysts may not understand the true
business needs of the users.
 The business users may not be aware of the
opportunities that a new technology may offer.
 It is important that the team carefully considers the
underlying business process and how best to support
that business process with information system
technology
The Process of Determining
Requirements
 The most effective approach is to have both business
people and analysts working together to determine
requirements.
 In fact, the analysis phase involves significant
interactions with people who have an interest in the
new system (often called stakeholders).
 One of the first tasks for the analyst is to identify the
primary sources of requirements, including the project
sponsor, project champion(s), all users of the system
(both direct and indirect), and possibly others. It is
important that all user perspectives are included.
The Process of Determining
Requirements
 The analyst must also consider how best to elicit the
requirements from the stakeholders.
 There are a variety of elicitation techniques that can
be used to acquire information, including :
1. Interviews,
2. Questionnaires,
3. Observation,
4. Joint application development (JAD),
5. Document analysis
The Process of Determining
Requirements
 The information gathered by these techniques is
critically analyzed and used to craft the requirements
definition statement.
 The analyst works with the entire project team and the
business users to verify, change, and complete the list
of requirements and, if necessary, to prioritize the
importance of the requirements that are identified
The Process of Determining
Requirements
 Techniques/methods of collecting requirements
1. Interviews
a) Individual Interviews
b) Group Interviews
The interview process involves: selecting interviewees,
designing interview questions, preparing for the
interview, conducting the interview, and post interview
follow-up
The Process of Determining
Requirements
2. Joint Application Development (JAD)
Capers Jones claims that JAD can reduce scope creep by
50%, and it prevents the requirements for a system from
being too specific or too vague, both of which can cause
trouble during later stages of the SDLC.
JAD is a structured process in which 10 to 20 users meet
under the direction of a facilitator skilled in JAD
techniques.
The facilitator is a person who sets the meeting agenda
and guides the discussion, but does not join in the
discussion as a participant.
The Process of Determining
Requirements
3. Questionnaires
A questionnaire is a set of written questions for
obtaining information from individuals.
Questionnaires often are used when there is a large
number of people from whom information and opinions
are needed.
The Process of Determining
Requirements
4. Document Analysis
Project teams often use document analysis to
understand the as-is system.
Under ideal circumstances, the project team that
developed the existing system will have produced
documentation, which was then updated by all
subsequent projects.
In this case, the project team can start by reviewing the
documentation and examining the system itself.
The Process of Determining
Requirements
5. Observation
 Observation, the act of watching processes being
performed, is a powerful tool to gain insight into the
as-is system.
 Observation enables the analyst to see the reality of a
situation, rather than listening to others describe it in
interviews or JAD sessions.
Selecting the Appropriate
Techniques
 Each of the requirements elicitation techniques just
discussed has strengths and weaknesses.
 No one technique is always better than the others,
and in practice most projects benefit from a
combination of techniques.
 Thus, it is important to understand the strengths and
weaknesses of each technique and when to use each
Selecting the Appropriate
Techniques
1. Type of Information
2. Depth of Information
3. Breadth of Information
4. Integration of Information
5. User Involvement
6. Cost
REQUIREMENTS ANALYSIS
STRATEGIES
1. Problem Analysis
2. Root Cause Analysis
3.Duration Analysis
4.Activity-Based Costing
5. Informal Benchmarking
6. Outcome Analysis
7. Technology Analysis
8. Activity Elimination
REQUIREMENTS ANALYSIS
STRATEGIES
 Problem analysis means asking the users and
managers to identify problems with the as-is system
and to describe how to solve them in the to-be
system.
 Most users have a very good idea of the changes they
would like to see, and most will be quite vocal about
suggesting them.
REQUIREMENTS ANALYSIS
STRATEGIES
 Root cause analysis focuses on problems first rather
than solutions.
 The analyst starts by having the users generate a list
of problems with the current system, then prioritizes
the problems in order of importance.
 Starting with the most important, the users and/or
analysts generate all possible root causes for the
problem.
REQUIREMENTS ANALYSIS
STRATEGIES
 Duration analysis requires a detailed examination of
the amount of time it takes to perform each process in
the current as-is system.
 The analysts begin by determining the total amount of
time it takes, on average, to perform a set of business
processes for a typical input.
 They then time each of the individual steps (or
subprocesses) in the business process.
 The time to complete the basic steps are then totaled
and compared with the total for the overall process
REQUIREMENTS ANALYSIS
STRATEGIES
 Activity-based costing examines the cost of
each major process or step in a business
process rather than the time taken.
 The analysts identify the costs associated with
each of the basic functional steps or
processes, identify the most costly processes,
and focus their improvement efforts on them.
REQUIREMENTS ANALYSIS
STRATEGIES
 Benchmarking refers to studying how other
organizations perform a business process in
order to learn how your organization can do
something better.
 Benchmarking helps the organization by
introducing ideas that employees may never
have considered, but that have the potential
to add value
REQUIREMENTS ANALYSIS
STRATEGIES
 Outcome analysis focuses on understanding the
fundamental outcomes that provide value to
customers.
 While these outcomes sound as though they should be
obvious, they often aren’t.
 With this approach, the system analysts encourage
the managers and project sponsor to pretend that
they are customers and to think carefully about what
the organization’s products and services enable the
customers to do and what they could enable the
customer to do.
REQUIREMENTS ANALYSIS
STRATEGIES
 Technology analysis starts by having the analysts and
managers develop a list of important and interesting
technologies. Then the group systematically identifies
how each and every technology could be applied to
the business process and identifies how the business
would benefit.
 Then the group systematically identifies how each and
every technology could be applied to the business
process and identifies how the business would benefit.
REQUIREMENTS ANALYSIS
STRATEGIES
 Activity elimination is exactly what it sounds like.
 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.