An Agile Requirements Method

But what if your customer can't be located on site? What if you are developing a new class of products for which no current customers exist? What if the concepts are so innovative that customers can't envision what stories they would fulfill? What if your system has to be integrated with either new systems or other existing systems? What if more than three to ten people are required? What if your system is so complex that it must be considered as a "system of systems" ”with each system imposing requirements on others? What if some of your team members work from remote sites? What if a few potential failure modes are economically unacceptable? What then?

Then you will need a heavier method, one that can address the additional risks in your project context. You will need a method that looks more like the agile requirements method depicted in Figure 30-2. Its characteristics are described briefly below.

Figure 30-2. An agile requirements method

Concept. In the agile requirements method, the root of the project is still the concept, but that concept is tested and elaborated by a number of means, including requirements workshops or interviews with prospective customers.

Vision. The vision is no longer only verbal; it is defined incrementally in the Delta Vision document, which describes the new features to be implemented in a specific release. The whole product plan describes the other elements of your successful solution: the commercial and support factors, licensing requirements, and other factors that are keys to success.

Requirements. The use-case model diagram defines the use cases at the highest level of abstraction. In addition, in this more robust method, each use case has a specification that elaborates the sequence of events, the pre- and post-conditions, and the exceptions and alternative flows. The use-case specifications will likely be written at different levels of detail. Some areas are more critical than others are; other areas are more innovative and require further definition before coding begins. Still other areas are straightforward extensions to known or existing features and need little additional specification.

Supplementary Specification/Nonfunctional Requirements. Your application may run on multiple operating systems, support multiple databases, integrate with a customer application, or have specific requirements for security or user access. Perhaps external standards are imposed on it, or perhaps a host of performance requirements must be individually identified, discussed, agreed to, and tested. If so, the supplementary specification contains this information, and it is an integral artifact to an agile requirements management method.

Tooling. As the project complexity grows, so do the tooling requirements, and the team may find it beneficial to add a requirements tool for capturing and prioritizing the information or automatically creating a use-case summary from the developed use cases. The more people working on the project, and the more locations they work from, the more important version control becomes, both for the code itself and for the use cases and other requirements artifacts that define the system being built.

With some practical and modest extensions to our extreme requirements method, we've now defined a practical agile requirements method, one that is already well proven in a number of real-world projects.