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.