Monthly Archives: July 2014


Next, you use your business requirement statement to design the business transformation. This is not usually easy, because you need to backtrack some. That is because your business requirement states only what needs to be, but not what is the case now. So, you must prepare a realistic and descriptive report of the current state of your business practice or process. Once you have described your current situation, and also what you want it to be instead, then you can design the transformation. That is, you can now map the steps you need to change from the current state to the future state of your business practice.


“Most horses won’t walk backward voluntarily, because what they can’t see doesn’t exist.” – Terry Pratchett


Business requirements transform business. They provide the roadmap to fulfilling client and customer satisfaction. By doing so, they give you your competitive edge.

How do you make that happen though? To some, it seems mystical and magical. To others, it seems obvious, so get out of the way and let them get started. But what really happens is that you must work the business requirements, in order to get work out of them.

To start with, as mentioned in a previous blog post, a good statement of a business requirement is both actionable and testable. It is simply, but completely stated so that it may be implemented without misunderstanding. There is truth in saying that identifying a problem is half way to solving it. Half the work of implementing a change to your organization is in defining its business requirement clearly.

Cultural Networking

An interesting bit of rapid cultural adaptation by Chinese to social media and smartphones has led to some unique communication shortcuts: 502 = ‘I love you’, 3q = ‘thank you’, 88 = ‘bye-bye’. It should be no surprise that many prefer memorizing numbers to characters or English words.


There is a substantial niche industry marketing requirements tracking databases, systems and servers. But these are not short cuts, and must be evaluated judiciously. It is good to remember that a thoughtful application of the requirement definition process yields direct bottom-line competitive and economic advantages.


The cliché “correlation is not causation” has an element of truth to it. Actually, MORE than just an element of truth. Too often we are handed a fait accompli of “scientific proof” that is based on correlative studies, but which has not established a confirmed cause and effect relationship. The following quotes from Ed Tufte (Beautiful Evidence) are relevant to establishing actual requirements:

“Correlation is not causation but it sure is a hint.”

“Empirically observed covariation is a necessary but not sufficient condition for causality.”

“Many true statements are too long to fit on a PP [PowerPoint] slide, but this does not mean we should abbreviate the truth to make words fit. It means we should find a better tool to make presentations.”

“In assessing causal linking lines, the claim that ‘X acts on Y’ should be tested against competing alternatives, such as the paired arrows of interplay. Another check is to reverse the claim: ‘Might it be instead that Y acts on X?’

“Evidence that bears on questions of complexity typically involves multiple forms of discourse.”

“Evidence is evidence, whether words, numbers, images, diagrams, still or moving. It is all information after all.”


These business requirement requirements are controversial. There are several reasons, but they all boil down to time and money. The principal objection is that creating and publishing well-written requirements becomes too daunting a task when there are thousands of requirements to list. Careful decisions must be made up front with respect to requirements which reference other requirements, to requirements which are subordinate to or included within others, or to requirements which may even duplicate others.

“The universe requires everything to be observed, lest it cease to exist.” – Terry Pratchett

“…the mappings are specific, coherent, credible, and testable…. When mappings make explanatory interpretations of images, then serious standards of quality for evaluating an explanation become relevant.” – Ed Tufte


Business requirements are not exactly specifications, but they are close. They “specify” an understanding of your business model in terms that can be communicated clearly to other members of your team. A better analogy may be a statement from statutory law. If you want to see an example of good requirements, read a few paragraphs of your state’s published family law code.