[How do you legislate for fun from a game planning and programming perspective? Following on from his analysis of the problem, veteran game coder Tom Hammersley proposes a solution that includes 'apprenticing', use cases, storyboards, and more.]

Introduction

Requirements engineering is a core software engineering activity driving design and implementation of our games. Time spent on an effective requirements engineering process saves time, effort and cost by focusing on building only the features important and relevant to the success of the project.

Requirements engineering focuses on identifying and understanding the features and characteristics of a game most important to the customer and defines what our software must do to satisfy them. A solid requirements engineering process prevents time wasted by chasing and resolving uncertainties and defines a clear path for development.

My previous article discussed and challenged some of the assumptions regarding requirements engineering in games. This article will discuss the core requirements engineering practices and how they can be integrated into the development process in the context of the games industry -- and practiced.

Requirements Engineering

Requirements engineering is the practice of determining what functionality and qualities or properties the game we are building needs to make it a success. Requirements engineering produces a comprehensive specification describing the game we need to build, why those features and qualities matter, and how to test the resulting game against that specification.

Perhaps unintuitively, this specification is not a design for the game; it specifies the problems we need to solve, the functionality we must have and the characteristics the game must have but not any prescribed solutions or implementations. The requirements specification represents a shared consensus and understanding of the game we are building; it communicates a common vision to the developers free of the restraint of specific technologies.

The individual requirements in the specification are statements of either functionality the game must have, or characteristics of how that functionality works. These types of requirements are known as functional and nonfunctional requirements respectively.

Ultimately, these requirements all come from stakeholders on the project (Robertson & Robertson p45). These stakeholders could be people such as artists, requiring functionality from the game to realize their vision, or designers, who have the creative vision of how the whole game will fit together.

These requirements are subsequently used in a number of ways:

• As a guide to implementation
• To estimate and schedule the work needed to complete the project
• To ensure the resulting implementation satisfies the goals of the requirement

Basic Structure of a Requirement

All good requirements have the same basic components.

Requirement Statement

All requirements must fundamentally consist of a statement describing what a feature must do or qualities it must have. The key to a good requirements statement is to avoid mandating any particular solution or technology unless absolutely necessary; we need to restrict ourselves to a statement of a need or a problem to solve.

This gives us the widest scope possible to find the best solution to this need. Clearly, however, it will be necessary on some occasions to specify certain types of solution or technologies. We can incorporate these as constraints on the solution (Robertson & Robertson p10).

Rationale

A requirements statement alone often does not capture sufficient meaning. It may be clear to a user, games designer or other stakeholder why a particular feature is needed, but this reason is often lost when the task is assigned to a programmer who may be several levels removed. Incorporating a statement of the rationale behind the requirement helps the programmer understand the purpose of a requirement, ensure that their solution fits the spirit of the requirement, and understand how this requirement fits within the overall product.

Fit Criterion

There is often more than one acceptable solution to a given problem. How do we know if we have an acceptable solution to the requirement? We specify a fit criterion to measure our solution against.

The fit criterion is a test, or measure that we devise to test if or how well a solution meets our requirement. Essentially we state an outcome that the solution must achieve. Functional requirements either successfully or unsuccessfully meet the fit criterion; non-functional requirements generally use some scale or measure to see how successfully they are met with a minimum standard or range.

The fit criterion works with the requirement statement and rationale to provide a coherent understanding of what needs to be implemented. Furthermore, a fit criterion helps us to avoid prescribing solutions in our requirements statement; often, we prescribe solutions as a means to getting the output that we desire. By incorporating this information into the fit criterion, we get the desired result and leave a wide scope for possible solutions.