Personally, I love reading requirements documents. I put them on my night stand right next to my last car loan contract and all the paperwork from my last home closing. They really do the stuff when it comes to insomnia, sure beats the prescriptions and the wacky side effects. But in all seriousness, let’s think about what these documents are and what they all have in common, (Besides being mind-numbingly boring to read).  All of these documents serve a purpose; the loan documents and title paperwork that we deal with in our personal lives are the standard that we refer to when questions arise. We’ve come to accept these documents and it’s a well known fact that we don’t read them and in many cases we can’t read them, at least not in an intelligible manner without our lawyers present.  Anyway, when was the last time you brought your lawyer to purchase a car? The fact of the matter is, we don’t.  We discuss the terms and assume that the person or organization we are doing business with is trust-worthy and while we might glance through the paperwork, ultimately we trust what was discussed and we sign blindly, and most of the time that works out OK.

So how does that differ from your stakeholders and requirements documents? Well in truth, it really doesn’t. The business (your customers) verbally or written in laymen’s terms explain what they would like: a new website, an update to the customer service app, integration with the new expense system, or any number of other projects. As analysts or project managers we then go off and decide what needs to be done to accomplish this goal; is it feasible (?), does it make sense (?), and if so what are the requirements? We then diligently begin our process of eliciting requirements from the stakeholders, the end users of the product, and any other interested or concerned party. A series of meetings is scheduled to review these during our validation phase and ultimately we create the beloved Requirements Document.  By this point, it truly becomes a document only an analyst or perhaps a lawyer could love. We’ve carefully crafted each line, diagram, and chart to clearly explain and account for each subtle nuance that the project requires, ensuring that we’ve taken the needs of the end users, the business and development constraints into account. We secretly admire the bulk of the document as the result of a lot of hard work. Some of us might even print a copy of it and prominently place it on our desks, hoping that our bosses will come by and be impressed by the sheer volume of our latest work. It’s our baby, or our latest masterpiece and we should be proud.

We then present this Requirements Document to our stakeholders who initiated the project and seek their approving signature. We discuss this in a meeting and the document is then presented for signing, but like our car purchasing analogy the document signing has become ceremonial. The stakeholder trusts that you understood the requirements and assumes that the signing is nothing more than a necessary step. But is it? Do they understand the constraints that development has placed on the project? Do they know that the end users requested a very different approach to the way the screens are configured? Just like buying a car or closing on a home, they give it a cursory glance, or perhaps hope that their team has read it in depth and would surely advise them if something was amiss. If this were the case why do the industry analysts consistently throw out numbers ranging from 20%-60% of each project budget is spent on re-work? The culprit is usually identified as poor requirements. Poor requirements? We worked for 8 weeks on that document, it was 160 pages long, we accounted for everything. How could we have ‘poor requirements’?

The answer is not poor requirements, but rather that once all parties were involved in the elicitation process the project began to change. With each new person giving their input to the requirements, it changed the goals and results of what the stakeholder had originally imagined when they first presented it to you. Given that they did not thoroughly read through the initial presented requirements document, they were not aware of what the new version of the project looked like. So development hosts the first review session of the product and the stakeholders are shocked.

“This is not what we contracted!” they say.

“But it’s all right here in the Requirements Document, you signed it.”

“Well it’s not what we wanted, it needs to be re-done.”

Start the re-work counter.

So, what can be done? Well many shops have switched to Agile to try and catch this a little sooner, and it can work well, but you still need defined requirements for the overall project and you need to understand what each sprint will entail (we still want successful sprints). Perhaps the problem is in the requirements process itself. Some have called for the “death of the requirements document”. In the near future, I don’t see the requirements document going away. It serves a purpose, but not to communicate requirements to stakeholders, just like the loan documents we sign don’t communicate the terms, of our loan, interest rates, or payments dates. There still needs to be a record of the work that is being performed, and there needs to be a form of acceptance.

What needs to change is how we present these requirements to our stakeholders; hosting visualization sessions, presenting mock-ups and wireframes with functionality built-in that give our stakeholders a real-world feel of the final requirements and how they may have evolved through the inputs of others. We might want to use process diagrams, use cases, or other tools to tell our story. The fact of the matter is we need to tell a story, not present a contractually binding document and hold our stakeholders feet to the fire when this goes wrong (we’ll save that for car salesman and realtors). Once this is understood through communication and we all agree on what it is we are embarking on. We can then, once and for all use the requirements document for what it is best suited for, a place to sign our name that signifies agreement amongst all parties before we drive off in our shiny new car, or take the keys to our new home, or begin development on that new much needed new application or update.