This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
[From a game programming and planning perspective, how do you legislate for... fun? Veteran game coder Hammersley discusses how you might split game technical planning into 'must-have' features and 'non-functional requirements' that enhance the game's fun factor.]
Development slippage is a key problem in the software industry. This is often because development time is wasted on developing features that are not needed, or attempting to determine what we need whilst we build it.
This is due to insufficient requirements engineering. There is a commonly encountered belief that requirements engineering for games is difficult, if not impossible.
I argue that this is not the case, and that we can succeed in requirements engineering in the games development industry. Requirements engineering provides us the cheapest and most effective way of determining what we need to build, saving development time and cost.
The first part of this article challenges the view that requirements engineering cannot be easily practiced in games development and discusses the surrounding issues; the second part will discuss requirements engineering best practices and how it fits into the development process.
The common reasons for this belief are:
I argue that this is not widely the case for a number of reasons.
Let me describe a typical development scenario. Firstly, the designer writes a detailed specification of the solution to a feature. The programmer attempts to slavishly implement the feature to the letter of that specification.
In doing so, he runs into many problems. He finds it difficult to solve problems that are not addressed by this solution, as only the solution is described, not the solution rationale or original problem.
A lot of time is then spent iterating on and refining the implemented solution. Subsequently, we conclude that requirements engineering is difficult or impractical and we are not convinced of the value.
The mistake we have made is that we have specified a solution, not a requirement. Whilst requirements and solutions appear superficially similar, there is an important difference that we must understand. A requirement states the problem to solve or a need that exists and why it exists; a solution tells us how to go about solving that problem or need.
It can be compelling to write solutions instead of requirements. It is tempting to design a solution to a requirement at the same time as writing the requirement -- especially the interesting ones! Writing solutions feels more authoritative, more formal, more precise and more accurate. But it is counterproductive.
We must ensure that we specify requirements for the features of the game, not solutions to those requirements. We need to specify the essence of the problem we must solve, and why we have to solve it, not a possible solution to it (Robertson & Robertson, p165).
By prescribing a given solution, we preclude any potential superior solutions. Prescribing solutions also limits our understanding of the problem domain and intent of the requirement.
We also rob ourselves of the opportunity to test whether we have solved the original problem; we can merely test whether we have implemented the prescribed solution satisfactorily.