This SSADM Version 4.2 Techniques Guide,
which is one of the four volumes of SSADM V4.2 Practitioner Manuals, provides
detailed rules and guidelines of SSADM techniques on where
and how to apply them during the course of systems analysis
and design.
The document provides guidance as 'how to
do it' within SSADM.
Some major
techniques described are summarized in the following sections.
Business Activity Modelling
The purpose of Business Activity
Modelling is to model the essential activities that need to
be undertaken within the business. It also supports the understanding
of the business events to which the business needs to respond
The following products are
prepared:
After business perspectives
are defined, business activities should be defined to support
the business perspectives. The model should capture these
types of activities: Doing, Enabling, Planning, Monitoring,
and Controlling.
Business events that trigger
business activities should be identified and documented.
Business Events are of three types: external, decisions
made in business activities, and scheduled points in time.
The business rules that
govern the business activities should be documented. They
consist of Constraints and Operational Guidance.
Data Flow Modelling
The Data Flow Modelling technique is used
during the analysis phase to provide a common vehicle, in
the form of diagrams and associated descriptions, to communicate
with users and among developers. It is also used to identify
the system boundary and major functions of the current environment
(if exists) and the proposed new system.
There are basically three versions of Data
Flow Model:
Current Physical Data Flow Model
Current Logical Data Flow Model
Required System Data Flow Model
Each Data Flow Model consists of:
A Context Diagram
A hierarchical set of Data Flow Diagrams
(DFDs)
Elementary Process Descriptions
Data Store Description (for current physical
data flow model only)
The following steps can be used to develop
the data flow model:
Develop a context diagram showing the system
boundary and interfaces with other external parties.
Develop level one current physical DFDs
Develop lower level DFDs
After the current physical data flow model
is confirmed with users, logicalize it to produce the logical
data flow model
Develop required system DFDs by including
the new features/facilities as stated in the user requirements
in the logical DFD.
Work Practice Modelling
Work Practice Modelling defines how the business
activities may be carried out within the user organization
and producing specifications of the user's jobs.
Two products, User Role/Function Matrix and
Job Title/User Role Matrix, will be produced.
The following steps can be used to develop
the work practice model:
Perform User Analysis to determine the
capabilities and expectations of the users.
Identify Candidate User Tasks by reviewing
the Business Activity Model.
Assign the tasks to user roles.
Define Job Title/User Roles Matrix by mapping
the user roles to the business organization in terms of
physical location and job titles.
Define User Role/Function Matrix by using
the tasks to user roles assignment from step 3, and further
elaborating the tasks into functions.
Logical Data Modelling
Logical Data Modelling is a technique used
to produce an accurate model of the information requirements
of all or part of an organization, evolving initially from
the business view of information requirements to a system
processing view.
There are three different Logical Data Models
(LDM) produced:
Each LDM consists of:
Logical Data Structure defines the data
entities and the relationships among them
Entity Descriptions define the volumetric,
data items and keys of each entity
Data Catalogue defines the data dictionary
of the data items in used
The following steps can be used to develop
the LDM:
Fact finding by analyzing forms, identifying
support information, etc.
Identify types of relationships. Consider
degree, optionality, multiple relationships, and exclusive
groups.
Draw the Logical Data Structure.
Normalize the LDM using Relational Data
Analysis technique.
Validate LDM against functional requirements
as stated in the Requirements Catalogue
Remove redundant relationships. Since the
LDM is developed to reflect the structure of the data, not
all of the relationships identified may be required for
functional purposes.
Resolve many-to-many relationships and
one-to-one relationships.
Present the LDM to users. It is important
to get user acceptance of the accuracy of each LDM.
Document the LDM.
Business
System Options (BSOs)
The Business System Options technique is carried
out to
enable users to decide what is required
in the system based on factors such as constraints on budget,
time, resources, etc.
reach a compromise between ideal and practical
solution of the required system.
Several BSOs are created to enable the users,
being the owner of the system, to decide what they require
the system to do under the effect and limitations of different
constraints. Each BSO will need to be described to users for
them to choose the most appropriate one for implementation.
When developing the options, priorities, impacts
on existing system or infrastructures, costs, planning and
constraints should be taken into consideration.
Once the BSO is selected, the reasons for
selection will be documented. And, the option selected will
be elaborated into details, whereas other considered options
will be included in the appendix of the Feasibility Study
or System Analysis and Design Report.
Entity Behaviour Modelling
For an analyst to understand a system thoroughly
it is necessary to examine it from different viewpoints. Two
such viewpoints are represented by Data Flow Modelling (process
point of view) and Logical Data Modelling (data point of view).
However, these two views are static. Data Flow Modelling does
not show the sequence of processing while Logical Data Modelling
does not indicate how the data changes with time.
Entity Behaviour Modelling looks at the system
from the 'event point of view', so as to validate the high
level processing and data views of the system and at the same
time identify further detailed processing and data requirements.
There are three products for Entity Behaviour
Modelling:
Event and Enquiry Catalogue - records the
events of the system and the frequency of the events happening
Entity Access Matrix - a two dimensional
matrix showing the effects of events on each entity in the
Logical Data Model
Entity Life History (ELH) - Jackson-like
structure diagrams to specify sequence of processing within
a system
The followings are the steps to develop Entity
Behaviour Model:
Identify events & prepare the Event
and Enquiry Catalogue.
Produce Entity Access Matrix.
Draw ELH. It is not required to draw ELHs
for all entities in LDS. In particular, ELHs need not be
drawn if the life history is too simple or if the structure
is typical and similar to other ELH.
Review ELH.
Add State Indicator to ELH. This is optional
but definitely beneficial because the defined sequence of
events can be enforced and current state of a particular
entity occurrence can be pinpointed.
Technical
System Options (TSOs)
TSOs provide a formal procedure for an objective
decision to be made by user management on the choice of a
technical implementation strategy for the required system.
The followings are some guidelines for developing
TSOs:
Identify Constraints.
Briefly outline some possible options based
on the constraints identified. Once the constraints are
identified, it is possible to create some outline TSOs to
meet the system requirements.
Reduce the number of outline options. The
high-level outline options are discussed between users and
project team in order to decide upon a manageable number
of outline options to develop into full TSOs.
Develop full TSOs.
The options created must be presented to the
responsible users for a selection to be made.
Only the selected option will be elaborated
in detail in the System Analysis and Design Report. Other
considered options will be included in the Appendix for reference.
For further information, you are welcome to
contact us through email enquiry@ogcio.gov.hk
.
|