A couple of years ago I wrote a blog titled the 5 Joys of using Excel as a Requirements Management Tool. In the post, I wrote about the frustrations I was facing using Excel as a requirements management tool. I still stand by what I wrote at that time (and if you are interested in learning about requirement management tools, take a look at our recent Tool Study).

I had quite forgotten that I had even written that blog until I was reminded of it recently. As I think back about the project that prompted my frustration, I do have to say, in all honesty and fairness, that I have found a redeeming feature of using Excel as part of the requirements process.

I have found that using Excel in the early part of the elicitation process to be tremendously helpful. In those early days of any project, I am really just playing with what the requirements might actually be. I’ve started to draft various models, such as the Business Objectives Model, Feature Trees, Process Flows, etc., and putting onto paper requirements that I’m hearing so I don’t forget them. These super early draft requirements are really rough; the final version usually looks nothing like the original.

The challenge in the early stages of writing requirements is that they are very fluid. As I start to draft, and as I learn more, the requirements change frequently. This is the case regardless of SDLC; even in an agile scenario, my work early in the definition of my product backlog changes a lot as a progress to getting enough stories ready to go for the first sprint. Because of the frequent and constant changes, I prefer to work in Excel.

Working in Excel does allow me flexibility to easily and quickly go between rows and make adjustments and changes to what I’ve written. I can easily add information in additional columns if necessary. And I can delete easily and quickly enough if I totally screw things up. In my experience with several requirements management tools, most do not allow that ease and flexibility to work in this manner. Even if they offer a spreadsheet view, it’s just not as quick and easy.

Now, there does come a time when I move everything over to the requirements management tool. I like to think that the original set of requirements have reached a stage where they are like jello…still kind of wiggly (meaning things are still changing a bit), but firm enough to stand on its own (but not changing frequently or with the velocity of the earlier stage). And once I’ve moved things over, all future work continues in the tool. The work done in Excel is the past, no longer current, no longer needed.

Please don’t get me wrong, I’m a huge advocate for using requirement management tools. The ability to do versioning, work collaboratively, workflows, etc. is still way much better in an RM tool. However, Excel does have its place in the overall process.