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!.

This entry was posted in Software Design, Woebot Chapter 1. Bookmark the permalink.

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

  1. rizwan anjum says:

    Eagan,
    Thank you again for writing this 3rd step :). I have got following questions for you:
    1) Should we involve other people in our analysis phase such as other developers or marketing people to discuss what features and uses cases are missing or needed? Or should we wait till we are done with our design?
    2) Once you have broken down these features and use cases into smaller logical packages, can we apply the same feature and use case analysis to solve the complicated features in smaller package as well or is it time to do some thing else such as activity diagram?

    Keep up the great work :)
    Thanks again

    • Rizwan,

      Man thanks again for reading over my blog entry. As per usual you’ve asked some great questions. In response:

      1. This is a matter that’s up for debate – I would say involve someone you think has an informed opinion, but don’t involve more people than you have to. Everyone approaches design in a different way, and it’s a nightmare to get a non-technical user trying to assert control over a software design. It’s best to have something prepared before you start a discussion and work from there (which will save time). I typically get some kind of feedback after each step – but don’t go far beyond features and use cases outside of my development team. More often than not you’ll find that no one even reads your use cases anyway – which is ok because they’re going to be more useful to the developers than anyone else. I would say that if you’re working with marketing features and mock ups are what they’ll get the most use out of.

      2. So, once you’ve broken your use case diagram and features down into systems, the next step would typically be to write any use cases that need to be written. There’s a whole authoring cycle that goes along with that, and some use cases don’t need more than a sentence for people to really understand them. After the use cases for a system are written the next step would wireframes, mock ups, and domain analysis (taking nouns/verbs from use cases and turning them into classes). After all that, it’s on to writing code! (This is all generally speaking, if you think of a missing feature or use case you might add that in the middle somewhere – and you might need to repeat some steps when you do that).

      Anyway – thanks again for reading the blog! It’s great to get your feedback on these, and I appreciate the excellent questions.

      • rizwan anjum says:

        You are welcome Eagan :)

        Great explanation. I think that by asking second question i just jumped into your 4th step :) Thank you for quick response.

  2. Pingback: Step 4: In which transform big software problems into smaller, more managable ones | Green Door Games

  3. Shane says:

    Is the key table on the right standard or is it a mix of custom and standard notation?

    • Great question – that’s actually standard UML 2.2, but UML 2.2 has a *lot* of different ways to represent stuff. However, as far as use case diagrams go these are pretty common. You might also see dependency lines (arrows with dashes for lines) used in place of aggregation lines to represent include relationships, though that choice is really up to each engineer.

      • Shane says:

        fish and pacman are standard… nice. :)

        • haha, I think these guys have been around a lot longer than UML. They’re kind of a traditional way to categorize how low level a design element is. You start out in the sky (cloud) for high level and then move down to the bottom of the sea (clam… or pacman, but really, it’s a clam) for low level. Everything else is somewhere in-between. Certainly you don’t have to use them if you’re some kind of pacman snob or something…

Leave a Reply to eagan.rackley Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>