Requirements for IT and Dreams?

The Elusive Dream of Good Requirements for ITIf you don’t know what you want, how will you know when you get it? Actually, that was put much more poetically in a song from an old Broadway musical, South Pacific: “You gotta have a dream. If you don’t have a dream, how you gonna have a dream come true?”

So what do requirements for IT have to do with dreams? Everything, actually. You see, requirements are how we as human beings communicate conditions that would have to be met for our dream to come true. For instance, if you look closely at Martin Luther King’s “I have a Dream” speech, there are eight sentences that start with the words “I have a dream…” Two of the sentences repeat the title “I have a dream today!” The other six are explicit requirements, each defining a specific condition that the future would have to satisfy for his dream to become reality. I won’t bore you with the details. You can trust me or look up the speech online and search for those eight sentences.

Requirements by Any Other Name?

Requirements for IT and in generalMaybe “dream” is too “fluffy” for you. After all, you live in the cold, hard world of business and what you have are not “dreams” but “business visions, missions, goals, and objectives”. What are these if not dreams? Depending on how well written they are, they may be more or less quantified dreams, but dreams they are nonetheless. If you achieved them, you would be happy. If they are good visions, missions, goals, and objectives, your organization would thrive. If your “dream” is worth achieving, you need to define it in terms that anyone whose help you need to achieve it shares your understanding of what it means. Welcome to the world of requirements.

The problem is that the word “requirement” has become a four-letter-word in many organizations, particularly when the requirements define a future Information Technology (IT) application. We can hardly blame those organizations given how many failed and underwhelming IT projects they have experienced as a result of misunderstood or missing requirements for IT. Nearly every independently executed root-cause analysis of IT project failures in the past half-century have identified “bad” requirements for IT as the primary cause. The real problem is one of basic human communication. Whether you call them “features”, “User Stories”, “Work Items”, or anything else, requirements by any other name will still cause project failure if they do not solve the communication problem.

Understanding Requirements

understanding Requirements for ITYou see, requirements express something that you as the one writing them wants. The question is, how will the person who delivers whatever it takes to satisfy your requirement understand it? Both parties often “understand” a requirement but still not share a common understanding of it. Here’s a simple example. My wife tells me, “I think you should paint the house; it’s looking pretty run down, don’t you think?” I agree, “Splendid idea.” I drive down to our local hobby store, buy an easel, a canvas, the paints, and brushes and return home ready to set up and prove my skills as an artist. I’m excited about the prospect of capturing the current, dilapidated state of our home in excruciating detail for posterity. Imagine my surprise when she was upset with my solution! She didn’t want me to paint the house, she wanted me to paint the house! That, in a nutshell, is the crux of the problem with requirements.

As this example shows, you do not have to be a business analyst or involved in IT development to benefit from writing better requirements. Requirements in any walk of life define the future by expressing a desired outcome of some proposed change in your environment, personal or professional (e.g., I thought what she wanted was a lovely painting of our house whereas what she really wanted was a lovely painted house. That is requirements miscommunication 101!).

As you can see, it is not enough that two people understand each other — what they really need is a common understanding of what the outcome of the change should be. Without that, any outcome is random. The only alternative to good requirements is hoping and praying that you get what you want! How has that been working out for you?