STRUCTURED SYSTEM ANALYSIS AND DESIGN METHOD

Structured system analysis and design methodology is a system approach to the analysis and design of
information systems SSADM was produced for the CCTA, a UK government office concern with a use of
technology in government , from 1980 onwards.

System design methods are a discipline within the software development industry which seek to
provide a frame work for activity and capture, storage, transformation and distribution of information
so as to enable the economic development of computer system that fit for perhaps.

SSAD is a waterfall method which an Is design can be arrive at SSADM can be tough to
represent a pinnacle of the rigorous document let approach to system design and contrast with rapid
application methods such as DSDM.

General system concepts

A set of connected things or parts that form a whole together to achieve a a common goal, can
be defines as a system. The objectives of a system demand that some output is procedure as a result of
processing suitable inputs.

inputs process
proces outputs

A PURCHASING SYSTEM
Notification of
purchasing order
Supplier
Purchasing Purchase
Ware
House Order
Department
Request
parts

System Boundary

A purchasing system orders goods suppliers. It keeps list of suitable suppliers, their products, lead
times, minimum quantities & etc. Inputs to the purchasing system are requested for a parts, the
processing is to select the most suitable supplier , negotiable rates, arrange delivery times & dates m the
outputs are purchase orders, notifications to the ware house that the parts have been ordered.
An order processing system

Order Sales Order

Customer
Office

Parts pick list

request order purchase order

Purchas
Supplier
e Dept.
DATA FLOW DIAGRAMS

DATA FLOW DIAGRAM SYMBOLS

1. External entity customer

2. Process

3. Data store M

4. Data flow Quotation Details

External Entity

The fundamental purpose of the symbol which is either a source of data ( An inquire) or a sink ( A
quotation) is to indicate that whatever happens at the end of the data flow. It is not the concern of the
activities been studies may be people, departments, functions, or other groups external to the area
being described by the DFD. An external entity cannot directly access a data store. A process can exist
between an external entity and a data store.

Process

In a DFD the rectangle implies shows that some activity takes place, transforming the
input data.

There must be no increase or decrease in the data as a result of processing. If the total
of the inputs does the outputs in all process the DFD is incomplete.

DATA STORES AND DATA FLOWS

There are only two justifications for data stores in any system. One is that data exists which will be
required frequently for output. But would be costly & time consuming to input each time. Therefore
referenced files are created. The second reason is that data exists which is not required currently by the
process but which will be required either in another or at a later date. It is not always necessary to name
flows to & from stores for e.g. When validating customer info. Again the customer data store it is only
necessary to show a data flow line from the data store to the process. Data store can’t communicate
with another data.

Levels

HOW MANY LEVELS

There are no rules about the num of the levels of the DFD used. This is holy dictated by the application &
the analyst. In some cases a single DFD will show all what is needed. In other cases 2,3 or more levels of
DFD may be necessary.
Request a prescription

Pre request

1 Surgery Prescription 1 prescription details

Patient
Extract Details or

Prescription

Prescrption Details

2 Doctor
authorize Patient
Prescription
APPLYING FOR A MEMBERSHIP – LEVEL 2

Title

1 Produce Membership Card

1.1 Reception

Person Request membership validate personal

Person
details
Completed
application
form

Valid Person

1.2 Reception
Produce Personal D1 Members Details
Member
Membership card details

REVIEVING THE FIRST LEVEL DATA FLOW DIAGRAM

1. The complete life of each data flow has been record.

2. Each data store has a flow going into &one coming out. (Not necessarily from the same process.)
 3. Data stores are not connected to external entities. (There must be a process between.)
4. Data flows do not deceirper into a process.
5. All names used are familiar to uses.

FACT FINDING

The term fact is finding is used for the aspect of the analyst fob. Information gathered during the
investigation wil concern not only the existing system but also what the user requires from a new one.
The analyst must recognize these two aspects & document them separately. This chapter deals first with
some of the general problems associated with the investigation activity under the following headings.

1) Throughout the investigation

2) Business activity modeling
3) Dealing with the user
4) Changes
5) The specification

THOROUGH INVESTIGATION
Thoroughness alongside investigation of he write aspects of a system is the key to a successful
investigation. Frequently an analyst has only partly understood what an existing system does & what a
new system needs to do. As a direct result, a new system needs to do. As a direct result , a new system,
however matches the analyst description of the organization’s requirements. Phases it does to much,
phases it does to little. In either case it needs to be modified.

Modification to the system is not uncommon. Some be require because if changes on policy Or
the environment in which the system’s operate, where as other modifications are required because of
errors in the system but to inadequate analysis or design.

The earlier an error is is discovered & the system altered the cheaper the alteration will be.

An error discovered during the investigation & analysis to ensure that the information collected
is accurate, factual & complete, is time & effort well spent

The write things for the analyst for investigate for both current practice & requirements are

1. The processors /procedures(how)

2. The data (What)
3. The people involved (who)
4. The reasons why things are done (why)
5. Where they happen (where)
6. When they happen (when)

If the analyst keeps in mind to ask questions beginning what, why, where, when, how, who these
aspects will be elicitated.
BUSINESS ACTIVITY MODELLING
When investigating the information technology requirements for a new system a definition of
requirements is of better quality if it is based only why the knowledge of the business environment
within which the users operate.

The definitions of requirement are improved whether if the analyst understands not only what the users
do, why they do it & how different users business activities are interrelated. The business activity model
(BAM) is a meets of documentary & analyzing those activities which are essential for the business to
meet specific objectives. It enables the analyst to understand the overall business & develop
requirements to ensure that the new computer system will support the attainment of the business
objects.

BUSINESS ACTIVITY MODEL DIAGRAM

SUPPLIER New Parts BUYER spare parts Parts store

obtain spare parts

Work station
customer car Reception cars for service
Service Car
Collect car

Resource flow

The business activity model should contain 4 components

1. The business perspectives

• Sharing why the business does what I does
2. The business activities & their interactions
3. The business events indicating when business activities are carried out
4. The business rules
• Defining how activities should be carried out
DEALING WITH THE USER

The analyst needs to keep in mind the fact that at all levels has a job to do. The amount of time
that they can usually allocate to describing their work, checking that the analyst has correctly
understood it & generally working with the analyst to be very limited.

However resent user centered approach to the system development requires appropriate users
to be allocated to the development team or considerable proportion of their time. ( Policies even full
time for a short period.) this can be very effective provided that the user does not also have the whole
of their usual job to perform at the same time.

MISSING THE OBVIOUS

A user knows their functions in the existing system & the often considers it to be obvious.
However it may not be obvious to the analyst, who will need care & fact to obtain relevant information.
The difficulty in trying is in trying in a very short time to understand what is done & why. The people
who operate the system are completely familiar with it, where as the analyst is not. They know what is
important and what is desirable. (Nice to have)

The analyst should try to identify the important parts of the policy been implemental. He or she
cannot expect to receive a clear details & accurate account of precisely what is done, why & with what
properties.

INSTANT DESIGN
While the analyst is taking to people listen & recording what they say his or her mind will be
busy pigeon holding. The analyst should take great care at the early stage. He or she should not commit
anyone to a particular part & should make no promises or suggestions. The analysts usually just not have
any authority to make decisions at this stage regarding the future development.

TIMES OF REFERANCE

Before an analyst can start the investigation he or she requires the investigation he or she
requires a statement of what needs to be done. This statement is called terms of reference. It sets out
the,

1. Objectives of the investigation

2. Boundaries
3. Allowable expenditure & other resources available
4. Time by which it should be completed.
5. Method of presenting the results
 1. OBJECTIVES OF THE INVESTIGATION

The initial study I is a miniature investigation of its own which high lights areas that need a more detail
investigation of its own, which highlights the arias that need a more detail investigation & also provides
rough cost & benefits expected if a new system were implemented. This information can be dangerous
& misleading during the detail investigation. The analyst must not think solutions until the work of
analysis is complete. However the feasibility report spells out the basic objectives that should be met by
a new system & this helps the analyst to determine the user requirements.

2. Boundaries

The boundaries of an investigation are usually stated as departments, groups or functions that
are to be studied or sometimes excluded from the study. If the analyst can be given a list of those
people or groups who provide input to the aria to be investigated, and a list of those who receive
output from (e.g. The sources and sinks) then or she has by implication been given the boundaries .The
people or department that are the sources of input data and those that receive the output, sinks (A sink
Is a person or place that receives the output), are outside the area to be investigated. Everyone and
everything are in between the domain of study however this statement assumes that the analyst can
identify quite precisely what data flows in to an out of the domain of the study. Sometimes this is not
true and as the investigation progresses’ and problems and requirements are identified, what initially
appeared to be a source or a sink may need to be brought within the system boundary.

COST and TIME LINES

Cost and time are a normally two sides of a same coin.(D1) Cost is the number of person days at
the going rate. b

Not all investigations are carried out by one person full time if a particular investigation is
carried out in this way a time scale for completion will be the number of person days and the cost will
be that number multiplied by the current person day rates.

REQUIREMENT CATALOGUE

The analyst should build of the details of the requirements for the new system throughout the
investigation process. This can be in the form of a requirement catalogue. The requirement
catalogue is the central repository for information about requirements. The format will be
dependent on the case tool which is been used to manage the Catalogue but At least the
following information should be recorded to each requirement.
1. Requirement id/number

2. Requirement name

3. Business activity

5. Source –Person document

6. PRIORITY (high, low, optional)

7. Owner – person with the responsibility who negotiates about the requirements

8. Requirement type - functional and

(Find out the functional and non functional requirements)

9. Benefits – expected implementation of this requirements

10. Comments /suggestions

11. Related documents

12. Related requirements

MODIFYING THE TERMS OF REFERANCE

It is by no means uncommon for analyst to discover that some of the terms of reference need
to be modified in the light of detailed knowledge. It is therefore better to limit the initial terms
of reference to a statement of boundaries and timings. Then after the initial investigation the
terms of reference can be expanded to include new objectives and widen the scope of full
investigation.

METHODS OF INVESTIGATION
The first step in fact finding is to study background information on the area to be investigated.
Business activity modeling gives the analyst a sound understanding of the overall business
environment .other useful information includes
1. How the organization is structured, the relationships between various departments who
holds the key responsibilities their style of management and their interest in the current
investigation.

2. Previous studies that may have been carried out and their outcome, were the results
accepted or turndown, and why.

Having studies the background information, the analyst is ready to proceed with the
investigation. A number of methods can be used to collect facts; the analyst must choose which
method most suit the investigation and time scale.

methods are observation, record searching , special purpose recording , sampling

, questioners, interviewing, workshops,

[Functional and non functional requirements

Simultaneous users – doing two different actions in the same application at a given time

Concurrent users- doing the very same action in an application at the same time]

Entity Analysis

An entity is a thing which holds information about an organization. Entity modeling is a technique
showing relationships between entities. Entity analysis is the process by which the model is developed
and identifies the underline structure of the data and relationships of those data.

The diagram produce from entity modeling is called entity relationship diagram (ERD).

When is entity analysis performing?

Entity analysis is performs at two stages during the analysis phase of a system.

1. During analysis of the existing system, to aid the analyst understanding of it.
2. In conjunction with relational data analysis to produce a model of the required data structure
of the new system.
Entities
As defined above an entity is a thing about which the organization wants to hold information. Entities
may be physical things such as

1. Customer
2. Invoice
3. Product
4. Supplier
5. Employee
6. Training course

Or conceptual things related to the business area such as

1. Salary grade
2. Sickness history
3. Project

Attributes
All the entities have attributes. They are data that describes or qualifies the entity. In the entity
employee attributes could be

1. Employee no
2. Employee name
3. Employee address
4. Employee department
5. Employee salary

Entity occurrence
An entity has number of occurrences. If there are 200 employees in an organization there will be 200
occurrences of the entity employee. Each individual occurrence must have a unique identifier (a key)

Employee no Name Address dept salary

H001 Perera No. 5, Colombo HR Rs.50,000

Is one occurrence of the entity employee with a unique key of employee number.

Relationships
The relationship between two entities describes the way in which occurrence of one entity is linked to,
or influence by occurrence of another. For e.g. a department may have 0, 1 or many employees but each
employee will relate to only one department. (In this example where the business rule is that an
employee will only work in one department.)

Notation
Entity description – the entity name is always in the singular within a rectangle

Relationship – a relationship between two entities is shown as a line.

Producing an entity relationship diagram

Selecting initial entities
An entity can be identified by looking at existing files and documents where there is a unique
key(identifier) this will be a candidate for an entity an employee has a unique employee no, an

Invoice has a unique no, etc.

In a library example a member (borrower) has a unique membership number and a book has a unique
book no.

There will also be a topic catalogue where each topic is unique, an author catalogue where each has a
unique code, a reservation facility where the borrower number and the book number are recorded,
therefore first set off entities identifies for the library is

1. Borrower
2. Book
3. Author
4. Topic
5. Reservation

As with data flow diagrams entity modeling is an iterative process. Not all entities may be located at the
first attempt. If there is any doubt about whether something is an entity or not, it should be included.
The model will go through many stages of checking, where the redundant entities can be removed.

Placing entities in a grid

BORROWER BOOK AUTHOR TOPIC RESERVATION

BORROWER
BOOK *
AUTHOR
TOPIC *
RESERVATION
Entity Life Histories (ELH)

Entity life histories look at a system providing a means of representing how entities change within a
system with the passage of time. ELH start with the creation of an entity occurrence, record the
sequence of changes that take place during its life within the system and end with its removal from the
system.

When are ELH s produced?

It should be used during logical system design to validate the completeness and correctness of dfd’s and
data analysis and again alongside analysis of access requirements to ensure that all events which cause
changes to entities are considered.

Concepts and terminology

Update processers

Processors can be divided into two types.

1. Those which change the systems data

2. Those will simply referencing

They are called update inquiry/retrieval processors. ELH will concern with update processors only. The
following diagram represents and updates process in a DFD. Update processing within the process
“create new customer may include

1. A validity test of the format of the input data flow.

2. A check that the customer is not already on the file.
3. Creation of a new occurrence of the customer entity

D. 01

Events
An event is anything that activates (triggers) an update process. It may be the receipt by the process of a
particular data flow or it may be the arrival of a particular pointing time. Example: end of day, end of
month, yearend which is recognized by the system.
Effects
A single event may cause more than one entity to change. Eg. It may have more than one effect. An
effect can be

1. A creation of deletion of entity occurrence

2. Changes of the attributes of the entity occurrence
3. Creation or deletion of relationships
4. A combination of the above

Sub events
A single event may result in different effects depending on the condition of data when the event occurs.
In such cases the different effects are said to be caused by sub events, which are the combination of an
event and the condition of the data within the system at the time that the event take place.

E.g. Ammendments ofdetails

Amend
Sales Dep Customer
Customer

If the customer not on file insert new customer, otherwise amend details

Entity life history notation

General structure
An ELH is a pictorial mean of represent ting events that can affect the life of an occurrence of an entity,
from its creation within the system to its deletion from the system. The following diagram shows the
general structure of an ELH.

The events followed the sequence create, amend, delete from left to right in the diagram
 Events
associated
with entity A

Events which Events which cause Events which course

course entity of entity occurrence of ‘A’ entity occurrence of
‘A’ to be created to be mended ‘A’ to be deleted

General structure of an entity life history

The top box always containing the name of the entity lower level boxes represents events that can
happen during its life within the system.

The diagram is a hierarchy each lower level box will only be related (connected) to one higher level box.
The higher level box represents a sequence made of the lower level boxes connected to it. It is usual to
consider the most common sequence of events first, adding in abnormal events once an initial diagram
has been drowned. The structure diagram is based on three constructs

1. Sequence
2. Selection
3. Repetition