System Analysis

• Determination of System Requirements

System analysis is a details understanding of all important facets of the
business area under investigation. (For this reason, the process of
acquiring this information is often termed the detailed investigation).

Analysts structure their investigation by seeking answers to these four

major questions :
• What is the basic business process?
• What data are used or produced during that process?
• What are the limits imposed by time and the volume of work?
• What performance controls are used?
 Activities in Requirements Determination
Activity Description
Requirements Foreseeing systems characteristics based on previous
anticipation experience. May cause the analyst to investigate areas
and issues that could otherwise be overlooked. May also
introduce bias.
Requirements Study and documentation of the current system, using
investigation fact-finding techniques, data flow analysis, and decision
analysis.

Requirement Analysis of data describing the system to determine how

specification well it is performing, what requirements must be met,
and strategies for fulfilling term.
 System Analyst Skills
The interpersonal skills relevant
• Communication
• Understanding
• Teaching
• Selling
 System Analyst Skills
Technical skills include
• Creativity
• Problem solving
• Project management
• Dynamic interface
• Questioning attitude and inquiring mind
• Knowledge of the basic of the computer and the
business function.
 Academic and Personal Qualification
The background and experience of analyst
include :
• Familiarity with the workings of major application areas such
as financial accounting personal administration, marketing and
sales, operations management model building and production
control
• Competence in system tools and methodologies and a practical
knowledge of one or more programming and data base
languages.
• Experience in hardware and software specifications, which is
important for selection.
 The Multifaceted Role of the Analyst
• Change agent
• Investigator and monitor
• Architect
• Psychologist
• Salesperson
• Motivator
• Politician
 Information/ Fact-Gathering Tools

Review literature
Procedures, and
Forms

On-site
observation

Information- Data
Gathering tools Interviews Organization

Questionnaires
 Information/ Fact-Gathering Tools
• There are following tools available :
– Review of written documents
– Onsite observations
– Interviews and Questionnaires.

• Review of Written Documents :- When available, all documentation on data carriers (forms,
records, reports, manuals etc.) is organized & evaluated. Included in procedure’s manuals are
requirements of the system, which helps in determining to what extent they are met by the
present system.

• On-site Observation :- Another tool used by the system analyst in onsite observation / directs
observation. The analyst’s role is that of an info seeker. The purpose of onsite observation to
get as close as possible to the real “system being studied”

• Interviews & Questionnaires :- Interviews & Questionnaires method is less effective for
learning about people’s perceptions, feeling & motivation. In either method heavy reliance is
placed on the interview report for information about the job, the present system or
experience. The quality of response is judged in terms of its reliability. So the date gathering
depends on the design of the interview or questions manner, in which each instrument is
administered.
 Functional and Non- Functional
Requirements
• Functional requirements
– Statements of services the system should provide,
how the system should react to particular inputs
and how the system should behave in particular
situations.

• Non-functional requirements
– constraints on the services or functions offered by
the system such as timing constraints, constraints
on the development process, standards, etc.
 Functional requirements
• The functional requirement is describing the behavior of
the system as it relates to the system's functionality.
• Depend on the type of software, expected users and the
type of system where the software is used.
• Functional user requirements may be high-level statements
of what the system should do but functional system
requirements should describe the system services in detail.
• An example of a functional requirement would be that a
system must send an email whenever a certain condition is
met (e.g. an order is placed, a customer signs up, etc).
 Non- Functional requirements
• The non-functional requirement elaborates a performance
characteristic of the system.
• These define system properties and constraints e.g. reliability,
response time and storage requirements. Constraints are I/O
device capability, system representations, etc.
• Non-functional requirements may be more critical than
functional requirements. If these are not met, the system is
useless.
• A non-functional requirement for the system may be that
emails should be sent with a latency of no greater than 12
hours from such an activity.
 Non-functional classifications
• Product requirements
– Requirements which specify that the delivered product
must behave in a particular way e.g. execution speed,
reliability, etc.
• Organisational requirements
– Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
• External requirements
– Requirements which arise from factors which are external
to the system and its development process e.g.
interoperability requirements, legislative requirements, etc.
 Use Transaction Requirements
To understand the transaction requirements, analyst would
undoubtedly ask questions such as the following:
• What makes up the transaction being processed?
• What initiates the transaction?
• Who actually initiates the order? For what propose?
• How often do orders occur?
• Are there different conditions that can affect how orders are
processed?
• What details are needed to process the transaction?
• What information is generated? What data is stored?
 User Decision Requirements
Analysts investigating systems should raise the same questions
about timing and frequency discussed previously. But other
questions should also be posed to determine decision
requirements :
1. What information is used to make the decision?
2. What is the source of the information? Which transaction
systems produce the data used in the decision process?
Which data are required but do not result from processing
transitions? Which data originate from sources outside the
organization?
3. How should data be processed to produce the necessary
information?
4. How should the information be presented?
 SRS Template
• Project Name
• Introduction <Purpose of SRS. It is prepared for PM, Team, Sponsor, Client/ User>
• Business Requirement Overview <Describes the requirements that project work will fulfill>
• Assumptions and Constraints <>Describes any functional assumptions / constraints related to
project requirements
• Functional Requirements <Specify the expected behavior of the system being developed>
• Usability Requirements <Specify the ease of learning, task efficiency, ease of remembering, etc.>
• Performance Requirements <Specify the requirements that affect speed, safety, precisions,
capacity, scalability, etc.>
• Supportability Requirements <Specify maintainability, requirements related to training, ramp up
time, documentation , facilities etc.>
• Security Requirements < Specify the requirements that affect security such as security audits,
identification/ authentication, Privacy access etc.>
• Interface Requirements <Requirements include user navigation, presentation of application, and
associated functionality, data display etc.>
• SRS Approval
Date Signature
Name and Designation
 Creating Data Flow Diagrams
Steps:

1. Create a list of activities

2. Construct Context Level DFD
(identifies external entities and processes)
3. Construct Level 0 DFD
(identifies manageable sub process )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
5. Check against rules of DFD
 DFD Naming Guidelines

• External Entity  Noun

• Data Flow  Names of data
• Process  verb phrase
– a system name
– a subsystem name
• Data Store  Noun
Creating Data Flow Diagrams
Lemonade Stand Example
 Creating Data Flow Diagrams
Example
The operations of a simple
lemonade stand will be used
to demonstrate the creation
of dataflow diagrams.
Steps:
1. Create a list of activities
• Old way: no Use-Case Diagram
• New way: use Use-Case Diagram
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 0 DFD
(identifies manageable sub processes )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Think through the activities

that take place at a
lemonade stand.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Also think of the additional

activities needed to support
the basic activities.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Group these activities in

some logical fashion,
possibly functional areas.
Customer Order
Serve Product
Collect Payment

Produce Product
Store Product

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 2. Construct Context Level DFD
(identifies sources and sink)
Create a context level
diagram identifying the Context Level/0 Level DFD
sources and sinks (users).
Sales Forecast
Order 0.0
CUSTOMER Lemonade Production Schedule EMPLOYEE
Customer Order Product Served System Pay
Serve Product Payment Time Worked
Collect Payment Received Goods
Payment
Purchase Order
Produce Product
Store Product VENDOR

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 3. Construct Level 1 DFD
Create a level 1 diagram (identifies manageable sub processes )
identifying the logical Level 1 DFD
subsystems that may exist.
1.0
Sale
Customer Order Sales Forecast
Customer Order
Product Ordered
Serve Product
Payment
Collect Payment 2.0 Production
CUSTOMER EMPLOYEE
Production Schedule
Product Served
Produce Product
Inventory
Store Product Received Goods
3.0
VENDOR Procure- Order
Purchase Order
Order Raw Materials ment Decisions
Pay for Raw Materials Payment
Pay Time Worked

Pay for Labor 4.0

Payroll
 Creating Data Flow Diagrams
Example 4. Construct Level 2- n DFD
Create a level 2 (identifies actual data flows and data stores )
decomposing the processes Level 2 DFD
in level 1 and identifying
CUSTOMER
data stores.
Customer Order
Request for Forecast
Customer Order ORDER

Serve Product 1.1

Record
Collect Payment Order
1.3
Produce
Severed Order Sales
Produce Product Payment Forecast
Sales Forecast
Store Product
1.2
Receive PAYMENT
Payment
Order Raw Materials
Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 4. Construct Level 2 (continued)
Create a level 2
decomposing the processes Level 2 DFD
in level 1 and identifying
Product Order
data stores.
ORDER
Customer Order 2.1
Serve Quantity Severed
Serve Product Product
Collect Payment RAW
Production
MATERIALS
Schedule
Produce Product 2.2
Store Product Produce Quantity Used
Product

INVENTORTY
Order Raw Materials Production Data
Pay for Raw Materials
2.3 Quantity Produced &
Store Location Stored
Pay for Labor Product
 Creating Data Flow Diagrams
Example 4. Construct Level 2 (continued)
Create a level 2
decomposing the processes Level 2 DFD
in level 1 and identifying Order Decision
PURCHASE
data stores. 3.1 ORDER
Produce
Purchase
Customer Order Order Quantity On-Hand
Serve Product Quantity
RAW
MATERIALS
Collect Payment Received Received
Goods
3.2
Produce Product Receive
Items
Store Product RECEIVED
ITEMS
Payment Approval
Order Raw Materials
VENDOR
Pay for Raw Materials 3.3
Pay
Vendor
Pay for Labor
Payment
 Creating Data Flow Diagrams
Example 4. Construct Level 2 (continued)
Create a level 2
decomposing the processes Level 2 DFD
in level 1 and identifying Time Worked

data stores. 4.1 TIME CARDS

Record
Time
Customer Order Worked Employee ID
Serve Product EMPLOYEE
Collect Payment
Payroll Request
4.2
Unpaid time cards
Produce Product Calculate
Payroll
Store Product PAYROLL

Payment Approval
Order Raw Materials
4.3
Pay for Raw Materials Pay
Employe
e PAYMENTS
Pay for Labor
Payment
 Process Decomposition
1.1 1.2
1.0
Record Receive
Sale
Order Payment

2.1 2.2 2.3

2.0
Serve Produce Store
Production
Product Product Product

0.0
Lemonade
System
3.1
3.0 3.2 3.3
Produce
Procure- Receive Pay
Purchase
ment Items Vendor
Order

4.1 4.3
4.2
4.0 Record Pay
Calculate
Payroll Time Employe
Payroll
Worked e

Context Level Level 1 Level 2

 What is a Data Dictionary?
A data dictionary is a catalog – a repository of the elements in
a system. As the name suggests, these elements center
around data and the way they are structured to meet user
requirements and organization needs. In a data dictionary
we will find a list of all the elements composing the data
flowing through a system. The major elements are data
flows, data stores, and processes. The data dictionary
stores details and descriptions of these elements.
A data dictionary is a structured repository of data about
data. It is a rigorous definitions of all DFD data elements
and data structures.
 Why Data Dictionary is Important?

Analysts use data dictionaries for five important reasons :

1. To manage the detail in large systems
2. To communicate a common meaning for all system
elements
3. To document the features of the system
4. To facilitate analysis of the details in order to evaluate
characteristics and determine where system changes
should be made
5. To locate errors and omissions in the system
What does a Data Dictionary Record?

• Data elements
• Data structures
 Describing Data Elements
• Data names
• Data descriptions
• Aliases
• Length
• Data values
Relation of Components on Data Flow Diagrams

Data structure Invoice

Data of invoice
Vendor
Data element Vendor address
Item details
 Notation Used to Show Structural Relationships in Data

SYMBOL MEANING EXPLANATION USE

= Is equivalent to Alias Denotes synonyms
+ and Concatenation defines Denotes sequence relationship
components always included in a
particular data structure
[] Either/or Defines alternate components o a Denote selection relationship
data structure

{} Iteration of Defines the repetition of a Denote iteration relationship

component in a data structure

() Optional Defines iteration that occurs only Denote optional relationship

0 or 1 items
PREEIX DEPARTMENT
A Accounting Department
B Purchasing Department (Buyers)
M Manufacturing Division
P Personal Section
S Sales Department
T Transportation
 Describing Data Structures
• Sequence relationship
• Selection (Either/Or) relationship
• Iteration (Repetitive) relationship
• Optional relationship
 Data Descriptions and Notation
Invoice = Payment request “may be unlabeled from some*
Payment voucher = Invoice package + payment approval

Invoice receipt = Signed invoice

Audit approval = Audited invoice

Purchase authorization Purchase order number

= + authorization
Manager approval
date
Item details = Item number + item description + item cost + item extension

Amount of invoice = {Item extension} + shipping amount ( + sales tax)

Vendor balance = Beginning balance + {purchase} + {payments} + {credits}

Beginning balance = Vendor balance *sets up next month cycle*

Symbols : = is equivalent to
= and
[ ] either/or
{ } iterations of
( ) optional
* Encloses annotation
 Sample Data Flow Dictionary Entry
DATA FLOW Invoice package
NAME : Singed billing details from vendor and
DESCRIPTION : internal purchasing authorization – unedited
for correct
FROM 1.3 verify merchandise ordered
PROCESSES: 1.4 receive purchasing authorization

TO PROCESSES : 1.5 price invoice (batched through)

approved invoices delay)

DATA Invoice package

STRUCTURE - Invoice details
- receiving acknowledgement
- purchasing authorization
 Sample Data Store Dictionary Entry
DATA STORE : Approved invoices
DESCRIPTION : Vendor request for payments submitted for processing.
Itemizes merchandise received, cost of each and contains
signature of employee receiving merchandise
INBOUND DATA FLOW : 1.1 signed invoice
1.2 signed invoice-when signature needed
INBOUND DATA FLOW : Item details-batched invoice details

DATA DESCRIPTION : Vendor details Item details

Invoice number amount due
Invoice data
Purchase order reference
VOLUME : 200 daily : growing 10% annually ; heaviest at beginning
of month
ACCESS Delayed for batching, then accessed together; sequentially
processed from within batch.
 Sample Data Store Dictionary Entry
DATA FLOW Invoice package
NAME : Singed billing details from vendor and
DESCRIPTION : internal purchasing authorization – unedited
for correct
FROM 1.3 verify merchandise ordered
PROCESSES: 1.4 receive purchasing authorization
TO PROCESSES : 1.5 price invoice (batched through)
approved invoices delay)

DATA Invoice package

STRUCTURE - Invoice details
- receiving acknowledgement
- purchasing authorization
 Sample Data Store Dictionary Entry
DATA ELEMENT : Purchase order number
DESCRIPTION : Identification and authorization for each order
given to an outside supplier
TYPE : © AN N
LENGTH 7
ALIASES : PO, Requisition
LIST OF SPECIFIC VALUES (IF ANY) TO
TYPICAL VALUE increasing from 10000
Valid prefixes Meaning
Accounting
AC
AD Advertising
EX Executive office
PE Personnel
PU Purchasing
RD Research and development
SA Sales
OTHER EDITING DETAILS : Purchase order number includes 5 digit number
and department prefix
 Sample Data Store Dictionary Entry

PROCESS : Verify merchandise ordered

DESCRIPTION : Matches every incoming invoice with a valid purchase order
number or authorization

INPUT Invoice details

Purchase order details
OUTPUT Invoice package
Unverified package
LOGIC SUMMARY: Match received invoice with valid purchase authorization.
Attach purchase order information to complete invoice package.
If there is no valid purchase order have manager approve.
If approved by manager, note approval on invoice and complete
invoice package.
If not approved by manager, return invoice to originator noting
that it is not approved for payment.