Paper 5

Essential notes on Systems Analysis and Design

March 28^th 2001

OVERVIEW

Objectives

• To introduce systems methodology
• To describe fact finding techniques
• To describe systems evaluation.

1 STRUCTURED METHODOLOGIES

1.1 Concept

The concept of structured methodologies is relatively simple:

• A methodology is a way (means) of doing something
• A structured approach lays down the rules and approach to be followed. The greater the detail, the greater the structure.

A systems development methodology is basically the use of procedures, techniques, tools and documentation aids (most being computerised eg Computer Aided Systems Engineering (CASE)) to help analyse, develop and implement a new system in a particular way following a set routine.

It is estimated that there are at least 800 different registered methodologies. Only two are considered within this course:

• The Systems Development Life Cycle
• Structured Systems Analysis and Design Method (SSADM).

1.2 System development life-cycle (SSADM perspective)

2 STRUCTURED SYSTEMS ANALYSIS AND DESIGN METHODOLOGY

2.1 The method

SSADM is an example of a Structured method with emphasis on user participation. It does not cover the whole System development life cycle. It divides the development of a system into modules or phases. Each phase is decomposed into one or two stages, each stage into a series of steps, and each step into tasks.

SSADM uses the top-down approach. A broad overview of the system is refined into progressively greater levels of detail. This makes the development of a system manageable, as detail can be specified whilst keeping the wider context in mind.

2.1.1 Benefits

By adopting a standard approach in the analysis and design stages of the development of a computerised system, SSADM

• increases productivity and
• enhances the quality of the resulting systems.

SSADM also

• encourages flexible systems design
• allows progress to be monitored as work is carried out
• facilitates planning.

2.1.2 Standards used

• Structural standards – define a number of major stages, each consisting of a number of steps and tasks.
• Procedural standards – relate to particular techniques: data flow diagrams are an example.
• Documentation standards – define the forms and documents which are used throughout.

2.1.3 Outputs

• Program specifications
• File or database designs
• Manual procedures required for the system to function
• Operating instructions
• A plan of how the system will be implemented.

2.2 Phases

SSADM can be broken down into three phases

(1) Feasibility study (may not be included in description of SSADM)

(2) Systems analysis

(3) Systems design.

If the feasibility study is not included, SSADM can be considered to consist of two phases, comprising six stages.

2.3 Stages

Phase 1 – Systems analysis

Stage 1 Analysis of systems operations and current problems

Stage 2 Specification of requirements

Stage 3 Selection of technical options

Phase 2 – Systems design

Stage 4 Data design

Stage 5 Process design

Stage 6 Physical design

Points to note

• One step leads on to the next, with increasing refinement throughout. Changes to earlier work may be needed as development proceeds.
• The analyst looks repeatedly at the system from several different viewpoints. Errors should therefore be highlighted.
• Although phases, stages and steps make SSADM process-driven, it is also data-driven in that the data is examined and analysed throughout.
• SSADM requires the completion of "quality assurance" steps throughout the carrying out of a project.

2.4 5-step methodology

This concentrates on five (early) stages of the life cycle of a system’s development:

2.4.1 Logical vs physical

This separation of logical and physical analysis and design is an important aspect of SSADM. The concept behind this is that the users and developers can establish the data and information requirements without being constrained by preconceived ideas about the physical design.

2.4.2 Techniques

Techniques used to establish and record the logical and physical aspects of the system include

• Fact finding (see below)
• Analysis and design tools

• Entity relationship models
• Entity life histories
• Data dictionaries
• Flowcharts
• Data flow diagrams
• Decision trees
• Decision tables
• Structured English
• Normalisation

3 FACT FINDING

The fact-finding stage of systems analysis is essential in order for the project team to understand the way in which the current system works. Some or all of the project team may have no direct understanding of the system in operation, as they may never have been system users. Obviously it is preferable that at least some members of the project team are experienced in its use.

3.1 Questionnaires

3.1.1 Use

Particularly where there are a large number of system users, a questionnaire may be designed to gather the opinions of users regarding the strengths and weaknesses of the system.

3.1.2 Features

A good questionnaire has the following features:

• Clarity
• Scope
• Conciseness
• Consistency
• Objectivity.

3.1.3 Advantages

Well-designed questionnaires have a number of advantages in fact finding:

• Low time commitment
• Capable of analysis using statistical tools
• Objective responses
• Not biased by personal contact
• More structured and formal but less costly method than an interview
• Open ended questions may provide important insights.

3.1.4 Disadvantages

• Time-consuming to construct
• Questions may be biased
• Response rates may be low
• Respondents may not be able to give views not covered by questions
• Open ended questions are difficult to analyse systematically (compared with closed questions).

3.2 Interviews

Formal meetings to obtain information about the operation of the present systems and the requirements of any planned replacement.

Objectives, time and venue, and authorisation should be planned.

3.2.1 Use

Face-to-face interviews are a much more personal way of gathering information about the current system, and are particularly used when there are few users or they are very senior in the organisation.

3.2.2 Advantages

• Higher response rate
• Personal views can be given
• Not constrained by pre-planned questions.

3.2.3 Disadvantages

• Difficult to control
• Difficult to record
• Difficult to analyse
• May be "hijacked" by interviewees
• Very time-consuming and expensive.

3.3 Observation

3.3.1 Use

The observation of a system in operation is, in theory, the most effective way of gathering data regarding the system.

3.3.2 Advantages

• Does not interfere with operation
• Human behaviour can also be studied.
• May expose features of a system in normal operation that might not otherwise be identified (eg conditions which are taken for granted).

3.3.3 Disadvantages

• People do not behave normally when being observed
• Parts of the system may be hidden from view
• Very time-consuming and expensive.

3.4 Simulation

3.4.1 Use

The operation of the system may be simulated in a number of ways.

• By building a model of the system and testing it
• By passing "dummy data" through the system.

Simulation by model can be very expensive, and large volumes of dummy data must be used to check all aspects of the system.

3.5 Documentation

Where the current system is already computerised, one technique which can be used is a thorough review of the system documentation – desk top review. User manuals, technical manuals and forms can be analysed to give a picture of how the system works in theory. It must be recognised, however, that this technique cannot identify most of the failures in the operation of the system. Documentary review only highlights weaknesses in the system logic or programming and is only as good as the quality of the material and how up-to-date it is.

3.6 Practical issues

In most practical cases a combination of some or all of the techniques outlined above will be used. In some specialised cases, techniques may be combined, for example a questionnaire to a large group of users and a follow-up interview of specific users.

4 SYSTEM EVALUATION

4.1 Objectives

The first stage in systems evaluation is the determination of the project objectives. These may be considered in terms of the original feasibility study (economic , technical and operational), actual achievement of output requirements (scope) and the achievement of deadlines (time). These objectives then form the standard against which the performance of the system may be assessed.

Objectives can be divided into critical success factors and performance indicators.

4.2 Performance

The information gathered about the system performance must then be analysed to determine the performance of the current system when compared with the objectives agreed.

4.3 User acceptance

It must be remembered that although a system may achieve its objectives, it is not successful unless the users have confidence in it and are happy to use it. Part of the analysis process should consider the extent to which the users accept the system

Now read: Systems Analysis and Design Tools