SYSTEM ANALYSIS AND DESIGN

THE ANALYSIS PHASE

Analysis refers to breaking a whole into its parts with the intent of understanding the parts’ nature,
function, and interrelationships.
Basic Process of Analysis
1. Understand the existing situation (the as-is system).
2. Identify improvements.
3. Define requirements for the new system (the to-be system).

REQUIREMENTS GATHERING AND ANALYSIS

I. Sampling and Investigating Hard Data
SAMPLING : it is a process of systematically selecting representative elements of a population.
The reasons systems analysts do sampling are
Need for Sampling
 Reduction of costs
– More time & cost involves to ask all employees, reading all web pages
– Redundant data
 Speeding up the data-gathering process
– Little burden to gather sampled data rather than all data
 Improving effectiveness
– Ask detail questions to few employees which requires little time and the analyst can
follow up on missing and incomplete data
 Reduction of data-gathering bias
– i.e. Biased interview by the executive who like to see the project successful

Sampling Design Steps

To design a good sample, a systems analyst needs to follow four steps:
1. Determining the data to be collected or described
– Identify attributes, variable, associated data item
– Data gathering methods like interview, questionnaire, observation etc.
2. Determining the population to be sampled
– Duration of analysis (i.e. 2 month, 1 year)
– Determine whether interview should take place on one level or all level of organization
or outside of the organization
3. Choosing the type of sample
4. Deciding on the sample size

Four Types of Sampling

1. Convenience samples
– System analyst post a notice asking everyone interested in new sales performance report
to come to a meeting at 1 PM on 12th December
– Easiest to arrange but most unreliable
2. Purposive samples
– Analyst chooses group of knowledgeable individuals who are interested in the field
– Moderately reliable
3. Simple Random Sampling
– Based on a numbered list of the population
– Each person or document has an equal chance of being selected
– Choose every k-th element
– Not always practical
– Complex Random Sampling
– Has three forms
• Systematic sampling:
• select every k-th element like simple random sampling
• Stratified sampling:
• sub group the population (i.e. executive level, line level) & then sample

qR1st1nah 1
 SYSTEM ANALYSIS AND DESIGN
• Cluster sampling:
• select a group of document or people to study
• There are many “sonali” bank around the country. Investigate 1 or 2 of
them
HARD DATA
Investigation of hard data is another effective method for systems analysts to gather information
Hard data can be obtained by
• Analyzing quantitative documents such as records used for decision making
• Performance reports
• Records
• Data capture forms
• E-commerce and other transactions

II. Interviews
Five Basic Steps
1. Selecting Interviewees
Based on Information Needed
Often Good to Get Different Perspectives
Managers
Users
Ideally, All Key Stakeholders
Figure 1: Sample Interview Schedule

2. Designing Interview Questions

Unstructured interview
Broad, Roughly Defined Information
Structured interview
More Specific Information
Types of Questions
TYPES OF QUESTIONS EXAMPLES
Closed – Ended Questions How many telephone orders are received per day?
How do customers place orders?
What additional information would you like the
new system to provide?
Open – Ended Questions What do you think about the current system?
What are some of the problems you face on a daily
basis?
How do you decide what types of marketing
campaign to run?
Probing Questions Why?
Can you give me an example?
Can you explain that in a bit more detail?
Questioning Strategy

qR1st1nah 2
 SYSTEM ANALYSIS AND DESIGN

Figure 2: Top-Down and Bottom-Up Questioning Strategies

Bottom-up interview, the interviewer starts with very specific questions and moves to broad
questions. In practice, analysts mix the two approaches, starting with broad general issues,
moving to specific questions, and then back to general issues.
The top-down approach is an appropriate strategy for most interviews. (It is certainly the most
common approach.) The top-down approach enables the interviewee to become accustomed to
the topic before he or she needs to provide specifics. It also enables the interviewer to understand
the issues before moving to the details, because the interviewer may not have sufficient
information at the start of the interview to ask very specific questions. Perhaps most importantly,
the top-down approach enables the interviewee to raise a set of big-picture issues before
becoming enmeshed in details, so the interviewer is less likely to miss important issues.

3. Preparing for the Interview

Important things to do in preparing for an interview
Prepare General Interview Plan
List of Question
Anticipated Answers and Follow-Ups
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

4. Conducting the Interview

Things you should do in conducting an interview
Appear professional and unbiased
Record all information
Check on organizational policy regarding tape recording
Be sure you understand all issues and terms
Separate facts from opinions
Give interviewee time to ask questions
Be sure to thank the interviewee
End on time
Interpersonal skills are those that enable you to develop rapport with others, and they are very
important for interviewing. They help you to communicate with others effectively. Some people
develop good interpersonal skills at an early age; they simply seem to know how to communicate
and interact with others. Other people are less “lucky” and need to work hard to develop their
skills. Interpersonal skills, like most skills, can be learned.
Here are some tips:
Don’t Worry, Be Happy

qR1st1nah 3
 SYSTEM ANALYSIS AND DESIGN
Pay Attention
Summarize Key Points
Be Succinct
Be Honest
Watch Body Language

5. Post-Interview Follow-up
Prepare Interview Notes
Prepare Interview Report
Look for Gaps and New Questions

Figure 3: Interview Report

Interview Notes Approved by: Linda Estey
Person Interviewed: Linda Estey,
Director, Human Resources
Interviewer: Barbara Wixom
Purpose of Interview:
Understand reports produced for Human Resources by the current system.
Determine information requirements for future system.
Summary of Interview:
Sample reports of all current HR reports are attached to this report. The information that is not
used and missing information are noted on the reports.
Two biggest problems with the current system are:
1. The data are too old. (The HR Department needs information within 2 days of month end;
currently information is provided to them after a 3-week delay.)
2. The data are of poor quality. (Often, reports must be reconciled with the HR departmental
database.)
The most common data errors found in the current system include incorrect job-level
information and missing salary information.
Open Items:
Get current employee roster report from Mary Skudrna (extension 4355).
Verify calculations used to determine vacation time with Mary Skudrna.
Schedule interview with Jim Wack (extension 2337) regarding the reasons for data quality
problems.
Detailed Notes: See attached transcript.

III. Joint Application Development (JAD)

Joint application development (or JAD as it is more commonly known) is an information gathering
technique that allows the project team, users, and management to work together to identify
requirements for the system.

JAD Key Ideas

Allows project managers, users, and developers to work together
May reduce scope creep by 50%
Avoids requirements being too specific or too vague
Joint Application Design (JAD) Important Roles
Facilitator : someone who is an expert in JAD or e-JAD techniques and, ideally, someone who
has experience with the business under discussion. In many cases, the JAD facilitator is a
consultant external to the organization because the organization may not have a regular day-to-
day need for JAD or e-JAD expertise.

qR1st1nah 4
 SYSTEM ANALYSIS AND DESIGN
Scribe : assist the facilitator by recording notes, making copies, and so on. Often, the
scribes will use computers and CASE tools to record information as the JAD session proceeds.
Joint Application Design (JAD) Setting
U-Shaped seating
Away from distractions
Whiteboard/flip chart
Prototyping tools
e-JAD : Electronic JAD, or e-JAD, attempts to overcome these problems by the use of groupware.
In an e-JAD meeting room, each participant uses special software on a networked computer to
anonymously submit ideas, view all ideas generated by the group, and rate and rank ideas through
voting. The facilitator uses the electronic tools of the e-JAD system to guide the group process,
maintaining anonymity and enabling the group to focus on each idea’s merits and not the power
or rank of the person who contributed the idea.

Figure 4: JAD Meeting Room

The JAD Session

Tend to last 5 to 10 days over a three week period
Prepare questions as with interviews
Formal agenda and groundrules
Facilitator activities
Keep session on track
Help with technical terms and jargon
Record group input
Help resolve issues
Post-session follow-up

Managing Problems in JAD Sessions

Reducing domination
Encouraging non-contributors

qR1st1nah 5
 SYSTEM ANALYSIS AND DESIGN
Side discussions
Agenda merry-go-round
Violent agreement
Unresolved conflict
True conflict
Use humor

IV. 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.
Questionnaire Steps
Selecting participants
Using samples of the population
Designing the questionnaire
Careful question selection
Administering the questionnaire
Working to get good response rate
Questionnaire follow-up
Send results to participants
Good Questionnaire Design
Begin with non-threatening and interesting questions
Group items into logically coherent sections
Do not put important items at the very end of the questionnaire
Do not crowd a page with too many items
Avoid abbreviations
Avoid biased or suggestive items or terms
Number questions to avoid confusion
Pretest the questionnaire to identify confusing questions
Provide anonymity to respondents

V. 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.
Provides clues about existing “as-is” system
Typical documents
Forms
Reports
Policy manuals
Look for user additions to forms
Look for unused form elements
VI. Observation
Users/managers often don’t remember everything they do
Checks validity of information gathered other ways
Behaviors change when people are watched
Careful not to ignore periodic activities
Weekly … Monthly … Annual

Criteria for Selecting the Appropriate Techniques

Type of information
Depth of information
Breadth of information
Integration of information
User involvement

qR1st1nah 6
 SYSTEM ANALYSIS AND DESIGN
Cost
Combining techniques

Figure 5: Comparison of Requirements Elicitation Techniques

qR1st1nah 7
 SYSTEM ANALYSIS AND DESIGN
PROCESS MODELING
KEY DEFINITIONS
A process model is a formal way of representing how a business operates
Data flow diagramming shows business processes and the data that flows between them
Logical process models describe processes without suggesting how they are conducted
Physical models include information about how the processes are implemented

A. Data Flow Diagrams

Data flow diagramming is a technique that diagrams the business processes and the data that pass among
them. The focus is mainly on the processes or activities that are performed. It models the system by
depicting external entities from which the data flows and where results terminate, processes which
transform data flows, data stores from which the data are read or into which data are written by the
processes.

Data Flow Diagram Elements

Typical Computer-
Data Flow Aided DeMarco and
Gane and
Diagram DESCRIPTION Software Yourdon
Sarson Symbol
Element Engineering Symbol
Fields
PROCESS An activity or a function that is Label (name)
1
performed for some specific Type (process)
business reason. Processes can Description Name
Name
be manual or computerized. (what is it)
Every process has Process number
– a number Process description
– a name (verb phase) (structured English)
– a description Notes
– at least one output
– data flow
– at least one input
– data flow
DATA FLOW A data flow is a single piece of Label (name)
data (e.g., quantity available) Type (flow)
(sometimes called a data Description
element), or a logical collection Alias (another Name Name
of several pieces of information name)
(e.g., new chemical request). Composition
Every data flow has (description of data
– a name (a noun) elements)
– a description Notes
– one or more
– connections to a
process
DATA STORE A data store is a collection of Label (name)
data that is stored in some way. Type (store)
Every data store has Description
– a number Alias (another
– a name (a noun) name) D1 Name D1 Name
– a description Composition
– one or more input (description of data
– data flows elements)
– one or more output Notes
– data flows
EXTERNAL An external entity is a person, Label (name)
ENTITIY organization, organization unit, Type (entity)
or system that is external to the Description
Name Name
system, but interacts with it Alias (another
(e.g., customer, clearinghouse, name)
government organization, Entity description
accounting system). The Notes
external entity typically

qR1st1nah 8
 SYSTEM ANALYSIS AND DESIGN
corresponds to the primary
actor identified in the use case.
External entities provide data to
the system or receive data from
the system, and serve to
establish the system
boundaries.
Every external entity has
– a name (a noun)
– a description

RULES OF DATA FLOW

Data can flow from
– external entity to process
– process to external entity
– process to store and back
– process to process
Data cannot flow from
– external entity to external entity
– external entity to store
– store to external entity
– store to store

GOOD STYLE IN DRAWING DFD

 Use meaningful names for data flows, processes and data stores.
 Use top down development starting from context diagram and successively levelling DFD
 Only previously stored data can be read
 A process can only transfer input to output. It cannot create new data
 Data stores cannot create new data

DESCRIBING SYSTEMS WITH DFD & LEVELLING DFDS

An entire system is represented by one DFD which gives the system’s overview. It is called a context
diagram. It gives little detail & is also known as the top level DFD.

Context DFD
Context DFD is the entrance of a data flow model. It contains one and only one process and does not show
any data store.

Example: The figure below shows a context Data Flow Diagram that is drawn for a Food Ordering System.
It contains a process (shape) that represents the system to model, in this case, the "Food Ordering
System". It also shows the participants who will interact with the system, called the external entities. In
this example, Supplier, Kitchen, Manager and Customer are the entities who will interact with the system.
In between the process and the external entities, there are data flow (connectors) that indicate the
existence of information exchange between the entities and the system.

Supplier

0
Customer Food Ordering System
Kitchen

Manager

qR1st1nah 9
 SYSTEM ANALYSIS AND DESIGN
LEVELLING DFD
A context diagram gives an overview; it should be split into major processes which give greater detail.
Each major process is further split to give more detail. Each major process is further split to give more
detail.

WHY LEVEL DFD?

If a DFD is too detailed it will have too many data flows and will be large and difficult to understand.
Therefore, start from a broad overview. Expand the details - Idea similar to using procedures and linking
these with a main program. Each DFD must deal with one aspect of a big system

LEVELLING RULES
 If process p is expanded, the process at the next level are labeled as p.1,p.2 etc.
 All data flow entering or leaving p must also enter or leave its expanded version.
 Expanded DFD may have data stores
 No new external entity can appear in expanded DFD
 Keep the number of processes at each level less than 7.

ILLEGAL CONSTRUCTS IN DFD

 No loops are allowed in DFD
 A process cannot be a pure decision
 A single data flow should not be split into many flows with different labels
 No data flow allowed between data stores

Example: The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of the
Food Ordering System process shown in the context DFD.

The Food Order System Data Flow Diagram example contains three processes, four external entities and
two data stores.

qR1st1nah 10
 SYSTEM ANALYSIS AND DESIGN
Based on the diagram, we know that a Customer can place an Order. The Order Food process receives
the Order, forwards it to the Kitchen, store it in the Order data store, and store the updated Inventory
details in the Inventory data store. The process also deliver a Bill to the Customer.

Manager can receive Reports through the Generate Reports process, which takes Inventory
details and Orders as input from the Inventory and Order data store respectively.

Manager can also initiate the Order Inventory process by providing Inventory order. The process forwards
the Inventory order to the Supplier and stores the updated Inventory details in the Inventory data store.

EXERCISE#1: Create a DFD

Create a data flow diagram for a university library borrowing system. (Do not worry about catalogue
searching, etc.) The system will record the books owned by the library and will record who has borrowed
what books. Before someone can borrow a book, he or she must show a valid ID card that is checked to
ensure that it is still valid against the student database maintained by the registrar’s office (for student
borrowers), the faculty/staff database maintained by the personnel office (for faculty/staff borrowers), or
against the library’s own guest database (for individuals issued a “guest” card by the library). The system
must also check to ensure that the borrower does not have any overdue books or unpaid fines before he
or she can borrow another book. Every Monday, the library prints and mails postcards to those people
with overdue books. If a book is overdue by more than two weeks, a fine will be imposed and a librarian
will telephone the borrower to remind him or her to return the book(s). Sometimes books are lost or are
returned in damaged condition. The manager must then remove them from the database and will
sometimes impose a fine on the borrower.

Assignment:
Differentiate Logical DFD from Physical DFD.

qR1st1nah 11
 SYSTEM ANALYSIS AND DESIGN
LOGICAL AND PHYSICAL DFD
DFD’S considered so far are called logical DFDs. A physical DFD is similar to a document flow diagram. It
specifies who does the operations specified by the logical DFD. Physical DFD may depict physical
movements of the goods. Physical DFDs can be drawn during fact gathering phase of a life cycle.

Logical process models describe processes without suggesting how they are conducted.
Physical process models provide information that is needed to build the system.

Leveled DFDs
 Top-level DFD (Context diagram)
 Consists of only one process, representing the entire system
 Shows the interfaces between the system and the external entity
 Level 0
 Immediately beneath the context diagram
 Show the major functions and interfaces among them within the system
 Level 1 or below
 The numbers serve as a convenient way of relating a process to the next lower level
DFD
which should be numbered for convenient reference
 Example
 Process A be indexed at “2” in level 0
 Sub-process of A in level 1 should be “2.1”
 Remind the process name is carried down to the next lower level figure

Context Diagram
 The first DFD in every business process is the context diagram.
 It shows the entire system in context with its environment.
 The context diagram shows the overall business process as just one process and shows the data
flows to and from external entities.

Level 0 Diagram
 The level 0 diagram (or level 0 DFD) shows all the major high-level processes of the system and
how they are interrelated.
 The Level 0 diagram shows all the processes at the first level the numbering, the data stores,
external entities, and data flows among them.
 A key concept: Balancing
- Ensuring that all information presented in a DFD at one level is accurately represented in the next-
level DFD.
 A process model has one and only one level 0 DFD.

Level 1 Diagrams
 Each process on the level 0 DFD can be decomposed into a more explicit DFD called level 1
diagram (or level 1 DFD).
 The set of children and the parent are identical; they are simply different ways of looking at the
same thing.
 It is important to ensure that level 0 and level 1 DFDs are balanced.
 All process models have as many level 1 diagrams as there are processes on the level 0 diagram.
 The parent process and the children processes are numbered consistently.

Level 2 Diagrams
 The next level of decomposition: a level 2 diagram, or level 2 DFD.
 A level 2 DFD shows all processes, data flows, and data stores that comprise a single process on
the level 1 diagram.
 It is important to ensure that level 1 and level 2 DFDs are balanced.

qR1st1nah 12
 SYSTEM ANALYSIS AND DESIGN
Alternative Data Flows
 A process can produce different data flows under different circumstance.
 We show both data flows and use the process description to explain why they are alternatives.

Process Descriptions
 The purpose of the process descriptions is to explain what the process does and provide
additional information that the DFD does not provide.
 Three techniques are commonly used to describe more complex processing logic:
– Structured English
– Decision trees
– Decision tables

CREATING DATA FLOW DIAGRAMS

 DFDs start with the information in the use cases and the requirements definition.
 Generally, the set of DFDs integrates the individual use cases.
 The project team takes the use cases and rewrites them as DFDs, following the DFD formal rules
about symbols and syntax.
 CASE tools are used to draw process models.

STEPS:
1. Build the context diagram.
2. Create DFD fragments for each use case.
3. Organize the DFD fragments into level 0 diagram.
4. Develop level 1 DFDs based on the steps with each use case. In some cases, these level 1 DFDs
are further decomposed into level 2 DFDs, level 3 DFDs., and so son.
5. Validate the set of DFDs to make sure that they are complete and correct.

Creating the Context Diagram

 The context diagram defines how the business process or computer system interacts with its
environment.
 Draw one process symbol for the business process or system being modeled (numbered 0 and
named for the process or system).
 Add all inputs and outputs listed on the form of the use cases as data flows.
 Draw in external entities as the source or destination of the data flows.
 No data stores are included in the context diagram.

Example:

qR1st1nah 13
 SYSTEM ANALYSIS AND DESIGN
Creating DFD Fragments
 A DFD fragment is one part of a DFD that eventually will be combined with other DFD fragments
to form a DFD.
 Each use case is converted into one DFD fragment using the information given on the form of
the use case: the name, the ID number, and major inputs and outputs.
 The information about the major steps that make up each use case is ignored at this point; it will
be used in a later step.

Example:

qR1st1nah 14
 SYSTEM ANALYSIS AND DESIGN
Additional Example of Fragment

 Important changes are often made in converting the use case into a DFD:
- modifications to the process names
- the addition of data flows.
 Make sure that any information given to the user is obtained from a data store.
 There are not formal rules covering the layouts; typically
– place the processes in the middle
– inputs start from the left or top
– outputs leave from the right or the bottom
– place data stores below the processes

Creating the Level 0 Diagram

qR1st1nah 15
 SYSTEM ANALYSIS AND DESIGN

USE CASE ANALYSIS

A use case represents how a system interacts with its environment by illustrating the activities that are
performed by the users of the system and the system’s responses.

Elements of a Use Case

qR1st1nah 16