Requirements in the Organisation

Shoulds, coulds, woulds, mays, mights. Dotted around lessons, tutorials, papers, books, blogs on how to write requirements. Every expert on requirements wants them to be specific, well defined, exact. And so they should be, because a black-and-white, success/failure test needs to be created based upon them. So why do writers consistently use “should be written as”, “would be best if” and the like?

People.

You can’t get away from them. Business Analysts are people. Clients are people. Experts are people. Now this ‘would’ be a point that we ‘could’ stop at and leave it there: you can’t perfect requirements because there are imperfect objects involved in their definition. But we can’t make excuses for an imperfect solution when it is finally presented to our client.

There are many frameworks for designing perfect requirements. Concise, correct, isolate, necessary, unambiguous, predicated, bounded, testable. But the client’s picture of requirements is a melange of functional statements, emotive comments, and ‘ingenious’ solutions weighed down with ingenuous pride. I worked with one client for whom we coined the word ‘solutionising’. I’m sure I’m not the only person to have used it. For us it meant defining the solution as the requirement. “We want a database table to store all our customers alongside their products indexed by date purchased.” “You should use a hyperlink in the email to record responses.” By presenting the ‘nonsense’ word it made the avoidance of defining solutions as requirements something of a game. An alternative is to present alternatives to the solution, but this is something of a ‘but’ situation. Nobody wants to be presented with a but. It gets their goat up, makes them stand their ground, argue their case. What you really want to get at is the requirement behind the solution, or the reason for the emotion.

Why?

You remember that game you used to play with your parents? “But why, Daddy?” Eventually the answer would come back as “just because”, or some version of the same. When you can’t go any further with the question, the reason is the last good answer that you received.
“We want it indexed by date purchased.”
“Why?”
“All our users search on a date parameter for the latest product.”
“Why?”
“The software we sell is versioned, so clients calling in tend to say the name without knowing the version they have – we check for them.”
“Why?”
“That’s the way we work.”
“Okay, so you want to be able to present the user with the client’s version number for their software when they call in for technical support?”
And so forth… The last situation, admittedly not yet a true requirement as it would be documented, is what the client really wants. And the solution might not be quite what they considered.

The Business Analyst is translating between people and machines, between conversation and code, and ‘why?’, I believe, is one of the most powerful tools to enable this.