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.
[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.
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.
Requirements Engineering Practices
Requirements engineering practices generally focus on
communication and analysis. The general principle underlying these practices is
to form an understanding of a stakeholder's needs, construct a description
agreed by all stakeholders and communicate this to the development team and
test team.
Given that the games industry works in two different
domains, we need to consider different requirements for engineering practices according
to the particular domain we are working in.
Apprenticing
Apprenticing involves a programmer or designer sitting with
a user and learning how to perform some piece of work or process. The objective
is to understand the issues and problems faced by the user that are not easily
anticipated, understood or readily communicated in other fashions. This
technique has three benefits:
Increased understanding of the real problems and
issues facing the user rather than those assumed.
The opportunity to identify useful new features
for the user and therefore functional requirements.
The opportunity to identify new nonfunctional
requirements. A dialogue box may be understandable to a programmer, or a
programmer may consider an export feature fast enough, but an artist may find
either unacceptable.
This practice is most relevant when dealing with existing
real-world domains, such as tools programming or automation.
Use Cases
Whilst there is a degree of variation in its definition, a
use case generally refers to a description of one piece of functionality as
experienced by the user. Use cases are there excellent for specifying
functional requirements.
Use cases are a versatile vehicle for communicating and
describing a series of actions. Anyone can understand a use case - designers,
programmers, artists, testers or any other stakeholders. Use cases are not
reliant on a particular technology or methodology. Use cases therefore are a
tool that can equally describe real-world functionality or virtual domain
functionality within a common framework.
The two main techniques for describing use cases are diagrams
or text. Common diagram techniques are UML activity diagrams, flow charts or
even state machines. Textual use cases can be written in the form of short
paragraphs, stories or as step-by-step scenarios. Care must be taken with
textual use cases to ensure clarity and avoid ambiguity.
Misuse Cases
These are a variation on use cases (Alexander 2003). These
seek to explain how someone could intentionally or unintentionally use a
feature incorrectly. This helps us to gain insight on how a feature may be
misused, for what motivations or causes, and how to resolve that.
The
resolution may be in two forms: we can write functional requirements describing
the actions that the game must take in this case, or we can write nonfunctional
requirements (for example, usability) describing qualities the game will have
that prevent or mitigate these problems.
Storyboards
Storyboards (Robertson & Robertson p294) are a technique
commonly used within creative industries, such as films or TVs. They are useful
for showing how a story will be told. Using scenarios for requirements is a
form of storytelling, describing the properties and broad functionality of a
feature. The key advantage of using storyboards to illustrate how something
will work to users is that they are holistic, considering both functional
requirements, nonfunctional requirements, interactions amongst users or players
and what role other systems may play.
We can even combine the storyboard technique with other
information such as artwork mood-boards. This is particularly relevant for
artwork-heavy requirements analysis, such as determining the requirements for a
wet weather special effect or an indoor lighting system.
Use Case Workshops
Use case workshops (Robertson & Robertson p113) are a
mainstream IT technique used by requirements analysts to discuss a set of use
cases with the relevant stakeholders and domain experts. Use case workshops take
the form of a forum, where use cases are discussed, debated and considered from
all perspectives.
Engaging all the relevant stakeholders in this discussion
leads to a consensus on how a particular use case works. Moreover, this forum
gives us the opportunity to discuss which use cases are related, what
functionality may be duplicated or shared and where they all fit within the
product.
It is difficult to apply this real-world analysis technique
directly when dealing with the virtual domain we are constructing for our game.
However, we often find that we do very similar practices informally; designers
often discuss and clarify a feature with a programmer individually who then
implements an appropriate solution. Typically, if another programmer raises a
similar query, the process is duplicated, or second- or third-hand information
is distributed. This informal practice is very inefficient and loses a lot of
value.
There is a place for a practice along the lines of use case
workshops in games. Game design documents are often only one expression of a
possible way a feature could work. We can augment the document with a use case
workshop where the designers explain to an audience of programmers, artists and
producers their vision of how a feature or use case should work.
This gives us many benefits. The team will have a shared
understanding of the purpose and intent of a feature, backed up by a set of
solid requirements guiding development. As all the relevant stakeholders are
together, we can ensure the best solutions are found and any possible
unfeasible solutions debated or rejected. And finally, we eliminate any Chinese
whispers effect, removing any possibility of inaccurate information being
circulated.
Goals and Softgoals
This is a technique for linking functional requirements to
nonfunctional requirements (Mylopoulos et al 2001). It is based on the concept
of goals, which are used to measure the satisfaction of a functional
requirement, and softgoals, which measure the satisfaction of a nonfunctional
requirement.
Firstly, we break down our functional requirements into
goals and subgoals. Goals are objective and discrete; we have either satisfied
them, or not. So, a functional requirement is subdivided into all the required
components of that functionality, and whether we have satisfied it or not.
Softgoals are similar to goals, but they are not black and
white, absolute measures. Instead, we measure the extent we have satisfied that
softgoal. We say we have met a softgoal when there is sufficient contribution
towards it, and insufficient contribution against it. They are therefore suited
to nonfunctional requirements, which are often subjective or relative
properties of software.
Usability is a good example. We can list requirements to
help make our software user-friendlier, but equally other non-functional
requirements such as security may make the software less easy to use. Whether
the software is ultimately considered usable is a question of the balance of
the two.
So, we use softgoals and subsoftgoals as a way of
decomposing our nonfunctional requirements and measuring our implementation or
requirements against them.
Having identified the hierarchy of possible goals, subgoals,
softgoals and subsoftgoals we then identify the relevant ones to target to
satisfy our requirements. From this set, we can identify the relationships
between them and the set we need to satisfactorily implement our features.
Object Life Histories
One of the key principles behind object-oriented development
is that any system has a number of key objects or concepts that can be implemented
as software entities. These objects will typically be created with an initial
set of conditions and then experience many interactions and events that change
their state throughout their life span.
We can represent these states, and the transitions between
them as a state machine diagram. This state machine diagram can be used to help
find functional requirements. This technique is known as Object Life Histories
(Robertson & Robertson, p296-297)
Consider the example of a car in a typical racing game. This
car may begin life on the grid, undamaged with a full tank of fuel. Throughout
the course of the race a number of events can happen to the car. For instance,
a car may run low on fuel and need to enter the pits to continue. A car may be
struck by another car and become damaged. The car may be repaired following a
visit to the pits. This set of example illustrates states (initial state,
damaged state) and events (refuel, hit by another car) serving as transitions
between those states.
We can use the states and transitions between states to
discover functional requirements. For instance, the ability to repair damage to
a car during a pit stop is a functional requirement. The ability for the car to
become damaged following a collision is a nonfunctional requirement.
By
adopting a different perspective of what could happen to an object during its
lifetime, rather than the use-case oriented view of what changes we can affect
to an object we can discover a whole new set of requirements that we may
otherwise miss.
Volere Template
The Volere Template is a comprehensive document detailing a
requirements specification template covering all aspects of the requirements
engineering process, developed by James and Suzanne Robertson.
The template
contains sections covering issues such as the driving forces behind a project,
the project's constraints, functional requirements, non-functional requirements
and project issues.
The Volere Template is a comprehensive document; however, it
does not have to be used verbatim. The template can be trimmed to those areas
most important to your project, or even simply used as a checklist or guide to
structure other processes.
Wikis are a superb tool for all aspects of requirements
analysis. Wikis are a participative, collaborative method of capturing,
refining and communicating information. Wikis can be used to obtain input from
a wide range of perspectives and sources, breaking down political, power or
functional lines. Furthermore, as the history is stored, we can retrieve
information such as how design decisions were taken.
Conclusion
Formally or informally, explicitly or implicitly,
consciously or unconsciously, requirements engineering is a core software
engineering activity that is always practiced at some level. Introducing cohesive
requirements engineering processes can help us avoid wasting time and cost building
the wrong software and ensure the software we build is high quality and
satisfies our customers.
References
Robertson, S. and Robertson, J. (2006), Mastering the Requirements Process, Addison-Wesley
Mylopoulos, J., Chung, L., Liao, S., Wang, H. and Yu, E., 'Exploring
Alternatives during Requirements Analysis', IEEE
Software, January/February 2001
Alexander, I., 'Misuse Cases Help to
Elicit Non-Functional Requirements', Computing & Control Engineering,
February 2003
