[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.