System design

SYSTEMS ANALYSIS AND
DESIGN
Cutajar & Cutajar

SYSTEM ANALYSIS 2
INTRODUCTION
System analysis and design covers the activities involved
in developing a new system.
It is the process of analysing particular systems (scientific, business
or control), to see if replacement (or upgrading) would yield a more
useful, productive and profitable way of performing the business
operations.
System analysis and design involves System Analysts.
System Analysts are deeply involved:-
Analyse the data processing requirements of an organisation, in whole
or in part;
Decide what, in consequence, the computing system should do;
Specify the tasks of the computing system in detail, so that the technical
specialists (programmers) can do their work;
Ensure that the developed computing system works efficiently.

SYSTEM ANALYSIS 3
WHAT IS A SYSTEM?
A system is a collection of interrelated components that work together
to achieve some objective
Different components making up a system include:
Hardware
Software
Collection of data
Work of a number of people.
Different components making up the software component of a system
include:
inputs
processes
stored data
outputs
human communication interface (HCI)

SYSTEM ANALYSIS 4
SYSTEM ELEMENTS
A commercial or industrial enterprise can be defined in
terms of system elements:
Physical
e.g. Buildings, raw materials, finished product;
Procedural
e.g. Order processing routines, credit checking procedures;
Conceptual
e.g. Statement of policy, material for products;
Social
e.g. Workers, departments.

SYSTEM ANALYSIS 5
SYSTEM ENVIRONMENT
The system operates in an environment and relates to
that environment, which itself includes various elements.
Elements relating to the environment include:
Physical
e.g. transport routes;
Procedural
e.g. codes of practice, legal requirements;
Conceptual
e.g. monetary system, political ideologies;
Social
e.g. trade unions, suppliers, customers.

SYSTEM ANALYSIS 6
SUB-SYSTEMS
An enterprise can be divided into a number of
SUBSYSTEMS defining the functional areas. These
include:
Those dealing with the environment: marketing and
purchasing subsystems;
Those dealing with transformation functions: the
production subsystem;
Those acting in a supportive role: accounting,
personnel, and management services subsystems.

SYSTEM ANALYSIS 7
BUSINESS SUBSYSTEMS
These subsystems are all interconnected. The diagram shown is a
‘simple’ model of business subsystems:
Customers
Marketing
Accounting
Management
Control
ProductionPersonnel
Purchasing
Suppliers
GoodsOrders
Purchases
Staffing
required
Payments
OrdersGoods
Deliveries
Deliveries
Schedules
Budgets
and plans
Budgets
Financial
analysis
Budgets
Manpower
analysis
Payments
Invoices
Orders
This diagram
illustrates the
INTERFACES within
the business, and
hence the type of
difficulty that can
arise in defining
boundaries.
Henceforth the
difficulties of the
system analyst to
analyse, design,
help implement
and review.

SYSTEM ANALYSIS 8
OBJECTIVES OF COMPUTERISATION
To reduce costs
Take advantages of the facilities offered by computers
To increase volume of business
Better management of information
Enable long-term forecasts
Enable better planning.

SYSTEM ANALYSIS 9
TYPES OF DATA PROCESSING SYSTEMS
1. Systems where processing is done periodically
(Batch Systems or File Processing Systems)
Large volume of data coming in at regular intervals but where
processing does not have to be done immediately.
e.g. Payroll System, Gas billing system, …
2. Database systems (On-Line Systems)
An on-line system is one in which information is available to all
users at their own terminals, although they may not be able to
update the information.
Independent of any individual application
Store of information to support other data processing systems.
Remark: In many instances, the above types then use a data
communication system to transmit data from one place to
another.

SYSTEM ANALYSIS 10
TYPES OF DATA PROCESSING SYSTEMS (cont…)
3. Real time systems
The computer has to keep pace with some external operation,
processing the received data more or less instantaneously and
producing results immediately.
a. Process control
e.g. oil refining process which is computer controlled
b. Information storage and retrieval
e.g. medical records system
Though shared data files, by nature of application, a single
record is not accessed by more than one user at the same
time
c. Transaction processing
e.g. online reservation system
By nature of application, the same record may be accessed by
different users at the same time; hence need of data locking

SYSTEM ANALYSIS 11
THE SYSTEM LIFE CYCLE (SLC)
The development and maintenance of a new software
system involves a series of stages - the SYSTEM
DEVELOPMENT LIFE CYCLE (SDLC) or simply the
SYSTEM LIFE CYCLE (SLC).
The term ‘life-cycle’ indicates that the process of
development and maintenance never ends.
The development of a system may take from a few weeks
to a few years.
The SLC is a model which tries to maximize the chance of
successful project development.
‘7 out of 10 IT projects “fail” in some respect’
(OASIG study)

SYSTEM ANALYSIS 12
THE WATERFALL MODEL
This SLC model consists of a
number of stages
The stages may be
characterized and divided in
different ways
Project Definition
System study and analysis
Feasibility Study
System Design
Implementation (Coding)
Testing & Integration
Control & Review

SYSTEM ANALYSIS 13
THE WATERFALL MODEL
The waterfall model is a very rigid model – “a sequence of
stages where the output of each stage becomes the input
to the next”.
In a rapidly changing environment and where up-to-date
software systems are required, this model does not work
The model assumes that all system requirements can be
identified in advance - in practice, most often, this is not
the case.
This model assumes that users are only to be involved in
order to specify system requirements

SYSTEM ANALYSIS 14
THE SPIRAL MODEL
This method allows the development team to progressively
complete a project by repeatedly going through the stages
of analysis, design and implementation.
Analysis
Implementation
Design
Analysis
Implementation
Design
Analysis
Implementation
Design

SYSTEM ANALYSIS 15
THE INCREMENTAL-ITERATIVE MODEL
Analysis Design Implementation
Component A Component CComponent B
Analysis
Implementation
Design
Analysis
Implementation
Design
Analysis
Implementation
Design

SYSTEM ANALYSIS 16
THE INCREMENTAL-ITERATIVE MODEL
The project is divided into subprojects and then the waterfall method
is performed on each subproject. Instead of completing functionality
of the entire application with each pass, the incremental-iterative
method completes components.
Each component does not necessarily become a deliverable that is
usable by a client (though at milestones the components are joined
together to create a usable product).
This approach to project development promotes the development of
reusable code. It promotes the separation of functionality required
into different components (e.g. GUI controls, data access …) and it
helps clarify exact functionalities required.

SYSTEM ANALYSIS 17
THROW-AWAY PROTOTYPING
The objective is to understand the customer’s requirements and hence
develop a better requirements definition for the system
Mock-up
A ‘mock-up' of the proposed system is produced for demonstration
purposes. Prototype has appearance of the final system but lacks any
real processing or storage capabilities.
Trial Prototyping
A simplified working model of proposed system serves for
demonstration purposes and also provides an opportunity to try out
ideas and investigate specific points of interest.

SYSTEM ANALYSIS 18
RAPID PROTOTYPING
Also known as Evolutionary Prototyping
The objective is to work with the customer to explore their
requirements and deliver the final system. The development starts
with the parts of the system which are understood . The system
evolves by adding new features as they are proposed by the
customer.
Rapid prototyping is particularly suitable for:
For small scale systems which are required urgently and which
have a limited life.
When it is difficult to establish a detailed system specification. E.g.
AI systems which attempt to emulate human capabilities.

SYSTEM ANALYSIS 19
RAPID PROTOTYPING
Evolutionary development:
Specification
development
validation
Initial version
Intermediate
versions
Final version
Outline project
description
Concurrent activities

SYSTEM ANALYSIS 20
COMPARISON OF PROTOTYPING STRATEGIES
Remarks re prototyping:
Throw-away methods aid work done in analysis and
design by being incorporated into the development life-
cycle
Evolutionary methods provide short term gains – rapid
results but, on long term can become costly, difficult to
maintain and tend to be less reliable

SYSTEM ANALYSIS 21
PROJECT DEFINITION
This initial stage of project development is an attempt
to formulate project requirements in broad terms by
identifying exact reasons for project selection.
A steering committee is set up to monitor project
progress
Top management and all users are involved to gain
their support and participation.
Output: An assignment brief i.e. clear definition of
problem and objectives

SYSTEM ANALYSIS 22
FEASIBILITY STUDY
Preliminary survey to determine whether a project should
proceed.
The feasibility study should be conducted quickly and in
broad terms but must be sufficiently detailed for
management to draw proper conclusions.
Feasibility study must include consideration of:
TECHNICAL aspects
ECONOMICAL aspects (incl. COST-BENEFIT ANALYSIS)
OPERATIONAL (incl. LEGAL) aspects
SOCIAL aspects
Hence the main aim at this stage is to rule out bad ideas
Example: Proposed project technically possible but too
expensive to implement.

SYSTEM ANALYSIS 23
FEASIBILITY REPORT
The resultant feasibility report should include:
Recommendations
Options considered
Economic justification for the choice (cost-benefit analysis)
Resource implications on staff, premises, etc…
Development plans and time-table for introduction
If, on the basis of the feasibility report, the project is
acceptable to the steering committee, a written go-ahead
is given to proceed to next stage.

SYSTEM ANALYSIS 24
SYSTEM STUDY AND ANALYSIS – PART I
This stage covers a review of the existing system leading to a design
specification for a new system. (Can help develop ideas for new system)
It is a detailed study of current practices, files, documents, working
methods, etc.
Tasks falling within this stage:
1. Define and identify the objectives of the current system
2. Establish sources and types of information
3. Decide on method and collection of data
a. Interviews,
b. Questionnaires,
c. Observation,
d. Documentation study
4. Record, store and retrieve information - collection of current system
data.

SYSTEM ANALYSIS 25
SYSTEM STUDY AND ANALYSIS – PART II
5. Process, adapt and present information - Documenting the existing
system (if any,) involves the use of charts and other techniques to help
understanding and presentation
6. Analyze information (Who What Why When Where How)
a. Are current system objectives valid? And are they being met?
b. Identification of key activities and interrelationships within the
current system
c. Identification of strengths and weaknesses of the current
system
d. Opportunities and constraints of the current system
e. Establishing the resource use of the current system

SYSTEM ANALYSIS 26
SYSTEM STUDY AND ANALYSIS – PART III
7. Statement of requirements: This is the output report from the
current stage of the system life cycle. Ideally, it should be prepared
jointly by the users and analysts for management approval. The SOR
should include:
a. criticisms of the existing system
b. the findings of the analysis stage and how the system can be
improved
c. the objectives of the proposed system
d. a design specification including main interfaces with other
systems
e. constraints and sample outputs
f. user responsibilities
g. an update of costs and development plan, and time-tables for
introduction

SYSTEM ANALYSIS 27
SYSTEM DESIGN
This stage is essentially a process of moving from a
general outline to a detailed final product. System design
leads to a SYSTEM SPECIFICATION that should:
Provide a basis of agreement and a source of reference between
management, users and analysts.
Serve as a specification of software programs, dialogues and
manual procedures within the system.
The system specification should be presented to the steering
committee for approval.
Structure of system specification:

SYSTEM ANALYSIS 28
CODING STAGE
Most time-consuming stage of system development life-
cycle.
Program development stage involves programming
techniques.
Modules coded are tested, during coding, according to the
test plan designed earlier (during the design stage)
This stage is complete when all code is written,
documented and successfully compiled.

SYSTEM ANALYSIS 29
CODING
Most time-consuming stage
Requires a lot of effort (hence expensive)
Choice of programming language is important
Aids to save time and money
Use of higher level languages, visual languages …
Facilitative IDEs (Integrated Development Environments)
Code reuse - existing library subroutines or classes, existing
modules, …
other RAD (Rapid Application Development) tools such as
o screen painting software,
o report generators,
o application generators …

SYSTEM ANALYSIS 30
SELECTION OF PROGRAMMING LANGUAGE
When a program needs to be written for a particular
application, selection of the language may be based on:
Which languages have special features most appropriate
to the application area
Whether the choice of a particular language would
substantially reduce development time
Whether the programmers have the time and/or expertise
to master a new language
Whether a suitable compiler exists for the hardware the
system being developed is intended to use

SYSTEM ANALYSIS 31
PROGRAM ERRORS
Program Errors : A program may have any or all of four types of
errors:
Syntax Errors: A statement in the program violates a rule of the language,
Semantic Errors: Violating rules of language, semantic errors are concerned
with the meaning of language statements (semantics).
Logical Errors: The program runs to completion but gives wrong results or
performs wrongly in some way.
Runtime Errors: Program crashes during execution.
The translator detects syntax and semantic errors but the translator
does NOT detect Logical and Run-time errors. These require rigorous
testing for detection and correction possibly with the aid of a
debugger.

SYSTEM ANALYSIS 32
PROGRAM TESTING
There are two ways of approaching testing :
Functional Testing (Black box testing)
Based on typical, extreme and invalid data values that
are representative of those covered by the specification.
Logical Testing (White box testing)
Based on examining the internal structure of the
program and selecting data which gives rise to the
alternative cases of control flow.
Remarks:
Functional testing is not adequate by itself.
Logical testing by the programmer during program development is
most effective.

SYSTEM ANALYSIS 33
TEST DATA AND TEST CASES
Test data must include:
Valid values,
Invalid values
limit values
Select test cases such that:
Every statement in the program is executed at least once.
The effectiveness of all sections of code that detects invalid
input is tested.
The accuracy of all processing is verified.
The program operates according to its original design
specifications.

SYSTEM ANALYSIS 34
THE TESTING PROCESS
Except for small programs, systems should not be tested as
a single unit. Large systems are built out of sub-systems,
which are built out of modules, which are composed of
object classes (or procedures and functions – depending on
the design (and language) paradigm adopted. The testing
process should therefore proceed in stages where testing is
carried out incrementally in conjunction with system
implementation.
In general, the sequence of activities is:
COMPONENT TESTING INTEGRATION TESTING USER TESTING

SYSTEM ANALYSIS 35
TESTING STAGES
As defects are discovered at any one stage, they require program
modifications to correct them and this may require other stages, in
the testing process to be repeated. (regression testing)
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
Testing
Integration
Testing
User
Testing

SYSTEM ANALYSIS 36
UNIT AND MODULE TESTING
Unit testing Individual components are tested to ensure
that they operate correctly. Each component is tested
independently, without other system components.
Module testing A module is a collection of dependent
components such as an object class, an abstract data type
or some looser collection of procedures and functions. A
module encapsulates related components and so can be
tested without other system modules.

SYSTEM ANALYSIS 37
SYSTEM TESTING
Sub-system testing : This phase involves testing collections of
modules which have been integrated into sub-systems. Sub-systems
may be independently designed and implemented. The most common
problems which arise in large software systems are sub-system
interface mismatches. The sub-system test process should therefore
concentrate on the detection of interface errors by rigorously
exercising these interfaces.
System testing: The sub-systems are integrated to make up the
entire system. The testing process is concerned with finding errors
which result from un-anticipated interactions between sub-systems
and system components. It is also concerned with validating that the
system meets its requirements.

SYSTEM ANALYSIS 38
ACCEPTANCE TESTING
Acceptance testing the final stage in the testing process before the system is
accepted for operational use. The system is tested with data supplied by the
system client rather than simulated test data.
Acceptance testing may reveal errors and omissions in the system requirements
definition because the real data may ‘exercise’ the system in different ways from
the test data. Acceptance testing may also reveal that the system facilities
provided do not meet the exact users’ needs or the system performance is
unacceptable.
Acceptance testing is sometimes called alpha testing. Bespoke systems are
developed for a single client. The alpha testing process continues until the
system developer and the client agrees that the delivered system is an
acceptable implementation of the system requirements.
When a system is to be marketed as a software product, a testing process called
beta testing is often used. Beta testing involves delivering a system to a
number of potential customers who agree to use that system. They report
problems to the system developers. This exposes the product to real use and
detects errors that may not have been anticipated by the developers. After this
feedback, the system is modified and either released for further beta testing or
for general sale.

SYSTEM ANALYSIS 39
TEST PLANNING
Careful test planning is needed to get the most out of testing and to control testing costs.
Test planning is concerned with setting out standards for the testing process.
The major components of a test plan are as follows:
The testing process.
A description of the major phases of the testing process. (maybe as described earlier)
Requirements traceability.
Users are most interested in the system meeting its requirements and testing should be planned
so that all requirements are individually tested.
Test Items.
The products of the software process which are to be tested should be specified.
Testing Schedule.
An overall testing schedule and resource allocation for this schedule. This, obviously, is linked to
the more general project development schedule.
Test recording procedures.
It is not enough simply to run tests. The results of the tests must be systematically recorded. It
must be possible to audit the testing process to check that it has been carried out correctly.
Hardware and software requirements.
This section should set out software tools required and estimated hardware utilisation.
Constraints.
Constraints affecting the testing process such as staff shortages should be anticipated in this
section.

SYSTEM ANALYSIS 40
TESTING STRATEGIES
A testing strategy outlines the general approach to the testing
process. Different testing strategies may be adopted depending on
the type of system to be tested and the development process used.
Some types of testing strategies:
1. Top-down testing where testing starts with the most abstract components
and works downwards.
2. Bottom-up testing where testing starts with the fundamental components
and works upwards
3. Thread testing which is used for systems (usually real-time) with multiple
processes where the processing of a transaction threads its way through
these processes
4. Stress testing which relies on stressing the system by going beyond its
specified limits and hence testing how well the system can cope with
over-load situations.
5. Back-to-back testing which is used when versions of a system are
available. The systems are tested together and their outputs compared.

SYSTEM ANALYSIS 41
IMPLEMENTATION : CROSS-OVER TECHNIQUES
A complete replacement at one go usually taking place
during a slack period.
It is cheap, simple, clear-cut method but risky because
there is no fallback position.
Used when
Users have previous experience of computerisation
The new system is not directly comparable with the old
The time scale is tight
Resources are limited e.g. no extra staff
The system is small
Old System
New System
Straight (Direct) Changeover

SYSTEM ANALYSIS 42
IMPLEMENTATION STAGE
Project Management
The planning and scheduling of resources, staff, equipment, …
Staff training and education
Without interrupting flow of work, good courses and manuals
File conversion
Reformatting files for the new system
Documentation check
Ensuring comprehensive and up-to-date systems
Deciding on method of changeover
Switching over from the old system to the new system
Handover

SYSTEM ANALYSIS 43
Parallel Changeover
Includes a period when the old and the new system run in
parallel until everyone is satisfied that the new system is
running successfully and then the old system is dropped.
Expensive changeover – involves more work
Difficult to make comparisons between the results
obtained by both systems
Less risky – standby facilities, useful cross check, gradual
changeover.
Old System
New System

SYSTEM ANALYSIS 44
Phased (Incremental) Changeover
The changeover is in a number of stages rather than all at once.
The division may be based on:
Location – say, one branch of a retail group each month
Subsystem –say, sales order processing system, then payroll system, then
accounting system, …
Subfile – say, in a customer account file, names beginning A – F, then G-L, …
Spreads the burden of the workload over time
Presents an opportunity to learn from problems of a previous phase
Takes longer than other changeover methods
Difficult to control a system working in two modes
New SystemOld System

SYSTEM ANALYSIS 45
Sometimes a part of the system which can be treated as
an entity is upgraded. E.g. the stock control system of a
single shop which forms part of a whole retail chain.
The changeover of the entity is done using direct or
parallel changeover.
When the pilot implementation is satisfactory, the project
to upgrade the whole system is undertaken.
Old
New
Old
New
Pilot

SYSTEM ANALYSIS 46
CONTROL AND REVIEW STAGE
Control
Setting and redefining standards against which performance can
be compared.
Measuring planned against actual performance
Taking corrective action where necessary so that system meets its
objectives
Review
At predefined intervals of time, system should be reviewed to give
overall picture of progress made
Findings help any subsequent system analysis

SYSTEM ANALYSIS 47
SYSTEM MAINTENANCE
System maintenance implies another system life cycle.
MAINTENANCE may be:
Adaptive maintenance due to identified new requirements
Corrective maintenance due to identified errors
Perfective maintenance due to identified improvements to the existing
set up.
Aids to maintenance:
Modular design
Use of structured system
development techniques
Readable Code
Good Documentation
17%
18%
65%
Corrective Adaptive Perfective

SYSTEM ANALYSIS 48
DOCUMENTATION
Documentation may be presented in different forms:
Manuals
Online help
Documentation types:
User Manual
Operations Manual
Technical Manual
(program listing includes inline documentation)

SYSTEM ANALYSIS 49
USER MANUAL
Typical information:
Overview of options available
Guidance on the sequence of operations to follow
Screen shots showing screen input forms
Instructions on how to enter data
Sample report layouts
Error messages that may be displayed and what
action to take

SYSTEM ANALYSIS 50
OPERATIONS MANUAL
The operations manual includes all the procedures
necessary to run the system.
Typical information:
System setup procedures, including details for each
application of the files required and consumables
requirements
Security procedures
Recovery procedures in the event of system failure
A list of system messages that might appear on the
operator’s console and what action to take

SYSTEM ANALYSIS 51
TECHNICAL MANUAL
Typical information included in the technical manual:
Overall system plan
Data organisation and flow
Full annotated listing
Details of test data and results

SYSTEM ANALYSIS 52
DECISION TABLES
A DECISION TABLE is a tabular
representation of expressing
process (decision) logic.
Decision tables are used to
analyze problems.
Conditions applying to the
particular problem are identified;
and the actions to be taken as a
result of any combination of the
conditions arising are set out.
ACTION
ENTRIES
ACTIONS
CONDITION
ENTRIES
(Outcome)
CONDITIONS
(Questions)

SYSTEM ANALYSIS 53
DECISION TABLES - EXAMPLE
Example:
Discounts allowed on customers’
order are required to comply with
the following policy:
“Any order from a credit-worthy
customer attracts a discount of 5%
if the order amounts to €500 or
more, and a discount of 3% if the
order amounts to less than €500.
Other circumstances must be
referred to the supervisor for a
decision.
XXRefer to
supervisor
XAllow discount of
5%
XAllow discount of
3%
Actions
NYNYIs credit-worthy
customer?
NNYYIs order €500 or
more?
4321Conditions
Rules

SYSTEM ANALYSIS 54
DECISION TABLES - EXERCISE
Use a decision table to represent the following system logic:
A credit union pays interest to its depositors at the rate of
6% per year. A number of constraints to this policy are:
Accounts of less than €100 are not paid interest.
Accounts of less than €1,000 are paid the normal 6%,
Accounts of €1,000 or more that have been with the
union for more than one year get paid the normal 6%,
plus a bonus of 1%.

SYSTEM ANALYSIS 55
MODULARITY
A module is a self-contained subprogram, which performs
independently one specific task.
Advantages in using modules
Re-usability
Easier to read, debug and maintain (update)
Natural division of work
Remarks
Modules can be compiled separately
Driver program is required to further test modules
PROCESSINGInput
ONE entry point
Output
ONE exit point

SYSTEM ANALYSIS 56
TOP-DOWN MODULAR APPROACH
Problem is broken down into a number of components
modules. Each component is progressively decomposed
into smaller, more manageable components until each
component (or module) can be easily comprehended.
Problem
Module A
Module A [1] … Module A [n]
Module B
Module B [1] … Module B [n]
Module A1 [1] … Module B1 [1] …

SYSTEM ANALYSIS 57
BOTTOM-UP MODULAR APPROACH
Individual manageable modules are initially identified; progressively
these are combined to form larger modules until the original problem
is fully addressed.
Method recommendable only in the case of experienced programmers
and the existence of a library of previously developed modules
Module A[1] Module A[2] Module B[1] Module B[2]
Module A Module B
Original Problem

SYSTEM ANALYSIS 58
STRUCTURE CHARTS
Structure charts are used to represent the high level modular design
of a programming project.
Consider the following structure chart for solving a teacher’s
examination results processing problem:
Process Examination Results
Input Details Process Details Output Details
Input
Results
Validate
input
Determine
Grade
Category
Determine
Grade
Counts
Print
Individual
Results
Print
Statistical
Summary
Print
Error
Listing
Exercise: Draw a structure chart to representing the issuing of reminder
letters for borrowers in a book library system

SYSTEM ANALYSIS 59
DATA FLOW DIAGRAMS
Data Flow Diagrams (DFDs) provide a pictorial
representation for recording:
o Where the data originates
o What processing is performed on it (data) and by
whom
o Who uses the data
o What data is stored and where
o What output is produced and who receives it.

SYSTEM ANALYSIS 60
DFD SYMBOLS
Source/destination
Process
Data store
Data flow
An operation performed on the data.
A process will use or alter the data in some way
E.g. sorting, using data to print a report.
A data source or destination which is extended to
the system. E.g. people/departments who
provide data or receive output
Data store denotes object where the data is
stored. E.g. data file, transaction file, input
document, report
The arrow represents the movement of data
between entities, processes or data stores.
Arrows should be clearly labelled to show what
data is being transferred.
Do not draw data flow directly between data
stores and external entities - there should be a
process box between them to show the
operation performed

SYSTEM ANALYSIS 61
LEVELLED DFDs
Since it is often impossible to represent a complete
system in a single diagram, two or three levels of data
flows may be used each showing progressively more
detail.
Consider the following example:
The payroll system of ABC LTD:-
At the end of each week, time sheets are collected and
sent to the salaries department. Here, the payroll data is
entered via a key-to-disk system, verified and validated,
producing a new valid transaction file on disc and an
error report. This file is used to update the employees
master file , issue payslips and electronically transfer
payment to employees’ bank accounts.

SYSTEM ANALYSIS 62
PAYROLL SYSTEM:- TOP-LEVEL DFD
Process
Payroll
Time sheets
Payroll
summary data
Cheque and
payslip data
Employees
Employees
Accounts
Department
Top level showing a single process:

SYSTEM ANALYSIS 63
PAYROLL SYSTEM :- SECOND LEVEL DFD
Employee number, hours
worked, batch control total
Employee number, total
pay, deductions… for all
employees
Rate of pay, tax
code…
Batch
time
sheets
Time sheets Time sheet data and
batch control totals
Verify
and
validate
Valid weekly
transaction file
Invalid data batch
and control totals
Prepare
payroll
Employee
number, name,
total pay,
deductions…
Cheques and
payslips
Employee number, hours worked
Print
Payroll
Summary
Print and
distribute
cheques
and
payslips
Employee number, total
pay, deductions… for all
employees
Employee
Accounts
Department
Employee
Error
Report
Employee
file Year-to-date pay…
validated data

SYSTEM ANALYSIS 64
STOCK CONTROL SYSTEM QUERY:- TOP-LEVEL DFD
In relation to this query, the user provides the stock
number and the system outputs the item’s description and
quantity of item in stock.
Top-level DFD to this query:
Stock Report
Request
Stock Number
Stock description
and
quantity in stock
Stock fileEnd User
Query
request
input
Unformatted
query request
output

SYSTEM ANALYSIS 65
STOCK CONTROL SYSTEM QUERY:-
SECOND LEVEL DFD
Validation
process Stock file
Description
of stock
report
Stored output
formats
Stock number
Stock file
processing
Select
report
output
format
Stock Description
Valid Stock
Data
User

SYSTEM ANALYSIS 66
DFD EXERCISE
A student can register by mail for a college course by
submitting a registration form with their name, ID number
and the number of courses they wish to take. The system
verifies that the course is not full and enrolls the student
on each course for which a place is still free. The course
file and student master files are updated and a
confirmation letter is sent to the student to notify them of
their acceptance or rejection for each requested course.
Draw a DFD diagram illustrating how data flows through
this student registration system.
SecondlevelDFDSolution:Heathcote&Langfield,“‘A’levelComputing”,5thed.p.319

SYSTEM ANALYSIS 67
FLOW CHARTS
A FLOWCHART is a graphical representation of the
sequence of operations in a system or program.
A SYSTEM FLOWCHART is used to show how data flows
from source documents through the computer (system)
to final output distribution – it gives a complete overview
of a system. E.g. Sequential file processing diagram
A PROGRAM FLOWCHART shows the sequence of
instructions to achieve a particular task (algorithm).

SYSTEM ANALYSIS 68
FLOW CHARTS SYMBOLS
Printed output Communications
links
Data
preparation
Manual
operation
Tape/sequential
access medium
Sort processManual
Input
Off-page
connector
Disk
Direct Access
storage
Start/end Process Input/Output DecisionPre-defined
Process
Connector Flow

SYSTEM ANALYSIS 69
SYSTEM FLOWCHARTS
Update
Process
MF
Old
MF
New
MF
SEQUENTIAL FILE
UPDATE PROCESS
Data validation
Display
input data
Data Entry
Collection of
Documents
Error
Report
Transaction
FileKEY-TO-DISK
INPUT SYSTEM
Example 1:
Example 2:

SYSTEM ANALYSIS 70
PROGRAM FLOWCHART
Y
Start
Read input
Name,index,
Mark
Is
Mark = -1?
Print
Index number
Is
Mark<40?
Is
Mark<70?
Print “FAIL” Print “PASS” Print “CREDIT”
Total Count
T = F+P+C
Print F/T*100%
P/T*100%
C/T*100%
Increment
Credit count
C=C+1
Increment
Pass count
P=P+1
Increment
Fail count
F=F+1
End
N
Y
N
N
Y
EXAMINATION RESULTS
PROCESS

SYSTEM ANALYSIS 71
PROGRAM FLOWCHART (Another Example)
Start
Input N
F = 1
M = 1
End
F = F * M
M = N ?
M = M + 1
Print F
COMPUTING
FACTORIAL N (N!)
N! = 1*2*3* … *N
Exercise
Draw the flowchart for
the algorithm which
generates the first N
terms of the fibonacci
sequence where N is
specified by the user.
Fibonacci Sequence 0 1 1
2 3 5 8 …

SYSTEM ANALYSIS 72
PSEUDOCODE
PSEUDOCODE represents a way how we can express the
sequence of instructions to achieve a particular task
(algorithm) independently of any programming language.
Pseudocode consists of English-like statements very close
to the target programming language to be used for
developing the software.
Examples:
SWAP TWO INTEGER VARIABLES
Assume swap integer variables X, Y
Declare integer Temp
Temp = X
X = Y
Y = Temp
CHECK WHETHER AN INTEGER
VARIABLE IS EVEN OR ODD
Assume Integer variable X
if (X modulo 2 == 0)
output message “even”
else output message “odd”
EXERCISE: Use pseudocode for expressing the
algorithm which generates factorial n (n!)

SYSTEM ANALYSIS 73
ENTITY-EVENT MODELLING
An ENTITY-EVENT MODEL is an abstract representation of
how the entities of a system are effected by business
events - business events trigger processes which in turn
affect entities.
An Entity-Event Model identifies business events and
defines the effects which these events have on the
system’s entities. It also defines the order in which these
events take place.
Entity-event modeling (similar to Jackson System
Development techniques), is a technique used in relation
to the SSADM standard.

SYSTEM ANALYSIS 74
ENTITY-EVENT MODEL
An entity-event model consists of
A set of entity life histories (ELH),
A set of effect correspondence diagrams (ECD)
An Entity Life History shows the sequence of effects
which business events cause on a particular entity type.
An Effect Correspondence Diagram shows the effects
of business events from the event’s point of view – shows
which entities are effected by a particular event.

SYSTEM ANALYSIS 75
ENTITY LIFE HISTORIES
A is a structural component
which shows that effect B is
followed by effect C
A
B C
SEQUENCE
A
B° C°
A is a structural component which
shows that either effect B takes
place or effect C but not both
SELECTION
A
B*
A is a structural component which
shows that effect B takes place 0
or more times
ITERATION
PARALLELISM
A
B
D*
C
E*
A is a structural component
which shows that either, both
(in any order and any number
of times), or neither of effects
D and E may occur
Entity life histories are drawn using the structured design (or
programming) constructs of sequence, selection, iteration and parallelism

SYSTEM ANALYSIS 76
ELH EXAMPLE
BOOK
New Book Acquisition Book DiscardedLibrary Book Life
Book details changes
Book State°
Book available changes
Book details change* Book available change*
Book Borrowed° Book Returned°
The top node represents the entity, the next level nodes denote the organization of
events, the next level nodes denote the individual events which change the entity,
and the lowest level nodes denote the tasks which achieve the higher level nodes.

SYSTEM ANALYSIS 77
EFFECT CORRESPONDENCE DIAGRAMS
Effect Correspondence Diagram are drawn in relation to
ELH. All entities effected by an event are listed.
Book
borrowed
Loan
Book
The event ‘book borrowed’
effects the LOAN and
BOOK entities
Place order
Order
Orderline
Set of orderline
occurrences*
The event ‘place order’ effects
several occurrences of the
ORDER entity
Booking
Booking
Provisional°
The event ‘booking’ can
effect the booking entity in
different ways
Confirmed°

SYSTEM ANALYSIS 78
ELH – Another Example
Draw the EHL diagram for the entity Borrower in the
context of a book library system
BORROWER
New Membership End MembershipLibrary Member Life
Borrower detail changes
Borrower’s address°
Borrower detail change*
Borrower’s Tel.No.°

SYSTEM ANALYSIS 79
USE CASE DIAGRAMS
The USE CASE diagram is used to give a high level view of the
system, depicting who will use the system and what they will be able
to do with it.
There are four basic components to USE CASE diagrams:
actor
Use case
relationship
update
inventory
administrator
system
Prepare report
administrator manager
update
inventory
View report

SYSTEM ANALYSIS 80
USE CASE DIAGRAMS : GENERALISATION
GENERALIZATION is a technique used to indicate
inheritance of an item. Generalization can be applied to
both actors and use cases to indicate inheritance of
functionality from parents.
The generalized actor plays a
more specific role in the
system
phone order sale
generalized actor generic actor walk-in sale
sales persontelephone
operator
sale
phone order

SYSTEM ANALYSIS 81
USE CASE DIAGRAMS : RELATIONSHIPS
INCLUDE and EXTEND are two ways of relating use cases
which are highly related to each other.
These relationships help you to identify where you can
reuse functionality during system design.
update
inventory
load
inventory
save
inventory
<<include>>
<<include>>
verify
credit card
sale
<<extend>>
The EXTEND relationship is used to
identify when a use case can
optionally be extended by
functionality in another use case

SYSTEM ANALYSIS 82
CREATING USE CASE DIAGRAMS
Steps to follow in creating USE CASE diagrams:
identify the actors and use cases in the system
Prioritize the use cases
Detail each use case
Structure the case model
Prototype user interfaces
Example:
A system is required to:
Allow teachers to record and update students’ results; and notify
guardians if individual students’ results are not satisfactory
Allow teachers, students and the administrator to view results
recorded
Enable the administrator to generate students’ reports

SYSTEM ANALYSIS 83
“STUDENTS’ RESULTS” USE CASE DIAGRAM
Recording students’ results:
update grades
teacher
student
record grades
view grades
save grades notify guardian
<<include>>
<<include>>
<<extend>>
load grades
<<include>>
administrator
generate
reports
<<include>>

SYSTEM ANALYSIS 84
EXERCISE
Create a use case diagram for the following business
requirements of a point-of-sale (POS) system:
The system will allow the administrator to run inventory reports by
loading inventory data from disk
The administrator can update the inventory by loading and saving
the inventory data to and from a disk
A sales clerk records walk-in sales
A telephone operator is a special type of sales clerk who handles
phone orders
Any kind of sale must update the inventory
A sale may need to verify a credit card if the purchase is a credit
card purchase
A sale may need to verify a check if the purchase is a check
purchase.

SYSTEM ANALYSIS 85
SOLUTION
Update
inventory
administrator
telephone operator
run inventory
reports
phone-in
sale
save inventory
verify
credit card
<<include>>
<<include>>
<<extend>>
load inventory
<<include>>
sales clerk
sale
<<include>>
walk-in
sale
verify check
<<extend>>

SYSTEM ANALYSIS 86
CLASS DIAGRAMS
A CLASS DIAGRAM consists of classes and their relationships to each
other.
The main components of a class are attributes and operations.
Formal notation of a class:
ClassName
- attribute 1
- attribute 2
- attribute 3
+ operation 1 ()
+ operation 2 ()
+ operation 3 ()
Visibility:
plus (+) signifies that the member is visible.
minus (-) signifies that the member is private.
hash (#) signifies that the member is visible only
to classes of the same system – protected.
Remarks:
•Depending on the detail you want to communicate,
only the first compartment is a must.
•Note the difference between a hidden compartment
and an empty compartment

SYSTEM ANALYSIS 87
RELATIONSHIPS
Two classes can relate to each other with a line and an
association name:
Teacher Class
teaches >
Multiplicity allows us to indicate how many objects of one
class relate to one object of another class.
Teacher Class
teaches >
1 1..*
Exercise: Extend the above class diagram to include
another class named “Student” where a given student
may take from four to six classes at any one time and a
class includes fifteen or thirty students.

SYSTEM ANALYSIS 88
INHERITANCE
Inheritance is a way of allowing one class to gain the
functionality of another class
Animal
Feline Bird
Vehicle Weapon
Tank
Say, classes LION and TIGER, in
turn, inherit the functionality of
the class FELINE - inheritance
hierarchies
Classes can be derived from
more than one superclass –
multiple inheritance

SYSTEM ANALYSIS 89
POLYMORPHISM
Polymorphism is the ability of two or more abstract
classes to have the same interface but operate on their
data differently because each has its own section of code.
Animal
NumberOfEyes
NumberOfLegs
+Eat()
+Sleep()
Feline
+Run()
+Sleep()
Bird
+Fly()
+Sleep()
Say, we use polymorphism to
model the fact that each animal
sleeps differently – felines sleep
lying down while birds sleep
standing up

SYSTEM ANALYSIS 90
EXERCISE
Create a Class Diagram using the following information:
A student can be an undergraduate or a graduate student
An undergraduate student can be a type of tutor
A tutor tutors a student
A teacher and a professor are two types of instructors
A teacher assistant can assist a teacher and a professor,
but a teacher can be assisted by only one assistant, while
a professor can be assisted by up to five assistants
A teacher assistant is a type of graduate student

SYSTEM ANALYSIS 91
SOLUTION
Tutor Instructor
Teacher
Student
Undergraduate Graduate
tutors>
Professor
Teacher Assistant
<assists assists>
0..1
1
0..5
1

SYSTEM ANALYSIS 92
SOME SDLC STANDARDS: UML & SSADM
Both UML and SSADM are standards within the SDLC
study field.
Each has its own strengths and weaknesses
A comprehensive overview SSADM
A comprehensive UML tutorial (overview)
A comparison of SSADM and UML

System design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to System design

Similar to System design (20)

More from John Cutajar

More from John Cutajar (13)

System design