Structured Systems Analysis and Design Method (SSADM) 1.

Background
result of collaboration between the CCTA (government run - Central Computing and Telecommunications Agency) and LBM (software development house - Learmonth and Burchett Management ystems) in the early !"#$s% built on the success of LBM &s data driven methodology% CCTA involvement has guaranteed its use in government departments% started with the development of the early structured development methodologies which were process oriented% now combines different views of development' data (predominant)( process and time dependent behavior based on the conventional life cycle view of development% publicly available (trainers are licensed( practitioners are not)% methodology is under constant development( version ) issued in !""$*

2. Aims
CCTA specified the methodology should' be self chec+ing% use tried and tested techni,ues% be tailored% be teachable*

-rimarily aimed at the development of medium to large computer-based systems* Templates for other classes of system have been developed e*g* Micro A.M*

3. Characteristics
.ata driven (benefits such as stability( developer ob/ectivity and easier user validation result)' static view (top down L. and bottom up 0.A approaches used)% dynamic view (.1.)% time oriented view (2L3)*

Cross chec+ing'

comparison of different modelling approaches% 'SSADM has turned a serious problem with the reductionist approach into a strength' 4.owns( !""56% user involvement and validation*

eparation of logical and physical descriptions -rescriptive' rigid definition of standard framewor+% fle7ibility issues addressed by availability of templates and tailoring by authori8ed personnel*

.ocumentation' copious% standards and forms used provide a means of structuring information*

0eductionist' brea+ down of pro/ect into small steps facilitates planning and deployment of staff*

Techni,ues' integrates techni,ues developed from a variety of sources( has ta+en the best techni,ues from a number of different methods% significant use of diagrammatic techni,ues*

9uality assurance' reviews ta+e place at end of each stage% user sign off ensures involvement issue is addressed% technical review improves ,uality*

oftware support available

4. easi!ility Study" Stage #

This assumes that the proposed pro/ect has been identified as a result of an e7ercise such as strategic planning and sets out to evaluate the various technical( organisational( financial and business options available* The aim is to establish the whether the direction and re,uirements of the pro/ect are feasible* :n essence this is a shortened( higher-level version of tages ! and 5 (re,uirements analysis and re,uirements specification)* This should not be an e7pensive or time consuming e7ercise (ma7imum of one team wor+ing for !;5 months)* The aim is to evaluate the feasibility of the proposal( involving an analysis of the

problem and determination of the best solution% usually a range of potential solutions are presented* Conte7t diagrams( current physical .1.s( overview 20.s( a re,uirements catalogue( pro/ect management techni,ues such as activity networ+s and <antt charts are produced* To pass this stage and go through to system development a proposal must demonstrate 4=endall>=endall( !"##6' ? 2conomic feasibility% ? Technical feasibility% ? @perational feasibility% @ther types of feasibility may also re,uire consideration( for e7ample legal feasibility*

4.1 $conomic easi!ility

The aim here is to assess the costs re,uired for alternative systems and set them against the e7pected benefits* The types of alternatives that are fre,uently considered are the manual;computer boundaries as some tas+s may benefit more than other s from computeri8ation and non-functional characteristics such as the time delay between the real world and the different parts of the system' should we be loo+ing at batch( on-line or real-time or a combination A The system costs should also be estimated in terms of basic resources of money( people and time* 1or e7ample( the following must be costed' ? ystems development( for e7ample in-house or management consultancy% ? Bser time for re,uirements ac,uisition( testing and training% ? 3ardware > software costs* et against the costs should be a ,uantifiable assessment of the e7pected benefits( for e7ample reduced labour costs( improved customer service or predicted increase in orders* 2conomic feasibility is a bit of a 'black art'( it&s difficult to predict with any degree of certainty whether a system will in fact benefit an organisation* The most fre,uently missed cost is the cost of maintaining the system once it is installed*

4.2 %echnical easi!ility

This is concerned with whether the solution can be implemented using e7isting technology* :f it can then e7isting technology may re,uire upgrading or adding to* :f it can be done then the solution may re,uire the integration of e,uipment or software that has not been combined before* Con-functional re,uirements such as batch or on-line processing( ma7imum response time for user-computer interaction( estimated fre,uency of transactions( ma7imum record and file si8es( networ+ing loads and typical number of users are considered here* :n addition( re,uirements of system e7pansion( security( data archiving and reliability are considered*

4.3 &'erational easi!ility

This investigates factors such as the li+ely reaction of employees and union representatives to /ob

and other proposed organisational changes* The main aim is to assess whether the solution will operate and be used after installation* 1or e7ample( if users are happy with the current system and see no reason to change then there may be a high degree of resistance to the new proposal* 0elevant factors here concern whether the solution has general management support and whether or not the users have been involved in the development of the proposal*

4.4 (egal easi!ility

This encompasses a broad range of sub/ects including contracts( liability and the .ata -rotection Act*

4.) easi!ility *e'ort

The result of the feasibility study should be a feasibility report that provides a detailed terms of reference( a management summary( details of how the feasibility study was underta+en( analysis of the current situation( details of the future re,uirements( e7planation of the proposed system( details of options that were re/ected( a financial assessment of the costs and benefits of developing the proposed system( a pro/ect plan and recommendations*

). *e+uirements Analysis" Stages 1 , 2

This consists of 5 stages* :n stage ! re,uirements are defined by investigating the current environment and identifying problems or areas that need improvement* tage 5 then develops a range of options that meet the defined re,uirements and selects one option as the basis for the desired system*

Stage 1" -n.estigation o/ Current $n.ironment

An overview of the current processing and data is created* Current problems are documented as a necessary improvements and any new data or functions that will be re,uired* The intended users of the new system are also identified* ? A .1. is produced showing the current system* ? An 20. is produced showing the entities and relationships obtained by analysis of the data in the current system*

Stage 2" Business Systems &'tions

A Business ystem @ption (B @) describes a suggested new system in terms of its functionality and its boundary' inputs( outputs( processes and data are described* The aim is to help the users choose( from all the listed re,uirements( /ust what they want their new system to do* A B @ is a te7tural description of the boundary( inputs and outputs( and principle processing activities (or functions) to be performed of a proposed system* The B @ may include diagrams

(.1.s( 20.s etc*)* 3owever( such diagrams would be very much an overview* Technique: .raw up a list of about D B @s( covering a range of re,uirements identified in tage !* The range should cover' ? @ne option that covers the stated minimum re,uirements and no more% ? @ne option that covers every new re,uirement% ? Bp to four options that each cover the stated minimum re,uirement and a different set of the other re,uirements* The si7 options will then cover si7 different boundaries and si7 different functionalities - all will cover the minimum functionality re,uired* Con-functional re,uirements should also be covered( for e7ample' ? Cost;benefit of the proposed option% ? :mpact Analysis of implementing the B @% ? Timescales for development and construction* The obvious non-starters can then be eliminated* The remaining B @s should then be e7tended to include' ? Constraints% ? :mpact on e7isting systems - loo+ out for the ripple effect% ? .etailed plans and time scales for the subse,uent implementation of the system% ? @rganisational impacts and implications* The short-listed B @s should then be presented to the decision ma+ing body* A.M activities and

0. *e+uirements S'eci/ication" Stage 3

3aving selected a specific B @ a detailed specification of re,uirements now begins* The emphasis is on determining the desired system data( functions and events* -rototyping techni,ues are also suggests for the development of the 3C:* ? The previously defined s+eletal .1.s and 20.s are modified and refined to match the re,uirements in the selected B @% ? All attributes are specified for the 20.% ? Con-functional characteristics such as security( access and archiving re,uirements are defined% ? The input;output data is defined using 'input/output structures'% ? The system dialogues are defined%

? As a chec+ on the 20. 'relational data analysis' is used% ? -rototyping the re,uirements with the users to obtain errors and capture any additional re,uirements is suggested* A.M provides procedures for managing prototyping sessions% ? Bsing 'entity e!ent modelling' more detailed processing re,uirements are obtained( This is done by creating an 'entity life history' for each entity on the 20.( and an 'effect correspondence' diagram is constructed for each event( showing the entities affected by that event* An 'enquiry access path' is created for each anticipated en,uiry showing the entities on the 20. that are to be accessed*

1. (ogical System S'eci/ication" Stages 4 , )

Stage 4" %echnical System &'tions
This assesses the different options for implementing the specification and describes the costs( benefits and constraints* 1actors include internal and e7ternal constraints* 27ternal constraints consist of( for e7ample( time( cost( business performance and any hardware or software constraints set in the feasibility study* The procedure for producing and selecting Technical ystem @ptions (T @s) is very similar to that for B @s* 1irst( draw up an initial list of appro7imately si7 options* The s+eletal T @s should then be e7panded to include details derived from potential suppliers such as' ? Cost% ? 1acilities% ? -erformance% ? upport etc* The intention is not to decide on a choice of vendor but to establish ballpark figures and estimates to present to the -ro/ect Board for each T @* As with B @s( the range should cover' ? @ne option that suggests no change% ? @ne option that covers the stated minimum re,uirements and no more% ? @ne option that covers every new re,uirement% ? Bp to four options that each cover the stated minimum re,uirement and a different set of the other re,uirements* The range should then be e7amined to eliminate obvious non starters* The remaining T @s should then be presented to the board

Stage )" (ogical Design

The "ogical Dialogue of the system is defined* This does not include the physical dialogues (menu structures( form designs etc*)* Ceither is this the stage at which the physical screen characteristics are defined* At this stage the logical e7change of data is defined* The #pdate $rocessing is also defined* This specifies the logic of each database update re,uired for an event* The 2ntity Life 3istories are updated with State %ndicators* tate :ndicators describe the specific state of the data associated with each event in the 2L3* 1or e7ample( when a Customer 0ecord is created the initial state of all the attributes is empty* As the Customer 0ecord is processed the state of the attributes will change over time*

2. 3hysical Design" Stage 0

The -hysical 2nvironment the system will operate in is considered* A $hysical &n!ironment 'lassification Scheme is used to categori8e the physical environment* The scheme considers factors including' ? .ata storage% ? -erformance% ? -rocessing characteristics* The characteristics( demands and constraints of the environment will clearly have an effect on translation from the Logical .esign* .ecisions such as denormalising( clustering and inde7ing will be made at this time* The physical screen designs are developed*

*e/erences"
4=endall>=endall( !"##6 =endall = 2 > =endall E 2( ystems Analysis > .esign( -rentice 3all( !"## 4.owns( Clare > Coe(!""56 A.M' Application and Conte7t( -rentice 3all( 5nd 2dition( !""5