Gathering requirements is job number one for the development team today. According to SearchSoftwareQuality.com's...
2008 Agile Trends survey, when it comes to application lifecycle management, organizations are often thwarted when they try to figure out what users want. Effectively gathering user requirements has never been easy -- and it is not getting easier as development teams seek to employ more Agile processes.
Requirements gathering was cited by 31% of respondents to the survey as the lifecycle area with which they have the most difficulty. That beats process improvement (12%), software testing (12%), and application performance management (8%) as certified areas of pain.
Requirements have often been cited as a stumbling block. So, what is new? The rise of Agile development processes has changed requirements as much as any other part of development. Agile-based principles are more open to adding and refining requirements later in the development process and to having as thin a level of document detail as possible -- less detail than was common in requirements gathering for traditional software processes.
With the Agile movement has come an upsurge in use of user stories to gather requirements -- user stories being seen as a more agile way to elicit user needs.
But the user story, cited as a requirements gathering technique by 26% of our survey respondents, remains just one of many requirements techniques. Agile Trend survey respondents tended to select several techniques. User requirements models (40%), focus groups (41%) and the ubiquitous spreadsheet (35%) are also part of the wide requirements gathering tool kit of 2008.
Use cases, often associated with use of the Unified Modeling Language (UML) notation and with pre-Agile processes such as the Rational Unified Process (RUP), have by no means been fully supplanted by user stories. Use cases were employed by survey respondents' organizations to the tune of 50%. Overarching all, and covered obviously by other techniques, is the user interview (67%).
A range of companies focuses on tools that support the objectives of Agile-style requirements gathering. Count among these AxoSoft, Blueprint, IBM, iRise, MKS, NetObjectives, Rally Software, Ravenflow, Sparx Systems, Telelogic (recently merged into IBM), ThoughtWorks, and VersionOne.
The fact that Microsoft Excel is a commonly used requirements tool -- as are the whiteboard and the index card -- should not be overlooked. Even vendors admit "soft skills" are required: Success rests on how you use the requirements tools and how much your team is able to elicit valid requirements from people in the enterprise. That is pretty much true whether you employ user stories or use cases. But why are requirements so challenging?
"It's an art and a science," said Daniel Moul, IBM Rational offering manager for requirements. "It involves the soft skills of working with people and teasing out their ideas, and then going through all of the requirements definition cycle."
"It starts with somewhat vague statements of need and moves to precise and actionable statements of what the system needs to conform to," he added.
"It's about having the product owner being an active participant in defining the requirements," said Jim Highsmith, director of Cutters Agile Product and Project management practice.
User stories vs. use cases
How do user stories stack up against use cases? The use case may be thought of as preceding the user story in the annals of requirements jargon. Use cases have been described as a series of events told from the point of view of an actor -- or system user.
Use cases were part and parcel of UML, used as a notation to achieve better development outcomes. The use case was also associated with RUP, which more than a few developers judged to be too complex. RUP and other processes led in turn to counter trends Extreme Programming (XP) and its slightly more subdued sibling known as Agile development.
Meanwhile, user stories have been described as system requirements formed in just a few sentences that use the language of the user. The user story's drive for brevity plays to the widespread desire to streamline the requirements task. As part of traditional processes, requirements gathering often seemed to result in voluminous documents that did not lead to successful final systems. And those requirements were not visible to the whole team during the life of the entire project.
Clearly, use case techniques may be influenced by the user story, and vice versa. Use cases in Agile style development can succeed, said David West, managing director at Ivar Jacobson Consulting, if teams focus on specifying only things that will actually get implemented, and that these things are specified at the appropriate level of detail.
IBM RUP users among the development groups at Swedish truck maker Scania have adapted use cases to new processes and have taken a few pages out of the Agile playbook.
"We used use cases as we used them in RUP SE," said Anna Hard Af Segerstad, senior program manager at Scania. "But we put them on a wall so everyone could walk around and view them. So everyone in the team could get the same view of the system."
Segerstad described a service-oriented architecture (SOA) project in which a new order management system was created to interface to legacy systems. Among lessons learned: It is best to develop detailed requirements in an iterative approach. Segerstad, shared her SOA requirements gathering experiences in a technical session at the IBM Rational Developers 2008 Conference in Orlando, Fla.
Tools of the requirements trade
The differences between use cases and user stories can be subtle. But a simple view may hold that "use cases are bigger and more complex," said Kevin Brennan, vice president at the International Institute of Business Analysis, a group that was founded to help professionalize the role of the business analyst. In turn, he suggested, "a user story can be viewed typically as one thing a user wants to do."
"Typically you would look at a user story being a scoping tool in Agile development. You use it to figure out what you are going to build in an iteration. The actual work is then done between the developer and the stakeholder," said Brennan.
That work involves detailing exactly how the product is going to work. Meanwhile, use cases tend to lead to a document, and the developer's task is to work through the document.
Where use cases might be used would be in more complex settings, said Brennan, where different kinds of users interact with the system.
There are important similarities in the techniques.
"Both use cases and user stories have the advantage of being linear, readable, and easy to understand," Brennan said.
The diversity of user requirements gathering techniques almost guarantees that many tools will be used for some time to come.
"There are plusses and minuses with all the [requirements] techniques. No one technique is going to be perfect for all occasions. My feeling is that a business analyst has to be comfortable with several of them," Brennan said.