Download
1 / 12
120 likes | 124 Views
Learn why it is important to limit expectations in software development to prevent disappointment and ensure client satisfaction. Understand the reasons behind differences in expectations and discover techniques for managing expectations effectively.
E N D
G&W Chapter 18: (Limiting) Expectations Software SpecificationLecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Why Limit Expectations? • The difference between disappointment and delight is a matter of how well a system or product matches the clients’ expectations. • Users feel cheated when they discover limitations after the fact.
Why Limit Expectations? (cont’d) • It’s your job to help the customer understand limitations, in contrast to those who write phrases like “participating Holiday Inns.”
Why are there Differences in Expectations? • People are not perfect.Miscommunications and misinterpretations naturally occur during RE. • People are not logical. Customers may be disappointed when, upon delivery of a product, they discover the true meaning of some “invisible” word in the requirements document. (Being logically – or even legally – correct is not the same as satisfying the user.)
Why are there Differences in Expectations? (cont'd) • People perceive things differently. As when stakeholders from different cultures use similar language to mean different things. • Designers are people, too. They sometimes get carried away by some great idea, and need to stop to consider limitations.
The Expectation Limitation Process • Generate a list of specific expectations from representatives of each user constituency. Use questions like: “What are you most looking forward to in this system?” or “Which part of the new system will be most valuable to you?” • Work with the list to understand and generalize each expectation.
The Expectation Limitation Process (cont'd) • Negotiate to limit expectations to what is reasonable, leaving open possibilities for future enhancements, but ruling out anything unreasonable. (Make explicit those decisions the designer would otherwise make implicitly.) • Document the source of limitations – otherwise the list becomes almost impervious to change.
Some Tips and Issues • A good heuristic for revealing hidden expectations is the Rule of Three. (If you can’t think of three things that might cause your great idea to fail, you probably need to think about it more.)
Some Tips and Issues (cont’d) • On the other hand, if the limitation process gets bogged-down with “fantasy-gone-wild,” you may need to appeal to the Doctrine of Reasonable Use. (We can’t imagine all the bizarre things someone might do with this system, but we’ll know what is reasonable when we see it.)
Hints and Variations • Sometimes designers say, “If the clients knew about this limitation now, they’d kill the project. But after it’s built, they’ll like the other features so much that they won’t mind that this one is left out. So, let’s not make waves.” Thoughts?
Hints and Variations (cont’d) • It has been pointed out that the argument, “limitations without reasons…are impervious to change” can also be applied to functions, attributes, constraints, and all other descriptions of the product. Thoughts?
G&W Chapter 18: (Limiting) ExpectationsSoftware SpecificationLecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida
