Do you ever wonder why the most often used tool (by far) to capture software requirements and write specifications come in the Microsoft Office Suite? Or why most requirements experts consider themselves to be tool agnostic?
With poor requirements consistently cited as the cause most often attributed to failed software projects, one would think that teams large and small would be looking for a means to improve requirements and specifications. Surely there is a tool that can solve this problem! And judging from the price of most requirements tools, vendors seem to think that the price of project failure makes a good argument for steep tooling costs. I have been on many teams where the desire was there to use requirements tools, but the budget was not. So despite the cost and risk of failure, MS Word was what we used.
With over 90% of business analysts using tools not designed for requirements analysis (aka, Word, Excel, PowerPoint), it would appear that the market has not yet turned to tooling to help solve the problem. Industry-wide usage statistics would certainly back up an argument against investing in requirements tools.
So if requirements problems aren't solved by tools, perhaps it can be solved by methodology. There are plenty of those too. Agile is the backbone of the latest best methodologies. When it comes to requirements and documentation, perhaps the agilists are on to something. Perhaps the best solution to the requirements quagmire is to ignore it. Or at least de-emphasize it. If requirements analysis is consistently done so poorly, just skipping it all together and using the time and expense that has traditionally gone to requirements gathering to just talk about it and code will lead to higher success rates. The record so far does indicate fewer failures. (Do fewer failures mean more successes?)
Ignoring methodology for a second, when one seeks to improve their requirements process, they find techniques, and not tools. That's because users and subject matter experts just can't tell you how a visionary software product is going to solve their problems. For most, the first time around full-circle in the effort of requirements elicitation and elaboration turns into significant frustration, as they hear the proverbial "That might be what I said, but it's not what I meant."
Until we learn to dig and get to the "what we meant" part we'll produce poor requirements documents in any tool we use, even tools designed to "coach" techniques. The flip is true as well. With some experience, quality requirements documents can be created in any tool. This is why requirements experts can teach elicitation and be tool agnostic.
Accepting where the true challenge is in requirements management, we can identify the ancillary difficulties encountered in the process where tools can make a significant impact. Tools that help manage the sheer volume of requirements that often arise and keep track of those requirements to ensure that they are represented in documentation (traceability). Tools that help in ongoing maintenance. Tools that help in communicating necessary change. These are the difficulties that tooling to can solve.
When considering requirements tools, recognize that there are no silver bullets. The real challenge in requirements gathering can only be solved with knowledgeable and highly skilled people. Recognize where in the process tools can help people improve the efficiency and quality of requirements work and adopt tools for those issues.