1. Portal to a new gaming experience

    October 17, 2007 by Craig

    I got the Half-Life 2 Orange Box this week. I haven’t played it much (I don’t have much time for gaming these days) but I did beat Portal in a day. I’ve also played a bit of Team Fortress 2, and it’s a pretty good visual upgrade to Classic (but still the same game). I’m saving Episode 2 until Laura gets back into town, as she enjoys watching me play. I was slightly annoyed at having to re-buy Half-Life 2 and Episode 1 over again, but I’ve forgiven Valve as I’ve come to understand that they were mostly pressured into it by the brick-and-mortar retailers. Valve did the right thing by allowing (and in fact promoting) the transfer of extra licenses/activation keys to other people. By the way, if you’d like my keys for HL2 and Ep1, let me know.

    If the Gravity Gun was a big step forward in gameplay evolution, then the Portal Gun is a flying leap. (The fact that they’re both born from the same series should tell you something). It’s definitely the most flexible and enjoyable game weapon I’ve seen yet. It’s a teleporter, lock pick, jet pack, grappling hook, cloaking device, and grenade launcher all rolled into one. The best part is that it’s not overbalanced at any of those things, so you have to be clever to get the most out of it.

    The big problem is that it’s way to easy to be too clever, and so the map designers had to design in heavy restrictions to keep it from becoming too unbalanced. Thus, you can only use the Portal Gun where they allow you to use it, via the mechanism of walls that don’t allow portals. At times the restrictions are stifling, but it’s completely forgivable once you consider:

    • The game is designed and marketed as a puzzle game, not a more freeform adventure.
    • They worked the restrictions into the storyline very well: the protagonist is supposed to be advancing through a testing facility, not running around free.
    • It’s clear that the entire Portal project was a proof-of-concept for future Half-Life games. It’s going to get better from here. I pity the level designers though.

    Also: I’ve often said that Fallout 2 has the best intro movie of any computer game; I think Portal gets the prize for best end game movie (though it loses some of the effect if you haven’t played it all the way through).

  2. Mining Clients for Requirements

    October 11, 2007 by Craig

    Ted says: Clients don’t always say what they mean. This is 100% true. My experience is that the majority of all people in business can’t fully and clearly articulate their thoughts, either verbally or in writing. Compounding this are situations where the client isn’t 100% honest and forthcoming; these run the range from simple cautiousness to outright deceit. Thus, you typically can’t take a client’s statement at face value.

    Furthermore, even if a client can say what they mean, they may not mean what they actually want. And, even if they mean what they want, they may not actually want what they need. It’s the need that should be fulfilled, but there’s a lot of obstacles in the way.

    To make matters worse, these obstacles are often multiplied by the numerous layers of “clients” involved. Here’s an example based off a real-world situation (the one I was in until recently):

    1. The implementor gets requirements from his immediate boss.
    2. The boss gets the requirements from the business/marketing/client relations department.
    3. The client relations department gets their requirements from a 3rd-party development company (who is subcontracting part of the work to the implementor’s company)
    4. The contracting development company gets their requirements from the actual client.
    5. The client gets their requirements from the users.

    It’s easy to see how confusion and misinformation can affect the requirements when there’s this many stages between the producer and the consumer of a piece of software. That’s why it’s important to do a thorough review of a particular request to verify that the sights haven’t drifted too far off the target.

    I like mining as metaphor. There’s a nugget of gold buried in a mountain of communication. You need to dig away all of the useless rock in order to find it. As you dig, you’d better be setting up struts of solid reasoning to keep it from collapsing on you… and you’d better be digging in the right direction, or else you might miss the prize entirely.

  3. Refining Problems and Goals

    by Craig

    Bruce responds to my prior post on requirements:

    …I think you also have misinterpreted the user’s statement of the requirement.

    Ted’s discarded first sentence IS a problem statement, but only for the second sentence (password confirmation field).

    I don’t think the last sentence is a goal for the two requirements, in fact it has got nothing to do with problem statement. Interpreting it as the goal causes your question 5 to yield a negative answer.

    The last sentence is (I think) a statement of a second problem, which leads to the second (but already stated) requirement. I would interpret the paragraph (briefly) as…

    I didn’t really put any interpretation into the validity of the first and fourth sentences, nor did I attempt to answer any of the questions I asked. I just used them to illustrate the questions & types of statements themselves.

    However, Bruce’s disagreement shows exactly the kind of process I was looking for when assigning qualifiers and questions to the sentences in the first place. He brings up valid points which prompt further action:

    1. acceptance (if everyone on the team is convinced he’s right)
    2. counterargument (if someone on the team thinks he’s wrong and can explain why), or
    3. clarification (go back to the requirement writers and ask for more information to confirm or deny the assumptions we’ve made

    The last two actions restart the process until full agreement is achieved. If you have enough people with good reasoning skills and tenacity to see disagreements through until they’re resolved, then the results of your analysis will probably be very close to the hypothetical “most correct answer possible.”

    Along the way, all of your requirements, problem statements, and goals stand a good chance of complete replacement. That’s a good thing — if you’re doing the wrong thing, it doesn’t matter how well you do it, you’ll still come out with a poor result.

  4. Refining Requirements

    October 10, 2007 by Craig

    My old boss, “Teflon” Ted, has written a great post on producing “digestible” requirements:

    I commonly get “requirements” documents from clients that read like a college book report, just pages and paragraphs of disorganized stream-of-consciousness ramblings. When this happens, I use a little trick to restore some order to the chaos. I break it down into one long checklist of digestible tasks.

    He then illustrates his process for taking a verbal description and refining it into a beautifully clear and concise list of tasks. It’s well worth a read.

    Lately I’ve been getting back into the requirements ends of things after years of being implementation-only, so I’ve been especially interested in this sort of topic. I think I’ll adopt Ted’s checkbox method straight away (it’s certainly easy enough to do so), but I would like to expand on it a bit.

    For starters, let’s take his example verbal/written requirement:

    “We’re tired of users mistyping their passwords and not being able to access their new accounts. First of all, we want to add a password confirmation field to the sign-up form. Secondly, we want to force them to pick a password between eight and twelve characters. This should make their accounts a little more secure.”

    Aside: I think he’s being extremely generous with the example requirement here. I’ve dealt directly with some of the requirement text that he’s been involved with too, and it’s usually a lot worse than this in terms of length (either overly wordy or overly sparse), clarity, and grammar/spelling.

    Ted splits it into four sentences, and then drops the first and the last, neither of which are actually requirements. The two remaining sentences are then trimmed down and split up into action items and assigned check boxes.

    That’s well and good, but I’d like to take a closer look at those two dropped sentences:

    We’re tired of users mistyping their passwords and not being able to access their new accounts.


    This should make their accounts a little more secure.

    These are definitely not requirements, if you define “requirements” as “items to be acted upon.” However, they are, I think, important, and deserve to be included in a formalized / reorganized specification.

    So, if I were to improve upon Ted’s method, I’d then restate the first and fourth sentence as:

    • Problem: Users are not able to access their accounts due to incorrectly answered passwords.
    • Goal: Make user accounts a little more secure.

    From here, we can then ask several important questions:

    1. Is the problem clearly stated?
    2. Is the problem actually occurring?
    3. Are the stated (assumed) causes of the problem correct?
    4. Is the problem worth solving (or at least worth investigating further to determine the costs of solving)?
    5. Does the goal really address the problem?

    If you get negative answers to any of these questions, then the requirements need to go back to the submitters for more discussion before the action items are refined further. If the problem and goals aren’t solid, then it won’t matter how well the requirements are organized and implemented; the whole thing will fall apart at the foundation anyway.

    Once that’s done, you can then refine the requirements, and then ask:

    • Will the action items, if implemented correctly, achieve the goal (and thus solve the problem)?

    Of course, all of this work should already be done in advance of anyone in the implementation department (ex: software developers/designers/architects) gets near it. That is to say, the people in the business/marketing/management department should have already asked and answered these questions. However, it’s been my experience that pretty much everyone with a non-technical background does not (and sadly, can not) perform this kind of investigation to an acceptable degree… and thus the people lower down the chain have to compensate.

  5. Santa Not Coming to Calgary in 2007

    by Craig

    …at least, not for the parade.

    Downtown construction has cancelled the annual parade that brings out thousands of people every winter. The Calgary Downtown Association, which organizes the Santa Claus parade, said Tuesday that construction and road closures made it impossible to keep the tradition going this year.

    It’s just as well, as the reindeer are all off in the oilpatch, and the elves are busy framing houses in Airdrie.