Tuesday, May 05, 2015

In both volumes of Exploring Requirements, we follow each chapter with a section of hints and variations about the topic of the chapter. Many readers tell us that this extra material is often more valuable than the chapter body itself. For that reason, I've decided to present a blog entry consisting entirely of the hints and variations from the first chapter of Volume One. Enjoy!

(1) Another source of complexity in development projects is the desire of non-experts
to be involved in the design of complex products. Most customers naturally prefer to
learn as little as possible about product design, yet still have all their wishes met in
the requirements process. When customers prefer to remain naive about the product
design process, most of the burden falls on the notation—a lot to ask of a notation.
The design complexity problem can be solved by creating a tutorial to convert a naive customers into an expert—but not if the customers doesn’t want to invest that kind
of effort.

(2) Customers often turn away from the design process because the professional
designers treat them in a patronizing manner. Remember, most participants are naive
only about the development process, and are themselves experts in subjects about
which the designers are naive. Such expertise is why their participation is essential.
We’re much more likely to have their full participation if we create an environment
of shared expertise.
(3) Methodology experts underestimate the difficulty of understanding their nota-
tions, which they believe to be “intuitive.” To understand how difficult it really
is to define an “intuitive” notation, consider the problem of designing universally
understood international road signs.
(4) When two sets of experts participate in the same requirements process, there’s
often a conflict about which notation is intuitive. Children reared in Paris think
French is intuitive, but children reared in Montreal may think both French and
English are intuitive. In the same way, experts often share a “first love” syndrome
for notations. This first-learned-first-loved bias can be prevented in the same way
bilingual children avoid a bias for one language. If you are teaching a notation,
instruct your students in two at the same time. Do all maps in both notations, and
compare the pair of maps explicitly.
(5) Mastery of the notation may give one party dominance in the requirements
process, while excluding those who haven’t mastered the notation. To avoid political
wars, you must devote attention to depoliticizing the language issue. Try following
the Swiss example: All “first love” notations of participants are declared to be
“official” languages of the requirements process. Every official document must be
presented in all of the official languages before the process is considered complete.
(6) Although this multilingual approach may seem burdensome, the Swiss example
shows it can work if done in the right spirit. Indeed, in Swiss meetings, people
from the “dominant” language group often present their ideas in the “secondary”
languages, as a courtesy to the minority participants and as a strong indication of
how much they value their participation. In our experience with requirements work,
this multilingual approach always yields a more accurate definition of requirements
as well as a more complete involvement of all participants.

(7) Our colleague Eric Minch suggests a theoretical model: all descriptions of the de-
signed system—including the various constituencies’ requirements and satisfactions,
the constraints and decisions, and the final specifications for implementation—can
be considered statements in different “languages.” In other words, instead of seeing
all of these as different descriptions in a single language, we can think of them as the
same description in different languages. The full design task then involves finding a
way of translating among these languages, and the final product is such a translation
strategy.
(8) Minch’s idea stimulated us to recall “translation” is not quite the simple one-to-one task we often assume. Some translations are works of art in themselves,
like Edward FitzGerald’s English translation of The Rubaiyat of Omar Khayyam.
Consider the famous quatrain:
A Book of Verses underneath the Bough, A Jug of Wine, a Loaf of Bread—andThou
Beside me Singing in the Wilderness—
Oh, Wilderness were Paradise enow!
What part is original with Omar the Tentmaker, astronomer and mathematician from
eleventh century Persia? What part has been added (or subtracted) by FitzGerald, the
nineteenth century Suffolk gentleman? What part has been added by twenty-first century readers, such as us?
(9) Experiencing the final product, we don’t so much care if it’s an exact translation,
but only whether we like the product. This verse reminds us: value can be added at
any stage of the product development cycle. Requirements are merely a guide. They
are to be taken literally, but not too literally. There are many roads to Paradise.
(10) These observations connect directly with a remark by Ken de Lavigne, our
colleague at IBM: “Your discussion of maps brings out the great problem introduced
by ‘stepwise refinement’ approaches: although they claim to postpone decisions until
the time comes to make them, in fact the most far-reaching decisions are made first,
when one has the least amount of information.” Always be prepared to go back and
revise the “translation,” or “map,” when further exploration shows there was a wrong
branch higher in the decision tree. To do this, let go of the idea of the “one right way,”
or “the perfect translation.”Extra HintTo see an annotated catalog of all of Jerry's ebooks and bargain bundles, visit https://leanpub.com/u/jerryweinbergTo see a list of most of his books, ebooks and bound books, visit http://www.amazon.com/-/e/B000AP8TZ8