Chapter three

Systems Analysis

Chapter Content:

Part II: Requirement Structuring

Part I: Requirement determination

Systems analysis
Definition of System Analysis
 System analysis is the study of a business problem for
the purpose of recommending improvements and
specifying the business requirements for the solution.
 It has three parts: determining requirements,
structuring requirements and selecting the best
alternative design strategy. These steps are may be
parallel and repetitive
3.2. Requirements Determination

 Requirement determination means gathering information on

what the system should do from as many sources as possible.
 Analysts use system requirements determination to
understand current problems and opportunities, as well as
what is needed and desired in future systems.
• The sources can be the users of the current system, reports,
forms and procedures. All the system requirements are
carefully documented and made ready for structuring
 Requirements Determination
•The characteristics of a good systems analyst in determining the
requirements are:
• Impertinence: You should question about each and every aspects
involved in the system
• Impartiality: to find the best organizational solution
• Relaxing of Constraints : Assume that anything is possible and
eliminate the infeasible and traditions.
 Attention to details: Every fact must fit with every other fact. One
element out of place means that the ultimate system will fail at some time.
 Reframing: Analysis is, in part, a creative process; the organization must
be viewed in new ways.
Deliverables and outcomes

• The primary deliverables from requirements

determination are the types of information
gathered and the information can take many
forms such as transcripts of interviews, notes
from observation and analysis of documents,
analyzed responses from questionnaires, set of
forms, reports, job descriptions and other
documents
 Requirements Determination
 In addition a SA need to understand the following components of an organization
 The business objectives
 The information people need to do their jobs
 The data handled within the organization to support the jobs
 When, how and by whom or what the data are moved, transformed and stored
 The sequence and other dependencies among different data handling activities
 The rules governing how data are handled and processed
 Policies and guidelines that describe that nature of the business and the market and
environment in which it operates
 These all information must be organized for the purpose of requirements structuring
3.2.1. Traditional Methods for gathering requirements

 The traditional ways to get information directly from

those who have the information is by conducting
interviews, questionnaires and direct observation.
 And collecting documentation on the current system and
organizational operation in the form of written
procedures, forms, reports and other hard copy.
• All the methods can be used to gather requirements and
build up information about the current system.
a.Interviewing

 The System Analyst has to spend a large

amount of time in interviewing the people
about their work, the information they use to
do it and the types of information processing
that might supplement their work
 Interviewing

 The advantages of open-ended questions: previously

unknown information can surface, and interviewee
may get more of a sense of involvement and control
in the interview.
 The major disadvantage of open-ended questions in
the length of time it can take for the questions to be
answered.
a.Interviewing

 Closed-ended questions provide a range of answers from which the

interviewee may choose.
 These sort of questions works well when the major answers to
questions are well known. Another plus is that interviews based on
these questions do not require a large time.
 The major disadvantage of closed-ended questions is that useful
information that does not quite fit the defined answers may be
overlooked as the respondent tries to make a choice instead of
providing his or her best answers.
a.Questionnaires

 Questionnaires have the advantage of gathering information from

many people in a relatively short time. Interviews are quite expensive
and time-consuming process, but the questionnaires are not expensive.
 Questionnaires are passive and often yield less rich information than
interviews.
 Questionnaires are most useful in the requirements determination
process when used for very specific purposes rather than for more
general information gathering.
•
c. Direct observation

 It is also possible to gather information about a

system by watching the users of the system at work.
 This method can bring more objective information -
as the analyst can see what the person does
(behavior), rather than what they say they do.
 This can be used to supplement or confirm the
information obtained by asking questions.
a.Analyzing Documents (Reports, forms, procedures and manuals)

 Another way to gather information about the current system or possible

improvements to it is to review and analyze documentation
 This can provide information about :
o Problems with existing systems (Ex. Missing information, redundant steps)
o Possible new features that can be added to existing systems, if certain new
information is now available (Ex. analysis of sales based on customer type)
• Special Circumstances that occur irregularly but may not be identified
by any other requirements gathering technique(Ex. if special handling is
required for a few very large volume customers, where customized
customer ordering procedures are required)
Data definitions, rules for processing data (Business rules) in the system
3.2.2. Modern methods for gathering requirements

 The modern methods are additional techniques to collect information about the current
system, the organizational area requesting the new system, and what the new system should
be like: the modern methods are Joint Application Design and Prototyping.
 These techniques reduce the time of collecting and structuring the requirements.
•Joint Application Design (JAD)
 JAD is a means to bring together the key users, managers, and systems analysts involved in
the analysis of a current system.
 The goal of JAD is to collect systems requirements simultaneously from the key people
involved in the system.
 JAD sessions are usually conducted in a location away from where the people normally
work, to keep them away from all distractions , so that they can concentrate fully on
systems analysis.
Figure- A typical room layout for a JAD
session
 PART II: SYSTEM ANALYSIS
Structuring Systems Requirements

•The information gathered during the requirements gathering

process needs to be organized into a form that is a meaningful
representation of the existing system and of the requirements for
the new system.
•This is done by producing models of the processing elements and
data transformations and then of the structure of the data. This
entire process is called structuring requirements
• There are three stages in the structuring process
 Process modeling
•Definition: involves graphically representing the processes, or
actions that capture, manipulate, store and distribute data
between a system and its environment and among the
components within a system.
•A common form of a process model is a data flow diagram
(DFD). DFD is a graphic that illustrates the movement of data
between external entities and the processes and data stores
within a system.
Conceptual Data Modeling:

•Involves representing the data in a system or

organization, to show the overall structure of the
data. A data model should be independent of any
DBMS and of other implementation considerations.
•Entity-Relationship diagram(ER) data models
are commonly used diagrams that show how data is
organized in a system.
Logical modeling:

•Logic modeling involves representing the internal

structure and functionality of the processes
represented on data-flow diagrams. These
processes appear on DFDs as little more than
black boxes, in that we cannot tell from only their
names precisely what they do and how they do it.
Yet, the structure and functionality of a system’s
processes are a key element of any information
system. Processes must be clearly described
before they can be translated into a programming
language.
Data Flow Diagrams
• The DFD is an excellent communication tool for
analysts to model processes and functional
requirements
•Data Flow diagramming mechanics
•Data flow
• Registration data
•Process
• Is a work or actions performed on data so that
they are transformed, stored, or distributed
 Data Flow diagramming mechanics

Symbol: Circle or a Rounded Rectangle.

Data Store
•Process
 Guidelines for drawing DFDs
• Completeness: It refers to whether the DFDs
include all the components necessary for the system
you are modeling. If the DFD contains data flows
that do no lead anywhere, or data store, processes,
or external entities that are not connected to
anything else, that DFD is not complete
• Consistency: It refers to whether or not the
depiction of the system shown at one level of a
DFD is compatible with the depictions of the
system shown at other level.
 Guidelines for drawing DFDs
• Timing considerations: On a given DFD,
there is no indication of whether a data flow
occurs at what time and there is also no
indication of when a system would run.
• The iterative nature of drawing DFDs:
Iterative development recognizes that
requirements determination and requirements
structuring are interaction, not sequential, sub
phases of the analysis phase of the SDLC
U sin g D a ta flo w d ia g ra m m in g in th e a n a ly si

 Gap Analysis: The process of discovering discrepancies

between two or more sets of data flow diagrams or
discrepancies within a single DFD.
 DFD can be used for gap analysis. Once DFD is
completed, it is examined for problems like redundant data
flows, data that are captured but not used by the system,
and data are updated identically in more than one location.
•INFORMATION
•Entity
 A data entity is anything real or abstract about which we want to store data.
•Entity types fall into five classes: roles, events, locations, tangible things or concepts.
E.g. employee, payment, campus, book. Specific examples of an entity are called
instances. E.g. the employee John Jones, Mary Smith's payment, etc. Relationship
 A data relationship is a natural association that exists between one or more entities.
E.g. Employees process payments.
 Cardinality defines the number of occurrences of one entity for a single
occurrence of the related entity. E.g. an employee may process many payments but
might not process any payments depending on the nature of her job.

•Attribute
 A data attribute is a characteristic common to all or most
instances of a particular entity. Synonyms include property,
data element, field. E.g. Name, address, Employee
Number, pay rate are all attributes of the entity employee.
• An attribute or combination of attributes that uniquely
identifies one and only one instance of an entity is called a
primary key or identifier. E.g. Employee Number is a
primary key for Employee
Conceptual Data Modeling (E-R Diagram)

•An entity-relationship model, a graphical representation of

entities and their relationships to each other, describes the
organization of data within databases or information systems. An
entity is a piece of data—an object or concept about which data is
stored. A relationship is how the data is shared between entities.
•ER diagram expresses the overall logical structure of a database
graphically.
•There are three types of relationships between entities:
 Conceptual Data Modeling (E-R
Diagram
 One-to-one: one instance of an entity (A) is associated with one other instance of another entity
(B). For example, in a database of employees, each employee name (A) is associated with only
one social security number (B).
 One-to-many: one instance of an entity (A) is associated with zero, one or many instances of
another entity (B), but for one instance of entity B there is only one instance of entity A. For
example, for a company with all employees working in one building, the building name (A) is
associated with many different employees (B), but those employees all share the same singular
association with entity A.
 Many-to-many: one instance of an entity (A) is associated with one, zero or many instances of
another entity (B), and one instance of entity B is associated with one, zero or many instances of
entity A. For example, for a company in which all of its employees work on multiple projects,
each instance of an employee (A) is associated with many instances of a project (B), and at the
same time, each instance of a project (B) has multiple employees (A) associated with it.