110 likes | 124 Views
Understand the limitations of direct questions in software specification and the importance of using additional tools and techniques to elicit accurate requirements. Explore the order of questions, decision trees, and the value of different interrogative methods. Learn valuable insights and practical tips for improving the requirements gathering process.
E N D
G&W, Chapter 4: The Tried but Untrue Use of Direct Questions Software SpecificationLecture 11 Prepared by Stephen M. Thebaut, Ph.D. University of Florida
So what’s wrong with direct questions? Why do I need other tools and techniques to get the requirements right? Answer:There’s nothing wrong with direct questions, but questioning without other tools and techniques is never enough to get the requirements right. Did the “Design a transportation device” example of Chapter 4 convince you of this? Software Specification: G&W Chapter 4
Quiz G&W’s “Design a transportation device” example most convincingly illustrates: • The usefulness of decision trees for supplementing direct questions. • How important it is to ask questions in the right order. • Which tools and techniques are most needed to get the requirements right. • That human beings are not good at seeing what they’ve overlooked. Software Specification: G&W Chapter 4
The Order of Questions Does it really matter which of the following questions you ask FIRST? “What color should it be?” “Should it be a bicycle or a skateboard?” Software Specification: G&W Chapter 4
The Order of Questions (cont’d) How about the following? “Want mustard and ketchup on it?” “Do you want a hamburger or ice cream?” Software Specification: G&W Chapter 4
The Order of Questions Counts When... • Some requirements are much more important than others, and • Time is not an unlimited resource. • Irrelevant questions can be avoided by asking others first. In other words, the order of questions counts when efficiency counts. Software Specification: G&W Chapter 4
Idea for a Game… • Players are divided into 2 or more teams of “analysts”. • A “customer” thinks of a product and gives a first, very ambiguous requirement (e.g. “design a transportation device”). • Each team separately interrogates the “customer” by asking a series of direct, yes/no questions (made up on-the-fly), until the product is correctly identified. • The team requiring the fewest questions wins. Software Specification: G&W Chapter 4
A Couple of Gems • If you find yourself feeling that what the customer wants is not what he needs,try to convince him of this. If you can’t, then either produce what he wants or find some other customer. It’s not a good idea to work for people whose intelligence is so disparate from yours, in one direction or the other. Software Specification: G&W Chapter 4
A Couple of Gems (cont’d) • As you do requirements work you will often find that people think you are wasting their time when you do anything other than ask direct questions. It is your job to help them see the value of other tools and techniques. Software Specification: G&W Chapter 4
End of Part I Part II: Ways to Get Started • Starting Points • Context-Free Questions • Getting the Right People Involved • Making Meetings Work for Everybody • Reducing Ambiguity from Start to Finish Software Specification: G&W Chapter 4
G&W, Chapter 4: The Tried but Untrue Use of Direct Questions Software SpecificationLecture 11 Prepared by Stephen M. Thebaut, Ph.D. University of Florida