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

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:

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.

The Volere template can be found at www.volere.co.uk

Wikis

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

---

Title photo by 3:19, used under Creative Commons license.