Introduction to

SAD

Slide 1
 What is SAD?
System Analysis:
• System analysis is the process of
investigating a system, Identifying problems,
and Using the information to recommend
improvements to the system.

• Emphasis is made on understanding the

details of an existing system or a proposed
one.

• Analysis specifies what the system should

do.1-2
Recap
What are the basic processes of
analysis phase?

Slide 3 PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
What is SAD?
• System Design:
• Software design is the process of
transforming all the requirements gathered
through system analysis into some suitable form
that describes the complete structure of the
system.

• Focus is put on designing the system based

on the information gathered at analysis stage.

• Design states how to accomplish the objective.

Slide 4
Software Development Life Cycle Activities
in SAD
SN SDLS

1. Preliminary Investigation

2. Project Planning

3. Determine human information

Requirement

4. Analyze System needs

5. Design

Slide 5
1. Preliminary Investigation

Steps involved: Deliverables:

1. Identify the problem. 1. A clear description of the

problem in question

2. Propose a new or 2. Proposed system/solution

updated system.

3. Feasibility study 3. Feasibility report

Slide 6
Identifying the problem
• In this phase the analyst tries to brainstorm the current
system to identify its objectives, limitations and/or problems.

• Some of the problems that may require an organization to

update or change its entire system are:
The current system may no longer suit its purpose,
Technological advancement may have rendered the
current system redundant,
The business is expanding beyond the capacity of the
system
Customers are complaining about the speed and quality of
work the business provides,
• Deliverable:
• A clear description of the current system’s problem.
Slide 7
Propose a new or updated system
• Once the problems are identified and the need for
new or improved system is established, all possible
alternate solutions/systems are laid down.

• All these systems are known as "candidate

systems".

• All the candidate systems are then weighed and the

best system is selected as the solution system, which
is termed as the "proposed system”.

Deliverable:
The proposed system
Slide 8
Feasibility-Critical Decision

The feasibility report should guide the entire

project team to decide whether or not the
proposed system is the best solution and is
feasible. It includes
•Technical (focuses on whether the system
can be built, technology, project size, and
compatibility with existing systems)
•Economic(includes cost–benefit analysis of
development costs, operational costs,
tangible benefits, and intangible costs and
benefits), and;
Slide 9
Feasibility-Critical
Decision
• organizational feasibilities
(acceptance by its users and
incorporation into the ongoing
operations of the organization).
If it is, then project
development move to the
planning phase, otherwise it is
terminated.
Slide 10 PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
2. Project Planning
• This phase determines how the project team
members will go about developing the system.
• To do that, the project manager will carryout the
following tasks:
1. Create a work plan(records and track of all of the tasks that need to
be accomplished over the course of the project)
2. Form the project team(how many people should be assigned to
the project-matching people’s skills with the needs of the project, staffing plan-
number and kinds of people who will work on the project, overall reporting
structure, and the project charter-objectives and rules.)
3. Provide the guidelines that will be applied by the
team to control/direct the project through the entire
SDLC.
Deliverable: The project plan.
Slide 11
Gantt Chart
• This is a project planning/management tool which:
Is a horizontal bar chart that shows the same task information as the
project work plan, but in a graphical way
• displays project activities against time
• shows the various activities
• display when each activity begins and ends
• shows how long each activity is scheduled to last
• displays where activities overlap with other activities, and
by how much
• shows the start and end date of the whole project

• Each activity is represented by a bar; the position

and length of the bar reflects the start date,
duration and end date of the activity.
Slide 12
Gantt Chart Example

Slide 13
3. Determining Human Information
Requirements

This is a fact gathering phase where the system

analyst tries to identify what the system should do
and cares less about how it will do it.

• The requirements include:

User requirements, Functional requirements,
Nonfunctional requirements and System
requirements.

Deliverable:
Requirement Definition Statement
Slide 14
What is a Requirement?

• A requirement is a high-level abstract description

of the services which the system should provide and
the constraints under which the system must
operate.

• A requirement is a detailed, formal definition of a

system function/characteristics it needs to have.

Slide 15
Types of requirement
User requirements(what the software should do)
• statements in natural language plus diagrams of the
services the system provides and its operational
constraints.
• Written for customers.
• User requirements are quite general.

System requirements(how the system should be built)

• Structured statements setting out detailed
descriptions of the system’s functions, services and
operational constraints.
• system requirements provide more specific details
about services and functions of a system.
• may be part of a contract between client and
contractor.
Slide 16
User and System Requirements: Example

Slide 17
System Requirements Classifications

• Software System Requirements are often

classified
into two:

1. Functional Requirement(what the software

should do)

2. Non- Functional
Requirements(characteristics the system should
have)

Slide 18
Functional Requirements

Functional requirements are statements of services

the system should provide, how the system should
react to particular inputs and how the system
should behave in particular situations.

• May state what the system should not do.

• Functional requirements are mostly

specified using ‘Shall’

Slide 19
Functional Requirements: Example

• A user shall be able to search the appointments

lists for all clinics.

• The system shall generate each day, for each

clinic, a list of patients who are expected to attend
appointments that day.

• Each staff member using the system shall be

uniquely identified by his or her 8-digit employee
number.

Slide 20
Non-functional Requirements

• Non-functional requirements are constraints on

the services or functions offered by the system such
as timing constraints, constraints on the
development process and standards.

• Non-functional requirements may be more critical

than functional requirements.
• If these are not met, the system may be
useless.
• A single non-functional requirement may
lead to many functional requirements.

Slide 21
Non-functional Requirements:
Classifications

Slide 22
Non-functional Requirements:
Classifications

• Product requirements
• Requirements which specify that the
delivered
product must behave in a particular way e.g.
execution speed, reliability, etc.

Slide 23
Non-functional Requirements:
Classifications

• Organisational requirements
• Requirements which are a consequence of
organisational policies and procedures e.g.
Process standards used, implementation
requirements, etc.

Slide 24
Non-functional Requirements:
Classifications

• External requirements
• Requirements which arise from factors
which are external to the system and its
development process e.g. interoperability
requirements, legislative requirements, etc.

Slide 25
Methods of Gathering Requirements

• Elicit method: Requires interacting with the

system users
-Interview
-Questionnaires
-Joint Application Design

• Unobtrusive method: do not requires interaction

-Sampling
-Investigation
-Observation

Slide 26
Requirements Elicitation
Techniques
interviews
JAD session
questionnaires
document analysis, and
observation

Slide 27 PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
Interview

• A direct contact between the analyst and the system end

users (conducted one on one)
• Steps in planning an Interview:
Read Background Material: to understand the current
system and its users.

Establish Interviewing objectives: using what you have

learnt from the background reading, list out the facts
you would want to clarify from the interviewee such as
Human
Computer Interactions concern, Information sources,
Information formats, Decision making frequency
Qualities of information

Slide 28
Interview cont.

• Decide whom to Interview

• Make a list of the people to interview.
• Be sure to include all the End users of the System in
question.

• Prepare the Interviewee

• Give him sufficient notice to allow him prepare.
• Give him an idea on what the interview is all about.
• Possibly, send him the interview questions in
advance.
• Preferably face to face interview, or via video calls,
but not on emails.
• Don’t keep him long during the interview, 45 minutes
to an hour at most.
Slide 29
Interview cont.
• Decide on questions types and structures
oTwo basic types of questions:
 Open ended questions: the interview is
allowed to answer in his own words(leave room
for elaboration, similar to essay questions)
• Example: What do you think about the
current student registration?

Closed ended questions: limits the

interviewee’s response to some set of expected
answers (more specific answers).
• Example: Are you happy with the current
student registration system? (Bipolar
question) – Yes or No(similar to multiple choice questions)
• How many times have you had problem with the
registration portal?
Slide 30
Interview cont.

Slide 31 PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
Interview cont.
Two basic ways of logically structuring your interview
questions: Pyramid structure
o Begins with specific questions and mostly closed-
ended questions and then gradually move to more open-
response questions(elaboration). E.g “Do you handle a lot of
requests?” it is better to ask “How many requests do you process per day?”
o Usually applied when you need to nurture the interviewee
on the interview topic
.

Slide 32
Interview cont.

Funnel structure:
o A reverse of the pyramid, begin open ended and then
gradually closing
o Allow the interviewer to have a general opinion of the
interviewee before getting the specifics

Slide 33
Interview cont.

Pyramid

Slide 34
Interview cont.

Funnel

Slide 35
Joint Application Design

•Allows the project team, users, and management

to work together to identify requirements for the
system
•A group session, usually a seminar, that brings all
stake holders (system analysts and end users alike)
together to discus on the system information
requirements.

• Developed by IBM, as an alternative to interviews

to cut down time, cost, and misinterpretations
associated with interviews.
Slide 36
Example of JAD

Slide 37
Why do we use JAD

• Accelerates application development process

• Increases development productivity
• User participation in application’s design
• Improves communication between:
• User and System
• User and user
• System and system
• And finally, it enables consensus,
commitments, and partnership across the
organization.

Slide 38
Questionnaires

• Another method of information gathering where potential

users are given a written set of questions to be filled up and
returned.

• It covers a larger number of people than the other methods

and under a short time.

• A questionnaire is a set of written questions for obtaining

information from individuals/ to conduct a survey.

• The questions are used for audience analysis and they are
meant to create understanding of the target users feelings,
perception, needs, and beliefs about the system.

Slide 39
Design rules for questionnaire

• Allow sufficient white spacing.

• Allow easy response with sufficient space if

needed.

• Consistent style.

Slide 40
Good Questionnaire
Design

Slide 41 PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
Categories of
Questionnaire
• Open Response

• Closed Response

• Other types include

• Mixed questionnaire
• Pictorial questionnaire
Slide 42
Open Response
Questionnaire
• Open-Response Based Questionnaire
The questions do not require any direction or specific
response.

The aim of this category of questionnaire is

 to gather information and data about the
essential features of the system.
 to learn about the opinions and experiences
of the respondents.

Slide 43
Closed Response Questionnaire

• This category can be classified into several types:

Fill-in-the-blanks.

Ranking scale questions; ask the respondents to

rank a list of items in the order of importance or preferences.

Multiple-choice questions; offers respondents a few

fixed choices ato choose.

Rating scale questions: an extension of multiple choice

where the respondent is asked to rate the options on a given
scale

Slide 44
Closed Vs. Open

Open Closed

• More flexibility and • More specific and

freedom to the restriction to the
respondents. respondent.

• Used in exploring certain • Used in obtaining factual

situation. information.

• Requires a lot of time to • Requires a lot of time to

evaluate create

Slide 45
Document analysis
Document analysis entails
reviewing the existing
documentation and examining
the system itself.
It can provide insights into the
formal and informal system.

PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and
Slide 46 Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
Observation
Observation is the act of
watching processes being
performed, to gain insight into
the as-is system (existing
system).
To check the validity of
information gathered from
interviews and questionnaires
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and
Slide 47 Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.
Observation
Observation is often used to
supplement/support the
information that users provide
in interviews.
It enables the analyst to see the
reality of a situation firsthand.

PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and
Slide 48 Design
Copyright 2000 © John Wiley & Sons, Inc. All rights reserved.