Ever get the impression that your stakeholders simply aren’t going to read the requirements documents you create? Better yet, have you ever had a stakeholder actually tell you directly that he or she just isn’t going to read the requirements? I haven’t, but I wish someone would. That sort of direct, honest communication would be a shock, but sometimes that’s exactly what we need to shake ourselves out of familiar, yet unproductive, patterns of behavior.

In a recent post, Joyce explained the importance of context in our work. Her post was about providing context for both your current and future audiences. But what if those audiences can’t or won’t use the documents? Even if you provide context for your requirements like Joyce suggests, if you don’t deliver your requirements to your stakeholders in a way they can or will use (in other words, provide them in the context of their use) then you’ve completely missed the boat.

Unfortunately, many times we don’t find out that stakeholders can’t or won’t use the documented requirements until it’s too late — the system has been built, it doesn’t meet the requirements, but it’s too late to change anything and still meet the delivery date. When pushed to explain WHY the system doesn’t meet the requirements, the stakeholders explain that they thought something was included in the requirements but it wasn’t, or the development team explains that they couldn’t understand the requirements so they just built what they thought was right, or the test team explains that they were unfamiliar with the format of the requirements so they tested against the existing system instead. Sound familiar?

It would be great if your stakeholders told you up front that they wouldn’t use your documentation. That way, you’d have a chance to talk with them about what kinds of documentation they could or would use. You could discuss all of the options for capturing, documenting and managing requirements, and then you could choose the right set together. You could pick the right tools for the context of their use. If only those darn stakeholders would just be straight with you up front, right?

Let’s be honest — it’s our job to know that requirements reviews and use are challenges in software development, and more importantly it’s our job to find ways to make the process work. Talk with your stakeholders about past projects and requirements efforts. Find out what their context is for the work you’re doing. And then use your expertise to come up with and use new approaches and tools that make this project better than the last for everyone involved.