That's a Completely Useless Answer!

Have you ever asked someone a question, only to have him/her respond with, "Well, it depends..."? It can be extremely frustrating, especially when all you want is a simple, direct answer. For example, if I'm looking for directions to a restaurant and someone tells me that it depends on whether I want to take the most quick, the most direct, or the most scenic route, I probably don't mind the clarifying question. If, on the other hand, that person just says, "It depends" and stops talking, then a very annoyed look will probably appear on my face.

But the answer to many questions DOES depend on additional information that the asker doesn't provide. I may know that my car is low on gas, or that the dinner reservation is in 10 minutes, or that I just rented a convertible and want to drive around with the top down, any of which would allow someone to suggest an applicable route to dinner. But because those things are an integral part of my world that I don't consciously consider when phrasing the question, they're probably not on the tip of my tongue when I'm posing my question.

As a result, what often happens is that the person asking the question gets either a non-response ("It depends...") or an inappropriate response given my specific (but unstated) objective. The answer is either annoying or just plain wrong for the situation -- and in either case, the person who asked it probably thinks "That's a completely useless answer!" Unfortunately, if you ask enough vague questions, people stop answering them, and if you answer enough questions inappropriately or with only "it depends," people stop asking you for answers. Neither of those situations is good for someone in the requirements business!

In earlier posts, both Joyce and I extolled the virtues of context, and this is another great example of the importance of that kind of additional information. When you're meeting with stakeholders to gather requirements, explain the context for your involvement with the project and the questions you're asking. When you're answering requirements questions, don't just stop with "It depends" -- tell them what it depends upon and what some possible answers are for each situation. You'll build credibility with your team, establish a reputation as a reliable source of information, and (perhaps most importantly) not be the cause of that annoyed look on anyone's face!

I'm NOT Going to Read Your Requirements

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.