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. The agile approach to software requirements embraces change, flexibility and face-to-face communication in a just-in-time manner. This method can help bridge the communications gap between developers and users that has been a longstanding pain point in software projects.
So what are some approaches to defining requirements within agile teams? Agile development methods focus on defining "just enough" requirements detail for the next sprint. In other words, don't produce any requirements specifications that are not absolutely critical to getting the point across to the rest of the team. So how do you decide what is "just enough," and who makes this decision? What happens when the team is colocated or distributed? How do you deal with changes to these requirements details and their priorities?
According to Martin Crisp, CTO of Blueprint Systems, more detail in your requirements artifacts is a good idea when you're working with a new system, offshore or distributed teams, a newly formed team or a large, complex solution. You can get away with less detail in requirements if you're dealing with a simple or moderate addition to an existing system, a colocated team that has been working together for a while, and a small or simple solution.
What about verbal versus written requirements? Verbal communications with a whiteboard session are typically the fastest way to convey a requirement. According to James Shore, consultant and co-author of The Art of Agile Development, "In the agile world, we believe documents are one of the least effective ways of communicating -- you don't see nuances, tone, facial expressions." So communicating better around requirements requires cross-functional teams that meet together, Shore said. "Agile recognizes that the creation of software is a team activity, and that alone helps bridge the communications gap."
But the verbal-only approach doesn't ensure that all stakeholders are in the loop. It is all too easy for people to have different recollections of details discussed two weeks ago let alone two months ago. This can lead to misunderstanding of requirements during development, testing, writing product user guides and training material. So you may have saved time initially, but wasted more time in the long run. Capturing meeting minutes or taking photos of whiteboards is a starting point for communicating all stakeholders' issues. And whatever techniques you decide to use to document requirements, keeping these requirements details in a central repository and linking them to each other in an organized manner is critical to the collective success of your agile team.
Watch the below video for SearchSOA.com editor in chief Jack Vaughan's insights on the difficulty of requirements gathering as well as the goals and evolution of agile development and how agile and SOA interact.
With the agile development movement has come an upsurge in the 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 2008 agile survey respondents, remains just one of many requirements techniques. Other agile requirements gathering techniques include user requirements models, focus groups and the ubiquitous spreadsheet.
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 a 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 many 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, 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 if these things are specified at the appropriate level of detail.
Betty Luedke
What about Scrum and requirements gathering? One user interested in agile and Scrum wrote to us with the following complaint: "Requirements gathering has been a sticky point for us, with some people feeling that … we have some communication issues with requirements (groups not talking with/understanding each other and so forth)." According to requirements expert Betty Luedke, lingering "communication issues" and "sticky points" are usually symptoms of a project environment that is not fully functioning with the commitment, focus, openness, respect and courage that Scrum require. Taking the leap to Scrum means that everyone on the team will need to have (at a minimum):
An understanding of basic principles and practices.
A commitment to working differently.
Roles assigned and accepted.
Financial and moral support for learning and transitioning to a new approach (training, coaching).
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.
