Agile Requirements – no BRUF just GRIT
The first principal of agile software development is that the highest priority is to satisfy the customer through early and continuous delivery of valuable software. This is a significant departure from traditional waterfall methods in which delivery of working software happens not early, but very late in the process. In waterfall type methods, the focus of the work early in the process is on understanding and documenting what the software product should do. Understanding and documenting the requirements is seen as critical to the success of the endeavor and for any non-trivial software product a significant percentage of the total project schedule will be devoted to the requirements phase before design and development can begin.
Unfortunately, the history of software development does not provide a lot of evidence that this Big Requirements Up Front (BRUF) technique works very well. There are a number of good reasons why it is a challenge to accurately and completely capture requirements before any implementation effort takes place, and some not-so-good, but commonly cited reasons as well. In any case, if one of our goals is to deliver working software early, we can’t devote a lot of time to BRUF before getting down to the business of writing code.
A common misunderstanding about agile methods is that not doing BRUF means not doing requirements documentation at all. This of course, is a recipe for disaster, or at least frustration, as many new agile teams learn. What we need is a new way of presenting requirements modeling and documentation concepts that emphasizes what is important. I like a term I heard recently, Great Requirements In Total or GRIT.
The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.
If the objective is to produce quality working software, you may wonder, why we need to also develop a model. GRIT recognizes that software is a product and should be managed as a product, not a project. Each iteration results in a new release of the product. Minor releases introduce new or refined features, ultimately leading to a major release. The model provides stability across iterations and allows multiple small agile teams to work on large development efforts in an integrated fashion.
Over the total lifecycle of a software product there will be many projects that may add features, improve performance, or even move the product to an entirely new deployment environment. The model provides essential documentation of the requirements in a way that ‘documented in the code’ simply cannot.
Agile teams aspiring to move beyond small development efforts and disposable products should adopt GRIT as one of their guiding principles.
Unfortunately, the history of software development does not provide a lot of evidence that this Big Requirements Up Front (BRUF) technique works very well. There are a number of good reasons why it is a challenge to accurately and completely capture requirements before any implementation effort takes place, and some not-so-good, but commonly cited reasons as well. In any case, if one of our goals is to deliver working software early, we can’t devote a lot of time to BRUF before getting down to the business of writing code.
A common misunderstanding about agile methods is that not doing BRUF means not doing requirements documentation at all. This of course, is a recipe for disaster, or at least frustration, as many new agile teams learn. What we need is a new way of presenting requirements modeling and documentation concepts that emphasizes what is important. I like a term I heard recently, Great Requirements In Total or GRIT.
The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.
If the objective is to produce quality working software, you may wonder, why we need to also develop a model. GRIT recognizes that software is a product and should be managed as a product, not a project. Each iteration results in a new release of the product. Minor releases introduce new or refined features, ultimately leading to a major release. The model provides stability across iterations and allows multiple small agile teams to work on large development efforts in an integrated fashion.
Over the total lifecycle of a software product there will be many projects that may add features, improve performance, or even move the product to an entirely new deployment environment. The model provides essential documentation of the requirements in a way that ‘documented in the code’ simply cannot.
Agile teams aspiring to move beyond small development efforts and disposable products should adopt GRIT as one of their guiding principles.
posted by MJMurphy at 10/08/2007 11:32:00 AM
3 Comments:
Thank you!!! This is a great articile. I used this model when I was teaching staff about reqwuirements building and customer satisfaction. This process helps the customer to contune to refine and aligne his requirements to his business project at the earliest stages. Saves him money, time, and frustration. This model helps to assure that this project will be meet with good results using the software product(s). I am heartened to see that someone still feels the way I do about requirements.
Sharonlee Cummins
Software Quality & Project Officer
Whiltierna@fortinedsl.net
This blog post is being discussed here:
http://requirements.seilevel.com/blog/2007/10/agile-requirements-no-bruf-just-grit.html
Thanks! This is a great post.
My company has been using Agile for a while. While we have improved in a lot of ways, but the requirement gathering stage still remain the same. In a way, it also seems to obstruct the flow of Agile.
Hope you can share more example of GRIT
Post a Comment
<< Home