Academics write a lot: paper and books and lecture notes. The fruits of industrial knowledge are usually locked inside people's experiences, or where written are usually confidential. However, the products they produce are an important source of knowledge. Your client's request may be "I have a system that does such and such, but doesn't do it very well, I want a better one". In this case, the existing product may be one of your most important sources of domain information. In addition, you can look at similar products, both marketed ones and those produced as the product of previous research (including previous projects).
As mentioned earlier, there are other things that people make as well as software products: procedures, organisational structures, physical things as well. I will use the world 'artefact' to cover all these.
Whenever you consider a word-processor, database package, aeroplane or any other artefact, they all in some way embody the accumulated experience of their makers. This is particularly obvious in traditional hand crafts, but is also true of more industrialised products. Often this knowledge is unwritten and as discussed earlier, they may not be able to explain it when asked.
If you ignore the experience locked up inside existing artefacts, you are likely to make the same mistakes that the previous systems made or at best correct some, but make other things worse. To unlock this implicit knowledge you need to analyse the artefact.
First ascertain exactly which features are good or bad. Usually a system is not all bad! having done that ask yourself why. For example, given a database interface, you might decide that it is bad because there are some queries which it cannot perform, but that the graphical interface is pleasant to use. If there is a bad feature look twice at it. Why is it that way. Did the designers simply not notice or is it due to some other factor. It may be due to some constraint that no longer holds, or due to something that you might have otherwise not considered. Finding out why something is wrong is the first step to making it better.
These why question are very important, and the deeper you ask, the more you understand the situation. Implicit in any system are the theories which either support or refute it. For example, we might say an interface is good because it uses a mouse. Why? Well we could consider that this is because hand/eye control is better than typing commands. Of course, we should then ask what we mean by 'better': faster, easier, less error prone ...
Deeper understanding really does help produce good designs. Imagine you are an animal designer. You notice that crocodiles are good because they have strong jaws and you notice that elephants are good because that are big and strong. In pursuit of a new better animal you put a crocodile's head on to an elephant's body - getting a crocophant, good for nothing. In computer systems this happens all the time, understanding why something is good or bad can avoid these crocophants.
Also, if you understand why something is good at a deep level, then you may be able to find something which achieves the same end in a different context. For example, you think that graphical user interfaces are good, but want to design an interface for the blind. You ask yourself why a graphical interface is good. There are various reasons including the rapid feedback of your actions. So, you consider alternatives so that an unsighted user can experience the same rapid feedback, perhaps speaking back menu item as a mouse is moved.
In general, the deeper your understanding the greater your ability to focus on those area which need improvement and correction. Also the greater the chance that your ideas for improvement will work.
Finally, when considering existing systems remember that artefacts embody assumptions about the context in which they were developed. You might find an existing piece of software which appears to satisfy all your requirements. However, if it was designed with a different context in mind it may be inappropriate or need modification for your context.
One example of this is the trade-off between speed and memory requirements in computer algorithms. For example, in database system you might improve the speed of queries by storing lots of indices which consume a lot of disk space. Many current applications assume that RAM and disk space is cheap and so typical Windows, X and Mac applications consume many mega-bytes of memory. These may be good applications, but if you wanted an application to run on a hand-held computer then clearly the change in context requires a radical redesign.
Knowing that artefacts can tell you about the context can also help when analysing your problem domain. You ask why the existing system behaves in a particular way and the answer may uncover some aspect of the domain you had not previously noticed.
Alan Dix 12/8/97