Objectives • 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
Topics • Product design process overview • Needs versus requirements • Needs elicitation challenges, heuristics, and techniques • Documenting domain, goals, and needs • Modeling • Checking needs documentation
Top-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 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
Needs versus Requirements • 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 Challenges 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 Challenges 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 Heuristics • Learn about the problem domain first. • Determine stakeholder goals as the context of stakeholder needs and desires. • Study user tasks.
Elicitation 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
Elicitation Techniques 2 • 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
Elicitation Techniques 3 • 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
Elicitation Techniques 4 • 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 Domain • Organize notes • Make a problem domain glossary • Make an organization chart • Make UML activity diagrams
Documenting Goals Categories are based on roles, not individuals, jobs, or titles. A stakeholders-goals list is a catalog of important stakeholder categories and their goals.
Documenting Needs and Desires • 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 Statements • 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.
Modeling • 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 Documentation 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.
Checking Needs Documentation 2 • 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
Summary 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 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.