Posted by Tom Grant on April 9, 2008
Working on the PM tools research (drafted, in editing) has led to a recurrent question: what sort of requirements tool? Requirements definition? Requirements management? Something else?
Does it matter? The distinctions seem a bit arbitrary. The raw data is the same, regardless of the immediate task (collecting, analyzing, using them in a product plan, using them in feature or use case documents, tracking the progress of a release towards meeting these requirements, etc.). Why should these different bits of information be stored and managed in separate systems?
If you don't believe that having a shared repository of dynamically assembled requirements information, go work for a PM group for six months, and count the number of times you type the same information into multiple formats. For example, let's assume Friendly Customer Inc. wants a particular enhancement. A short version of that enhancement request may appear in a list of possible features for the next release. Friendly's use case might be important supporting documentation for the feature write-up. When the CEO demands to know how the company is responding to Friendly, one of the firm's best customer, the enhancement will appear in a slide. And son on.
While you might not want to try tackling every possible use of requirements data in the original application, the natural gravity of product management certainly tugs in that direction. Otherwise, why not just go back to using Microsoft Office, manually re-purposing the same information in new documents for different audiences?
You have to set some boundaries. Still, the borders are pretty wide. Atlassian, for example, has a product strategy that tries to pull all members of a technical teams--developers, QA engineers, product managers, and project managers--into the same suite of integrated tools. They're not requirements tools, in the strictest sense that some people prefer, but certainly the issue tracking part of the Atlassian suite, JIRA, has direct relevance to customer needs that may turn into features. Makes sense, just as much as automated test case generation from a requirements tool like Borland's Caliber DefineIt is a necessary byproduct of what PMs do when writing requirements.
Rather than worrying about how finely you can slice the requirements tools market, the real question might be, How big a collection of functionality should a requirements tool embrace?