|
Rethinking how you view requirements management
January 22, 2007
URL:http://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-modeling-newsletter/196902703
One of the most visible differences between agile software development and traditional software development is the way that we approach requirements. By now you're probably sick and tired of hearing about how agilists embrace change, so it's time to move past this concept in this newsletter. What I want to explore is three nuances of agile requirements management which we don't hear about as often:
In my January 2007 "Agile Edge" column entitled Agile Testing Strategies I described how many agile teams choose to have an independent test team which performs investigative testing throughout the lifecycle. When this independent team finds a potential bug in the software they write up a "defect story", the agile equivalent of a defect report, and give it to the development team. Agilists treat defect stories like any other type of requirement: They are prioritized, estimated, and put on the stack.
Wait a minute! A defect story is a type of requirement? You bet. A defect story describes either broken or missing behavior: If it describes broken behavior, then the requirement is effectively "Rework X so that Y happens". If it describes missing behavior, then clearly it's a potential requirement. When you think about it, a "requirement" should similarly be considered a defect because it describes missing behavior. For example, the Eclipse project, the largest agile development project currently underway, maintains its requirements in Bugzilla, an open source defect tracking tool. I've heard of agile RUP teams using ClearQuest, a commercial defect tracking tool, in a similar manner.
The only time that the "a defect is a requirement" philosophy can get you in trouble is with a fixed-price project. With fixed-price projects you want to ensure that you are paid to implement new functionality that wasn't originally specified. In these situations defect stories which describe missing functionality must be put through a change management process where the business stakeholders determine whether they wish to pay for the new functionality.
A second issue which agilists don't talk about often is the need to put more than just requirements on our "requirements stack". Or, perhaps another way to look at it is that we have several stacks to manage, not just a requirements stack. Either way, our current work queue needs to reflect the fact that implementing requirements isn't the only thing that we do during an iteration. People go on vacation or on training courses. They also do non-project related work, such as reviews of work performed by other teams or HR-related activities such as staff reviews. All of these things are important and must be planned for, along with implementing new functionality.
The Open Unified Process (OpenUP) takes an interesting approach to managing our work. OpenUP teams maintain a single "work items list" upon which we place prioritized requirements as well as non-requirement activities such as vacations, external reviews, and so on. Where Scrum has two stacks, the Sprint backlog which is where the requirements for the current iteration are managed and the Product backlog where all other requirements are maintained, OpenUP has just the one stack of work items. OpenUP's work items list is effectively a more robust combination of Scrum's Sprint Backlog and Product Backlog.
The third idea is that we should consider rethinking the concept of requirements completely. Is something really a requirement if it evolves over time? Is something really a requirement if it gets deprioritized and as a result never gets implemented? Is something really a requirement if it gets reorganized into smaller pieces and then only a subset of the pieces is implemented?
Philippe Kruchten and Steve Adolph, both of the University of British Columbia, introduced me to this concept about a year ago during our work on the OpenUP. Their philosophy is that it really isn't requirements which we are gathering, or eliciting, or whatever verb you prefer, but instead it is the stakeholder's intent which we are trying to understand. We know that our stakeholders aren't very good at defining their "requirements", yet many software development processes still aim to define requirements in detail and worse yet strive to baseline them early in the lifecycle. Our real goal should be to understand our stakeholder's goals and desires and then build software which reflects those intents.
My hope is that this newsletter has made you rethink the way that you view requirements management. I suspect that most organizations will see the benefits to be derived from treating defects as a type of requirement. I also think that most agile teams will benefit from the "work items stack" approach taken by OpenUP. Finally, although I truly believe that intent is a far better concept than requirements, that in the term "requirement" is too embedded in the IT lexicon for us to ever evolve away from it. Time will tell.
As its title suggests, Implementing Lean Software Development is a follow up to Rick Brandon and Tom and Mary Poppendieck's first book, Lean Software Development, where they show how to apply the lean principles in practice. The principles have evolved a bit since their first book, they are now: Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People, and Optimize the Whole.
Although the book is chock full of valuable wisdom, I believe that the primary skill that you will gain from this book is how to recognize, and then address, wastage within your software processes. Waste is caused by building extra features into a system (you're doing extra work); unnecessary churn, resulting from specifying detailed requirements and design too early or testing too late; and having unnecessary boundaries between groups or even individuals over which work must cross, boundaries where defects are often injected and loss of information occurs.
I believe that this is one of the few "must read" books for any software professional. If you're an agilist it will explain many of the concepts which you sense to be true but don't know why. If you're a traditionalist then it will explain why many of the things that you sense are wrong about your software process are truly inefficient.
Implementing Lean Software Development: From Concept to Cash by Rick Brandon and Mary and Tom Poppendieck --SWA
The Agile Alliance is the best starting point for anyone interested in learning more about agile software development.
Inclusive modeling tools and techniques which support active stakeholder participation in intent/requirements-oriented modeling are described at www.agilemodeling.com/essays/inclusiveModels.htm.
Agile requirements change management is described in detail at www.agilemodeling.com/essays/changeManagement.htm.
The www.eclipse.org/projects/dev_process/.
You can learn more about Scrum at the Implementing Scrum site.
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The principles of Agile Modeling v2 are described at www.agilemodeling.com/principles.htm.
The practices of Agile Modeling v2 are described at www.agilemodeling.com/practices.htm.
Check out the Agile Modeling mailing list at www.agilemodeling.com/feedback.htm.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.