Print

Up-Front Requirements

15 Jun, 2005

I was once on a project where we required the stakeholders to sign off on the requirements. I handed the document to one of our two key stakeholders. He glanced at it, turned to our company liaison, and said, "Is this right?" The liaison (who was not a business analyst) said, "yep," and the stakeholder signed the document. He never read it.

Guess who had the most complaints about the final result later.

This was an educational project for me. We did requirements "right"--we conducted modelling sessions with users, created a prototype, watched users use the prototype and give us feedback, and our requirements document had screenshots of every screen and details about how each one would behave. We used that requirements document as a bible and we implemented the product exactly as the requirements stated. We met with the stakeholders to break the requirements down into features and prioritize them. Then we implemented them in one-month iterations.

Despite all of this careful effort, we implemented the wrong thing. After our first release, we learned that two chunks of functionality we had postponed as "unimportant" (access control and reporting) were in fact so important that the software couldn't be used without them. Even later, we learned that one of our stakeholders (who had signed our requirements document with screenshots!) had expected a web application, not a Windows application.

Did we do the requirements wrong? No, I think we did a great job, and certainly the best job that we were capable of. What went wrong is that the customers didn't engage in the up-front requirements process. They looked engaged--they were physically present and participating--but they didn't know what they were getting and couldn't imagine it from the materials we were giving them. I think what went wrong is that imagining software from a verbal or written description is a difficult skill, one that most customers don't have.

On my recent trip to Europe, I spent a lot of time in countries where I had no clue about the language. I found myself doing something that I always thought was really stupid. When people talked to me and I didn't understand, I smiled and nodded. Why was I nodding!? I didn't understand, and here I was acting as if I did.

It's uncomfortable being in a country where everyone is talking in a language you don't understand. You feel out of place and kind of dumb. There's this very powerful urge to pretend that you understand, even when you don't. Even worse, if you let people know that you don't understand, they'll try again: slightly louder and slower, but with no more comprehension on your part. So you smile and nod and hope it wasn't important.

When presented with that requirements document and those planning sessions, our customers smiled and nodded. I've since decided that the way to really deliver what our customers want is to put real, working, non-prototype software in front of them with the expectation that we'll need to make changes.