Should your requirements practices embrace the change-driven approach of agile methods--lightweight models, minimal documentation, and little process? Or should you take a risk-driven approach--robust models, careful validation, and rich documentation? In this two-part weekly column, Ellen Gottesdiener explains that you should tailor your requirements practices to your project and product.
That is true wisdom, to know how to alter one's mind when occasion demands it.
~Terence, Roman comic dramatist (185-159 BC)
When I help teams define software requirements, I often encounter people confused by when and how to adapt existing requirements practices to fit different situations. I recently spoke with a team that was implementing a large, complex software package for processing the company's core business activities. This team needed to do three things: understand the company's business processes, engage stakeholders in making the needed business changes, and determine what functionality to implement.
Another company I worked with wanted to leverage its successes in conducting facilitated workshops to accelerate a major enhancement effort--adding functionality to a device from an existing product line. A large amount of functionality was already implemented, and the architecture was in place. The team had a good grasp of the desired quality attributes and a habit of writing overly detailed textual requirements that were ignored by engineering. Compared with the first team, this one had a different set of tasks: efficiently defining and prioritizing user requirements to meet a time line for a critical market segment.
In both situations, what the project teams needed most was to choose the best requirements approach to work in these new project situations.
Experts continue to study and describe good practices for developing and managing requirements, but we've known for some time that there is no cookie-cutter solution. Certain practices may or may not fit your project, and other practices must be tailored to fit.
Add to this challenge the conflicting approaches of differing software development paradigms, such as agile development versus traditional software engineering. A common misconception is that agile development projects "don't do" requirements. Consequently, some agile teams often ignore commonsense requirements practices in their drive to create working software. It is true that in the end what satisfies the customer is not simply a documentation of requirements, but working software that meets real customer needs. Agile products need requirements. The differences between agile and traditional software engineering methods are the volume, depth, longevity, and formality of requirements practices and documentation.
When you're deciding on requirements practices for your situation, what do you need to consider?
Risk-Driven Versus Change-Driven Projects
A useful approach is to broadly categorize your software project as risk-driven or change-driven. Risk-driven projects tend to involve critical systems (those in which failure would place the business, mission, or safety at risk). Examples of risk-driven projects are plan driven or prescriptive. They often have stable requirements, require large teams--perhaps with some members geographically distributed--and rely on more formal documentation.
Change-driven projects, such as agile, adaptive, or dynamic projects, tend to develop or acquire software that poses less risk and complexity than risk-driven projects. Change-driven projects have more volatile requirements and tend to involve smaller teams, often physically collocated. In practice, most projects fall somewhere between these extremes. Remember that these are generalizations-agile, change-driven practices can be applied to the classic definition of risk-driven projects.
Adapting Your Practices
Figure 1 (above) shows an example of requirements practices you can adopt based on the nature of your project. It's sensible and practical to use some practices (shown in the center) for all types of projects. For example, it doesn't take long to create a well-defined vision statement and a glossary of common business terms, and these documents set the stage for success. Likewise, defining a wide and narrow subset of user requirements provides a basis for modeling portions of the system on a just-in-time basis. And performing a peer review-ranging from informal scenario or prototype walkthroughs to more