The Capture, Analysis, and Presentation of Requirements

The following 19 tips for agile requirements modeling are drawn from Chapter 4 of Scott W. Ambler's forthcoming book, The Object Primer, 3rd Edition: Agile Model Driven Development with UML 2 (Cambridge University Press, January 2004) and were published in the July 2003 issue of Software Development's Agile Modeling Newsletter. They are intended to help to set an effective foundation for agile requirements-modeling efforts:^A.1

1. ``Active stakeholder participation is crucial." Project stakeholders must be available to provide requirements, to prioritize them, and to make decisions in a timely manner. It's critical that your project stakeholders understand this concept and are committed to it from the beginning of any project.
2. ``Software must be based on requirements." If there are no requirements, you have nothing to build. The goal of software development is to build working software that meets the needs of your project stakeholders. If you don't know what those needs are, you can't possibly succeed.
3. ``Nothing should be built that doesn't satisfy a requirement." Your system should be based on the requirements, the whole requirements, and nothing but the requirements.
4. ``The goal is mutual understanding, not documentation." The fundamental aim of the requirements-gathering process is to understand what your project stakeholders want. Whether or not you create a detailed document describing those requirements, or perhaps just a collection of hand-drawn sketches and notes, is a completely different issue.
5. ``Requirements come from stakeholders, not developers." Project stakeholders are the only official source of requirements. Yes, developers can suggest requirements, but stakeholders need to adopt those suggestions.
6. ``Use your stakeholders' terminology." Don't force artificial, technical jargon onto your project stakeholders. They're the ones doing the modeling - and the ones the system is being built for - therefore, you should use their terminology to model the system.
7. ``Publicly display models." Models are important communication channels, but they work only if people can actually see - and understand - them. I'm a firm believer in putting models, even if they're just sketches or collections of index cards, in public view where everyone can access and work on them.
8. ``Requirements change over time." People often don't know what they want - and if they do, they usually don't know how to communicate it well. Furthermore, people change their minds - it's quite common to hear stakeholders say, ``Now that I think about this some more ..." or ``This really isn't what I meant." Worse yet, the external environment changes - perhaps your competitors announce a new strategy, or the government releases new legislation. Effective developers accept the fact that change happens and, better yet, they embrace it.
9. ``Requirements must be prioritized." Stakeholders must prioritize the requirements, enabling you to constantly work on the most important ones and thus provide the most value for their IT investment.
10. ``Requirements only need to be good enough." Not perfect? But you'll build the wrong thing! Agile developers don't need a perfect requirements specification, nor do they need a complete one, because they have access to their stakeholders. Not sure what a requirement means, because there isn't enough detail? Talk with your stakeholders and have them explain it; if they can't explain it, keep talking.
11. ``Use simple, inclusive tools and techniques." It's possible, and in fact desirable, for stakeholders to be actively involved in modeling. However, stakeholders typically aren't trained in modeling techniques, nor complex modeling tools. Although one option is to invest several months to train your stakeholders in modeling tools and techniques, a much easier approach is to use simple tools, like whiteboards and paper, and simple modeling techniques. Simple tools and techniques are easy to teach and are therefore inclusive because anyone can work with them. Don't scare people with technology if it's not needed!
12. ``You'll still need to explain the techniques - even the simple ones." Because people learn best by doing, it's often a good idea to lead stakeholders through the creation of several examples.
13. ``Most requirements should be technology independent." I cringe when I hear terms such as ``object-oriented", ``structured" or ``component-based" requirements. These terms are all categories of implementation technologies and therefore reflect architectural and design issues.
14. ``Some requirements are technical." It's important to recognize that some requirements, such as the technical constraint that your system must use the standard J2EE and relational database technologies employed within your organization, are in fact technology dependent. Your stakeholders should understand when this is applicable, and why.
15. ``You need multiple models." The requirements for a system are typically complex, dealing with a wide variety of issues. Because every model has its strengths and weaknesses, no one single model is sufficient; therefore you'll need several types of models to get the job done.
16. ``You need only a subset of the models." When you fix something at home, you'll use only a few of the tools in your tool box, such as a screwdriver and a wrench. The next time you fix something, you may use different tools. Even though you have multiple tools available, you won't use them all at any given time. It's the same thing with software development: Although you have several techniques in your ``intellectual toolbox," you'll use only a subset on any given project.
17. ``The underlying process determines some artifacts." Different methodologies require different requirements artifacts. For example, the Rational Unified Process and Enterprise Unified Process both require use cases, Extreme Programming requires user stories and Feature-Driven Development requires features.
18. ``Take a breadth-first approach." It's better to first paint a wide swath to try to get a feel for the bigger picture, than to focus narrowly on one small aspect of the system. By taking a breadth-first approach, you quickly gain an overall understanding of the system, and you can still dive into the details when appropriate. Taking an Agile Model-Driven Development approach, you gain this broad understanding as part of your initial modeling efforts during ``Cycle 0."
19. ``Start at your enterprise business model." Some organizations have what's called an enterprise business model that reflects their high-level business requirements. If your organization has one, and it's current, it's a perfect starting place to understand both your organization and how your system fits the overall picture. You should be able to identify which high-level requirements your system will (perhaps partially) fulfill; otherwise, it's a clear sign that either the model is out-of-date or it's not necessary in your organization.