In the course of developing a system, the analyst's understanding of the system will change in light of the analysis they do. The same is probably true of the customer. So in the course of analysing a system, the analyst will often make several versions of each type of model — either building upon earlier ones or even throwing old ones away and starting again. It makes sense then to have models which are reasonably cheap and can be developed and maintained without too much cost and time overhead.

For this reason the models often take the form of diagrams, pictures and text which can be printed on paper or drawn on a white-board. This makes them very cheap! Occasionally, more sophisticated models are used, such as software prototypes in the prototyping life-cycle model.

The models used should also be easy to change. Re-writing or re-drawing models by hand is tedious, and CASE software tools (Computer Aided Software Engineering tools, see Chapter 2, Process and Model) can be used to relieve the burden of producing models. More fundamentally though, the models themselves should be such that adding or removing detail does not have many repercussions on other, distant parts of the model. In most cases this means that the model should not represent the same piece of information in two different places. This property of reducing multiple representations of the same thing is called minimal redundancy. The property of changes to part of a model having minimal repercussions on other parts is called low viscosity or robustness to changes. A good model will usually have both minimal redundancy and be robust to changes.

Having decided to produce models on paper, we have the choice between graphical representations of the system or textual descriptions.

It is possible to describe a system entirely in words. There are some problems with this, the biggest being that for a large system, a huge number of words will be needed. A developer trying to find technical descriptions and design decisions would be lost in a maze of words. It would also require a huge time investment for the customer to check over such a document. This is clearly not practical.

Instead, for many modelling techniques, graphics make up the largest part of the model. A diagram, by using good notation, can represent a large amount of information in a form that is easy to grasp and, more usefully, can be put on a single sheet of paper.

So what characterises good notation? Some suggestions would be that each object in the diagram means something so that there is not much unnecessary clutter caused by objects with little or no meaning. Also, the objects themselves should have well-defined features so that there is little or no ambiguity. Different types of features of a system should be represented by different symbols, so that it is immediately clear what the parts of the diagram mean.

Using graphics does not mean that no text is used at all. In some places text is the best thing to use; indeed, graphics and text can play a supporting role for each other, clarifying or explaining portions which the other would be too tedious to use (such as with use case diagrams, described in Chapter 3, Requirements Engineering).

As discussed at the beginning of this section, the models need to be understood by many people: the customers, the developers, as well as the analysts and designers themselves. If it takes a long time to explain what the models mean, then much unnecessary time will be waisted. Good models should be clear and simple.

The ideal is for models to be well drawn and easy to understand — no explanation of them should be necessary at all. As a rule, a model drawn by an analyst which the analyst themself finds both complicated and unclear will be difficult to understand by others.