When you have a requirements document, if you have a very small and simple task, you may start immediately to write your program. It is very improbable to have a very small and simple completely new project, though. The chances are that your task lays is one of the following cases: a rather complex to very complex completely new project; or a maintenance issue of an existing project; or an adaptation of an existing project for another client or another situation.
Only for a small and simple issue or for a small and simple adaptation it is advisable to start coding immediately after getting the requirements document. For not-so-small (i.e. from rather lengthy to very lengthy) or not-so-simple (i.e. from rather hard to very hard) maintenance issues or adaptations, and for every completely new projects, it is advisable to do a preliminary work before starting to code the actual software. The preliminary work consists of two steps: architectural design and automation tests construction.
The architectural software design (from here simply “design”) has nothing to do with the stylistic look of the windows or of the printouts. Actually it is a high-level definition of the software system to build. The design is the abstract definition of how the source code will be organized, that is which files, which classes and methods if object-oriented, which global data structures and free-standing routines if not object-oriented, and which non-trivial algorithms are to be defined.
Such definitions may be written in plain natural language or, better, in a formal graphical formalism, like UML. Anyway the design is not targeted to laymen, and therefore a technical jargon may be used.
While the requirements document describes what the required software should do, the design documents describe how the required software should do it.
When a design document has been prepared, the automation tests construction may begin.
Another article will describe what are automated tests.
Another important concepts is that of iterative development. We said that software construction should begin with the analysis of the previous situation, proceed with the definition of the desired situation, and then with the definition of a design, and then continue with other steps. Actually this is not a one-way path, but very often a situation causes to fall back to a previous step. For example, when defining the design, a doubt about the requirements may emerge, and therefore the development process should go back to the requirements stage. After having changed the requirements document, possibly all the design may to affected, and therefore every part of the design should be reconsidered after a change of requirements. When coding, a change of design may be required, and that change may cause all the code to be reconsidered.
Therefore the software development process is composed of several stages. When a stage is complete the following stage may begins. Every stage bases its work on the results of the previous stage. At any moment the development process may jump back to a previous stage. After a stage is changed, every previously work done on the following stages must be reconsidered.
This development process is named “waterfall with feedback”.