ENGR2720U

ENGR2720 Software Design II

Software Product Design Resolution

Slides modified from: Introduction to Software Engineering Design (C. Fox)

Page 1

ENGR2720U

Product Design Alternative Generation, Evaluation, and Selection

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

ENGR2720U Software Product Design Process

Generic Software Product Design
Project Mission Statement : Problem SRS : Solution

Project Mission Statement

Analyze Product Design Problem

Elicit/Analyze Detailed Needs

Generate/Improve Candidate Requirements Evaluate Candidate Requirements

Select Requirements [else] [adequate] [else] [complete] Finalize Requirements SRS

Page 5

ENGR2720U

Generating Candidate Requirements

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
Page 6

ENGR2720U

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.

Page 7

ENGR2720U

Refining AquaLush Requirements

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

Requirements Atomization Example

Look at the transformation of figure 5-2-1 to the more readable and atomized list in figure 5-2-2

Page 12

ENGR2720U

Product Design Principles

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

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

Page 14

ENGR2720U

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

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

AquaLush Scoring Matrix

Evaluation Criteria Description Irrigation Control Weight 25% Moisture Controlled Rating 2 Score 0.5 Timer Controlled Rating 3 Score 0.75 Manually Controlled Rating 5 Score 1.25

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

Product Design Finalization; Inspections

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

ENGR2720U Software Product Design Process

Generic Software Product Design
Project Mission Statement : Problem SRS : Solution

Project Mission Statement

Analyze Product Design Problem

Elicit/Analyze Detailed Needs

Generate/Improve Candidate Requirements Evaluate Candidate Requirements

Select Requirements [else] [adequate] [else] [complete] Finalize Requirements SRS

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

SRS Quality Characteristics 1

Well-formednessAn SRS is well formed if it conforms to all rules about stating requirements. ClarityAn SRS is clear if it is easy to understand. ConsistencyA set of requirements is consistent if a single product can satisfy them all. CompletenessAn SRS is complete if it includes every relevant requirement.
Page 28

ENGR2720U

SRS Quality Characteristics 2

VerifiabilityEvery requirements in an SRS must be verifiable. UniformityA description has uniformity when it treats similar items similarly. FeasibilityAn SRS contains feasible requirements when designers are confident that they can be satisfied. Developers should check all these characteristics.
Page 29

ENGR2720U

SRS Quality Characteristics 3

CorrectnessAn SRS is correct if it specifies a product that satisfies stakeholder needs and desires, subject to constraints. Proper requirements prioritizationAll requirements are prioritized in accord with stakeholder needs and desires. Stakeholders should check these requirements validation characteristics.

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

Team Inspection [ok] [else]

Rework

Follow Up [major defects] [else] [else] [reinspect]

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

Requirements Inspection Checklist Example

Every requirement is atomic. Every requirement statement uses must or shall. Every requirement statement is in the active voice. Terms are used with the same meaning throughout. No synonyms are used. Every requirement statement is clear. No requirement is inconsistent with any other requirement. No needed feature, function, or capability is unspecied. No needed characteristic or property is unspecied. All design elements are specied to the physical level of abstraction. Every requirement is veriable. Similar design elements are treated similarly. Every requirement can be realized in software. Every requirement plays a part in satisfying some stakeholders needs or desires. Every requirement correctly reects some stakeholders needs or desires. Every requirement statement is prioritized. Every requirement priority is correct.

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

Modeling in Product Design

Modeling is useful throughout product design. Document problem domains Explore stakeholder needs and desires Test design constraints Detect misunderstandings, and incomplete or

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

A prototype is a working model of part or all of a final product.

Page 46

ENGR2720U

Horizontal & Vertical Prototypes

A horizontal prototype realizes part or all of a products user interface. One program layer Mock-ups A vertical prototype does processing apart from that required to present a user interface. Cuts across program layers Proof of concept prototype

Page 47

ENGR2720U

Throwaway and Evolutionary Prototypes

A throwaway prototype is developed as a design aid and then discarded. Exploratory prototype Quick to build Risky to use in the final product An evolutionary prototype is a prototype that becomes (part of) the final product. Iterative development More expensive to build Difficult to build to handle change

Page 48

ENGR2720U

Low- and High-Fidelity Prototypes

Fidelity is how closely a prototype represents the final product it models. There is a continuum of fidelity Low-fidelity prototypes Paper or rough electronic prototypes Executed by walking through interactions Very quick and easy High-fidelity prototypes Usually electronic Take longer to build (good tools help)
Page 49

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