First, the good news: More and more organizations recognize the critical link between requirements quality and the success or failure of software development initiatives. The bad news: There's still a lot of confusion about the best way to address the issue.

Organizations must be able to accurately identify exactly where in the requirements lifecycle the biggest problems lie. For example, are development snafus simply the result of losing track of which requirements a release includes? This is a requirements management issue that is best addressed in conjunction with development. But what if requirements are ambiguous, incomplete, or just plain wrong? This is a requirements definition issue—the more common and thornier challenge.

A Forrester report entitled "The Root of the Problem: Poor Requirements," authored by Carey Schwaber with Gene Leganza and Megan Daniels (September 1, 2006), cogently noted that the focus on—and availability of—tools that manage requirements during the software development process is detracting attention from the far larger problem of whether or not requirements are accurate in the first place. Simply managing requirements—no matter how well this is done—still results in the age-old problem of "garbage-in, garbage-out."

Today, several approaches are emerging to deal with the "garbage in" part of the equation. Here are some considerations.

UI prototyping and requirements definition and validation solutions are two categories that often get mistakenly lumped together. While both seem to address similar problems, each attacks a different root cause. Prototyping and simulation tools help stakeholders "see" the finished user interface, serving up a visual preview of how features will be incorporated and how users will navigate the system. Thus, prototyping and UI design tools answer the question: "How will this look once we get it done?"

Requirements definition, on the other hand, answers the question: "What do we want the software to do?" Needless to say, prototyping a nonessential requirement, or one that is poorly understood, is a waste of time—as it is critical to understand the "what" before addressing the "how."

To avoid this problem, a good place to start is the use case.

The use case is where most organizations begin to spell out the functional requirements of software applications. Primarily written by business analysts or users, the goal of the use case is supposed to be one of illumination, providing developers with the information they need to build a system that delivers on the vision.

Here's where the problem of poor requirements most often takes root. Accurate requirements get lost in translation between business people who think in words, and software architects and engineers who respond to models and visuals. Should organizations then attack requirements quality from the business analyst's perspective or the developer's? Of course, the answer should be both.

For a great majority of organizations, the most fundamental requirements pain point can be summed up in those immortal words from Cool Hand Luke, "What we have here is a failure to communicate." Does this scenario sound familiar? Business analysts hand a phonebook-sized set of use cases over to developers, who then struggle to create working visual models. Thus, the "translation problem" is a direct result of a manual and painstaking process for defining requirements that leaves a lot of room for miscommunication and error.

A better solution is one where words and pictures work with, rather than against, each other. Use cases and diagrams do not "spring forth" in their final forms spontaneously. Rather, an iterative process of elucidation and validation turns starting text into first-pass diagrams, which in turn reveal inconsistencies, leading to improved text and a better set of diagrams. What's needed is a way to automate and simplify this cycle, so that both technical and non-technical stakeholders can leverage text and visuals to collaborate more effectively and efficiently. Only then can true business/IT alignment be achieved.

So where's your requirements problem? Taking the time to find out can go a long way towards ensuring greater software development success.