Emergent Functional Requirements in Game Development

There is a tendency in the software industry to complain about scope creep. You know, you’ve designed something based on a set of functional requirements provided by the client … and then the client says, ‘ooh! can we add this or that’.

The software designer then makes a decision on whether or not to honor the request … trying to balance the customer’s whims against the developer’s resources, contractual obligations, and customer satisfaction. Its then that you’ll then hear software developers spending their lunches complaining about scope creep.

Follow up:

However, I believe that often issues appear that can not simply be blamed on scope creep. What I’m referring to is something I call ‘Emergent Functional Requirements’.

For example, I’m currently building a level editor for use by the game players. There is a specific game design document that lists all the functional requirements for the level editor. However, now that they have been implemented, there are a variety of new tasks that I feel I must address. These are functional issues that could not have anticipated until actually working with the finished product.

While I could simply return the editor in its current state to the designers and say it was built as designed, I feel (through purely personal feelings) it necessary to increase the scope of the project to address these new issues.

Fortunately, I work in a company where I have the flexibility to do this. However, not everyone does. Thats why I believe, in order to the ensure quality of the end product, project managers, developers, and designers should all ensure they have given themselves a bit of room for the types of software features that are not in the design documents simply because nobody could have predicted them. This could be considered the first step toward iterative design… or it could simply offer a bit less whining about scope creep when it really isn’t (scope creep).