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.

…and…

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.


4 Comments

  1. We need to do a podcast. We can give Drunk and Retired a run for their money. You buy all the equipment and do all the editing, I’ll just talk 😉

    Comment by Ted — October 10, 2007 @ 1:34 pm

  2. Heh… I so do not have time to record & edit voice (I actually have about half of the equipment now; I bought an Olympus handheld voice recorder, and I’d probably be willing to invest in a decent mike for it).

    OTOH, I’m always game for more blog-and-forth.

    Comment by Craig — October 10, 2007 @ 1:38 pm

  3. Craig,

    Good post. I especially like your “5 important questions”

    However 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

    Problem 1: Users mistype their password when defining it, and so can’t subsequently log in.
    Requirement 1: password confirmation field

    Problem 2: Accounts are insecure.
    Requirement 2a: Passwords at least 8 characters long.
    Requirement 2b: Passwords no more than 12 characters long.

    This gets rid of any expression of a goal, however the goal should generally be to solve the problem, so maybe item 5 in the list should just be “Do the requirements really address the problem?”

    Comment by Bruce — October 10, 2007 @ 6:51 pm

  4. > Good post. I especially like your “5 important questions”

    Thanks. By the way, I just came up with those 5 off the top of my head… there’s potentially more out there.

    I’ve responded to the rest of your comment with a new post. Enjoy!

    Comment by Craig — October 11, 2007 @ 8:48 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.