Introduction

A comprehensive introduction to Input Process Output tables. Learn how to effectively model the important processing going on in your system.

One of the first things we need to do in software development is understand the problem. We can't begin to plan the most effective solution until we properly understand what it is we are trying to solve. Input Process Output tables, or IPO tables for short, are an effective way to model the important processing going on in your system.

Let's consider the three parts of the table:

• Output - A piece of information which we want.
• Input - Data which is required in order to create the required outputs.
• Process - The steps involved in creating the outputs from the inputs.

An Input Process Output table then is a table listing what inputs are required to create a set of desired outputs and the processing required to make that transformation occur. Here is a simple example for calculating an average of a set of numbers:

Calculate average

Input	Process	Output
List of numbers	Add the numbers together Divide the sum by the total number of numbers.	Average

Notice there are many things missing here. We say nothing about how the output is displayed or what is done with it. We don't mention where the inputs came from. Actions are largely ignored. With an IPO table we are interested in data and little else. This helps us to be very specific and not get distracted by other details.

On the rest of this page I will explain my take on how Input Process Output tables should be used in software design and development. There is no official way they are to be used or implemented however so you will come across other ways of implementing them and you are more than welcome to deviate from what I have explained here if you feel it better helps you achieve your goals.

There are several examples of IPO tables on this page. Some of them are examples of what not to do. Those are listed with a red heading. Correctly implemented tables are listed with a blue heading.

Laying out your IPO tables

There are several different methods for displaying IPO tables. Some people prefer to list the items vertically instead of horizontally for instance. However you choose to display them is fine, the underlying principle of what they convey will still be the same. The layout described here is one which I find particularly easy to read.

This layout makes it easy to follow the flow of data from Input, through the processing to the final Output. Items are listed in chronological order. Inputs line up with the top of the processing. The output lines up with the final bit of processing which leads to it's creation. There should also be a descriptive heading on the table to label what the IPO table actually represents.

The language used for describing the processing is also important. It should be non technical. IPO tables are intended to help us define and understand the problem. They will be created by the developer and shown to the client or key actors to verify that the developers understanding of the problem is accurate and whole. Often these people do not have a software development background. It is essential that the processing is written in a way that they can fully understand what is going on. Avoid pseudocode in describing your processing.

Manage crossing light

Input	Process	Output
number of times pedestrian crossing button pressed, an array of state of traffic lights at the intersection	if number of times button pressed is greater than 0 set crossing light to true for light in traffic lights array if light is green or amber set crossing light to false	crossing light on or off

This would make perfect sense to someone with programming experience but could be quite confusing to others. It is ok to have decisions and repetition in your processing but they should be described in general terms rather than algorithmically. Here is a better way to do it:

Manage crossing light

Input	Process	Output
number of times pedestrian crossing button pressed, state of traffic lights at the intersection	If the button has been pressed more than once and all of the traffic lights are red then make the crossing light true. Otherwise make it false.	crossing light on or off

Two types of processes

When thinking about software development we can divide processes into two types. Those which are part of the problem, and those which are part of the implementation of the solution. Let's look at an example to illustrate what is meant by this.

If we are going to make a simple calculator then the processes of addition, subtraction, multiplication and division would be processes which are part of the problem. They are defined before we even start considering the solution.

How we decide to manage a history of calculations performed, eg. as an array of records, is an implementation process however. It is something we think about when planning how we are going to build the calculator.

What do we model with an IPO table?

Any process may be explored through an IPO table but if we say that it's purpose is to help us better understand and define the problem then this gives us guidance as to which processes would be better to model. Ideally we want to model processes representing the problem. Processes which are part of implementing the solution are generally better explained using algorithms.

If we are modelling a problem for which a computerised solution is to be created then major processes and things involving calculations should be modelled. Other aspects of the problem may be modelled considering how important they are to understanding the underlying principle of the problem.

If we are modelling an existing system from which to create a new or improved system then we probably want to model more processes within the system (virtually all processing is part of the problem) but still take into account the comments in the previous paragraph.

Deciding if a process is part of the problem or solution can sometimes be tricky, especially for certain types of things such as games. An easy way to help you decide is to think about what would happen if you were to implement a paper based solution instead of a computerised one. If the process would still be done with pen and paper it is probably something valuable to express in an IPO table.

As an example of this, lets consider a game of Tic Tac Toe. Even if playing the game on paper the process of determining if someone has won the game is still required. This is something we should therefore model.

Has player won?

Input	Process	Output
Location of pieces on the board	See if any row has all the pieces the same type. See if any column has all the pieces the same type. See if any of the diagonals have all the pieces of the same type. If any of these are true then someone has won. Otherwise, no winner yet.	Has a player won?

Other processes however such as how the players will input where their pieces are to go or how we go about rendering the board on the screen are processes which we wouldn't consider when playing with pen and paper so they are not part of the problem.

Don't worry that you are not modelling all of the system. You will probably only model a small and fragmented aspect of the system through the IPO diagrams. This is ok. Each diagram, table or chart, IPO's included, is only intended to model a certain aspect of the problem or solution.

Information not actions

A common mistake when creating IPO tables is to specify actions as either your Inputs or Outputs. For example an input may be listed as player wins game. This is incorrect as it is not an input but an event that occurs which triggers the processing. In an IPO we are not concerned with what triggers the processing (that will be looked at in other diagrams). We are only concerned with what information is to be created and what data is required in order to do this. Maybe the processing involves calculating a final score once the player has finished the game. The inputs then will be whatever details are required in order to calculate this high score. This may be for instance, player health, time taken, bonuses collected etc. Instead of:

End game

Input	Process	Output
Player wins game	Calculate the score. Clear the screen. Play a game over sound.	Display a game over screen and the final score.

Which is incorrect. The input is an action. The output does have data within it but it is more about how the data is displayed. We only want the data listed in an IPO table. How it is to be displayed is something which should be modelled using prototypes or screen designs. The processing also involves actions which will be performed but are not actually part of producing the output. A more correct IPO would be:

Calculate final score

Input	Process	Output
Player health, time taken, bonuses collected	Multiply the player health by 20. Minus the time taken. Multiply the number of bonuses by 5 and add to the total.	Final score

Your inputs and outputs should be categorised as either a data type (integer, float, string, boolean) or data structure (arrays or records) or a file with data in it.

The big picture

So how do Input Process Output tables fit into the big picture of software design and development?

IPO tables are a valuable tool to help you define and understand the problem. This may be one for which a computerised solution is to be created. Alternatively it may be an existing system which is to be replaced or improved. IPO tables will help you identify and understand the major processes that exist or need to exist. IPO tables look at these processes in isolation. These processes can then be linked together, by looking for matches between the inputs of a process and the corresponding outputs of other processes which will be represented by way of Data Flow Diagrams. The details of these tables will also help when creating algorithms for the final solution.

Summary

Activities

Pick a sport and create a set of IPO tables that would be required if you were going to develop a piece of software to manage scoring for a game.