SYSTEM DESIGN SEQUENCE
SYS364
Page 1 of 2
One of the most useful things that other designers have learned from information system designers is "the last will
come first" approach that we take: focus first on the end-product you seek!
The whole point of any information processing system is the creation of information for the decision makers! So the
most natural place to start when designing a system is the design of its Outputs. Output design involves several media
and several types of thinking: logical groupings, aesthetic appearances, layout to assist subsequent tasks, etc. This
means that you can adapt your work to the mood you're in at the moment, but still stay involved and productive with
what the eventual system should be achieving.
Once you're satisfied that you have all the system's outputs designed, you can move ahead to where all this
information is going to originate, and start designing the Inputs to the system. These may be forms, or input screens,
or outputs of other systems. Because you've already defined the outputs, you will be in great shape to consider the
input sources. Something that will make the whole process cyclic is that sooner or later in the design of input screens
or forms, you'll recognize the need for more outputs: the diagnostic messages or reports which reject inappropriate
input.
Designing the outputs and inputs effectively means that you have effectively defined the "user interface", because
these are the parts of the system that will be exposed to the users! Of course, if the input is being gathered through
interactive online dialogues, there will be more to the user interface design than just the individual input fields and
output fields. Especially if there is to be input validation, there will have to be "dictionary" or "master" files
available to test new input for correspondence to historical or de facto standards.
Once all the inputs and outputs have been designed, you're in good shape to start designing the files (or databases)
that will be needed as "bridges in time" to save the input data until it's needed for manipulating into shape for output.
What comes next would seem to be the processes (programs or procedures) which will convert the input data (and
stored input) into the information needed for output. Certainly some of these processes will seem obvious. Some of
them will be as trivial as sorting input into a new sequence, or collating related information from different input
sources. Some of them will involve summarizing, but that always implies sorting raw data or processed data into the
clumps or categories which belong together in a summary. Some of the processes will be less obvious.
However, there is another aspect of the system design which probably needs defining before you design the
processes: the controls which need to be applied to ensure that the collected input is accurate, complete, and
authorized; the controls which need to be applied to ensure that the output will reach all of the people who need it,
and only those people authorized to receive it; the controls needed to ensure that the processing techniques are
applied to all the data uniformly, and only to data for which those techniques are appropriate.
So far, the design sequence is thus the following:
1.
2.
3.
4.
5.
Output (reports, screens, messages)
Input (forms, screens, dialogues)
Files (and/or databases)
Controls (for input, for output, for file integrity, for processes)
Processes (whether computer programs, clerical procedures, or non-computer automated procedures)
What is missing here is any sense of how all these designs fit together! The tool that will provide insight into this
interconnection is a set of Data Flow Diagrams. (Or their historical predecessor, the System Chart). The other tool
which will help with every stage of the design is the Data Dictionary. Fortunately, the Data Dictionary is a painless
by-product of designing outputs, inputs, and files!
There have always been several schools of thought about where in the sequence to put the design of the DFDs (or
SysChart) and the development of the Data Dictionary. Some system designers start with a tentative SysChart, and
modify it as they go along, refining the designs for Outputs, Inputs, Data Stores, Controls, and Processes. Others
leave the DFDs or SysChart until they begin the design of Controls. Others have no more than a mental draft
(unrecorded) until they've designed the Processes. Each of you will no doubt establish your own preferences, and
vary them for different types of systems with particular features which influence your choice of sequence. Almost all
system designers treat the development of the Data Dictionary as an evolving by-product of other design activities.
SYSTEM DESIGN SEQUENCE
SYS364
Page 2 of 2
A very real danger in the design of systems is the premature adoption of a DFD set or SysChart. Too often, it will be
based on the present system which the new system is to replace, for good and well-considered reasons! The danger
is particularly vile in the case of DFDs, because their whole numbering system is based on an overview of something
that doesn't yet exist!
A potential system design sequence is thus the following:
1. Design Outputs
2. Design Inputs
3.
4.
5.
6.
7.
Design Data Stores
Design Controls
Sketch Data Flow
Design Processes
Revise Data Flow
1a.
2a.
2b.
2c.
3a.
4a.
Start Data Dictionary
Add to Data Dictionary
Design Input Validation
Add to Output Designs
Add to Data Dictionary
Revise Outputs, Inputs, Stores, DD
6a. Design Process Controls
CASE tools such as Rational Rose are often used in this process. MS-Excel or Word are very handy tools with which
to maintain a basic Data Dictionary. I prefer Excel because it is more of a 'database' tool. Word has basic drawing
tools built into that can be used for DFDs.
Process Control Systems
In all of the above, we have been assuming routine business systems are involved (like Order Processing, Inventory
Control, Purchasing, Sales Analysis, Accounts Payable, etc.), and that the input data involved is being captured by
pencil and paper or keyboard, and the information being output is delivered to humans via report or display.
However, there are systems which involve less human-dependent Input/Output! Perhaps some of the input will be
provided by devices instead of people, perhaps some of the output will actually control devices instead of merely
inform people! Business systems analysts often encounter these kinds of computer-based system, as for example in
the systems which are driven by point-of-sale scanners and will control cash registers. The biggest difference is the
extent of the controls which must be exerted. Thankfully, most such systems are most productively designed in the
same sequence as the more familiar human-oriented systems!