Game Requirements

Game development is as complex an activity as general software development.

Many disciplined software organizations collect a focused set of metrics on their projects. These metrics provide insight into the size of the product, the effort and time the project or individual tasks consume, and the product’s quality.

Building a game from scratch needs a project approach to be manageable.

Since requirements are an essential project component, you should measure several aspects of your requirements development and management activities to help you judge product size and project status.

Here (Measuring Requirements Management) I found some tips on how to do that.

Functional Requirements

Although you might represent requirements using a mix of use cases, business rules, event tables, functional requirements, and analysis models, you primarily implement functional requirements. So begin your measurement effort by simply counting the individual functional requirements that are allocated to a product release. Knowing how many requirements are supposed to go into your product will help you judge when it’s done.

Example:

1. Functional reqno.1
2. Functional reqno.2
3. Functional reqno.3
4. Functional reqno.4
...
n. Functional reqno.n

Of course, not all functional requirements are the same size or consume the same implementation or testing effort. A requirement that says “A valid color code shall be ‘G’ for green” is tiny compared to “The system shall respond to editing directives entered by voice” (both real examples). So, if you’re going to count functional requirements as an indicator of system size, your analysts will need to write them at a consistent granularity level.

One guideline is to decompose high-level requirements until the underlying “child requirements” are all individually testable. That is, a few logically related tests can verify whether a requirement was correctly implemented. Then count the total number of child requirements because those are what you’ll implement.

Example:

1. Functional reqno.1

• Testable functional reqno. 1a
  Testable functional reqno. 1b

2. Functional reqno.2

• Testable functional reqno. 2a

3. Functional reqno.3

• Testable functional reqno. 3a
  Testable functional reqno. 3b
  Testable functional reqno. 3c

...
n. Functional reqno.n

• Testable functional reqno. na
  Testable functional reqno. nb

Total: 8 testable functional requirements

To monitor overall project status, track the status of each requirement. This can help you avoid the pervasive “90 percent done” problem of software project tracking. Each requirement will have one of the following statuses at any time:

- [p]roposed (someone suggested it)
- [a]pproved (it was allocated to a baseline)
- [i]mplemented (the code was designed, written, and tested)
- [v]erified (the requirement passed its tests after integration into the product)
- [d]eleted (you decided not to include it after all)
- de[f]erred (it has been open for too long)
- [r]ejected (the idea was never approved)

When you ask a team member how she is coming along, she can say something like, “Of the eighty-seven requirements allocated to this subsystem, sixty-one of them are verified, nine are implemented but not verified, and seventeen aren’t yet completely implemented.” If I were a project manager, I’d feel like we had a good handle on the size of that subsystem and how close we were to completion.

Underneath flowchart shows the relationship between statuses.


Requirements Management

A body of work is done when all of the allocated requirements have a status of verified or deleted.

Because so much of requirements management is change management, track the status of your change requests. How many of them are open and how many closed? How many requests were approved and how many rejected? How much effort did you spend implementing each approved change? How long have the requests been open? Change requests that remain unresolved for a long time suggest that your change management process isn’t working effectively.

If you can convert some open requests to “deferred,” and convert long-term deferred requests to “rejected,” you can focus on the most important and most urgent items in the change backlog.

...