Just wanted to share and comment on a post I came across the other day that points out the potential drawback of requirements management tools. Per Jeff Levinson at Northwest Cadence:

There seems to be a growing move towards using tools … to subsitute for processes. Tools are great, they really are. They help make our lives, as software developers (using the term loosely to cover anyone who deals with software development) easier. They make our customers lives easier. But there’s a coming problem that relates to an over-reliance on tools. Our industry needs to step back and realize that soft skills are more important than tools – especially in the requirements area! Being able to talk to someone and write and take good and accurate notes and being able to read body language are more important than any tool. Tools make communication, traceability and monitoring of requriements easier but they don’t make the requirements any more accurate. It might even be nice if schools, on top of teaching all of the technical subjects, started teaching better communication skills (both written and spoken).

What they do..

First off, I agree with Jeff 100%. Requirements management tools are great in that they really help with the organization and reuse of requirements. They automate traceability – which, if you’ve ever done a traceability matrix manually, you know that having it done automatically is a huge savings in time and tedious effort. RM tools provide search and reporting functions and collaboration options that you just don’t get from a directory tree full project-specific specs in MS Word. They allow you to associate useful meta data (attributes) to your requirements and use them to further slice and dice them for reporting or tracking purposes. These are just a few of many great reasons to use a requirements management tool.

What they don’t do..

What RM tools don’t – and I’d argue that they can’t do – is help the analyst ask the right questions to draw out customer need. They don’t help the analyst articulate the requirements that they gather in a way that is accurate, precise, and understandable by the folks that will be using them to design and build the solution. It’s basically a “garbage in, garbage out” scenario. The requirements in your tool will never be better than the analyst’s ability to elicit and document them allows.

What they’re hoping to do..

We’re seeing – and I’ve spoken about it here – the emergence of the concept of the requirements workbench. Vendors are striving now to couple their requirements management tools with new tools that will help analysts capture and model requirements (see Blueprint, Borland Caliber DefineIT, etc.). I think that’s a neat idea. I think that being able to sit down with a customer and model the requirements within a tool is a great, time-saving capability that may also have some positive affect on the quality of requirements, and it puts them in a form which can be easily used by downstream designers, developers, and QA analysts.

The “art” of the matter..

The bottom line, though, is that business analysis – and in this case, requirements elicitation in specific – is an art. There is an art to being able to direct the flow of discussion/questioning to draw out true stakeholder need. There is an art to cutting through “symptoms” and false trails and identifying actual business problems. There is an art to being able to sense false consensus in a group or panel setting and to tactfully draw out participants’ true thoughts.

In the end, it’s the art of business analysis that just can’t be replicated by tools.