October 2, 2006

...Learn TDD with Codemanship

The Essence of Requirements Analysis

Much of the thrust of requirements analysis is figuring out how to express human wants and needs in a way that a computer will understand. We're led to believe that the right hemisphere is creative but irrational, and the left hemisphere is logical and rational but lacks imagination. I tell some of my clients that requirements analysis is - in essence - a journey from the right hemisphere of the brain to the left hemisphere.

We are taking "blue sky" thinking that is quite possibly not entirely bound by logic and is almost certainly ambiguous and untestable - expressed in a rich but informal language that is usually best-suited for this sort of thinking - and through some kind of voodo magic we slowly knock these ideas into a set of logical expressions that can ultimately be fed into a machine as instructions it will be able to understand. Machines are severely limited in their ability to interpret. And this can place very severe restrictions on what we can program them to do, especially with limited time and resources available.

A day may come when users can just speak directly to their computers and be understood using everyday speech. They might be able to ask their computer to recommend a restaurant that's "not too pricey and has a good atmos", or to pick out the customers most likely to want their latest product, and the software will chug away and figure out exactly what - in terms of machine-executable instructions - the user really wants it to do.

The mechanics of this journey from right to left brain is a mystery. Two things I know absolutely for certain:

1. It will require the ability to speak two kinds of languages - right brain languages (e.g., English, Spanish, Chinese) and left brain languages (e.g., C#, Java, Z, OCL, Assembler)
2. It will be an iterative, feedback-driven process, since there can be no surefire deterministic mechanism for deducing the correct interpretation of an ambiguous statement in a single step. When we present users with prototypes, we're essentially asking them "is this what you meant?" (I'll blog more about this process soon.)

Strange, then, that many analysts I've met don't know any programming or formal specification languages (what use is an interpreter who only speaks one language?) and are firmly against iterative, feedback-driven development processes. I don't call these people "requirements analysts", as they don't help to move us any further forward in our journey from left to right brain. Arguably they add no value to a project. A better title for them might be "ballast"...
Posted 14 years, 3 months ago on October 2, 2006