One of the Most Useful Things That Other Designers Have Learned from Information System

SYS364SYSTEM DESIGN SEQUENCEPage 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. Output (reports, screens, messages)

2. Input (forms, screens, dialogues)

3. Files (and/or databases)

4. Controls (for input, for output, for file integrity, for processes)

5. 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.

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 Outputs1a. Start Data Dictionary

2. Design Inputs2a. Add to Data Dictionary

2b. Design Input Validation

2c. Add to Output Designs

3. Design Data Stores3a. Add to Data Dictionary

4. Design Controls4a. Revise Outputs, Inputs, Stores, DD

5. Sketch Data Flow

6. Design Processes6a. Design Process Controls

7. Revise Data Flow

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!