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.
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.
Table 30-2. Applying Extreme Programming Principles to Requirements Risk Mitigation
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. |