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.