screw up. So the dictionary definition of requirements is something mandatory or obligatory. So apparently, they're not required. It's more like wishes.
Carol: I think in some cases that's the case, that…And we sometimes as an industry get caught up in the terminology. And extreme programming, from what I've seen, has its own set of terminology as well.
Kent: Well, where there was a concept that fit precisely, we certainly use it. But where the concepts weren't…Where we wanted a concept with a little different flavor to it, we borrowed words from elsewhere. Like the word for the features that we use in XP is "stories." And it's emphasizing the role…At the level of planning, the role of the business person is to tell stories about what the system ought to do, and the role of the programmer is to listen carefully to those stories. Now, picking that word "story," I was trying to emphasize this idea that we're talking about a human, social process. This isn't requirements capture, it's more like this thing that's been going on for 10,000 or 20,000 years around the campfire, where the important things get passed from one person to another in the form of stories.
Carol: Would you say that stories are the same as rational loads, or use cases?
Kent: No, I don't think they are at all. The most important difference is political. Any time you introduce a complicated piece of technology, you create a group of political haves and have-nots. So you have the people who know how to run the tools, suddenly have power in the project. Unfortunately, the skill to use those tools, or the desire to learn to use those tools, is completely orthogonal to the ability to actually make decent decisions. So use cases, not in concept but as I see them practiced, become something that's very technical. And the programmers typically are the only ones with the patience to figure out what all the different sections are, and what format they should be in, and how to use the tools. So all of a sudden, you have all these programmers running around, making what are essentially business decisions.
Carol: Right.
Kent: So the biggest difference between stories and use cases is one of the balance of political power. Practically speaking, they're quite different also. The use cases oftentimes, early on in the project, gather a lot of detail, and the stories gather detail rather more slowly. At first, it's just a name and an estimate on a card. As time goes on, maybe they'll get a little more detailed, and it's not until one of those weeks in which that story is picked that the rest of the detail gets fleshed out. And at that point, it becomes much more detailed than a use case, because you drive it all the way down to actual automated test cases that will demonstrate the presence of that story in the system.
Carol: Now, one of the things that I've heard, that was given to me as an analogy of what XP is really intended for, is that if I want to go from Santa Cruz to Tampa, and my user, or the person that's defining my trip says, "You must go from Santa Cruz to Tampa." And in traditional development, we'd sit down and we'd chart out, essentially using the AAA Trip-Tiks or something, exactly where we're going to go, where we're going to stop every night, and it's going to keep going like that. And when we finally finish that, and we get in the car,
About the author
Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.
