Less Is More

It's reasonable to define what you're going to build before you build it; to identify the requirements for something before you code it. What isn't reasonable is defining all of the requirements in a comprehensive document before you begin implementation—experience shows that this approach is not only a poor way to work, but actually puts your project at risk. In the U.K., Andrew Taylor's 2001 study of 1,027 projects ("IT Projects Sink or Swim, British Computer Society Review) revealed that scope management related to attempting waterfall practices—including detailed, up-front requirements—was cited by 82 percent of failed projects as the number one cause of failure.

Why are people motivated to pack on the pounds when it comes to requirements? They often believe that they need all of the requirements defined before they can accurately develop cost and schedule estimates. However, according to the Standish Group's 2003 Chaos Report, 15 percent of projects are outright failures and 51 percent are over budget, over time or missing critical features. Also, many stakeholders believe that they need detailed requirements to ensure that they get what they ask for. Unfortunately, what you ask for at the beginning of a project is rarely what you need once it's delivered (see "Benefiting from Brevity).

Agile Requirements Management

To handle this quixotic situation, try just enough initial modeling to identify project scope and develop a high-level schedule and estimate. Then, during development, you can model storm in a just-in-time manner (See "The Best-Kept Secret?, The Agile Edge, Oct. 2004) to explore each requirement in detail.

[click for larger image] In Practice Both XP and Scrum take a lean approach to deciding when requirements will be implemented.

Setting Priorities

New requirements, including defects identified as part of your user testing activities, are prioritized by your project stakeholders and added to the stack in the appropriate place. Your project stakeholders can define new requirements, change their minds about existing ones, and even reprioritize them as they see fit. However, they must also be responsible for making decisions and providing information in a timely manner.

When it comes to requirement prioritization, a single person must be the final authority. In Scrum, this person is called the product owner. The product owner must work with the other stakeholders to ensure everyone is represented fairly—often a difficult task. Beware a potential liability of this approach: Your stakeholders might prioritize the requirements in such a way as to push an architecturally significant (read devastating) requirement several months forward. For example, the need to support several technical platforms can cause significant havoc to project teams that are unprepared for these changes. In my experience, the order of requirements doesn't matter as long as you keep your design modular and of the highest quality possible via refactoring. Also, just as you do some initial requirements modeling up front, make sure to do some initial architectural modeling up front. You'd be amazed at how quickly you can sketch a few whiteboard diagrams that capture a viable architectural strategy for your team.

Estimating Requirements

Developers are responsible for estimating the effort required to implement the requirements that they'll work on. Although they may initially lack the requisite skills, it doesn't take long for people to hone their estimation expertise when they know that they'll have to live up to those estimates.

Smaller requirements are easier to estimate accurately. Shall statements, such as "The system shall convert feet to meters, are an example of very small requirements. User stories are a little larger but still relatively easy to estimate. Use cases can become too large to estimate effectively, although you can reorganize them into smaller and more manageable artifacts.

Use this rule of thumb: A requirement must be implementable within a single iteration. Scrum teams usually have month-long iterations, whereas XP teams often choose one- or two-week iterations. Short iterations reduce the feedback cycle, making it easier to stay on track. Successful teams deploy a working copy of their system at each iteration's end into a demo environment where their stakeholders have access to it. This provides another opportunity for feedback, often generating new or improved requirements, and shows stakeholders that the team is making progress.

The primary weakness of this approach? It isn't clear how much the system will cost because as the requirements change, so must the cost. But so what? When you deliver working software at each iteration's end, your stakeholders are completely in control of the purse strings—once they've had enough, they can stop funding the project. Would you rather have a detailed—and probably wrong—estimate up front, or be in control and spend your money wisely? The approach I'm describing enables the latter.

Embrace Change, Don't Prevent It

Active stakeholder participation throughout the project's lifecycle is key. Stakeholders must prioritize requirements, make decisions and provide information in a timely manner. Because they're the business experts, they should also be actively involved with any requirements and analysis modeling efforts. By embracing change and finding ways to truly manage requirements, you can deliver software that meets the needs of your users in a timely and cost-effective manner. Who can say no to that?