1.5 Agile Requirements Processes


1.5 Agile Requirements Processes

"You are old, father William," the young man said,
"And your hair has become very white;
And yet you incessantly stand on your head.
Do you think, at your age, it is right?"
-Alice's Adventures in Wonderland,
Lewis Carroll

This section discusses the role of requirements when taking an agile approach to building a system. It is aimed at developers and architects who aren't presented with a requirements specification as their starting point. Adopting an agile outlook isn't all-or-nothing; you can take small steps in that direction, or you can adopt it nearly wholeheartedly. You can do just some parts of a project agilely. You can take a traditional approach to specifying requirements and then perform design and development in an agile manner. In that case, you can use the traditional requirements process described in the previous section, and then take whatever agile approach you wish to the development.

The agile manifesto (which lives at www.agilemanifesto.org) defines an agile outlook as one that values people over processes, software over documentation, collaboration over contracts, and responsiveness over plan. "Software over documentation" is our main guide when deciding how to tackle requirements agilely: we should aim to churn out less documentation. The two approaches that follow concentrate on achieving documentary efficiency while still realizing the value that identifying requirements brings. Let's start with a couple of principles to guide any agile requirements process:

image from book

  • Principle 1: Distinguishing problem from solution is valuable. One way or another, you must decide what a new system must do. You must also decide how it will do it. This principle merely says it's good practice to recognize the what separately from the how and to do it first. It gives you something against which you can later gauge the quality of the solution and to compare the merits of two suggested solutions. It gives you a degree of objectivity that's lacking if everything blurs together.

  • Principle 2: If you identify a requirement, record it such that someone else can find it. This principle does not, however, say where or in what form a requirement should be recorded.

An Extreme Requirements Process

It sounds incongruous to talk about a "requirements process" in the context of extreme programming (XP), because requirements don't appear in concrete form at all in an extreme extreme programming approach. Still, no system can be built without someone deciding what it needs to do, so the requirements are there somewhere. And they must come about as a result of some process or another, however fleeting and ethereal it is. That's the kind of requirements process we're talking about here-with a view to catching and bottling its results.

Building a new system using extreme programming begins by asking users to write a full set of "user stories." A user story is a short description of something the users want the system to do for them. For user stories to be representative, at least one person from each user area (that is, each "actor") must contribute to them. The end result is user stories for the main user functions of the system. Anyone involved in writing user stories might find the requirement patterns in this book helpful for guidance, for suggestions on topics to cover.

Once a set of user stories has been produced, it is used to plan the order in which they are to be implemented. A user story is assigned to a developer, who then figures out how to implement it (starting by defining a set of tests, which XP calls acceptance tests). Each developer must formulate the requirements they are trying to satisfy, even if they are unaware that's what they are doing, and even if the process is over in a split second and never sees the light of day outside their head. The first step in any development task should be to ask: what am I doing? What problem am I trying to solve? Answer those questions before proceeding, and write the answer down as the beginning of the definition of this task's tests. Write it in the form of a requirement (or more than one requirement). Engage a requirement pattern to help you, if there's a relevant one available. A requirement pattern could lead you to recognize the need for extra requirements, some of which might spawn their own development activities.

There are three ways in which requirement patterns can be used in association with extreme programming:

  1. To suggest user stories and what to say in them (to make them more precise or more like requirements).

  2. To interpret user stories in a more systematic manner, to unearth the actual requirements they allude to, and also to identify extra functionality needed to support a function that implements a user story.

  3. To guide the production of a set of "common requirements" to be applied to all systems in your organization, especially rules for good practices to be followed by all developers.

An Incremental Requirements Process

Only perform requirements work as and when it's needed: just in time. That's the premise behind an incremental approach to it. Do a minimum of requirements work up front, so development can begin as early as possible. There are two things to decide here: how detailed the requirements need to be, and when to specify each piece's requirements. At one end of the scale, a full and detailed requirements specification would be written before starting any design and development work; at the other, individual requirements would be defined as part of a development unit. These two are represented by the traditional and the extreme requirements processes already described. An incremental approach is between these two.

Just as agile development involves incremental additions to the software, agile requirements ought to involve incremental additions-that is, gradual expansion of a single set of requirements. Everyone then has the same picture at all times, and we avoid repetition. The requirements specification, like the software, becomes a living being. What's a suitable process for doing this? In keeping with a lean, agile outlook, let's keep it simple:

  1. Specify requirements up front sufficient to convince the customer that we understand what they want from the system (making sure we capture the business objectives) and to get the customer's approval to proceed.

  2. When developer(s) are ready to begin building a particular area, expand the high-level requirement(s) that apply to that area, and specify detailed requirements for everything the system needs in order to satisfy that high-level requirement.




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net