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.