Product Design Analysis

1. Product Design Analysis

2. 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

3. Topics • Product design process overview • Needs versus requirements • Needs elicitation challenges, heuristics, and techniques • Documenting domain, goals, and needs • Modeling • Checking needs documentation

4. Software Product Design Process

5. 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

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

7. Stakeholder Roles

8. 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

9. 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.

10. 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.

11. Elicitation Heuristics • Learn about the problem domain first. • Determine stakeholder goals as the context of stakeholder needs and desires. • Study user tasks.

12. 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

13. 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

14. 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

15. 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.

16. Documenting the Problem Domain • Organize notes • Make a problem domain glossary • Make an organization chart • Make UML activity diagrams

17. 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.

18. 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.

19. 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.

20. 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

21. 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.

22. 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

23. 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.

24. 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.