ben is on the inter.net

Today was my first day back to work. Everything feels so strange now.

I had Eggo waffles today for the first time since my childhood. They had bits of strawberry in them, and I ate the second stack with no syrup (since, apparently, I now find syrup disgusting). It made me wonder how long somebody at the Eggo Corp Or Whatever, Ltd., spent trying to convince some higher-ups that adding fruity flavoring to the waffles was a good idea.

When XNA 2.0 comes out, support will be added for the guitar controllers. There’s already support for racing wheels.

I want to see a multiplayer shooter where one guy drives some vehicle and the passenger uses their guitar to shoot wailing laserZ at opposing drivers. It would be the World’s First (and Filthiest) Multiplayer CaRPG Rhythm Shooter.

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.