SWE2315 : SYSTEM

ANALYSIS & DESIGN

Lecture 04: Analysis

Maryam Ibrahim Mukhtar
1/14/2025 System Analysis & Design 2

Outline
• The Analysis Phase.
• Requirement Determination.
• Requirement Elicitation Techniques.
 1/14/2025 System Analysis & Design 3

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:

1. Understand the existing situation (the as-is system)

2. Identify improvements

3. Define the requirement for the new system (the to-be system).
 1/14/2025 System Analysis & Design 4

1. Understanding Existing Situation

• Sometimes the first 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 agile development methodology.

• Traditional SDLCs allot significant time to understanding

the as-is system while newer SDLCs do not.

• Experience shows that it is useful to study the current

situation whenever possible.
 1/14/2025 System Analysis & Design 5

2. Identify Improvement
• Critical thinking is the ability to recognize strengths and
weaknesses and recast an idea in an improved form.

• Analyst needs critical thinking to understand issues with

existing system and develop new and improved business
processes.

• Example : a user states that the new system should

“eliminate inventory stock-outs.”

• The analyst needs to think about it critically in order to formulate the

statement in terms of useful requirements.
 1/14/2025 System Analysis & Design 6

Example: Eliminate Inventory Stock-out

• The analyst could first have the users think about
circumstances leading to stock-outs (e.g., supplier orders
are not placed in a timely way),

• Then look at the issues that lead to supplier orders not

placed (e.g.,
• on-hand inventory levels are updated weekly;
• delays occur in identifying the best supply source for the items;
• delays occur in receiving approval of the supply order, etc.)

• By focusing on these issues, improvements to address

these concerns can be discovered.
 1/14/2025 System Analysis & Design 7

3. Requirements for new System

• The new requirements will then be based on the issues that
truly need to be fixed. From example(eliminate Inventory
stock out):
• Issue : on-hand inventory levels are updated weekly;
• Requirement for New System: The system shall update on-hand
inventory levels twice per day.

• Issue: delays occur in identifying the best supply source for the items;
• Requirement for New System: The system shall include a
recommended supplier with every out-of-stock notification.

• Issue: delays occur in receiving approval of the supply order,

• Requirement for New System: The system shall send an approved
supply purchase order to the supplier via secure electronic
communication.
1/14/2025 System Analysis & Design 8

3. Requirements for new System

• The analyst cannot realistically expect that the true
requirements for the new system are easily gathered
following a few conversations with the stakeholders.

• The analyst must be prepared to dig into the situation and

discover requirements.

• A number of techniques and tools can be used by the

analyst to facilitate this process of discovering
requirements.
1/14/2025 System Analysis & Design 9

Requirements Determination
• Requirements determination is performed to:
• transform the system request’s 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.
1/14/2025 System Analysis & Design 10

Requirements Elicitation
• For the analyst to get the requirements s/he must elicit
(gather)it.

• The analyst must consider how best to elicit the

requirements from the stakeholders.

• There are a variety of elicitation techniques that can be used

to acquire information, such as:
• interviews,
• questionnaires,
• observation,
• joint application development (JAD),
• and document analysis
 1/14/2025 System Analysis & Design 11

Interviews
• The interview is the most commonly used requirements
elicitation technique.

• After all, it is natural usually, if you need to know something,

you ask someone.

• In general, interviews are conducted one on one (one

interviewer and one interviewee), but sometimes, due to
time constraints, several people are interviewed at the same
time.
1/14/2025 System Analysis & Design 12

Interviews Steps
• There are five basic steps to the interview process:
• selecting interviewees,
• designing interview questions,
• preparing for the interview,
• conducting the interview,
• post interview follow-up.
1/14/2025 System Analysis & Design 13

Selecting Interviewees
1/14/2025 System Analysis & Design 14

Designing Interview Questions

 1/14/2025 System Analysis & Design 15

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
1/14/2025 System Analysis & Design 16

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.
•.
1/14/2025 System Analysis & Design 17

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.
 1/14/2025 System Analysis & Design 18

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.

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

under the direction of a facilitator skilled in JAD
techniques.
• The facilitator must be an expert in both group process techniques
and systems analysis and design techniques.
 1/14/2025 System Analysis & Design 19

JAD Steps
• There are five basic steps to the JAD process:
• Selecting Participants
• Designing JAD Session
• Preparing for JAD Session
• Conducting the JAD Session
• Post JAD Follow-up
 1/14/2025 System Analysis & Design 20

Selecting Participants
• Selecting JAD participants is done in the same basic way
as selecting interview participants.
• Participants are selected on the basis of information they can
contribute, a broad mix of organizational levels,

• The need for all JAD participants to be away from their

offices at the same time can be a major problem.
 1/14/2025 System Analysis & Design 21

Designing & Preparing for JAD Session

• 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.
 1/14/2025 System Analysis & Design 22

Conducting 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.
 1/14/2025 System Analysis & Design 23

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
1/14/2025 System Analysis & Design 24

Questionnaires
• A questionnaire is a set of written questions for obtaining
information from individuals.

• Four (4) Steps for doing a Questionnaire:

• Selecting participants -using a sample of people who are
representative of the entire group.
• Designing the questionnaire –following good practice
guidelines.
• Administering the questionnaire –improving the
response rates.
• Questionnaire follow-up –developing a report.
1/14/2025 System Analysis & Design 25

Good Questionnaire Design

 1/14/2025 System Analysis & Design 26

Documents 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 indication that system needs to be changed is when

users create new forms or make changes to the existing
forms/reports.
1/14/2025 System Analysis & Design 27

Documents Analysis--Example
 1/14/2025 System Analysis & Design 28

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.
 1/14/2025 System Analysis & Design 29

Selecting Elicitation Technique

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

• Some factors can be used to select the most appropriate.

1/14/2025 System Analysis & Design 30

Selecting Elicitation Technique

1/14/2025 System Analysis & Design 31

Requirements
• A requirement is simply a statement of what the system must
do or what characteristics it needs to have.

• During a systems development project (Elicitation phase)

requirements will be gathered/created that 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 (nonfunctional
requirements);
1/14/2025 System Analysis & Design 32

Business Requirements
• These statements reflect the business requirements that the
system, if built, will fulfill.

• Examples “Increase market share”; “Shorten order

processing time”; “Lower inventory spoilage”.

• Success of the software will be measured by evaluating

whether the stated business requirements have actually
been achieved.
1/14/2025 System Analysis & Design 33

User Requirements
• User requirements describe tasks that the users perform as
an integral part of the business’ operations,

• Example:
• “Schedule client appointment”;
• “Place customer order”;
• “Re-order inventory”
• “Make Payment”
1/14/2025 System Analysis & Design 34

Functional Requirements
• Functional requirements begin to define how the system will
support the user in completing a task.

• For example, assume the user requirement is “Schedule a

client appointment.”

• The functional requirements associated with that task

(“Schedule a client appointment.”) include:
• Determine client availability
• Find available openings matching client availability
• Select desired appointment
• Confirm appointment
1/14/2025 System Analysis & Design 35

Non-Functional Requirements
• Nonfunctional requirements describe a variety of system
characteristics:
• Operational:The physical and technical environments which the
system will operate
• Performance:The speed, capacity, and reliability of the system
• Security:Who has authorized access to the system under what
circumstances
• Cultural and political:Cultural and political factors and legal
requirements that affect the system

• Nonfunctional requirements are primarily used in the design

phase when decisions are made about:
• the system’s underlying architecture , the user interface, the hardware
and software,
1/14/2025 System Analysis & Design 36

Example-Non-Functional Requirements
1/14/2025 System Analysis & Design 37

System Proposal
• All the deliverable (Output) of the analysis phase is
combined into a system proposal system proposal.

• The proposal is then submitted to the approval committee

so that the approval committee can decide whether it
would continue to funding the project.
1/14/2025 System Analysis & Design 38

Case Study System: Tune Source

• Once the Tune Source approval committee approved the system request
and feasibility analysis, the project team began performing analysis
activities.

• These included gathering requirements by a variety of techniques and

analysing the requirements that were gathered.
 1/14/2025 System Analysis & Design 39

Understanding the System

• Jason believed that it would be important to understand the current Web-
based sales processes and systems that already existed in the
organization, because they would have to be closely integrated with the
Digital Music Download system.

• Two requirements-gathering techniques proved to be helpful in

understanding the current systems and processes document analysis,
interviews and Informal Benchmarking.
 1/14/2025 System Analysis & Design 40

Understanding the System- Document Analysis

• First, the project team collected existing reports (e.g., sales forms, screen
shots of the online sales screens) and system documentation (data
models, process models) that shed light on the as-is system.

• They were able to gather a good amount of information about the existing
order processes and systems in this way.

• When questions arose, they conducted short interviews with the person
who provided the documentation, for clarification.
 1/14/2025 System Analysis & Design 41

Understanding the System- Interview

• Jason interviewed the senior analysts, a contact from the IT person for the current
sales systems to get a better understanding of how those systems worked.

• He asked whether they had any ideas for the new system, as well as whether
there were any integration issues that would need to be addressed.
 1/14/2025 System Analysis & Design 42

Understanding the System- Interview and JAD

• Carly suggested that the project team conduct several JAD sessions with
store managers, marketing analysts, and Web-savvy members of the IT
staff.

• Together, the groups could brainstorm the features desired in the Digital
Music Download system. Jason facilitated three JAD sessions that were
conducted over the course of a week.

• The JAD session generated ideas about how Tune Source could apply
each of the technologies to the Digital Music Download system. Jason
had the group categorize the ideas into three sets: “definite” ideas that
would have a good probability of providing business value, “possible”
ideas that might add business value, and “unlikely” ideas.
 1/14/2025 System Analysis & Design 43

Understanding the System- Informal Benchmarking

• Next, Jason applied informal benchmarking by introducing the Web sites
of several leading retailers and pointing out the features that they offered
online.

• He selected some sites on the basis of their success with Internet sales,
and others on the basis of their similarity to the vision for Tune Source’s
new system.

• The group discussed the features that were common across most
retailers, versus unique functionality, and they created a list of suggested
business requirements for the project team.
 1/14/2025 System Analysis & Design 44

Requirement Definition
• Throughout all of these activities, the project team collected information
and tried to identify the business requirements for the system from the
information.

• As the project progressed, requirements were added to the requirements

definition and grouped by requirements type. When questions arose, they
worked with Carly and Jason to confirm that requirements were in scope.

• At the end of the analysis phase, the requirements definition was

distributed to Carly, two marketing employees who would work with the
system on the business side, and several retail store managers.

• This group then met for a two-day JAD session to clarify, finalize, and
prioritize the requirements and to create use cases to show how the
system would be used. process models and data models (Chapter 6) that
depicted the processes and data in the future system.
1/14/2025 System Analysis & Design 45

Requirement Definition
 1/14/2025 System Analysis & Design 46

System proposal
• Jason reviewed the work plan and made some slight changes.

• He also conferred with Carly and the marketing department members to

review the feasibility analysis. No major changes were made to it at this
point; the project remains highly feasible overall.

• All of the deliverables from the project were then combined into a system
proposal and submitted to the approval committee. Next slide for sample

• Carly and Jason met with the approval committee and presented the
highlights of what was learned during the analysis phase and the final
concept of the new system.

• On the basis of the proposal and presentation, the approval committee

decided that it would continue to fund the Digital Music Download system.
1/14/2025 System Analysis & Design 47

System proposal
1/14/2025 System Analysis & Design 48

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 requirements.
 1/14/2025 System Analysis & Design 49

Group Assignment
• Project Managers should refine the Work Plan to include analysis
• Add Twelve (12) Members to Analysis
• Break the Analysis Phase into the two(2) sub-steps and assign 6 members
to each sub step.

• Task 2: Analysis-Part A 6 members

a. Choose an elicitation technique, explain why it was chosen and
Conduct an elicitation based on the method selected
b. Create an elicitation report include some of the questions used and the
answers gotten from the users involved.(You may use charts or tables if
you want.
c. Identify the Functional and non-functional requirements gotten from the
elicitation conducted
Work breakdown: a should be done by 2 members
b should be done by 2 members
d should be done by 2 members
1/14/2025 System Analysis & Design 50

Questions !!!