Agile or Not, Requirements Management Can’t Be Skipped

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.

Post navigation

The only way to know what you are building is to develop the functional and non-functional requirements of a system or software package. Agile developers focus too much on doumentation and dismiss it entirely. In an agile shop, user stories developed with the software team and clienst fill the need for system requirements enegineering. While I appreciate agile techniques, I feel that a team should use the framework that gets the job done. This is why you engage in requirements engineering to ensure that you are building the right system or solution to your problem.

Requirements management is a necessary part of the system development life cycle and ensures that a development team is building the right system for its purposes. Agile proponents dislike the extensive documentation generated from “trawling” functional and non-functional requirements from clients. They prefer the client and the team being in the same room creating user stories to describe the system. There has been an agile versus non-agile war in the software engineering community in the last few years. Agile and non-agile approaches have good procedures and life cycles but a team should use the philiosophy that makes sense for their organization.