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.

The Data Management Association states that data management is the process of developing data architectures, practices and procedures dealing with data and then executing these aspects on a regular basis. So which bit failed when the personal details of more than 2,300 crime victims were lost in the post or discs containing personal information on almost 18,000 NHS staff have gone missing. The stories make it appear obvious, that discs containing personal data were sent in the post and went missing. But hang on just one second, that's a lot of discs going missing in a short period of time!

The Royal Mail says that there are 14.4 million items of 'lost post', which we can compare to 21 billion items that are delivered every year (2004 figures, see also the Consumer Focus website). I make that about 2 losses per 3,000 items. Yes, that's a lot, and I wouldn't trust sending personal data through this particular medium - that's one part of the story. But statistically thinking, does this mean that in the time period of the above two stories, there were about 3,000 items of post carried by the Royal Mail containing discs holding personal data? I don't claim to know whether envelopes containing discs are lost more or less often, or whether some other quirk of their nature means that they are badly addressed, but it is highly probable that a lot of personal data is getting sent this way.

Why?

I don't just mean why does someone stick the disc of data in an envelope, stick on a stamp and post it in the red post box. In both of the above cases, someone lost their job for doing just that. I have no knowledge of whether these persons truly made a gross error of conduct, but they were just cogs in the process of getting personal data from A to B. What I want to know is why was this data, valuable, personal data, being moved from A to B? This process failed, but why was this process instituted in the first place? What was the true fundamental, economic, business reason for getting this data from A to B?

If we knew the answer to that question, we could validate it. Is it an institutionalised process? Does it need to be updated? Does it need to happen at all? In my experience it is often found that it doesn't need to happen at all, so before sending data, go back to square one, and ask why?