System Analysis and Design

• The Systems Development Lifecycle

(SDLC) methodology allows a project
team to successfully build an application
uniquely suited to the organization’s needs
• SDLC allows organizations to incorporate
new requirements, technology and human
resources to IT development
 System Development Life Cycle
• Systems Planning
– Yields Preliminary Investigation Report
• Systems Analysis
– Yields Systems Requirements Document
• Systems Design
– Yields System Design Specification
• Systems Implementation
– Yields Functional Information System
• Systems Operation and Support
– Yields Operating Information System
 Structured Analysis
• E-R diagrams could encode many business rules.
• But many elements of business processes cannot be
represented by E-R diagrams:
– Actors (individuals, organizations) which generate
input data and/or receive output data;
– Data transformations using specific business rules
– Data storage or display that may or may not
correspond to entities
– Data flows between actors, processes or data stores
over time
• Many business processes are so complex that E-R
design alone will not give analysts insight into their
businesses
 Tools - SDLC design
• Physical Design Tools - describe how a
system will be physically implemented
They include:
– Data Flow Diagrams
– Storyboards
– Flow Charts
– Structure Charts
– IPO charts
– Layout diagrams / mockups
– Pseudocode
Example
 DATA FLOW DIAGRAM
• Data Flow Diagrams (DFDs) are the link between
initial business analysis, E-R diagrams and
relational database models
• DFDs allow the analyst to determine:
• What does the organization do?
• How does the organization do it?
• Data flow diagrams (DFDs) are categorized as
either logical (reflects the business) or physical
(depicts the system).
• A logical DFD focuses on the business and how
the business operates. It describes the business
events that take place and the data required and
produced by each event.
• On the other hand, a physical DFD shows how
the system will be implemented.
Contrast features of logical and physical models
 Creating DFDs
• Define Entities
– External entities represent persons,
processes or machines which produce data to
be used by the system or receive data that is
output by the system
– Examples: Student, Customer, Client Student
• Define Processes
– Processes are discrete actions that transform
input data to output data
– Examples: Create Student Record, Calculate
Purchase Cost, Register Client 2.1
Create
Student
Record
 Creating DFDs
Define Data Stores
• Data stores are temporary or permanent repositories
of information that are inputs to or outputs of
processes
• Examples: Student Master, Client List
Student
D3
Master
Define Data Flows
• Data flows represent the transfer of data over time
from one “place” (entity, process, data store) to
another
• Examples: New Student Information
New Student
Information
 Creating DFDs
Define the System
• A system is the collection of all business
processes which perform tasks or produce
outputs. It is “what happens.”
• The system is a single process, connected to
external entities
• Represented in a “Context Diagram”
Define Subsystems
• A subsystem gives a more detailed view
individual processes contained in the context
diagram
• Includes data stores, more elementary
processes
Example
 Where to Begin Creating DFDs
• Start with the data flow from an external entity
and work forwards
• Start with the data flow to an external entity and
work backwards
• Examine the data flows into or out of a data
store
• Examine data flows, entity connections and data
stores associated with a particular process
Example
 Constructing a DFD
1. Process should be named and numbered
for easy reference. Each name should be
representative of the process.
2. The direction of flow is from top to
bottom and from left to right.
3. When a process is exploded into lower-
level details, they are numbered.
4. The names of data stores, sources and
destinations are written in capital letters.
Example
Example
Symbol
Example
 DFD Example: Bus Garage Repairs
• Buses come to a garage for repairs.
• A mechanic and helper perform the repair, record
the reason for the repair and record the total cost of
all parts used on a Shop Repair Order.
• Information on labor, parts and repair outcome is
used for billing by the Accounting Department, parts
monitoring by the inventory management computer
system and a performance review by the supervisor.
• Key process (“the system”): performing repairs and
storing information related to repairs
• External Entities: Bus, Mechanic, Helper,
Supervisor, Inventory Management System,
Accounting Department, etc.
 Bus Garage Repairs
• Processes:
– Record Bus ID and reason for repair
– Determine parts needed
– Perform repair
– Calculate parts extended and total cost
– Record labor hours, cost
• Data stores:
– Personnel file
– Repairs file
– Bus master list
– Parts list
• Data flows:
– Repair order
– Bus record
– Parts record
– Employee timecard
– Invoices
 Bus Garage Repairs

Bus

Mechanical Fixed
problem mechanical
to be repaired problems

0 Repair Supervisor
Helper Labor
Bus summary
Repair
Process List of
parts used Inventory
Labor Management
Labor, System
parts cost
Mechanic details

Accounting
 DFD Conventions
• Do not allow a single page of a DFD to get too complex.
• Each component and subcomponent should be
numbered. e.g. 1 2 3 4 5.
– The subcomponent DFD of component 3 would have components 3.1,
3.2, 3.3, and 3.4;
• and the sub subcomponent DFD of component 3.2 would have
components 3.2.1, 3.2.2, and 3.2.3. This enables a developer to plan
in a top-down manner.
• All processes must have at least one data flow in and one
data flow out.
• All processes should modify the incoming data, producing
new forms of outgoing data.
• Each data store must be involved with at least one data
flow.
• Each external entity must be involved with at least one
data flow.
• A data flow must be attached to at least one process
• Data flows cannot go directly from one external entity to
another external entity.
 DFD Helps
• With a DFD,
• developers can map
– how a system will operate,
– what the system will accomplish and
– how the system will be implemented.
• It's important to have a clear idea of
– where and how data is processed in a system to avoid double-
handling and bottlenecks.
• A DFD also helps management
– organize and prioritize data handling procedures and
– staffing requirements.
• A DFD lets a system analyst study
– how existing systems work,
– locate possible areas prone to failure,
– track faulty procedures and
– reorganize components to achieve better efficiency or
effectiveness.
 DFD disadvantage
• The DFD for large programs can be hard
to translate and take a lot of time.
• Needs large number of iterations to arrive
at the most accurate and complete
solution.
 DATA STORES
• Data Stores are some location where data is
held temporarily or permanently.
In physical DFDs there can be 4 types.
D = computerised Data
M = Manual, e.g. filing cabinet.
T = Transient data file, e.g. temporary program
file
T(M) = Transient Manual, e.g. in-tray, mail box.
As with external entities, it is common practice to
have duplicates of data stores to make a
diagram less cluttered.
DATA STORES
 DATA DICTIONARY
• It defines the data used in a system.
• It is a complete and authoritative definition
of all the data in the system.
• A data dictionary may cover a whole
organization, a part of the organization or
a database.
• More advanced data dictionary contains
database schema with reference keys, still
more advanced data dictionary contains
entity-relationship model of the data
elements or objects.
 DATA DICTIONARY
• A data dictionary may contain:
– Data element number: Data element number is used
in the technical documents.
– Data element name (caption): Unique data element
name. This is the real life name of this data element.
– Short description: Description of the element in the
application domain.
– Security classification of the data element:
Organization-specific security classification level or
possible restrictions on use.
– Related data elements: List of closely related data
element names when the relation is important.
 DATA DICTIONARY
• Cont.
– Field name(s): Field names are the names used for this
element in computer programs and database schemas.
These are the technical names, often limited by the
programming languages and systems.
– Code format: Data type (characters, numeric, etc.), size
and, if needed, special representation. Common
programming language notation, input masks, etc. can
be used.
– Null value allowed: Null or non-existing data value may
or may not be allowed for an element.
– Default value: Data element may have a default value.
Default value may be a variable, like current date and
time of the day
– Element coding (allowed values) and validation details
or reference to other documents: Explanation of coding
(code tables, etc.) and validation rules when validating
this element alone in the application domain.
Data dictionary
 FLOW CHART
• A diagram that uses graphic symbols to depict
the nature and flow of the steps in a process.
• It provides an excellent form of documentation
for a process, and quite often are useful when
examining how various steps in a process work
together.
• Different types
– Top-down flow chart
– Detailed flow chart
– Work flow diagrams
– Deployment chart
 Common Flow Chart Symbols

Terminator - Marks the beginning or ending

of a flowchart
Process - A task that needs to be done

Decision - also known as an "IF" statement.

 Common Flow Chart Symbols

Input/output.  

Where data should be stored on disk

Another term for "random access" (e.g. hard

disk) storage (as opposed to "sequential
access" (e.g. tape)
 Common Flow Chart Symbols
A set of actions defined elsewhere in
another flowchart (e.g. "make coffee")

Display

Document

Internal storage
 Common Flow Chart Symbols
Manual input

Manual operation

Merge

Or

A delay in a process, waiting for

something
Management Review
PROCESS Planning System
Control of Quality of Records
Training
Audit
 Advantages
• Better communication
• Effective analysis
• Effective synthesis
• Proper program documentation
• Efficient coding
• Systematic debug and test
 Limitations
• It is very time consuming
• Redrawing is tedious
• No standards on determining the amount
of details should be included
 Structure Charts
• It is a structured designed approach.
• The structured design is an attempt to minimize
complexity and make a problem manageable by
subdividing it into smaller segments, which is
called modularization or decomposition.
• A structure chart (module chart, hierarchy chart)
is a graphic depiction of the decomposition of a
problem.
• It is a tool to aid in software design
• They are used to show the relationship between
modules using chart symbols to represent
– Modules, Control, Subordinate, Library, Data couples,
loops etc.
 Structure Charts
• The top of the
chart is a box
representing the
entire problem,
the bottom of the
chart shows a
number of boxes
representing the
less complicated
sub problems.
 Structured Charts

1. The module is represented by a rectangle with a

name. It is contiguous set of statements. (the
module)

2. A vector linking two modules represents the

connection. It usually means one module called
another module. (the connection)

3. An arrow with circular tail represents the couple. It

represents data items moved from one module to
another. (the couple)
Structured Chart
 Coupling
• Each module is evaluated for :
– the module's connections to other’ modules, called
coupling, and
– its intra-module strength called cohesion
• Module coupling refers to the number of
connections between a "calling" and a "called"
module and the complexity of these connections.
– Coupling measures relationships and
interdependence among modules.
– There must be at least one connection between a
module and a calling module.
– A design objective for producing an easily understood
code is to make the modules as independent as
possible (loosely coupled).
The traffic between the modules is coupling
 Types of coupling
• Content coupling: it is when one module
modifies or relies on the internal workings
of another module
• Common coupling: It is when two modules
share the same global data
• External coupling: It occurs when two
modules share an externally imposed data
format, communication protocol, or device
interface.
• Control coupling: It is one module
controlling the flow of another, by passing it
information on what to do
Contd.,
• Stamp coupling: It is when modules share
a composite data structure and use only a
part of it, possibly a different part
• Data coupling: It is when modules share
data through.
• Message coupling: Modules are not
dependent on each other, instead they use
a public interface to exchange parameter-
less messages
• No coupling: Modules do not communicate
at all with one another.
 Cohesion
• Module cohesion refers to the relationship
among elements (instructions) within a
module.
– Cohesion measures a module’s scope and
processing characteristics.
– If a module does more than one discrete task,
the instructions in that module are said not to
be bound together very closely.
– Modules that perform only one task are said
to be more cohesive (and less error-prone)
than modules that perform multiple tasks.
putting strongly associated things in the same module
 Types
• Functional cohesion
– It contains elements that all contribute to the
execution of one and only one problem-related
task. For e.g READ TRANSACTION RECORD
• Sequential cohesion
– This module is one whose elements are
involved in activities sequentially
• Communicationally cohesion
– This module is one whose elements contribute
to activities that use the same input or output
data. e.g.
• FIND TITLE OF BOOK
• FIND PRICE OF BOOK
• FIND PUBLISHER OF BOOK
• FIND AUTHOR OF BOOK
Contd.,
o Procedural cohesion
o A procedurally cohesive module is one whose
elements are involved in different and possibly
unrelated activities in which control flows from each
activity to the next. E.g.,
o CLEAN UTENSILS FROM PREVIOUS MEAL
o PREPARE food
o MAKE PHONE CALL
o TAKE SHOWER
o SET TABLE

• Temporal cohesion
– A temporally cohesive module is one whose
elements are involved in activities that are related
in time. E.g,
• PUT OUT MILK BOTTLES
• PUT OUT CAT
• TURN OFF TV
• BRUSH TEETH
Contd.,
• Logically cohesion:
– A logically cohesive module is one whose
elements contribute to activities of the same
general category in which the activity or
activities to be executed are selected from
outside the module. E.g,
• GO BY CAR
• GO BY TRAIN
• GO BY BOAT
• GO BY PLANE

• Coincidental cohesion:
– A coincidentally cohesive module is one whose
elements contribute to activities with no
meaningful relationship to one another
 DRAW – Structured Chart
• Aim: to derive design units which are highly
cohesive and loosely coupled.
• Review the DFD’s and object models
• Identify modules and relationships
• Add couples, loops, and conditions
• Input: component accepts input and passes it to a
higher level component, perhaps in a modified form.
• Output: component accepts data from a higher-level
component, transforms it and passes it to a lower-level
component as output.
• Transform: component accepts data from a higher-level
component, transforms it and passes it back the first
component.
• Coordinate: component is responsible for coordinating
the actions of other components.
 OUTPUT DESIGN
There are three main reasons why outputs
from the computer are required. They are:

• For communicating to the persons

concerned.

• For re-input to the computer for being

connected with other data and further
processing.

• For permanent storage.

 Types of Output

• Outputs of a system can take different

forms :
– reports, displays on screen, printed forms
• Outputs of a data-processing system can
be placed into two categories:
– Application Output
– Operating Output
 Application Output
• These are the outputs desired out of the system
to meet its objectives. These are of three types:
– Output as a basis for decision-making.
• Management generally requires this type of output for
decision-making purposes.
– Output as a requirement to meet a functional
objective.
• Invoices, Excise Gate Passes, Purchase Orders are the
examples of such output.
– Statutory Outputs: All organizations are required to
produce a certain amount of reports and forms as
required by law.
• Examples are 'C' forms; '3A' and '6A' forms for provident
fund, income tax certificates etc.
 Operating Output

• These outputs are mainly generated for

use of E.D.P. staff and give various
indications as to
– how the system operates.
• System logs, error messages, status indicators etc.
are the examples of such output.
– These types of output are not concerned for
the users.
 Output Design Consideration
• Type of user and purpose:
– Generally different levels of users will have
different requirements from the system.
• Some want exception reports (e.g. when sales fall
below a certain level),
• some want summary reports (e.g. sales quantity
and value for each region)
• some want details (e.g. list of invoices for a period)
• Again statutory reports will normally be as per
requirement specified under the law and the
designer will not have much flexibility to change
the format
 Output Design Consideration
• Content: The data that are needed to be
included in the output. These will be related to
the purpose of the output.
• Format: This refers to the arrangement of data
on the report, size of the paper, titles, headlines,
Color of the paper etc.
• Frequency and Timing: At what frequency (daily,
weekly, monthly, annually etc.) and when (after
annual closing of accounts, after the end of the
fiscal year, before the last day of every month
etc.)
 Output Design Consideration
• Volume: Often sheer volume of the output deters
one from using the output The sheer bulk of the
report may also create problems for handling,
filing or printing time.

• Sequence: The usefulness of an output very

often depends on the sequence of data printed. A
proper sequence will also help distribution of
outputs to different users (e.g. pay-slips printed
department-wise facilitates easier payment).

• Quality: This relates to the content, appearance

and accuracy of the output Outputs generated for
external users should be given special attention
in respect of its get-up, quality of paper.
 Output Design Consideration
• Type of stationary: Reports can be generated on
ordinary blank stationery or on specially printed
stationery, which is useful when most of the
contents of the output (e.g. Invoice, Pay-slips
etc.) are constant.
– This type of stationery has the following
advantages:
• Saves computer time.
• Attractive appearance convenient to use by
the users.
 Design of Report
• A report normally has the following
structure.
– A report heading which generally appears
only on the first page of the report.
– A page heading and sub heading are given at
the top of each page of the report
– A set of records containing some common
features may be grouped together. Such a
group is named as control group. Control
heading can be named as for this group.
 OUTPUT DESIGN
• The general principles to be used in designing
outputs reports are:
– The design must be such that it can be read from left
to right and from top to bottom.
– The most important item, such as the key field, should
be easily available.
– All pages must have a heading and a page number.
– Too much detail should be avoided.
– Control footing abstracts information about groups of
detail lines must be effectively used.
– Similarly, page and report footings must be properly
defined.
 Design of Screen Output
• A video display screen has normally 80
columns and 24 rows.
• Active involvement of the user is required
as it is displayed on-line.
• User must be given proper instructions for
retrieving the required information.
 Form Design
• People read from forms, write on forms, and
spend many hours in handling forms and
filing forms.
• The data the forms carry come from people,
and the informational output of the system
goes to people so the form is a tool with a
message;
• it is the physical carrier of data of
information.
• It also can constitute authority for action.
• It provides information for making decisions
and improving operations.
Classification of Forms
 Requirements of Forms Design
• Size and shape of the form should be such that
it is convenient for handling, filing, sorting etc.
• Arrange the materiel in a logical order so that it
becomes easy to fill it up.
• The form title must clearly identify its purpose.
Columns and rows should be labeled to avoid
confusion.
• Precise contents should be recorded. Adequate
and compact space should be provided for items
to be recorded. Pre-printed entries should be
taken care of.
Requirements of Forms Design
• Special features like security and control are to
be considered.
• Introduce emphasis by shading columns, heavy
lines, etc. if the form is to be used for specific
clerical operation
• The form designer should design the form in
such a way so as to cover the specific needs of
the purpose for which it is designed
 Types of Forms
• Flat Forms; single-copy form prepared
manually or by a machine and printed on
any grade of paper
• Unit-set/snapout forms: an original copy
and several copies with one-time carbon
paper interleaved between them.
• Continuous strip/fanfold forms: multiple-
unit forms joined together in a continuous
strip with perforations between each pair
of forms.
 Types of Forms

• NCR paper: several copies can be made

by pressing a chemical undercoating on
the top sheet into a claylike coating on the
top of the second sheet.
– The writing pressure forms an image by the
coating material
• Preprinted forms
 Forms Control
• The first objective of this form control program is to
establish standards.
– Different departments using different forms to
accomplish the same task is an unnecessary
expense.
• Forms should be titled, numbered and contain the
data of the most recent revision.
– So all forms in a given system can easily be
located when that system is under study.
• The forms control specialist also seeks to reduce
the number of copies of each form used.
– Routing one copy of a form control through
several departments is probably the best way to
achieve this.