product design analysis

1© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Product Design Product Design AnalysisAnalysis


ObjectivesObjectives

To explain the product design process as top-down and user centered

To list and explain several needs elicitation heuristics and techniques

To describe how to analyze and document needs elicitation results

To explain how to check analysis results


TopicsTopics

Product design process overview Needs versus requirements Needs elicitation challenges,

heuristics, and techniques Documenting domain, goals, and

needs Modeling Checking needs documentation


Software Product Design Software Product Design ProcessProcess

Generic Software Product DesignProject Mission Statement : ProblemSRS : Solution

Project Mission Statement

SRS

[adequate]

[else]

[complete]

[else]

Analyze Product Design Problem

Elicit/Analyze Detailed Needs

Generate/Improve Candidate Requirements

Evaluate Candidate Requirements

Select Requirements

Finalize Requirements


Top-Down ProcessTop-Down Process

Design resolution begins with abstract requirements and refines them

Designers move from user-level to operational-level to physical level requirements

Main activity in the resolution loop


User-Centered ProcessUser-Centered Process

Stakeholder focus—Determine needs of all stakeholders and include them in evaluation

Empirical evaluation—Collect data about needs, desires, and design quality

Iteration—Improve design repeatedly until adequate


Stakeholder RolesStakeholder RolesActivity Stakeholders’ RoleAnalyze Product Design Problem

Clarify project mission statementAnswer questions

Elicit Needs Answer questionsBe subjects of empirical studies

Analyze NeedsAnswer questionsReview and validate models and documentsParticipate in analysis with designers

Generate/Improve Alternatives Participate in generation and improvement

Evaluate AlternativesAnswer questionsBe subject of empirical studiesParticipate in evaluation with designers

Select Alternatives Participate in selection with designers

Finalize Design Review and validate requirements


Needs versus Needs versus RequirementsRequirements

Stakeholder needs and desires define the product design problem.

Requirements specify the product design solution.

Needs and requirements statements are similar, but the heart of product design is moving from needs to requirements.

• Conflicting needs and desires• Tradeoffs (needs and constraints)• Ways of satisfying needs and desires


Needs Elicitation Needs Elicitation Challenges 1Challenges 1

Needs and desires must be understood in the context of the problem domain.

Stakeholders may not be available.

Stakeholder responses are often hard to understand and sort out.


Needs Elicitation Needs Elicitation Challenges 2Challenges 2

Stakeholders often cannot explain their work, or articulate their needs and desires.

Stakeholders make mistakes, leave things out, and are misleading.

Stakeholders often don’t understand the capabilities and limitations of technology.


Elicitation HeuristicsElicitation Heuristics

Learn about the problem domain first.

Determine stakeholder goals as the context of stakeholder needs and desires.

Study user tasks.


Elicitation Techniques 1Elicitation Techniques 1

Interviews—Designers question stakeholders

• Most important technique• Many ways to do interviews• Recording responses

Observation—Designers watch users work• Better than having people explain their work• Several of the right people, several times• Talking out loud• Recording observations



Focus groups—Informal discussion led by a facilitator

• Six to nine people• Facilitator keeps people on task• User-level requirements

Elicitation workshops—Directed discussion led by a facilitator

• More directed and detailed than a focus group• Specific goals• Needs or desires or product features and

details• Requires committed stakeholders



Document studies• Books (problem domain)• Policies and procedures• Process improvement studies• Development documentation• Problem and bug reports• Suggestions

Competitive product studies• Products themselves• Reviews and market studies



Prototype demonstrations• A prototype is a working model of part or

all of a final product.• Ferret out features and capabilities• Explore user interface ideas• Visionary products

Use several techniques, favoring those that allow direct contact with stakeholders.


Documenting the Problem Documenting the Problem DomainDomain

Organize notes Make a problem domain glossary Make an organization chart Make UML activity diagrams


Categories are based on roles, not individuals, jobs, or titles.

Documenting GoalsDocumenting Goals

A stakeholders-goals list is a catalog of important stakeholder

categories and their goals.


Documenting Needs and Documenting Needs and DesiresDesires

A need statement should• Name the stakeholder category or categories• State one specific need• Be a positive declarative sentence

Often requires interpretation of raw data

A need statement documents a single product feature, function, or property

needed or desired by one or more stakeholders.


Organizing Need Organizing Need StatementsStatements

Needs lists should be arranged hierarchically

Try arrangements with note cards Prioritize needs

• Numbers• Hi/Med/Lo• Consult stakeholders

A needs list catalogs need statements.


ModelingModeling

Many kinds of models can represent the problem and help designers understand it.

Many modeling notations and techniques useful for analysis will be discussed later.

• Various UML diagrams• Use case descriptions, user interface

diagrams, dialog maps• Conceptual modeling, use case modeling


Checking Needs Checking Needs Documentation 1Documentation 1

Correctness—A statement is correct if it is contingent and accords with the facts.

Scope—A goal or need is within the project scope if it can be satisfied using the planned features of the product created by the project.

Terminological consistency—Terminological consistency is using words with the same meaning and not using synonyms.


Uniformity—A description has uniformity when it treats similar items in similar ways.

Completeness—Documentation is complete when it contains all relevant material.

Review activities• Developers should use checklists• Stakeholders should review documents

Checking Needs Checking Needs Documentation 2Documentation 2


Summary 1Summary 1

The product design process is essentially top-down and user centered.

Product design begins with design problem analysis.

Stakeholders can play many roles in product design.

Needs define the product design problem; requirements state the solution.


Summary 2Summary 2

Designers should understand the problem domain and stakeholder goals before eliciting needs.

Needs can be elicited in many ways and preferably by direct contact with stakeholders.

Many kinds of models can help understand the problem.

Needs must be documented, organized, and checked.

product design analysis

Documents