Last October my friend Linda handed me Harry Potter and the Sorcerer's Stone, and I was hooked on the series. While submerged in the world of wizards and witches, I found survival lessons for the world of requirements. As analysts, we usually look for something specific: facts, needs, wants, and definitions. In doing that, we may overlook what isn't so apparent. We might confuse imagination with fact, be surprised by what is hidden, or avoid what could be threatening. Our oversights are more than hassles; they can undermine getting the right requirements.

Conjuring Requirements from What Seems Like Thin Air
In the book, Harry Potter's early life plays out under a veil of convenient lies. His aunt and uncle tell him his parents were killed in a car accident. They want to avoid any discussion of Harry's true wizard identity, as magic terrifies them. Illusion fills Harry's world and I thought about how it also filters into requirements.

Like Harry's aunt and uncle, we might invent false requirements. So unlike Harry's aunt and uncle, we should make no pretense of fantasy being reality. Imagination can elicit legitimate customer needs when project direction is not clear. For example, the "box prototype" technique proposed by Tim Lister and Tom DeMarco suggests using cardboard boxes and other crude props to imitate a desired system's operation. In this way you can exaggerate or push the limits: leave a feature out, fall short of a target, ignore a condition, and find out what happens if you do. By making the imagined requirements almost foolish, you find out what really matters. And by using simple props instead of a working prototype, customers never assume the system is real, but their reactions and comments about requirements are genuine.

When Truth Confronts Illusion
Early in the first Potter book, Harry reaches his eleventh birthday and learns the truth about the murder of his wizard parents. His life opens to new opportunity, but also impending crisis. Sometimes when our requirements evolve into operational systems, crisis hits. This is the effect of reality colliding with our imagined requirements.

While discussing project crises with my colleague Brian, he recalled an employee benefits system he helped develop. Once in production, the peak level of system usage exceeded the expected level. The system choked. Why didn't their architecture anticipate the problem?

Brian said the peak load was a given requirement. In retrospect, however, he admitted that the predicted usage was really a guess. When the team designed according to an accepted but incorrect system view, they failed to allow enough slack for the performance they eventually had. The load requirement was believed as fact even though it was the product of imagination: a guess. Then reality and disaster hit.Unexpected Troubles
As analysts, we can fall prey to another form of illusion-what we don't see, doesn't exist. Again, during the saga Harry faces an unknown adversary each school semester. He usually doesn't expect trouble. A few times he receives warnings. Either way, he seems to encounter the trouble where he least expects it.

Once upon a project, I coordinated information for six teams. Ultimately their software needed to blend into one large, complex system. The scenario was perfect for integration problems. Hence I threw myself into making sure everyone shared the same view about who owned what controls, functions, and information; who sent what to whom; and how we could compare specific data and assumptions. The technical analysis went relatively smoothly. That is, relative until I ran into a bigger problem: personal conflict that was eroding team trust.

Fear
Two of the team leads felt threatened by the new requirements process. The project manager wanted clear requirements for the whole system to identify common functionality and ensure that each team understood its specific charter. The two leads feared that they wouldn't make their schedule. Many others feared failure, feared being found out and feared admitting their fears. This anxiety overrode any examination of requirements.

In the end, we worked intentionally to ease fears, help people discover value in what the new project manager wanted, and move forward. In one episode Harry comprehends that his biggest fear isn't the dark wizard everyone refers to as You-Know-Who, but is fear itself. Fear emerges as the supreme dark force. And so it was on this project.

Some Survival Lessons
Harry's tales reminded me that our biggest dangers may be of our own making. We can be clever, brave, and talented, but not in all areas and not all the time. Here's my summary of lessons for surviving the requirements process:

1. Illusion may substitute for reality for a while, and this can be both good and bad. Remain aware of exactly what you know, what you don't, and the consequences each might carry
2. Watch out for what you can't see. It may surprise you and probably will force you to change direction
3. Fear is a dark force that can disable the best of our efforts and us