Requirements revisited

in Issue#4 Requirements by gustav — 2010/12/02 at 11:37 | 0 comments

To understand the parallel development of use cases and user stories you have to go back to the 1960s. At that time, Ivar Jacobson invented use cases for his own use when he was working with Ericsson telephony systems. “When you look at particularly the ‘extensions’ aspect of use cases, you can still see remnants of Ericsson telephony systems”, says Cockburn. At that time, they would lock the documents at a certain point, so you could not make any more changes to them. An ”extension” was a way to write a new document and say, “At step 17 of that old document, we want to detect the following condition and insert the following behavior.” This makes good sense for that environment, but of course doesn’t make much sense for our modern electronic-repository based and hyperlinked requirements tools.”

“The other thing was that in telephony”, Cockburn continues, “services are largely additive. A customer owns a simple service, then adds call waiting. The execution of call waiting is that the simple services runs, and then is interrupted by a condition – the call waiting – that the system detects, at which point it goes off and does that behavior, then returns to the simple service. Here again, you can see that the extensions model of use cases makes good sense – it describes interrupting a flow of behavior to inject a new flow of behavior.”

Ivar Jacobsen left use cases alone in the 1970s, and revisited them in the 1980s when he was writing his Ph.D. dissertation. At that point he introduced them for general application development.

“What I had to test for my methodology was whether his form of writing, which works so well for telephony, works well also in application development. It was not clear in 1991 that it would. Over the years, I have found that it works remarkably well for general process descriptions of all sorts, and particularly black-box requirements for interactive software applications.” User stories got their start when Kent Beck was looking for lighter, faster ways to gather feature requests. (Note, he does not like the word “requirements”).
He was working in areas where there were not many users, so he could literally walk down the hall, ask the user a question, walk back and start typing.

“In 1993, I attended a workshop called WOOD (Workshop on Object-Oriented Design)”, says Cockburn. “It was held at the Snowbird ski resort (not accidentally the same place we wrote the agile manifesto – we several times held workshops there). At that workshop, Ivar talked about use cases for almost two days. As we left, I recall thinking that we were in for a rough time, because it was clear that everyone had formed a different impression of what a use case was – and the people in the room were all notable writers: Adele Goldberg, Kenny Rubin, Jim Rumbaugh, Larry Constantine, Kent Beck, Martin Fowler and others.”

Sure enough, at the next WOOD in 1994, Ivar Jacobsen wasn’t present. Among the 17 people present, 14 different definitions for “use case” were found based on memories of the previous year. Martin Fowler offered the quip, “I think use case
is just Swedish for ‘scenario’.” And Kent Beck said, “Just ask the users what they want, and write that on a card.” The cards should have no particular structure – duplication and overlap were allowed. The point was only to find out what the real users wanted. Real diligence would need to be applied.
Kent Beck got to try his card method out in several places, including Wall Street firms and on the Chrysler payroll system. Those are very different environments, and have very different user types – the only thing they have in common is a small user base.  Kent Beck came to call these things “user stories”.

“In strong distinction to use cases, user stories were supposed to be informal ‘reminders to have a conversation’ as opposed to requirements documents, they were to be written on index cards as opposed to being maintained online, they were to reflect what real users requested as opposed to consolidated decisions made by business analysts, and they were not to have any particular structure, as opposed to the structured form that use cases have.”
“And that,” Cockburn concludes, ”started the long wars between use cases and user stories.”

Tags: featured requirements usecases userstories

More posts by gustav »

Author: GustavBergman

Gustav Bergman is the Editor-in-chief for Lean Magazine since 2008. He has a background as a project manager in the Swedish Telecom Industry for ten years, and in marketing for several software companies.