These days, requirements management is often misunderstood or under-appreciated in IT. Many people have used migration to Agile methodologies as an excuse to discard requirements or rethink how they're used to support most projects. One of the key tenets of Agile application development is not to over-think technical requirements in advance. The premise is that it's usually impossible to accurately predict the details, which would invariably lead to costly rework after the fact—as opposed to an Agile approach of incremental refinement. So who's right? Do Agile advocates make a convincing case that a too-precise definition of requirements is counterproductive, or does the more traditional view of requirements management make more sense? Before we answer that question, let's review several pertinent factors:

• Not all IT projects involve coding (for example, software development).
• Even Agile methodology includes some level of requirements definition.
• Many, if not most, organizations track "functional" level business requirements, a task usually managed by business analysts.
• The majority of people who collect and manage requirements don't follow a specific methodology, since it's often considered less important than the follow-on development or implementation activities. What's more, most people don't realize that requirements management is a collaborative activity.

Maybe both camps are wrong, or perhaps both approaches suffer from a similar flaw. Traditional requirements management and Agile requirements represent two ends of a spectrum—and each assumes the other end is ineffective.

Common Ground

As in most things, the truth lies somewhere in between. Not all requirements are the same, so they shouldn't all be managed the same way. Either camp could go wrong in this area. Also, the main reason that requirements management has come under criticism isn't that defining solutions up front is intrinsically wrong, it's that defining solutions out of context is. Followers of both traditional Waterfall and Agile techniques can fail to define solutions in context. The difference is that with Agile, the flawed results are more likely to be noticed early. Context can be lost when a team develops requirements without:

• End-user input
• Stakeholder input
• Use cases and test cases
• Mechanisms for validation and incremental development
• Integration of business and technical requirements processes.

It's worth pointing out that the controversy over whether requirements management is a worthwhile practice hasn't led to widespread insight into how it can be corrected. Instead, it has led to sporadic use of requirements or a complete disregard for them. Meanwhile, even with Agile, the success rates of IT projects haven't improved all that much.

The Best of Both Worlds

Requirements management is the most logical place to integrate business and technical processes and teams. Instead of moving from one either/or philosophy to another, we should take the best elements of each camp and create a better approach. Far from abandoning requirements as a central part of every project, it's time to start advocating their use in all projects. Here's why: Requirements are the foundation of all good design and architecture, all portfolio and project management, and all project or solution collaboration. If compiled properly, they capture vision and thinking from a diverse spectrum of team members and document the solution as it's progressing. As we said, not all projects need to apply requirements the same way. Conditional requirement approaches might be applied to these project categories:

• Pure Development: Little or no code reuse. This might involve a more Agile approach, including more experimentation and more test-driven or scenario-driven requirements.
• Commodity Development: Significant use of existing libraries or software packages. This might focus more on integration and performance requirements. For example, an existing knowledge base may support more detailed technical requirements.
• User Interface-Driven Solutions: Much more focused on event-driven expectations and extensive user stories.

Requirements don't have to predict all aspects of a solution, and they can be corrected or updated as the solution emerges. They can easily become evolutionary in nature. The bottom line is, don't skip them. Compiling them now can save you a lot of trouble later.