Quite often the requirements are uncertain, i.e. ideas are not clear about what the required software should look and behave. Telling the programmer to do what he thinks is the best thing results in a design that may be quite elegant and maintainable but that probably is not satisfying at all for the user. Only the user can really say the last word about which feature are useful and which are not. Only the user, or a person that observes the user’s behavior, can say if a user interface is really usable or not.
Too often a system is built according reasonable requirements and then abandoned or heavily changed because the original requirements resulted in an unusable system. Of course a way to minimize the cost of such am outcome is to build a highly maintainable system, that may be changed rather easily. Another way is keeping the user informed of the progress of the development, so that any change of mind may be incorporated early in the development process.
These cited two techniques (maintainability, and continuous feedback) are advisable in any case, but another technique is advisable to ease a better requirements specification: prototyping.
In the software engineering world, the word prototyping means building a software system for the sole purpose of demonstrating the feasibility of a system, and evaluating its impact. Using a building simile, it is like building a scale model.
The simile is not perfect because a scale model is not a real building, while a prototype of a software system is a real software system. A prototype differs from the real system for the following aspects:
- A prototype is built using a rapid application development tool, that eases development at the expense of the flexibility, testability and maintainability of a software system built to endure time.
- A prototype does not really work with real data. The user may insert his input data, but when he asks the results of the computation or of the query, the prototype shows always the same precomputed date, without performing any computation and any database connection.
- Some buttons or menu items are mock, with no performed command.
- The user interface is not internationalized.
- The software is not configurable.
- Only the most typical scenarios are shown.
- Prototypes are not formally tested, only shown to the user to get feedback.
But the most important thing to say about prototypes is that the software written to build a prototype should be thrown away and not reused for the real system, as it is tempting. To avoid such temptation, it is advisable to use different development tools or programming languages for the prototype and for the real system.