The Challenge of Enterprise Requirements Management

well-meaning inspectors come to these formal reviews and call out spelling and punctuation errors in the document, and miss the real intent, which is to verify accuracy and relevance to the business solutions required by the effort.

Creating detailed early specifications represents a Lean anti-pattern that violates the Lean principle "minimize work in progress." This is like writing thousands of lines of code before compiling and integrating.

In the end, silos of optimized processes create organizations that cannot tolerate change. This should come at no surprise, since the techniques for process improvement come from Six Sigma , whose goal is raise quality by making processes repeatable and non-varying. This trait is manifest in a dysfunctional organization when project teams categorize new requests as "requirement changes" that must go through "change control." Change control is a costly symptom of a dysfunctional, enterprise organization.

What About Use Cases?
Legions of proponents espouse the virtues of the mighty use case. Its celebrated purpose is to bridge the chasm between IT and business by providing user-system interactions described from the user's perspective, in language understood by both business and system developer. Use cases gained acceptance as organizations formed around the Rational Unified Process (RUP). Well-written use cases have served software delivery teams well, in that they help break flows into discrete, analyzable steps.

These steps map well into the analysis and design models that are fundamental to many enterprise delivery organizations. The intended value of use cases is best realized as a tight coupling of business goals to the system design. The most powerful example of this value is when use case steps are listed beside logical and physical sequence diagrams, as described by Ambler. [vii]

The business value of well-written use cases has been so widely recognized that organizations have been created focused on the use case as its deliverable. The unintended result of creating an organization to generate use cases is that the artifact becomes the group's focus and reason for existence, instead of the direct creation of business value (product). The pattern below is not unusual in large IT organizations:

Charged with optimizing the creation of use cases, process experts rush in and focus on how to most efficiently capture and manage use cases. The logical place to focus is on re-use. "Why should we create the same use cases over and over?" is a valid question. Generic use cases begin to appear with generic actors. These are managed with "exception steps" that allow a generic user-action/system-response pairs to be used over and over, as long as the appropriate statements are added. Soon, well-written and easily understood use cases transform into documents that are understood by neither business nor developer. In the end, the well-intended goal of re-use creates unusable documents.

This is a noble sub-optimization effort. But it is a lean anti-pattern, clearly breaking the "optimize the whole" principle. Over time, the management of enterprise use cases creates integration and validation work for the business and development organizations. In Lean terms, we have a backed up queue of efficiently generated requirements that are difficult to read, integrate, and validate.

In a moment of courage, I once challenged a silo of use case experts to prove that a set of enterprise use cases were "accurate." My challenge to the inspection team was simply to trace through the documents for a specific actor, performing the most basic function, and validate each step along the way. This happy path tracing ended up taking a room full of experts two full days to complete. During this inspection, infinite loops, jumps to nowhere, and other issues