Академический Документы
Профессиональный Документы
Культура Документы
Page 1
ENGR2720U
Page 2
ENGR2720U
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
Page 3
ENGR2720U
Topics
Product design resolution activities Generating/improving alternatives Stating design alternatives as requirements Evaluating design alternatives Selecting design alternatives
Page 4
Page 5
ENGR2720U
ENGR2720U
Page 7
ENGR2720U
Tables 5-1-2 to 5-1-4 demonstrate examples of the categorization and alternatives that were derived from the original Aqualush needs. Table 5-1-2: Frequency Setting Requirements Table 5-1-3: Water Allocation Requirements Table 5-1-4: Moisture Level Requirements
Page 8
ENGR2720U
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
Page 9
ENGR2720U
Stating Requirements
Follow the rules of good technical writing. Write complete, simple sentences in the active voice.
http://owl.english.purdue.edu/handouts/grammar/g_actpass.h
tml
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.
Page 10
ENGR2720U
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.
Page 11
ENGR2720U
Look at the transformation of figure 5-2-1 to the more readable and atomized list in figure 5-2-2
Page 12
ENGR2720U
AdequacyDesigns that meet stakeholder needs, subject to constraints, are better. BeautyBeautiful design are better. EconomyDesign that can be built for less money, in less time, with less risk, are better. FeasibilityA design is acceptable only if it can be realized. SimplicitySimpler designs are better.
Page 13
ENGR2720U
Page 14
ENGR2720U
Still based on stakeholder needs and desires Stakeholders and designers in collaboration Participatory design
Page 15
ENGR2720U
Selection Techniques 1
Pros and consList advantages and disadvantages and decide by vote or consensus Easy and fast Driven by persuasion Crucial experimentsDecide 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
Page 16
ENGR2720U
Selection Techniques 2
Multi-dimensional rankingassign 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.
Page 17
ENGR2720U
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 scoreshigh score wins
Page 18
ENGR2720U
Reliability
Ease of Use Robustness Risk
20%
20% 20% 15%
3
4 3 4
0.6
0.8 0.6 0.6
2
3 3 3
0.4
0.6 0.6 0.45
2
2 5 2
0.4
0.4 1.0 0.3
Total Score
3.1
2.8
3.35
Page 19
ENGR2720U
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
Page 20
ENGR2720U
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.
Page 21
ENGR2720U
Small Exercise
E10 Use a spreadsheet to make a selection matrix for the Pigeonhole Box Office alternative requirements described previously. Weigh each evaluation criterion equally. Rate each product for each evaluation criterion as you see fit. Try to cut and paste it as a text file to the quiz. I will take a look in class to see what you have done.
Page 22
ENGR2720U
Page 23
ENGR2720U
Objectives
To explain product design finalization To present SRS quality criteria and assign responsibility for them To define several types of reviews To examine inspections in detail
Page 24
ENGR2720U
Topics
Product design finalization SRS quality characteristics Reviews Inspections Roles Process Activities Checklists
Page 25
Page 26
ENGR2720U
Design Finalization
Final product design step Ensures that requirements are properly documented Designer review Ensures that requirements are valid (that is, the product design is good) Stakeholder review
Page 27
ENGR2720U
ENGR2720U
ENGR2720U
Page 30
ENGR2720U
Reviews
A review is an examination and evaluation of a work product or process by qualified individual or teams.
Page 31
ENGR2720U
Types of Reviews
Desk checkAn examination of a work product by an individual. Often the author (proofreading) Checklists WalkthroughAn informal examination of a work product by a team of reviewers. No assigned roles, no set process Usually preparation (desk check) by reviewers InspectionFormal work product review by trained team of inspectors with assigned roles using a checklist to find defects. Mandatory preparation Formal review process
Page 32
ENGR2720U
Requirements Inspections
Find as many defects as possible Not intended to evaluate the author Not intended to correct defects Expensive and time consuming Efficient and cost effective Can be used for any work product
Page 33
ENGR2720U
Inspection Roles
ModeratorManages and facilitates the process InspectorSearches for defects AuthorOriginates the work product ReaderReads the work product during the inspection meeting RecorderNotes defects found, issues, inspection characteristics, etc.
Page 34
ENGR2720U
Inspection Modify Check Readiness [else] [ok]
Inspection Process
Inspector 1 Prepares
Overview Meeting
Inspector 2 Prepares
...
Inspector k Prepares
Rework
Page 35
ENGR2720U
Preparation Activities
Readiness check Usually done by the moderator Ensures that the work product has no obvious defects Overview meeting Short (~20 minutes) Tasks
Schedule review meeting Distribute work product, checklist, etc. Answer questions
May be done electronically Each inspector carefully reviews the work product using a checklist Takes several hours
Page 36
ENGR2720U
Inspection Meeting
Moderator insures that inspectors are ready; if not, the meeting is rescheduled Reader reads through the work product Inspectors note defects or raise issues Recorder notes all defects, issues, comments, collects data, etc. The meeting should not last more than two hours There should not be more than one inspection meeting per day
Page 37
ENGR2720U
Inspection Checklist
Must be specific to work products and projects Should be modified continuously Checklist items should be removed if they rarely turn
up defects Checklist items should be added to find defects that are often missed
Page 38
ENGR2720U
Page 39
ENGR2720U
Inspection Conclusion
The author corrects defects found by inspectors. The moderator ensures that all defects are dealt with. If the work product is much changed or still appears to have defects, another inspection may be scheduled.
Page 40
ENGR2720U
Summary
Design finalization ensures that the SRS is of high quality. Designers and stakeholders review the SRS for various quality characteristics. Reviews include desk checks, walkthroughs, and inspections. Inspections are reviews with explicit goals, assigned roles, and a formal process, that relies on checklists to find defects.
Page 41
ENGR2720U
Prototyping
Page 42
ENGR2720U
Objectives
To survey the use of modeling in product design To explain different kinds of prototypes To list the uses of prototypes To present prototyping risks and mitigation strategies
Page 43
ENGR2720U
Topics
Modeling in product design Prototypes Horizontal and vertical Throwaway and evolutionary Low- and high-fidelity Prototype uses Prototyping risks
Page 44
ENGR2720U
inconsistent specifications Generate design alternatives Evaluate and select design alternatives Record product designs
Page 45
ENGR2720U
Prototypes
A prototype is a special kind of model. Represent a target (the product) Must work in some way
Page 46
ENGR2720U
Page 47
ENGR2720U
Page 48
ENGR2720U
ENGR2720U
Prototype Uses 1
Needs elicitation Basis for discussion, jogs memory, inspires ideas Usually throwaway horizontal paper prototypes Needs analysis Captures developers understanding of needs Usually throwaway horizontal prototypes at various levels of
fidelity
Requirements generation and refinement Design alternatives Explore new ideas Often horizontal throwaway paper prototypes
Page 50
ENGR2720U
Prototype Uses 2
Requirements evaluation and selection Usability studies Requirements feasibility Usually higher fidelity; sometimes vertical prototypes Design finalization Better for review than an SRS Advisable to make high-fidelity evolutionary horizontal
prototypes
Page 51
ENGR2720U
Prototyping Risks
Using a throwaway prototype as the basis for development Avoid making high-fidelity throwaway prototypes Make it very clear to stakeholders that the prototype only
appears to work
Fixation on appearance rather than function Dont use prototypes for functional needs elicitation Use low-fidelity prototypes for needs elicitation Prototype is better than the final product Use low-fidelity prototypes Ensure that high-fidelity prototypes are accurate representations
Page 52
ENGR2720U
Summary
A variety of models are used for several tasks in product design. A prototype is a working model of (part of) a final product. Prototypes can be throwaway or evolutionary, horizontal or vertical, and have varying degrees of fidelity. Prototypes are useful for needs elicitation, for alternative generation, evaluation, and selection, and for design finalization. Risks attendant on the use of prototypes can usually be mitigated.
Page 53