Requirements Are A Conversation, Not A Dictionary
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.
That's fine, if the problem you're facing requires completeness. However, in many cases, the problem isn't the contents of this dictionary, but the conversation constructed from it. How do we review the requirements? Can we tailor the content to different audiences? Is there a better way to convey the information so that people more clearly envision what it is we're building? From this need to moderate the discussions about requirements arose new types of requirements tools, such as iRise, and new features in the old-style "dictionary" tools.
Inevitably, however, requirements are really a conversation. Every organization has a different data structure for its requirements because, in that tribe, they speak a different dialect. Requirements must conform to the subculture within a team, a principle that applies to more than just the content. Teams have different tools they already have in place for other functions, such as coding the software, generating tests, collecting new requirements data, and so on. One of the killer features of many requirements tools, therefore, is their ability to integrate helpfully into other tools. The developer who doesn't need to leave Eclipse to get more information about the feature he or she is coding is usually very grateful for that convenience. The conversation about work happens without interfering with work, in a fashion that respects how that person works.
If you're new to a team, it takes time to learn how best to communicate about requirements. For example, stakeholders outside the organization don't want all the details that someone in development may require, but which information do these decision-makers expect to see? The new PM learns, over time, and often through trial and error, what syntax to use with this audience.
Collaboration drives demand for integration, which is one reason that integration is a big priority for ALM vendors, and why an integration framework like Mylyn is getting a lot of attention. But that's a much bigger topic for another post.