/dev/design 17 Apr 2007 10:37 pm
Let’s Talk About Client Requirements
Client Requirements are going to be some list of expected functionality for a feature. From these requirements it should be possible to create a complete design (and from that design, a list of functional requirements can be created). Lots of people mix up the client requirements and the functional requirements into one massive document (or at the very least, assign a single owner to most or all of these documents).
Client requirements are often confused with Designs and, while they are related, they need to be separated. I’ll talk about Designs later.
This is a client requirement:
REQUIREMENT: The user should be able to load files from a memory card.
This is another one:
REQUIREMENT: The game should run with a smooth framerate, even when playing online.
You will note that these are brief statements! If they contain lots of complicated logic then they will likely confuse the reader. It’s best to simplify these requirements! Use Cases can and should be employed by requirements writers to better present their ideas to the technical designers.
This might be a client requirement (if your game’s back-of-the-box feature was High Resolutions Up To 1280!):
REQUIREMENT: The game should run at a maximum resolution of 1280 x 1024.
This is definitely not a client requirement:
REQUIREMENT: The PSP game should have very little disc access during gameplay because disc access causes hitches.
The actual way to word that requirement would be:
REQUIREMENT: The PSP game should not hitch during gameplay.
Note the subtle differences! The first requirement is a functional requirement. The people coming up with requirements for your product should only care about the outcome, not the road to that outcome.
Organizing all of this is a completely different problem, but any software built without a list of clear requirements can never be finished (until you run out of time, at which point you either stop working on it or destroy it).
Since the technical requirements will be based on these requirements, this is where cuts happen. When these requirements change (and they’re easy to change, they’re just a collection of sentences!) then you will be able to write new technical requirements and re-plan.
