Gamasutra is part of the Informa Tech Division of Informa PLC

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.

Gamasutra: The Art & Business of Making Gamesspacer
Planning For Fun In Game Programming - Part 2
View All     RSS
September 21, 2020
arrowPress Releases
September 21, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Planning For Fun In Game Programming - Part 2

June 24, 2009 Article Start Previous Page 2 of 4 Next

Requirements Engineering and the Development Process

Requirements engineering is one of the earliest development processes and the building block for many further processes. Requirements engineering discovers and defines what functionality we need to build, what needs and problems we need to address and the characteristics of the resulting game.

From this understanding, detailed design can design a solution to those requirements. We can plan a project to build this design. We can schedule the tasks needed to implement this design. And finally, once this design is implemented, our requirements specification can be used to test whether this implementation satisfies our project goals.

We can see that requirements engineering therefore plays a major role in the development process, driving the direction of the project. Requirements engineering isn't a one-time task; we can practice it at any point in development to define and guide planning, implementation and testing.

The Source of Requirements

As noted in my previous article, there is one significant difference between the games industry and mainstream IT with regards to requirements engineering: the analysis of real-world domains versus virtual, created domains.

In the games industry, we work in two domains: the real world domain, related to tools engineering, server engineering and supporting artists versus the virtual domain that we create and build our games inside.

This has significant implications for requirements engineering. Mainstream requirements engineering practices rely on the identification of Business Use Cases (Robertson & Robertson p87). These use cases describe the work done in the real world domain to achieve a given goal. These are then decomposed into a Product Use Case (Robertson & Robertson p87), describing the part of that work that the product will do.

In our game's virtual domain we have no business use cases. Furthermore, product use cases make no sense as everything is contained within our games. We need a new source to identify our requirements.

Two things fill this void: the high-level game design, and the development team. Our high level game design provides a global overview of our product. It describes the overall structure and scope of the product in addition to direction on the basic functionality of some features.

Ultimately, we must remember that the development team creates this high level design; they are the true and ultimate source of requirements on our product. The tendency to practice requirements engineering informally, as spontaneous discussion between programmers and designers illustrates this.

Requirements engineering serves as a means of agreeing on and communicating ideas within our team, as opposed to communicating an understanding of a domain foreign to the development team, as in mainstream IT.

Requirements and Reusability

We often find that a new game needs a very similar piece of code to some existing code. We attempt to reuse this piece of code directly, or change it to our new purpose. We often find, however, that this is not successful, typically blaming it on poor code and subsequently rewrite or reimplement the code.

Is poor code or design really the fundamental reason for failure? A piece of code is a direct solution to a set of requirements. Superficially it may appear a good candidate for reuse, but it was written to solve a different problem. The code subsequently proves difficult to use, or difficult to refactor, and we end up writing new code to solve a similar but slightly different problem.

Are we in fact addressing the wrong end of the development process? Can we expect a piece of code that is a solution to another problem to be readily usable as a solution to another, potentially subtly but significantly different problem? Code reuse can only succeed if the requirements are sufficiently similar between both cases.

Requirements engineering is therefore the basis of reusable code. Requirements engineering can allow us to identify potential code reuse candidates through comparison of requirements. A well-chosen set of requirements can lead more reusable code by ensuring a solution implements flexibility in key areas. Finally, requirements themselves can be directly reused (Robertson & Robertson pp303-317), directly identifying and encapsulating chunks of a game product that can be reused from one game to another.

What about Agile?

Agile methods are becoming increasingly widely practiced in games development. It is tempting to assume that requirements engineering conflicts with agile development principles.

Requirements engineering is often perceived as awkward, formal documentation, or a burdensome process preceding implementation. Agile methodologies promote working software and individual interactions over these types of behaviour. There appears to be a conflict between requirements engineering and agile methodologies.

This is not the case: software development always consists of the same basic activities; agile methodologies present a different, and possibly more effective way of doing them. We cannot abandon our need for an accurate description and understanding of the functionality we need to build to make our game a success.

Requirements engineering can be incorporated within agile methods by employing alternative, less formal methods and techniques. The purpose of requirements engineering is to ensure we build the right product; agile methodologies propose alternative methods to construct the product more efficiently and ensure it meets customer demands. Therefore, requirements engineering and agile methodologies complement each other.

Finally, agile processes frequently employ close customer collaboration. This is good practice; however, we need to be mindful of how we are employing the customer. Customer collaboration with a view to eliciting, understanding and verifying the customer's needs and requirements is good practice; employing the customer as a surrogate for good design or requirements engineering is a bad practice.

Article Start Previous Page 2 of 4 Next

Related Jobs

Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Engine Programmer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Technical Designer
Random42 — London, England, United Kingdom

UE4 Technical Artist
Evil Empire
Evil Empire — Bordeaux, France

Senior Technical Developer

Loading Comments

loader image