Analyse Requirements

System Analysis
(Analysing Requirements)
CSC 2202 Systems Analysis and Design 1

Outline
Objectives
Types of Requirements
 Functional requirements
 Non-Functional requirements
Structured Analysis techniques
 Data flow diagrams
 Data dictionary
 Process descriptions
 Entity Relationship Diagrams
Review questions

Objectives
• Explain the structured analysis
process and identify its elements
• Explain data flow diagrams their use in
documenting requirements
• Describe the data dictionary and its
use in documentation.

Requirements Analysis
Requirements analysis describes all the
tasks of instigation, scoping and
definition of a new or altered computer
system.
It enables business analysts or software
developers identify the needs or
requirements of a client in order to design
a solution

Types of Requirements
Functional requirements
Describe what the system should do
Non-functional requirements
Consists of Constraints that must be adhered to
during development (design and implementation)
Operative word: ‘Constraints.’

Functional requirements
What inputs the system should accept
What outputs the system should produce
What data the system should store that other

systems might use
What computations the system should perform
The timing and synchronization of the above

Non-functional requirements are global constraints on
a computer system
 e.g. development costs, operational costs,
performance, reliability,
The challenge of Non-functional requirements:
 Hard to model
 Usually stated informally, and so are:
 often contradictory,
 difficult to enforce during development
 difficult to evaluate for the customer prior to

delivery
Define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations.
Process requirements may also be specified
mandating a particular programming language or
development method
Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless

Examples of NFR
Interface requirements
 how will the new system interface with its
environment?
 User interfaces and “user-friendliness”
 Interfaces with other systems
Performance requirements
 Time - response time
 Throughput - transactions per second

Examples of NFR
Security
 permissible information flows
 Or who can do what
 Survivability – e.g. system will need to survive fire
natural catastrophes, etc
Operating requirements
 physical constraints (size, weight),
 personnel availability & skill level
 accessibility for maintenance
 environmental conditions

Examples of NFR
Lifecycle requirements
 Maintainability, Enhanceability, Portability,
expected market or product lifespan
limits on development
 E.g development time limitations, resource
availability and methodological standards.
Economic requirements
 e.g. restrictions on immediate and/orlong-term
costs.

User Requirements
Specification -URS
It is a document produced by, or on
behalf of an organisation, which
documents the purposes for which a
system is required
Its functional requirements - usually in
order of priority / gradation.

User Requirements
Specification -URS
The URS document outlines precisely
what the User (or customer) is expecting
from this system.
The term User Requirement Specification
can also incorporate the functional
requirements of the system or may be in
a separate document labelled the
Functional Requirements Specification -
the FRS.

System requirements
specification
What do we agree to provide?

A structured document setting out
detailed descriptions of the system
services.
Written as a contract between client and
contractor.

User Requirement Document
The URD has has the following
information:
3. Functional Requirements
4. Non-Functional Requirements

Structured Analysis

Structured Analysis
Examines inputs, outputs, and processes
Process-centered technique
Uses three main tools
 Data flow diagrams (DFDs)
 Data dictionary
 Process descriptions(modeling)
Tools can be applied using computer-aided software

engineering (CASE) tools

Analysis Models
Each modeling tool provides a different perspective
on the system under investigation
Data Flow Diagrams
Data Dictionary
Process (Transform) Descriptions using:
 Structured English, Action Diagrams, Decision
Tables, Decision Trees, Narratives
Entity Relationship diagrams

Structured Analysis
It deals more with the logic of the system.
The analyst defines what the system should do.
Breaks down the system into manageable subsystems
Method defines systems inputs, processes, and
outputs
Partitions systems into subsystems or modules that
show a logical graphic model of information flow.

Structured Analysis
Objective of Structured Analysis
Is to document all the end user requirements
for the proposed Information System and
present these requirements in the systems
requirement document.

Structured Analysis
Structured Analysis accomplishes the
following:-
• Views the system from the top to down.
• Specifies the interfaces that exist
between modules.
• Rigorously specifies the processes or
transformations that occur within each
module.

Components of Structured
Analysis
 Data Dictionary – description of all the data
used in the system.
 2. Graphic Symbols – icons and conventions
for identifying and describing the components of
a system and relationship among these
components.
3. Procedure and Process description – Formal
statements using techniques and languages that
enable systems analysts to describe important
activities that make up a system.
4. Rules standards for describing and documenting
the system correctly and completely
Document Flow Diagram
• A diagramming technique which is used to
identify physical movement of documents.
• It shows where the document comes from,
where it goes to, and what it is called.
• The source and destination of the
document are usually shown using an
elliptical shape.

Document Flow Diagram for a
Purchasing System
1 Order
Supplier Purchasing
Dept
Invoice
Delivery notes
Stores

Document Flow Diagram
• For each document or communication that
occurs in the system, identify the source
and the target. This will help in developing
a context diagram during analysis.
• It is a physical data flow diagram.

Process modeling with data flow
diagrams
Data Flow Diagrams – show how data
moves and changes through an IS in a
graphical top-down fashion. i.e. a graphic
representation of a system’s components,
processes and the interfaces between them.

Data Flow Diagrams
Data flow diagrams (DFDs) are graphical
aids that describe an information system .
They represent a logical model that shows
what a system does, not how it does it.
It is a network representation of a system.
Stresses flow of data within a system.

Data Flow Diagrams
Simplicity (only 4 symbols used) enhances
communication between users and system
designers
Stress processes and transformation of data
within a system
“Drives” the process of system description
An iterative process

Data Flow Diagram - 4 components
A DFD comprises combinations

of 4 symbols:
• External entity – rectangle
• Data flow – arrow
• Process - circle (Yourdon).
• Data store - 2 parallel lines (Yourdon)

Data Flow Diagram - 4 symbols
(Yourdon)
Customer
•External Entity
•Data Flow Invoice
•Process Compute
Discount
•Data Store Customer Accounts

Data Flow Diagram - 4 symbols
(Gane and Sarson convention)

DFD components
 External
Entities
Sources/destinations for
data
Outside the system
Name is Noun Phrase
Conventions vary

DFD components
External entity :
 outside the context of the system
any class of people, organisation or another
system
 function is to supply or receive data
 also called Source and Sink

also called Origin and Destination
 are originators or receivers of information
outside the scope of the IS portrayed in the
data flowing.

DFD components
Data flow
Show movement of data
Is a pipeline carrying data through the system
These show the movement of data
between processes, external entities,
and data stores in a DFD.

DFD components
Process
incoming data flows are processed or
transformed into outgoing data flows
they portray the transformation of
input data flows to output data
flows in DFDs.

DFD components
 Process/System
Numbered
Name is verb/object phrase;

Noun for high-level systems

DFD components
Data flows
Directedarrow
Shows data in motion
Name uniquely identifies data
Name is a noun phrase

DFD components
Data flow symbol
Symbol is a line with an arrowhead
showing direction
A path for data to move from one part of
the system to another

Might represent one or many pieces of
data
At least one data flow must enter and exit
each process
DFD components
A resource flow/physical flow
shows the flow of any physical
material from its source to its
destination.
They are usually restricted to
early, high-level diagrams.
Used to describe the physical
flow of materials considered
important in the analysis.

DFD components
Data store
a temporary or time delayed repository
or collection of data
processes can add data to, or retrieve
data from, these stores
are either manual or automated
inventories of data. e.g. computer files
or databases, file cabinets& card files.
DFD components
Data Store
Staticdata
data held for archive or subsequent
processing
Name is a noun phrase

DFD components
Data Stores
Each store is given a reference letter
'D' - indicates a permanent computer file
'M' - indicates a manual file
'T' - indicates a transient store, one that is deleted
after processing.
To avoid complex flows, the same data store may be

drawn several times on a diagram. Multiple instances
of the same data store are indicated by a double
vertical bar on their left hand edge.
DFD - Context Diagram
Defines the scope of the system

Provides on “outward” looking view from
the system
Shows the other systems and/or groups
of people that interact with the system
Shows the main flows of data

DFD - Context Diagram (cont)
Context diagram - It is a simple DFD

that depicts the system being studied
as it relates to other systems, the
business, and the outside world – the
interfaces flowing to or from external
entities.

.
Order DFD - Context
Diagram
Invoice
Order
processing
Warehouse
Customer system Picking-labels
Order-rejection-
notice
Out-of-stock-
notice Context diagram of an order
processing system

.
DFD - Context Diagram
Notation

Data Flow Diagram- Context
Diagram
Register-Request
Student Course- Faculty

Enrolment
Schedule
Tuition-Bill Student
Student-Bal-Due
Registration
Accounts-Receivables-Stmt System
Accounts
Receivable
New-Bal-Due System
Data Flow Diagram- Context
Diagram
Airline
reservation
system

Context Diagram
One Process/System
 The system/process being analyzed
 Name: Usually a Noun phrase
Show Context Only

 Inputs/outputs
 External Entities
 No Data Stores
 No flows between external entities
Diagram Zero

Context Diagram
One Process/System
 The system/process being analyzed
 Name: Usually a Noun phrase
Show Context Only

 Inputs/outputs
 External Entities
 No Data Stores
 No flows between external entities
Diagram Zero

DFD guidelines
– Any data flow leaving a process must be
based on data that is input to the process
(Outputs must be derivable from inputs).
– All data flows are named and the name
reflects the data flowing between the
processes, sources, and data stores (All
elements must be named).
– All process have both inputs and outputs.
– No physical items

DFD guidelines
5. All the data needed to perform the process
should be input to that process.
6. The process should be independent of any
other in the system – each process has its
own input and output.
7. Data must move through a process.
8. Different data flows may not merge

More on DFD guidelines
All DFD diagrams must have a Heading
with :
 Name and Diagram No. (except for context
diagram)
All process bubbles must have name and
no.
Conservation of Data Flow
Flow Out = Flow In + Amount Stored
-applies to Transform bubbles and data
stores

More on DFD guidelines
Avoid infinite sinks i.e. a process with no
outgoing dataflows
Avoid spontaneous generation
bubbles i.e. a process without any
incoming dataflows
Beware of read-only or write-only data
stores

Data Flow Diagram
Ref: http://www.getahead-direct.com/gwbadfd.htm

Levelling Data Flow Diagrams
DFDs can be drawn in various levels of
details using a technique known as levelling,
ranging from depicting an entire system’s “big
picture” to showing the detailed processing of
a single transaction. The entire collection of
DFDs is called a levelled set.
Leveling breaks down higher level (parent)
DFD into constituent lower level (child) DFDs

Data Flow Diagrams –
Numbering Rules

How many levels deep in the hierarchy should
processes continue to be exploded?
Based on the judgement of the analyst
Some guidelines of when to stop drawing
more detailed diagrams are when a process
bubble:
-has a single input and output
-performs a single, well-defined function

How many levels deep in the hierarchy
should processes continue to be exploded?
Functional primitive or primitive transform
is the name given to each of the lowest
level process bubbles
Has an elementary process
description(EDP)
Unlikely that all parts partitioned to the
same level

Most investigations will stop at level 2 and it is

very unusual to go beyond a level 3 diagram


Drawing DFDs
Determine the System boundary
Context Diagram - one circle containing the system
name
Draw and label the external entities
Draw the major system inputs and outputs
Diagram 0 and below is more difficult
- start with what you know - not at the “Beginning”
Decompose Diagram 0 to lower level diagrams

Data Dictionary - supporting
documentation for DFDs
DFD’s need supporting
documentation to define:
2. The contents of the packets of
data in the data flows
3. the contents of the data stores
4. the processing that takes place
in bubbles that have not been
partitioned

4. To add the control functions that

are omitted from DFD’s e.g. IF...
ELSE ... logic; process performed
at the end of each day; etc
5. Data Dictionary is developed in
parallel with the DFD

A data dictionary is used to record
information about a system (textual and
numeric) that cannot be recorded on
diagrams
It is a database that supports analysts
and designers in the task of analyzing,
modeling and designing computer
systems

DD may be paper based
Purpose designed DD based on
commercial DBMS are now available.
A DD can be considered as a case tool.

Review questions
1. Explain the role of data flow diagrams in
the systems development process.
2. Explain the difference between logical and
physical data flow diagrams - use an
example.
3. Describe each of the four components of a
data flow diagram.

Analyse Requirements

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analyse Requirements

Uploaded by

Copyright:

Available Formats

System Analysis

CSC 2202 Systems Analysis and Design 1

CSC 2202 Systems Analysis and Design 2

CSC 2202 Systems Analysis and Design 3

CSC 2202 Systems Analysis and Design 4

CSC 2202 Systems Analysis and Design 5

What outputs the system should produce

What data the system should store that other

What computations the system should perform

The timing and synchronization of the above

CSC 2202 Systems Analysis and Design 6

 difficult to enforce during development

 difficult to evaluate for the customer prior to

CSC 2202 Systems Analysis and Design 8

 Interfaces with other systems

 Throughput - transactions per second

CSC 2202 Systems Analysis and Design 9

CSC 2202 Systems Analysis and Design 10

CSC 2202 Systems Analysis and Design 11

CSC 2202 Systems Analysis and Design 12

CSC 2202 Systems Analysis and Design 13

What do we agree to provide?

CSC 2202 Systems Analysis and Design 14

CSC 2202 Systems Analysis and Design 16

CSC 2202 Systems Analysis and Design 17

Tools can be applied using computer-aided software

CSC 2202 Systems Analysis and Design 18

CSC 2202 Systems Analysis and Design 19

CSC 2202 Systems Analysis and Design 20

CSC 2202 Systems Analysis and Design 21

CSC 2202 Systems Analysis and Design 22

CSC 2202 Systems Analysis and Design 24

CSC 2202 Systems Analysis and Design 25

CSC 2202 Systems Analysis and Design 26

CSC 2202 Systems Analysis and Design 27

CSC 2202 Systems Analysis and Design 28

CSC 2202 Systems Analysis and Design 29

A DFD comprises combinations

CSC 2202 Systems Analysis and Design 30

•Data Flow Invoice

•Data Store Customer Accounts

CSC 2202 Systems Analysis and Design 31

CSC 2202 Systems Analysis and Design 32

Name is Noun Phrase

CSC 2202 Systems Analysis and Design 33

 also called Source and Sink

CSC 2202 Systems Analysis and Design 34

CSC 2202 Systems Analysis and Design 35

CSC 2202 Systems Analysis and Design 36

Name is verb/object phrase;

CSC 2202 Systems Analysis and Design 37

Name uniquely identifies data

Name is a noun phrase

CSC 2202 Systems Analysis and Design 38

the system to another

CSC 2202 Systems Analysis and Design 40

CSC 2202 Systems Analysis and Design 42

To avoid complex flows, the same data store may be

Defines the scope of the system

CSC 2202 Systems Analysis and Design 44

Context diagram - It is a simple DFD

CSC 2202 Systems Analysis and Design 45

CSC 2202 Systems Analysis and Design 46