Product Design Alternative Generation, Evaluation, and Selection

1. Product Design Alternative Generation, Evaluation, and Selection

2. Objectives • To list design alternative idea sources and generation techniques • To explain conventions and practices for stating requirements • To list and explain design alternative evaluation techniques • To present alternative selection techniques, particularly scoring matrices • To explain requirements prioritization

3. Topics • Product design resolution activities • Generating/improving alternatives • Stating design alternatives as requirements • Evaluating design alternatives • Selecting design alternatives

4. Software Product Design Process

5. Generating CandidateRequirements • Common failing: too few alternatives • Idea sources • Users and other stakeholders • Props and metaphors • Competitive products • Similar products • Generation techniques • Team brainstorming • Individual brainstorming • Modeling

6. Improving Candidate Requirements • Identify stakeholder need statements relevant to a candidate requirement. • Use the idea sources and techniques from the last slide to improve requirements.

7. Specification Notations • Natural language • Easy to understand • Prone to ambiguity and vagueness • Semi-formal notations • More precise than natural language but not defined with mathematical rigor (most UML diagrams) • More precise than natural language • Easy to understand • Formal notations • Mathematical and logical notations • Very precise • Hard to understand

8. Stating Requirements • Follow the rules of good technical writing. • Write complete, simple sentences in the active voice. • Define terms clearly and use them consistently. • Etc. • Use “must” or “shall.” • Write verifiable requirements. • There is a definitive procedure to determine whether the requirement is satisfied.

9. Requirements Atomization A requirement statement is atomic if it states a single product function, feature, characteristics, or property, and it has a unique identifier. • Necessary for requirements traceability • Usually simple declarative sentences • Hierarchical numbering scheme • Number tables, diagrams, trees, etc.

10. Product Design Principles • Adequacy—Designs that meet stakeholder needs, subject to constraints, are better. • Beauty—Beautiful design are better. • Economy—Design that can be built for less money, in less time, with less risk, are better. • Feasibility—A design is acceptable only if it can be realized. • Simplicity—Simpler designs are better.

11. Requirements Evaluation Techniques • With respect to design principles (heuristic evaluation) • By collecting data from stakeholders (empirical evaluation) • Stakeholder surveys • Usability studies • Users perform tasks on prototypes • Measurements used for comparison

12. Selecting Requirements Alternatives Selection among alternatives can be made by the following parties: • Stakeholders only • Designers only • Still based on stakeholder needs and desires • Stakeholders and designers in collaboration • Participatory design

13. Selection Techniques 1 • Pros and cons—List advantages and disadvantages and decide by vote or consensus • Easy and fast • Driven by persuasion • Crucial experiments—Decide based on the results of a survey or usability study • Clear and objective results • Slow and expensive • Applies only when a single selection criterion is in question

14. Selection Techniques 2 • Multi-dimensional ranking—assign criteria weights, score alternatives, and compare weighted sums • Fairly objective • Takes multiple criteria into account • Fast and easy • Difficult to use with many alternatives and criteria • Use the techniques most appropriate for the decision at hand.

15. Scoring Matrices • List alternatives as column headers • Determine the selection criteria and weights to be used • Add the selection criteria and weights as row headers • Rate each alternative with respect to each criterion, fill a cell • Fill in score cells by multiplying ratings by weights • Total the scores—high score wins

16. AquaLush Scoring Matrix

17. Prioritizing Requirements • Needed to make decisions about what to do first or what to leave out • Based on needs priorities, if available • Otherwise • Designers can assign priorities based on needs • Stakeholders can assign priorities • Stakeholder should always check priorities

18. Summary • Designers should use a variety of sources and techniques to generate many design alternatives. • Alternatives stated as requirements should be atomized, verifiable, use “must” or “shall” and be well written. • Alternatives can be evaluated heuristically or empirically • Designers or stakeholders can select design alternatives. • Several techniques can be used to select alternatives depending on the circumstances.