An Extreme Requirements Method

In the last few years , the notion of Extreme Programming (XP) as originally espoused by Beck [2000] has achieved some popularity (along with a significant amount of notoriety and controversy). One can guess at what has motivated this trend. Perhaps it's a reaction to the inevitable and increasing time pressures of an increasingly efficient marketplace , or a reaction to the overzealous application of otherwise effective methodologies. Alternatively, perhaps it's a reaction to the wishes of software teams to be left alone to do what they think they do best: write code. In any case, there can be no doubt of the "buzz" that Extreme Programming has created in software circles and that the related Agile Methods movement is now creating as it attempts to add balance and practicality to the extreme approach.

Before examining how we might define an extreme requirements method, let's look at some of the key characteristics of XP.

• The scope of the application or component permits coding by a team of three to ten programmers working at one location.

• One or more customers are on site to provide constant requirements input.

• Development occurs in frequent builds or iterations, each of which is releasable and delivers incremental user functionality.

• The unit of requirements gathering is the user story , a chunk of functionality that provides value to the user. User stories are written by the customers on site.

• Programmers work in pairs and follow strict coding standards. They do their own unit testing and are supposed to routinely re-factor the code to keep the design simple.

• Since little attempt is made to understand or document future requirements, the code is constantly refactored (redesigned) to address changing user needs.

Let's assume you have a project scope that can be achieved by a small team working at one location. Further, let's assume that it's practical to have a customer on site during the majority of the development (an arrangement that is admittedly not very practical in most project contexts we've witnessed). Now, let's look at XP from the standpoint of requirements methods.

A key tenet of any effective requirements method is early and continuous user feedback. From this perspective, perhaps XP doesn't seem so extreme after all. Table 30-2 illustrates how some key tenets of XP can be used to mitigate requirements risks we've identified so far.

With this background, let's see if we can derive a simple, explicit requirements model that would reflect or support an XP process. Perhaps it would look like Figure 30-1 and have the characteristics described briefly below

Figure 30-1. An extreme requirements method

Concept. At the heart of any requirements process lives the product concept. In this case, the concept is communicated directly from the customer to the project team ”verbally, frequently, and repeatedly as personnel come and go on the team.

Vision. The vision carries the product concept, both short-term and long- term . A Delta Vision document typically describes the new features and use cases to be implemented in a specific release. In XP, this document may not exist. We are dependent on the customer's ability to tell us what the product needs to do now and what it needs to do later, and we are dependent on the development team to make the right architectural decisions now ”for both now and later. Whether or not this can be made to work in practice depends on a number of project factors and the relative risk the team is willing to take; you can't say for certain that it couldn't work, at least for some project scenarios. ^[3] Therefore, we'll leave this artifact out of our extreme requirements method.

^[3] As we said, the method is not without its critics . One reviewer noted the big drawback of the "one user story at a time" approach is the total lack of architectural work. If your initial assumption is wrong, you have to refactor the architecture one user story at a time. You build a whole system, and the nth story is, "OK, this is fine for one user. Now, let's make it work for 3,000."

Table 30-2. Applying Extreme Programming Principles to Requirements Risk Mitigation

Extreme Programming Principle	Mitigated Requirements Risk
Application or component scope is such that three to ten programmers at one location can do the coding.	Constant informal communication can minimize or eliminate much requirements documentation.
One or more customers are on site to provide constant requirements input.	Constant customer input and feedback dramatically reduces requirements-related risk.
Development occurs in frequent builds or iterations, each of which is releasable and delivers incremental user functionality.	Customer value feedback is almost immediate; this ship can't go too far off course.
The unit of requirements gathering is the user story, a bite of functionality that provides value to the user. Customers on site write user stories.	A use case describes sequences of events that deliver value to a user, as written by the developer with user input. User stories are often short descriptions of a path or scenario of a use case. Each captures the same basic intent ”how the user interacts with the system to get something done.

Requirements. Another principal tenet of our text is that the use-case model carries the majority of functional requirements. It describes who uses the system and how they use it to accomplish their objectives. XP recommends the use of simple "stories" that are not unlike use cases but are typically shorter (they appear to be more like a use-case scenario) and at a higher level of abstraction. However, we recommend that there always be a use-case model, even if it's a simple, nongraphical summary of the key user stories that are implemented and what class of user implements them. We'd insist on this use-case model, even for our extreme requirements method.

Supplementary Specification/Nonfunctional Requirements. XP has no obvious placeholder for these items, perhaps because there are not very many, or perhaps the thinking is that they can be assumed or understood without mention. On the other hand, perhaps customers communicate these requirements directly to programmers whose work is affected by them. Seems a bit risky, but if that's not where the risk lies in your project, so be it; we'll leave this artifact out of our extreme requirements method.

Tooling. The tools of XP are whiteboards and desktop tools, such as spreadsheets with itemized user stories, priorities, and so forth. However, defects will naturally occur, and although XP is quiet on the tooling subject, let's assume we can add a tracking database of some kind to keep track of all these stories ”perhaps their status as well as defects that will naturally occur and must be traded off with future enhancements.

With these simple documents, practices, and tools, we've defined an extreme requirements method that can work in appropriate, albeit somewhat extreme, circumstances.