(No, I haven’t forgotten about Test Automation. I’m just trying to leverage my time in the best possible way. Most of this post came out of a recent discussion on the SW-IMPROVE discussion list …)
One thing that I found helpful when gathering requirements is something I call “blank sheet of paper syndrome.” That is to say, if you give a (brand new) analyst a template, they will often react with something like this:
“oh, easy, I can do this. Project Name, Project Manager, Executive Sponsor, Initiated Date, Today’s Date, Desired Date … I can fill this out.” (… 30 minutes pass …) “Here’s your requirements doc.”
On the other hand, if you give them a blank sheet of paper, you are more likely to have a reaction like this:
“But … well … this is blank! I have no idea what to write! I don’t really know what the customer desires! I had better go find out!”
In my experience, this second reaction is much more likely to result in figuring out the /essential/ requirements of a software system, instead of gathering requirements that “all look like each other.”
The argument /for/ requirements templates is that without the template you would forget something. My personal conclusion is that, for the vast majority of projects I have worked on, I will gladly run the risk of forgetting something on the template, in trade for the benefit of, hopefully, capturing something more essential on a personally-written document.
Now, I would be remiss if I did not add that the Planning Game in Extreme Programming – where you have no person in the middle and negotiate the requirements, is one valid implementation of blank sheet of paper concept. You cards could even have a slot for title, points, priority, and description, and I wouldn’t be offended. 🙂
In other words, Jerry Weinberg’s Rule of three, in that you should strive for at least three options for every problem, still applies. “No Template/Blank Sheet” and “All Template/No Customization Sheet” is a false dichotomy – you can always do more or less, allow some customization, have a half-dozen questions instead of a three-page template, and so on.
All that I am saying here is that in the push for stable/predictable/repeatable, some organizations try to make all projects look the same. Sometimes, for the project team, that can do more harm than good.