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:
- Is the problem clearly stated?
- Is the problem actually occurring?
- Are the stated (assumed) causes of the problem correct?
- Is the problem worth solving (or at least worth investigating further to determine the costs of solving)?
- 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.