G&W Chapter 17: Preferences Software Specification Lecture 24 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Preferences vs. Constraints A constraint is a mandatory condition placed on an M attribute. A preference is a desirable but optional condition placed on an M or W attribute.

Preferences vs. Constraints (cont'd) In order for a solution / product to be acceptable, every constraint must, by definition, be satisfied. Preferences enable designers to compare acceptable solutions and choose the better ones.

Preferences vs. Constraints (cont'd) Constraints must be defined so as to enable testers to determine whether or not they have been satisfied in the finished product. Preferences must be defined in terms that will enable designers to determine to what degree they have been satisfied.

Preferences vs. Constraints (cont'd) Both constraints and preferences come from the client, NOT the designer. One person’s constraint (not parking in a “no parking” zone) is another person’s preference (minimizing total cost, including parking and time). (Remember the “legality” attribute?).

Preferences vs. Constraints (cont'd) Nothing about the underlying attribute itself tells us whether the condition is a constraint or a preference. Only the strength of the client’s fears or desires determines which is a constraint and which is a preference.

Making Preferences Measurable The importance of metrics is clear, but... The actual metrics are nothing; the process of “metrifying” is everything. What’s important is making the effort to identify a metric for every preference, because the thought process is going to help everybody understand exactly what the preference is.

Making Preferences Measurable (cont'd) If you get bogged-down… Check whether there are actually two or more preferences mixed into one. If necessary, set up a separate task group to define the metric at a later time, then proceed to the next preference. Don’t burden the requirements process with excessive precision.

The Problem of Unconstrained Preferences Q: By when must the system be produced? A: June 1. Q: By when do you prefer that the system be produced? A: As soon as possible. Consultants can always recognize projects that take place in an environment of unconstrained preferences: Just notice the climate of unrelenting panic.

How to Constrain Preferences Probe the solution space – ask the client to discuss his feelings about different points. Explore the relationship between preference levels and payoff for reaching those levels. What’s-it-worth? graphs When-do-you-need-it? graphs

What’s-it-Worth? Graph Preference 1 Preference 2 Value Attribute

When-do-you-need-it? Graph Value Delivery Date

Exploring Trade-Offs Among Preferences Getting more of one preference typically means getting less of another. Consider speed versus reliability in racing cars. G&W show how trade-off charts can be used to predict the expected net value of competing solutions based on a client’s value system.

Some Concluding Ideas Exploring preferences begins after constraints have bounded the solution space, but since this generally leads to the adjustment of some constraints (and vice versa), expect the process to be iterative. All requirements ultimately depend on the client’s value system; thus, the requirements process had better make this totally visible.

Some Concluding Ideas (cont'd) Whenever possible, reduce constraints to (constrained) preferences to give the designers a wider solution space to search. But clients: Beware of designers who fail the Orange Juice Test!

G&W Chapter 17: Preferences Software Specification Lecture 24 Prepared by Stephen M. Thebaut, Ph.D. University of Florida