During a briefing earlier this week, Jama Software's CEO Eric Winquist showed us a slide separating the repository of a requirements management system from the collaboration that happens around requirements. I really liked the slide because it nailed an important point about both the requirements process and the tools that try to support it.
Ever had one of those "So what?" conversations about requirements? The one in which someone looks at your carefully crafted bit of product requirement genius and says, "So what am I supposed to do with it?" If not, you probably haven't been a PM, so you should stop reading now. If so, you've experienced first-hand that requirements are not just a big Lego box full of information, from which people will easily construct something meaningful. Or, to use a different metaphor, the requirements repository serves the function of a dictionary, describing the things that matter in the universe of technology that we can build. No matter how big, precise, current, or clear the individual bits of information may be, they don't automatically add up to something that someone could use.
The first generation requirements tools were, in essence, dictionaries. Like the Oxford English Dictionary, an important measure of its success was completeness. Since the human brain couldn't retain and organize this information effectively, and Microsoft Office proved to be incapable of handling information complexity, then teams embraced tools like Borland (now Micro Focus) Caliber and MKS Integrity.