Managing requirements conversations

In Documents vs. Conversations, on the Pyre blog, Greg Wilson does that thing that we so rarely do – he takes a step back, and thinks from an entirely different perspective about managing requirements. He proposes the idea of managing requirements as conversations, instead of as documents.

Greg makes the point that the reason for managing requirements is not to create a document, but rather to communicate. He points out that no one can have an omniscient awareness of the entire spec, and therefore people operate based on an understanding of a subset of the spec at a given time. And since the evolution of the spec happens by conversation, he proposes a conversation-centric view of the requirements. Greg points to the successful examples of open source software development teams driving feature delivery from conversations.

Jerry Aubin of Seilevel, posts about context in their blog, Requirements Defined. The focus of Jerry’s post is on the conversations that drive the creation of use cases.

Conversations are most relevant while a spec is being defined. After the spec is defined, the conversation is less relevant – determining the genesis of a requirement is less important than determining the relevance of a requirement (i.e. which use case does it support, how does it help to achieve ROI, when will it be delivered). The primary beneficiary of a conversational analysis is the requirements manager, who benefits only in that it provides organizational context, which helps when defining a subset of the specification.

As Greg pointed out, we interpret subsets of the specification at a point in time. Writing of the specification also happens piece-meal. Once a portion of the spec has been written, the conversation that occurred starts to immediately lose its relevance. When internal teams are responsible for distilling the inputs from multiple conversations with multiple customers, then conversational models will help the product managers, but only until the spec is written – then the conversation becomes an (infrequent) reference.

When managing requirements for customer-specific software, a conversational model will have even less benefit. A discrete set of customers must approve a set of requirements or a statement of work. In these cases a document-centric model will be more effective.

There is definitely value in helping a product or program manager to manage and mine multiple conversation threads as part of forumulating a spec. Changing the tools we use to manage the resultant specs would be a step backwards, imho. Once the evolving spec is actionable, the consumers of the spec will still benefit from a contextual presentation. I would suggest using a tool like OneNote to collect and organize the information that comes from multiple sources (email, IM, hallway conversations, whiteboard discussions, etc). The custom tagging and search capabilities due to be introduced in Windows Vista could also be leveraged to make conversation management more effective.