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:

  • Documentation doesn’t imply Microsoft Word. I’ve struggled with the word “documentation” for a while, because to me it implies text-centric artifacts. But the Merriam-Webster online dictionary defines a document as “something that serves as evidence or proof” and elaborates that the “something” could be writing, photographs, recordings, or objects. It’s not all about the words, and we need to get past associating “documentation” with “text” and begin to view it as an artifact or collection of artifacts — text, pictures, audio, and video — that helps convey information.
  • Business analysts (BAs) need to focus on the documentation’s intent. Requirements documentation helps teams collaborate, helps business analysts analyze, and communicates meaning to business stakeholders, developers, and quality assurance pros to help them understand what software the team is trying to build. It also documents a system for those who will interact with that software later. By understanding the purpose of the documentation, you can better hone its focus.
  • Requirements authors need to understand their audience . . . Many people — not just business stakeholders — consume software requirements, and all have different preferences. Developers may prefer use cases and wireframes. Quality assurance (QA) pros might benefit from receiving requirements in a data-oriented format. And, yes, your business stakeholders may be most comfortable with Word — but they need a pared-down version to digest requirements efficiently.
  • . . . And they need to consider the documentation’s life span. If you need to document requirements formally to prove compliance, do it. But don’t spend hours creating formal, perfectly formatted documentation for something that will never be referenced again. This is where the “just enough” test is most critical when you’re trying to become Lean.


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 mgerush@forrester.com. How do you know how much requirements documentation is “just enough”? I look forward to your feedback!