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 formal inspections-will validate customer needs and improve your software's quality.
Some amount of requirements growth and change is normal. The practice of "playing around" with a product is an excellent way to explore and learn about users' real needs. It also helps teams adapt to changing requirements. Using requirements models or partial working prototypes, customers can play with a product early on and help clarify their needs. This practice translates into defining requirements iteratively, whether your project is change or risk driven.
Of course, you should always consider how the requirements documentation you create will be used in the project. If your developers are offshore, for example, sending them stories written on index cards won't give them enough information to know what to build. When you outsource or contract development, your documentation needs to be more formal. However, it's probably overkill to write detailed functional requirements after developing multiple interwoven user requirements models--process maps, scenarios, business rules, a data or class model, prototype sketches--unless defects in your product pose safety threats.
Before beginning your requirements work, get the team together to define the depth and breadth of the analysis models and documentation you'll need. Ask yourself and your team, do you really need that additional text? Who will use it? How? How much will it cost to produce this documentation? Where does creating this documentation fall among other requirements stakeholders want? Do the benefits from its use outweigh the costs of producing the documentation?
Until Next Time
The change-driven versus risk-driven classification is a useful way to improve your requirements practices, but it isn't the only technique. In part two, I'll look at other factors that influence adaptation choices.
Appreciation
I would like to thank Ian Alexander, Scott Ambler, Rachel Davies, Mary Gorman, Michal Patten, David Spann, John Suzuki, and Karl Wiegers for their helpful review of these columns.
Recommended Reading
Scott Ambler, "Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process"
Barry Boehm and Richard Turner, "Balancing Agility and Discipline: A Guide for the Perplexed"
Ellen Gottesdiener, "The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements" and "Requirements by Collaboration: Workshops for Defining Needs"
Craig Larman, "Agile & Iterative Development: A Manager's Guide"
Karl Wiegers, "More About Software Requirements: Thorny Issues and Practical Advice"
Click Here to Read Adapting Your Requirements Practices - Part 2
