OOAD Exercise Step 3: In which we discover that our feature list sucks

So, in case you haven’t visited before I’m writing a small game using a simple and very effective methodology. I’m also taking you, dear reader, along for the ride!

In our last post (Step 2: in which we figure out how our software is going to be used) we reviewed the importance of creating a good use case diagram to get a solid idea of how our software will be used. That information, when combined with a list of features will imbue us with only the first of our Analysis Superpowers!

Analysis Superpower 001: Figuring out what sucks and what doesn’t!

The first superpower we’re going to learn is figuring out whether there are features or use cases in our design that suck (there usually are). One way of doing this is to review each feature in our list and make sure it goes well with one or more of the use cases we just created. If we look at the feature and two use cases listed below, we can infer that some relationship exists between them (hint: they all deal with player interaction).

Analysis Superpower 001: The best way to get rid of Atë (the spirit of crappy features)

Feature:
(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.
Use Cases:
(Woebot-UC001): Player interacts with game engine
(Woebot-UC002): Player controls main character

If a feature can be connected with one or more use cases, we know it’s probably worth keeping around. If a feature or use case can’t be connected to anything you have, take a close look at it and make sure you want to keep it around (because it might be Atë, the spirit of crappy features manifest in your very design).

How do I know if my use case or feature is crappy?

Recognizing bad design decisions isn't always this easy...

So, how do you tell if a feature or use case is crappy? Here’s a handy check list:

• If it’s a feature and you can’t think of a use case that goes with it.
• If it’s a use case and you can’t think of a feature that goes with it.
• If you think it’s too low level to be a feature (see step 1 in this series).
• If it was written by someone who fancies themselves an expert but hasn’t actually written any software (see: The Dunning–Kruger effect).
• If it makes use of words like “synergistic”, “monetize”, or “performant”.
• If it was written by a woman named Medusa and involves a phrase like “Kitten-Cam”.

If at this point you’re thinking, “Oh snap-a-dap, that’s totally like one of my features!” then it might be time to kick that feature (or use case) to the curb. However if you still feel like what you have makes sense; then something is missing from your design. If you’ve got a stray feature – make sure to create a use case to go along with it, if you’ve got a stray use case – you need a new feature.

You generally don't want a crappy feature like this to sneak into your game...

Using our new Analysis Superpower on Woebot – Chapter 1:

So, now we’re ready to use our new found analysis superpower. I usually do this right on the UML diagram, but spreadsheets (or napkins) can be used here too. But, before we do anything else, let’s review our feature list from Step 1:

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.

Looking at that feature list we’re able to draw some pretty clear relationships between it and our use cases. Here’s what I came up with:

What happens to a use case diagram when you think about things a bit:

Items in red mean that something about the feature and/or use case didn't quite match up!

So, that didn’t go so well – we obviously have some features and/or use cases missing. Though this part of the process almost never gets it right the first time through. That’s what’s so great about it, the process encourages you to think about all the problems to be solved, and how you’re going to solve them.

So, to make this work all we need to do is look at any feature or use case in red and decide whether or not we want to keep them. If they’re all keepers, then we’ve got to make room for them in our design (by adding features and use cases). Here’s what I decided to do, though this is a situation where’s there’s really no wrong answer:

A newer, better use case diagram:

You only need a design that's "Good Enough" shooting for perfect in software design is usually just a waste of time.

As you can see I made some changes to the diagram. Not only did I fix the directions that the extension lines are supposed to be pointing (I’ve been doing this for ages and I still get that wrong) I also added a new use case and two new features! I also removed part of one of the features I had a problem with before (we can always add it in later on if we design our software well). Here are the changes we made to the feature list:

A newer, better list of 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 allow the player to collects power ups that will affect damage and output of the players weapon.
• (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.
• (Woebot-F007): The game shall provide multiple types of enemies each with a common/unique UI to provide an interesting player experience.
• (Woebot-F008): The game shall provide an informative game ending screen detailing the success rate and improvement level since the last time the game was played.

This leaves us (finally) with a nice balanced set of features and use cases that we know we actually want in our software. Hopefully by this point we’ve started to flush out some parts of the program we hadn’t thought of before (e.g. displaying game status, and what we actually do with the game over screen). Now that we’ve got all that done we can add it to our Woebot Chapter 1: Design Document.

Now, we’re ready for the next big thing: Step 4: In which we transform big software problems into smaller, more manageable ones. Where we’ll take our use cases and features and organize them into logical systems (which can be worked on independently by different developers).

Unfortunately, that’s won’t be until next time. However, in the meantime I hope you enjoyed the post, and please let me know what you think!.