1. Prepared by Stephen M. Thebaut, Ph.D. University of Florida
G&W, Chapter 1: Methodologies Aren’t Enough Software Specification Lecture 6
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida

2. Part I: Negotiating a Common Understanding
Methodologies Aren’t Enough
Ambiguity in Stating Requirements
Sources of Ambiguity
The Tried but Untrue Use of Direct Questions

3. Methodologies Aren’t Enough
Some would argue that “...in order to do a better requirements job...remove the people from the process and instead use a methodology.”
“Today,...packaged methodologies flood the market...”
So “...who needs a book about people-oriented tools?”
Software Specification: G&W Chapter 1

4. Consider the Guaranteed Cockroach Killer...
“Whether it’s roaches or requirements, the hard part is catching them and getting them to stand still.”
Even with guaranteed methodologies, “...you’ll still need the tools described in this book.”
Software Specification: G&W Chapter 1

5. Methods’ Effect on Problems
"Because there are now superior tools and methods, developers attempt systems that never could have been imagined (before).”
“...problems that are most amenable (to our superior tools and methods) are quickly eliminated, leaving a residue of ‘messy’ problems...”
Software Specification: G&W Chapter 1

6. Software Specification: G&W Chapter 1
Notations and Maps
Notation: a symbolic way of representing systems ideas.
The exploration metaphor leads to the term “map.”
The use of multiple notations “...can be useful, and even necessary.”
An important property of maps: ease of revision.
Software Specification: G&W Chapter 1

7. Making Sure Everyone Can Read the Map
The most important property of a map: “every-one involved should be able to understand it.”
Claims that someone’s favorite notation is “intuitive” or “easy to read” are true in the same sense that “Cantonese is intuitive” – in Hong Kong.
Software Specification: G&W Chapter 1

8. Exercises to Facilitate Notation Familiarization
“Have each map presented by someone who does not know the notation.”
“Ask each person to translate a map from one notation to another.”
“Use a CASE or CAD system with several embedded notations and the ability to transform a map from one to the other, instantly.”
Software Specification: G&W Chapter 1

9. Exercises to Facilitate Notation Familiarization (cont’d)
“Delay the start of requirements work until everyone has attended a course on the common notation.” or
“Conduct the class as part of the requirements meetings, perhaps keyed to specific examples from the system being developed.”
Software Specification: G&W Chapter 1

10. Maps of Requirements Are Not Requirements
“When the map and the territory don’t agree, always believe the territory.”
We have to work with maps, but maps aren’t perfect. They often under- or over-constrain requirements.
Software Specification: G&W Chapter 1

11. Helpful Hints and Variations
Problem: dealing with users wishing to get all their wishes met but unwilling to commit time to the requirements process.
A reason for this problem: treating customers in a patronizing manner. (“Most participants are naive only about the development process, and they are experts themselves in subjects about which the designers are naive.”)
Software Specification: G&W Chapter 1

12. Helpful Hints and Variations (cont’d)
“Methodology experts underestimate the difficulty of understanding their notations...”
“When two sets of experts participate in the same requirements process, there’s often a conflict about...notation...” (“...experts often share a “first love” syndrome for notations.”)
Software Specification: G&W Chapter 1

13. Helpful Hints and Variations (cont’d)
The Swiss example: all notations that are “first love” notations are “official.” (“Indeed, in Swiss meetings, people from the ‘dominant’ language group often present their ideas in the ‘secondary’ languages, ...as a strong indication of how much they value their participation.”)

14. Helpful Hints and Variations (cont’d)
A reminder: “...value can be added at any stage of...product development; requirements are only a guide. They are to be taken literally, but not too literally. There are many roads to Paradise.”
“Always be prepared to go back and revise (the map) when further exploration shows that there was a wrong branch higher in the decision tree.”

15. Summary: Avoiding Communication Problems
“Don’t leave all the hard parts to be handled by someone else, as in the Guaranteed Cockroach Killer kit.”
“...Don’t underestimate the difficulties for some people in adapting to new methods and new notations.”
“(different) mapping techniques will appeal in different ways to (different participants). “...don’t try to force people to conform or belittle them for being ‘stupid’.”

16. Summary: Avoiding Communication Problems (cont’d)
“...make sure at every step that everyone can read the map in order not to exclude anyone.”
“If you find yourself getting touchy about notational nuances, remember that the map is not the territory...”

17. Prepared by Stephen M. Thebaut, Ph.D. University of Florida
G&W, Chapter 1: Methodologies Aren’t Enough Software Specification Lecture 6
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida