Tuesday, May 05, 2015

Requirements Hints and Variations

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—and
Thou 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 Hint
To see an annotated catalog of all of Jerry's ebooks and bargain bundles, visit https://leanpub.com/u/jerryweinberg

To see a list of most of his books, ebooks and bound books, visit http://www.amazon.com/-/e/B000AP8TZ8

No comments: