Usually it is a good idea to have some idea where you are going before leaving on a journey. The process of creating any non-trivial computer program works the same way. Before you just "dive in" and just begin coding, it helps to have some clearly defined objectives. In the process of software development this is often called "requirements".
The Requirements Document describes what is expected from the program to be created. Sometimes a Requirements Document can be extremely detailed, showing the artwork (images, backgrounds, colors and even the shapes of the user interface controls), and the exact flow or sequence of interactions. Other times they can may be more "loose", giving only a general idea of what is expected. In the professional world of software development there is a process known as the "Waterfall Method". In this development process almost all of the design and planning happens before any code is written. This practice has been heavily used since the 1960's. The challenges of the Waterfall Method is that most people do not really know enough about what they really want before a software project begins. It is hard work to think through and document to that level of detail. Because of that hard work involved it takes time and in many cases can be seen as "heavyweight" and expensive. Furthermore, it often turns out that by the time the program is completed the original requirements may be seen as incorrect or needing to change. Going back and rewriting software can be expensive.
An alternative development process that started to become adopted is called "Agile Development". The Agile process assumes that the requirements will be incomplete, inaccurate and will often change while the software is being created. Responding to this high level of flexibility is difficult for many development teams and can also lead seemingly endless rework cycles.
This author has learned that an agile process gives more benefits that risks. In some cases software design has to be carefully considered. Waterfall can be the right choice too. This is especially true when there can be no error. An example of a successful Waterfall Process being adopted would be in the design of the software that was used to operate NASA's space shuttle. Error can lead to loss of substantial scale, including human life. For projects like that everything is planned out in exquisite detail before a single line of code is written. As you may imagine, this is also expensive. Most software projects do not require that level of certainty. Nor can they afford it. For example, if you were writing an algorithm for searching the Internet, it would be completely acceptable to give quicker results that are very close but maybe not include all possible solutions.
The process being followed for the development of the game described here aligns more closely with allowing an in-exact definition of work and makes the assumption that changes to what is wanted from the program will be natural as it is developed. What follows here then is one form of a Requirements Document that describes for the developer what is expected from the program yet to be written. In this case no attempt is made to describe colors and images to be used in the finished program. Rather, the focus of this Requirements Document is to describe what the developer needs to know to begin to design the Object Models that should be included as part of the overall program design.