 |
Home > Detail: Adapting Your Requirements Practices - Part 2 of 2
Viewing Item 1 of 1325
| A StickyMinds.com Original |
|  | |
Adapting Your Requirements Practices - Part 2 of 2
By Ellen Gottesdiener
   
Summary: 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. | | |
|
|
 |
 Hear more about this topic in the Gray Matters podcast interview with Ellen Gottesdiener.
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.
People Matters
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 user needs when the software is about querying and reporting. Rather, you should explore users' questions as a means of eliciting attributes and rules. You will get the needed user requirements more quickly.
Most project teams can adapt the best of agile modeling by slicing through lightweight models iteratively and then adding detail as needed. On one recent project, we generated a context diagram and event-response table to first clarify scope (taking less than two hours, with key stakeholders present). We then generated the names (only) of proposed use cases and created a list of initiating actors; this allowed us to drill down a level in our understanding and partition the product into feature sets. As we discovered new user requirements, we adjusted the event-response table and context diagram to reflect our new understanding.
Stakeholders then prioritized the feature sets, and the technical team added risk and architectural dependency considerations. This enabled the team to establish a release strategy and then go deep into a subset of use cases that would serve as the basis for an exploratory prototype. Using a role-playing technique in an informal workshop, the stakeholders defined detailed scenarios (which were recorded in a template, as they were being used as the basis for test cases) along with loosely written business rules. They also sketched data and class models on a whiteboard. In the afternoon, the team developed a prototype to test with the stakeholders on the following day.
Summary
If you're developing a product, it's essential to understand its requirements. All the techniques I've mentioned (and many others) work well for eliciting requirements--but not all of them work equally well in all situations. If you want smart requirements, you need to synthesize, adapt, and adopt requirements practices after considering your product and project situation.
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 1
About the Author
Ellen Gottesdiener helps teams to collaboratively explore requirements, shape their development processes, and plan and review their work. She is author of "Requirements by Collaboration: Workshops for Defining Needs" (Addison-Wesley, 2002) and contributing author to several other books. Ellen's latest book is "The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements" (GOAL/QPC, 2005). She presents seminars, is a conference speaker at numerous industry events, has authored numerous articles, and is a certified professional facilitator (CPF). She can be reached at ellen@ebgconsulting.com and http://www.ebgconsulting.com.
Back to Top
|
