Author Archives: Jump the Spark!

About Jump the Spark!

Unknown's avatar
Torix Corporation provides business transformation services * IT Consulting - Requirements Definition - Process Design - Project Planning - Project Management * Design - Software Design - Graphic Design * Innovation - Personnel Empowerment - Change Integration - Consensus Management - Novel Solutions

WORKING BUSINESS REQUIREMENTS

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.


REQUIREMENTS FOR BUSINESS REQUIREMENTS – Part 5

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.


CORRELATION IS NOT CAUSATION

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.”


REQUIREMENTS FOR BUSINESS REQUIREMENTS – Part 4

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


REQUIREMENTS FOR BUSINESS REQUIREMENTS – Part 3

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.


REQUIREMENTS FOR BUSINESS REQUIREMENTS – Part 2

This is getting pretty technical, but bear with me while I try to get through the next part quickly. The next few concepts are essential, but they can also be controversial.

  • Here is the first business requirement requirement: Each business requirement must be written as a complete statement. Just as in any other written communication, incomplete sentences and fragments create ambiguity, confusion and misunderstanding. If your statement is unclear, others may misunderstand it during implementation. That, in turn, will create more deliberation or rework. That costs you.
  • Each requirement must contain the word “must” or another similar term such as “needed,” “required” or “specified.” This makes the intent clear to all readers that this is not just a guideline or recommendation.
  • Each requirement must be a simple and clear statement. If you have a compound sentence then it may disguise multiple requirements. Clarity is essential to dispel ambiguity.
  • Each requirement must be actionable and testable. You can ask yourself these questions: How do I approach the task of implementing this requirement? How do I know when the requirement has been met? If you can answer these questions with confidence, then you have in hand a well-written business requirement.
  • Finally. a requirement statement must present the actual need, the actual deed to be implemented, and not describe only the requirement in general terms.

“Blinded by the light. Revved up like a deuce, another runner in the night.” – Bruce Springsteen