The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.[1]
In traditional software development, requirements engineering involves a dialogue between software designers/developers and the various stakeholders; e.g. client, users, etc.
The process is slightly different for games. Game design and development incorporates game design in addition to software design and development. Game design is often considered a "pre-production" phase that results in a Game Design Document (GDD); this document, which is often over 100 pages, describes the game in detail. It should answer any and all questions about the game and how it is played. It includes the story, game mechanics, character descriptions, concept art, market analysis, feasibiliy analysis, a production schedule, etc.
The requirement process in games, therefore, has two steps. The game designers elicits requirements from external stakeholders such as the client and users. The designers assimilate the results together with their game design and background research in the GDD. Software engineers then collaborate with the designers to convert the GDD into a software requirements specification (SRS).
Every time we showed the game, either internally or to ngmoco, the reply would always be "That's great! Wouldn't it be cool to do this, too?" We got lots of great ideas to improve upon the game; no single one was very big or time-intensive, but they certainly began to add up.But Callel etal. [4] report that these problems are often exaggerated in games. One reason they point to is that requirements often emerge late in the development cycle. For example, new gameplay requirements may emerge as a result of gameplay testing and new technical requirements may emerge as content is integrated into the game.
Callele etal. also argue that the requirements engineering process between the game designer and the software team is often problematic because the GDD contains many implied requirements; ones that can missed in developing the SRS.
The process begins with the development of the "game vision," which describes top level features of the game including what it is about, the main mechanics, look and feel, etc. It also identifies inital requirements including technical (e.g. platform), quality (e.g. replayability), client (e.g. learning objectives), and user (e.g. age group, computer literacy) requirements. In contrast to the game design document, the game vision is relatively short (8-11 pages).
At the start of an iteration the current "requirements backlog," is reviewed and prioritized. Requirements for the iteration, i.e. the next slice of game, are identified and elaborated. Design, development, documentation and testing proceed. The end product is evaluated and the requirements backlog is updated to eliminate completed or invalidated requirements and to add newly identified requirements. The process repeats. In an iterative development process, the GDD is a living document that emerges over the course of development and is finished at roughly the same time as development.
Is iterative development a panacea? No. Can it help? We'll look for the answer to that question on
your final exam.
[1] Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering.
[2] E. Bethke, Game Development and Production, Wordware Publishing, 2003.
[3]Chris Linder, Justin Lokey, Stephanie Morgan, Postmortem: ngmoco/Demiurge Studios' WordFu
[4] David Callele, Eric Neufeld, Kevin Schneider, Requirements Engineering and the Creative Process in the Video Game Industry.
[5] Thomas Demachy, Extreme Game Development: Right on Time, Every Time, Gamasutra, July 2003.
[6] Rory McGuire, Paper Burns: Game Design with Agile Methodologies, Gamasutra, June 2006.
[7] Clinton Keith, Beyond Scrum: Lean and Kamban for Game Developers, Gamasutra, November 2008.
[8] Johannes Norneby, Tobias Olsson, A New Attitude to Game Engineering: Embrace Change, Re-use, Fun, Gamasutra, August 2009.
[9] Paul Miller, Top 10 Pitfalls of Using Scrum Methodology for Video Game Development, Gamasutra, July 2008.