System Development, Methodologies and Modeling
Last edit December 2006


We are looking at how an analyst (or analyst team) designs information systems -  at the Requirements Analysis and Design phases of the systems development life cycle.

The Traditional Life Cycle

The diagram above shows the 'Traditional' systems development life cycle, highlighting the stages in which modelling is typically used.  (However, modeling, and the techniques we will look at can be, and are used in every type of system development process. The above diagram is itself a model!)

The problem for the analyst is  that any real world system is complex and computers somewhat limited in functionality. The analyst needs to abstract from the target system (ie: the system being analysed) the important data and activities/processes which must be incorporated in a computerised system to make it useful.

In the last thirty years a number of methodologies, incorporating a variety of techniques, have been developed to make the analysis and design stages more manageable. Almost every methodology has at its heart at least one modeling technique. 


In the initial Project Selection phase, a major decision is what system development life cycle (SDLC) will be used during the project.
A second major decision is what methodology will be used - although often this decision is made by default when an analyst or consultant team is chosen. There are many different methodologies used in systems development.

which will help the systems developers .. to implement a new information system. .. It is usually based on some philosophical view, otherwise it is merely a method, like a recipe." (Avison and Fitzgerald, 1991:4)

'Philosophical' in this context can be understood as referring to the underlying attitudes and viewpoints, and the different assumptions and emphases to be found within the methodology. For example, some 'philosophies' on which a methodology might be based:

Why use a methodology?
Some methodologies

Avison & Fitzgerald (1991) describe a number of methodologies eg:

Modeling Computer systems are models of the real world - they abstract from the complexity of the real world.

The analyst observes the complexity of the real world and constructs a model of (parts of) the target system in her head. Using systematic modeling techniques the target system can be modeled on paper, or, using a Computer Aided Software Engineering (CASE) tool, in a computer package. Some CASE tools (in theory) will process the model to produce the required new system - at the press of a key!

You as model

One thing that all these systems have in common is that the 'you' which they model is an abstraction - usually your name and only those details which are relevant to the particular system. Events which happen to you in the real world are (or should be) mirrored in the model, but only those events which are seen to be relevant to that system.
How up-to-date a computerised model is, is dependant on the efficiency of the system's methods of data capture.

Assignments as Example

What is a model?

Douglas T. Ross (in Marca 1988) suggests that a model answers questions; that the definition of a model is:

M models A if M answers questions about A
Why model?
We need to model complex systems in the real world in order to understand them. For example: we create computerised models of the real world to manipulate large amounts of data and hence derive information which can assist in decision making.

An analysts will create diagrammatic models of a target or proposed system in order to:

Modeling techniques are extremely useful in tackling the complexity which is found when attempting to analyse and understand a system. Models are also extremely useful communication tools; ie: complex ideas and concepts can be captured on paper and can be shown to users and clients for clarification and feedback; or for distribution to other professionals, team members, contractors etc. In this respect, the final models created in the Design and Development phases of a system are essentially paper based prototypes
Modeling Techniques

The three most important modeling techniques used in analysing and building information systems are:

Data Flow Diagrams (DFDs) model events and processes (i.e. activities which transform data) within a system. DFDs examine how data flows into, out of, and within the system. (Note: 'data' can be understood as any 'thing' (eg: raw materials, filed information, ideas, etc.) which is processed within the system.
See: Data Flow Diagrams (DFDs).
Logical Data Structures (LDSs) represent a system's information and data in another way. LDSs map the underlying data structures as entity types, entity attributes, and the relationships between the entities.
See: Logical Data Structures (LDSs) - Getting started.
Entity Life Histories (ELHs) describe the changes which happen to 'things' (entities) within the system.
These three techniques are common to many methodologies and are widely used in system analysis. Notation and graphics style may vary across methodologies, but the underlying principles are generally the same.

In SSADM (Structured Systems Analysis and Design Methodology - which has for a number of years been widely used in the UK) systems analysts and modelers use the above techniques to build up three, inter-related, views of the target system, which are cross-checked for consistency.

Data Flow Diagrams (DFDs)
SSADM uses different sets of Data Flow Diagram to describe the target system in different ways; eg: Another way of looking at it is that, in SSADM, DFDs are used to answer the following data-oriented questions about a target system:
What processing is done?  When? How? Where? By whom?
What data is needed?  By whom? for what? When?

However, we are not interested, here, in the development process in detail, only in the general modeling technique. Essentially, DFDs describe the information flows within a system.

DFD Principles

Basic DFD Notations

In a DFD,
a process may be shown as a circle, an oval, or (typically) a rectangular box; and
data are shown as arrows coming to, or going from the edge of the process box.

(SSADM) DFD Notations

SSADM uses 4 diagramming notations in DFDs

  • Processes transform or manipulate data. Each box has a unique number as identifier (top left) and a unique name (an imperative - eg: 'do this' - statement in the main box area) The top line is used for the location of, or the people responsible for, the process. 
  • Data Flows depict data/information flowing to or from a process. The arrows used to represent the flows must either start and/or end at a process box. 
  • Data Stores are some location where data is held temporarily or permanently. 
  • External Entities , also known as 'External source/recipients, are things (eg: people, machines, organisations etc.) which contribute data or information to the system or which receive data/information from it. 

DFD Levels

The 'Context Diagram ' is an overall, simplified, view of the target system, which contains only one process box, and the primary inputs and outputs.
The Context  diagram above, and the one which follows, are a first attempt at describing part of a 'Home Catalogue' sales system. In the modeling process it is likely that diagrams will be reworked and amended many times - until all parties are satisfied with the resulting model. A model can usefully be described as a co-ordinated set of diagrams.
The Top or 1st level DFD, describes the whole of the target system. 

The Top levelDFD 'bounds' the system -and shows the major processes which are included within the system.

Each Process box in the Top Level diagram may itself be made up of a number of processes, and where this is the case, the process box will be decomposed as a second level diagram.
Any box in the second level decomposition may be decomposed to a third level. Very complex systems may possibly require decomposition of some boxes to further levels.

Decomposition stops when a process box can be described with an Elementary Function Description using, for example, pseudocode.
Each box in a diagram has an identification number (derived from the parent - the Context level is seen as box 0) in the top left corner.


C.Ashworth & M.Goodland (1990) ' SSADM A Practical Approach', McGraw-Hill.

D.E.Avison & G.Fitzgerald (1991) 'Information Systems Development', Blackwell.

David A. Marca (1988), 'SADT. Structured Analysis and Design Technique', McGraw-Hill.

Tony Drewry
Tony's Home Page
Back to TOP