340 likes | 857 Vues
Product Design Alternative Generation, Evaluation, and Selection. 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
E N D
Product Design Alternative Generation, Evaluation, and Selection
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
Topics • Product design resolution activities • Generating/improving alternatives • Stating design alternatives as requirements • Evaluating design alternatives • Selecting design alternatives
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
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.
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
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.
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.
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.
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
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
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
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.
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
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
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.