OOAD Exercise Step 1: In which we figure out what our software is going to do… (or, How to write a Feature)

So, in case you haven’t visited before I’m writing some articles about a simple and very effective design methodology. This methodology is for writing great software, and consequently we’re going to be writing a game to make it more fun (there’s a lot more to game development than this, so don’t take it as best practices for writing games).

Today, we’re figuring out what our features will be. If you continually find yourself at odds with clients or end up with crazy marketing people who say one thing before you write a project and expect another when you’re done – a good set of features can make all the difference.

This guy needs some features

I’ve seen a lot of developers get burned by not figuring out what their software is supposed to do before they start writing code. In fact, thinking back – I’ve been one of those developers more times than I’d like to admit. If you get a reasonably big project, and you’re the type who starts coding right away – stop now, seriously – a little time spent on upstream activities can save you many-a-late-night in the long run. The biggest problem with the “Jump right in” philosophy (and there are many) is that it usually doesn’t involve effective communication between the developer and the person they’re writing software for (even if they’re the same person). So, how do we fix that? Well, making a list of features describing exactly what your software is going to do is a good place to start!

You two could’ve discussed a feature list *before* you turned her to stone…

People usually get confused between features and requirements (especially marketing people), so it’s important to note that features and requirements are not-the-same-thing! Features are big picture items that help people visualize what software is supposed to do, requirements are all the small details that make up a feature. In other words, features let you talk to anyone about what you’re going to make before you make it, while requirements are really more for your technically savvy co-workers and stakeholders.

Here’s the wrong way to communicate about a feature:

No amount of alcohol is going to make what you’re saying sound less complicated…

Ok, obviously this is entirely too detailed to be a feature, and is really more like a bunch of requirements (we’ll get more in depth on requirements another day). As you might imagine, most people have an idea what a ninja is, but not everyone is going to know what a kursarigama is (a weapon consisting of sickle, chain, and a heavy iron weight, naturally). The point of a feature list is that it’s as descriptive as possible using as few words as possible (almost like a haiku… except different). That way, you can talk with other people (even your grandma) about what your software will do without them getting distracted by all the nitty gritty details.

Here’s a better way to talk about a feature:

There’s no hope for Grammy – she’s in sales, but that feature was well written…

This is much more like it – it allows people to get a good idea what might be happening without overwhelming them with information. A short, concise (and sometimes intentionally vague) feature is much easier for people to form a mental image of.

So, now that we’ve gone over what features are and why they’re good – let’s write some for the game! My goal is to create a horizontal platformer/shooter that can be played in five minutes. Let’s make a list of features, and maybe add a quick synopsis just for fun.

The Woebot feature list:

Project:

Woebot Chapter 1 – Ascent into the ridiculous world of the pretty much extinct humans

Synopsis:

Woebot is a short game about a small slightly depressed robot who has decided that the cure to his depression is to leave the underground home of his peers to live with humans on the surface. Unfortunately the road to the surface is full of peril, and the robots haven’t seen a human in over a thousand years!

Features:

• (Woebot-F001): The game shall allow the player to control a humanoid robot character in a single level of side-scrolling-platforming-shooter-style awesomeness.
• (Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.
• (Woebot-F003): The game shall provide a choice of weapons to the player at the start of the game, which can be improved as the player collects power ups.
• (Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.
• (Woebot-F005): The game shall contain narrative elements explaining the back story for the relationship between robot and human. (e.g. The robot civilization decided to sunder themselves from the humans over a thousand of years ago, and why that happened).
• (Woebot-F006): The game shall provide a simple narrative ending leaving the door open for sequels while providing clear completion to the goals of the game.

So, that’s my attempt at developing a set of features for the game. Now I can use this list to discuss the game with other stakeholders and improve our design from there. Remember that features shouldn’t be set in stone until you start to code, these will need to change as we go through the design process and realize some are missing, and others are just plain wrong.

I’ve added what we did here to our Woebot Chapter 1: Design Document, please feel free to review it. Next time we’re going to figure out how our software will be used in Step 2: In which we figure out how our software is going to be used (obviously). In the meantime, I’d love to hear feedback if you’ve got some!