Adapting Your Requirements Practices, Part 2 of 2

[article]
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.

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

About the author

Ellen ellensqe's picture Ellen ellensqe

Ellen Gottesdiener, Founder and Principal with EBG Consulting, is an internationally recognized facilitator, coach, trainer, and speaker. She is an expert in Agile product and project management practices, product envisioning and roadmapping, business analysis and requirements, retrospectives, and collaboration.

In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis with Mary Gorman, Ellen is author of two acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

View articles, Ellen’s tweets and blogfree eNewsletter, and a variety of useful practitioner resources on EBG's website, ebgconsulting.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03