Requirements vs Solutions
There is a big different between creating requirements and creating solutions (or specifications, in some circles). It may sound odd, but this is a tough thing to learn. Yes, Scott always gets me thinking about writing requirements 
A lot of folks, especially if they have experience with implementation / coding / whatever, will have an inclination to state a solution and not a requirement. The trouble with that is, they can be irrelevant and confusing, and not make sense to the dev team.
My advice: leave the solutions and specs to the programmers and developers and architects and even program managers. This is a very hard split to make, but I was very lucky it’s lesson I learned early on in my career and carry with me to this day.
So, what exactly do I mean? Let’s look at an example.
Say you wanted to call attention to a group, or type, of items in a report. What’s the difference between the requirement and solution? Well, a solution (or the “spec”) would look like this:
“When running the SQL query to extract data out of the database for the report, loop through it, and if an item equals [some value meeting a condition] set it’s associated <span> tag to have a background color of #f5f5f5.”
Or, even to a greater degree:
“Connect to the database using the ADOdb connection library, execute the SQL query (SELECT…), and loop through it like this: (foreach…), and make sure the HTML looks like this: (<span>). This isn’t rocket science and should only take you an hour or so.”
The problem with this, even if you can do it right, is that the PM is a) not a developer, b) you will inevitably develop disdain with developers and (to be candid), c) you are wasting time.
See, the requirement is much shorter. Something like this:
“Highlight items that meet condition X in report Y.”
You could go further and describe the business value / context. Maybe there are some permutations in there. I will typically do this in a quick conversation with the developer, but that’s because I am afforded the flexibility. I have written things like that out in the past.
Now, yes, you could state a non-functional requirement as well:
“Make items of type X in report Y yellow.”
So yes, understand the difference between functional (do stuff) requirements and non-functional (look & feel stuff) requirements.
Now, to me, this makes perfect sense. You can bullet out a million requirements this way. OK a million is probably excessive. But you get the picture. If you were stating SQL, code, this and that (i.e., the spec), it would take you a lot longer.
And your time is better spent writing what? Well, more requirements of course (or release notes). Or doing BAT testing, or being on a Sales call, or a myriad other things.
April 14th, 2007 at 1:13 pm
Great practical example Adam! I like the phrase “highlight items X in report Y”, it is actionable.
An interesting thought - can you go a step more abstract:
Why is this report being generated? Is it so the exec knows about items X? Not really - the exec wants to make some sort of decision about the business. Someone else has already decided that “viewing items X” is the best way to support this decision analysis.
So from that perspective, “view X” is a HOW not a WHAT (or WHY). “view X” is dramatically better than “format the in the CSS.” But the interesting question is - is it in OUR scope to ask the question “is viewing X the right answer?”
Some product managers would say that the requirement is “support the decision” - but then who on our team is going to say “viewing X is the best way to support the decision”?
A business analyst should be able to design the business solution (”if you need to make a decision, you should view X and do Z with it”). That level of understanding opens an interesting possibility - instead of having a product that highlights X, why not have a product that reccommends Z?
Always fun to think about requirements
- thanks for the shout-out, and for making me think some on a Saturday.
April 17th, 2007 at 5:42 am
I like how you distinguish between requirements and solutions. But more importantly your statement of requirements is very refreshing. I’m a developer and analyst so I get to both write the requirements and develop them.
Not so long ago I worked for a software company who had a ‘product manager’ who like to write specs the ‘bad’ way. What’s even funnier is the president of the company, in a meeting with me as the project manager, said exactly - “This shouldn’t take you long, it’s only one form - it’s not rocket science”.
Needless to say there was definitely disdain.
May 14th, 2007 at 6:22 am
I enjoyed reading it! Another good article that I rely on is http://www.yinsochen.com/blog/2006/09/08/rock-solid-requirements/
Thanks!