In part 1 of this article (published as a weekly column on May 22), Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management.
Not all software projects are alike, and not all requirements approaches work in all situations. When you assess how to adapt your requirements practices for your project, consider factors such as the product's usage and the project's economics.
For example, if your software is part of a product line serving a vertical market, it needs to share common functionality with other products and will undergo frequent adaptive enhancements. In this situation, you may decide it is essential to have well-documented requirements, strong prioritization practices, and well-defined quality attributes. If your software will be used to enforce regulations or might be examined for compliance by external agencies (such as FDA, FDIC, IRS, or state insurance boards), then you may choose to rely on robust requirements documentation and traceability.
Alternatively, if you're under pressure to deliver a software product quickly to new markets, you will probably require less formal documentation, and it may make sense to use prototypes and lightweight stories.
Factors Influencing Requirements Adaptation
Figure 1 above shows the factors I use when recommending requirements practices to teams. Note that the factors are divided into project type, product characteristics, product usage, social, and economic factors. Analyzing your project in this way gives you a useful profile of your product and project and helps you make smart decisions in adapting your requirements methods.
I've found that teams tend to be familiar with analyzing factors in "hard" categories such as product and economic considerations, but less confident of their ability to address the social issues involved in software development.
These social factors are critical when you make decisions about adapting requirements. If team members are collocated and have healthy interactions, typically you can use more relaxed requirements documentation--sketches or models on paper or whiteboards--and less notation. If you are a team-of-teams or your culture demands formal reporting or bureaucratic oversight, you may have to live with more rigor (or, as Alistair Cockburn nicely describes it, "ceremony") in your documentation.
Ready stakeholder access and involvement are critical success factors for any software project. What is your situation vis-à-vis stakeholders? Agile development requires an on-site customer (or as close to that as possible). Having informed, accessible customers lets you exploit informal conversations, frequent show-and-tell sessions, and exploratory prototypes.
If you have on-site customers, do they really represent the needs of all your end-user communities? Do they have the right subject matter expertise? If they don't, then you need to adapt your practices, validating requirements with additional stakeholders. Otherwise you risk getting the wrong requirements. In this situation, it makes good sense to add practices such as requirements workshops, walkthroughs or other informal peer reviews, and detailed user requirements models to your agile approach.
Adapting Elicitation and Analysis Techniques
I've had a lot of experience in helping teams conduct requirements workshops. I've worked with large, distributed teams that push the envelope on stakeholder involvement by using multiple facilitated workshops to elicit, analyze, and validate requirements in days rather than weeks or months. Yet other teams I work with use short, focused, agile modeling sessions followed by prototypes to explore requirements quickly and efficiently. They then apply agreed-upon prioritization schemes to quickly reach closure on requirements. In both cases the same practice-workshops--is adapted to the specific product and project.
The analysis models you choose should also fit your problem domain. Many project teams believe that to do requirements right they must employ use cases or--now more popular--user stories. The smart choice is to use the right analysis model for the problem domain. For example, I do not recommend adopting stories or use cases to represent