- Forrester Councils
- Councils Overview
- log in
Posted by Mary Gerush on April 13, 2010
A couple of days ago, Texas Stadium was reduced to a pile of rubble. Wow. The former home of my Dallas Cowboys, the site of victories and record-setting performances — gone in a matter of minutes. Was I sad? Yeah. But also a bit relieved. The Cowboys have moved to their new, super-duper (and quite ostentatious) stadium, Texas Stadium memorabilia has been auctioned off, and the poor, neglected building had become quite an eyesore.
Sometimes destroying something unusable is the best way to move forward.
Run that statement past your approach to documenting software requirements. When was the last time you took a step back to evaluate how your organization represents requirements? If it’s been awhile and your business analysts are still delivering massive, text-heavy, all-encompassing business requirements documents (BRDs), it’s time for some demolition of your own.
Why? Compelling forces have converged, drastically changing the way application development teams author software requirements. Organizations are recognizing the connection between software failure and poor requirements, and authoring better requirements has become a major initiative in many firms. At the same time, Lean and Agile are front and center, so right-sizing requirements documentation is on everyone’s radar. Bottom line, you need to do more with less: author stronger requirements while minimizing waste and being as lean as possible.
That begs a question: Assuming you accept the fact that the massive BRD needs to go bye-bye, what do you replace it with? Lean and Agile proponents will tell you to create “just enough” documentation to communicate requirements. But how much requirements documentation is “just enough”? I’ve been asked this more than once, so I’m doing research for an upcoming Forrester report. Here are a few of my initial thoughts:
A recent BA Times.com article clearly calls out: “The Big Freakin’ Requirements Document Must Die. Here’s Why.” I agree — and love the title! How have you moved from massive, text-heavy requirements documentation to something leaner and more efficient? I invite your comments on our blog site, or feel free to email me at email@example.com. How do you know how much requirements documentation is “just enough”? I look forward to your feedback!
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »
Free On-Demand and Live Events
Latest events from Forrester analysts, online and in person. »