May 22, 2007Mohamad Eid Discovery Chapter 5. May 22, 2007Mohamad Eid Outline  Discovery Phase Framework  Collection  Interpretation  Documentation.

Slides:



Advertisements
Similar presentations
Design, prototyping and construction
Advertisements

Chapter 11 Designing the User Interface
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Discovery Phase Framework Collection Heim, Chapters Lecture 2 Discovery.
Data gathering. Overview Four key issues of data gathering Data recording Interviews Questionnaires Observation Choosing and combining techniques.
SECOND MIDTERM REVIEW CS 580 Human Computer Interaction.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
Requirements Analysis Concepts & Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Jump to first page Chapter 2 System Analysis - Determining System Requirements.
© Pearson Education Limited, Chapter 6 Fact-finding Transparencies.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Software Process and Product Metrics
socio-organizational issues and stakeholder requirements
The voyage of discovery is not in seeking new landscapes but in having new eyes. (Proust, 1982) Selections from Heim Chapters 4 Lecture 2 User Requirements.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Introduction to Information System Development.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
RUP Requirements RUP Artifacts and Deliverables
COMPSCI 345 S1 C and SOFTENG 350 S1 C Discovery: Interpretation and Documentation Lecture 20 Lecturer: Jim Warren Based on Heim Chapter
1 BTEC HNC Systems Support Castle College 2007/8 Systems Analysis Lecture 9 Introduction to Design.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Requirements Analysis
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
Software Waterfall Life Cycle Requirements Construction Design Testing Delivery and Installation Operations and Maintenance Concept Exploration Prototype.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Interpretation Documentation Heim, Chapters and Dix et al, Chapter.
DISCOVERY Textbook: S. Heim, The Resonant Interface: HCI Foundations for Interaction Design [Chapter 4] Addison-Wesley, 2007 March 2, 2011 CS 320 Interaction.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley The Resonant Interface HCI Foundations for Interaction Design First Edition.
May 22, 2007Mohamad Eid Design Chapter 6. May 22, 2007Mohamad Eid Outline Technology Myopia Conceptual Design Physical Design Evaluation Physical Design.
COMPSCI 345 S1 C and SoftEng 350 S1 C Discovery: Collection Lecture 6 Chapter (Heim)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley The Resonant Interface HCI Foundations for Interaction Design First Edition.
 Development is organized in a series of short, fixed-length mini-projects called iterations  Iterations are also incremental  Successive enlargement.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley The Resonant Interface HCI Foundations for Interaction Design First Edition.
Database Analysis and the DreamHome Case Study
DISCOVERY Textbook: S. Heim, The Resonant Interface: HCI Foundations for Interaction Design [Chapter 4, continued] Addison-Wesley, 2007 March 7, 2011 CS.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Systems Analysis and Design in a Changing World, 6th Edition
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
Requirement engineering Good Practices for Requirements Engineering
Centre for Information & Knowledge Management INFORMATION SYSTEMS MANAGEMENT Jamie O’Brien Centre for Information & Knowledge Management University of.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
©2011 1www.id-book.com Data Gathering Chapter 7. ©2011 Data Gathering What is data gathering? –The act of gathering data through a study The data can.
COMPSCI 345 S1 C and SoftEng 350 S1 C Discovery: Interpretation and Documentation Lecture 7 Chapter (Heim)
Ch 4: Discovery Yonglei Tao School of Computing & Info Systems GVSU.
June 5, 2007Mohamad Eid Usability Testing Chapter 8.
CS223: Software Engineering Lecture 8: Requirement Engineering.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
DISCOVERY Textbook: S. Heim, The Resonant Interface: HCI Foundations for Interaction Design [Chapter 4, continued] Addison-Wesley, 2007 March 9, 2011 CS.
Fashion MARKETING TID1131. Types of research Quantitative research Information relating to numbers – quantity. Method - surveys Qualitative research To.
Requirement Discipline Spring 2006/1385 Semester 1.
Session 2: Developing a Comprehensive M&E Work Plan.
Information Technology Project Management, Seventh Edition.
Informed Traveler Program and Applications Agile / Scrum Overview Jerry Inberg.
Day 8 Usability testing.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Recall The Team Skills Analyzing the Problem (with 5 steps)
EKT 421 SOFTWARE ENGINEERING
Presentation transcript:

May 22, 2007Mohamad Eid Discovery Chapter 5

May 22, 2007Mohamad Eid Outline  Discovery Phase Framework  Collection  Interpretation  Documentation  Design Scenario

May 22, 2007Mohamad Eid Discovery  During the collection portion you will formally identify:  The people who are involved with the work  The things they use to do the work  The processes that are involved in the work  The information required to do the work  The constraints imposed on the work  The inputs required by the work  The outputs created by the work

May 22, 2007Mohamad Eid Discovery  You will then interpret the information by:  Creating descriptions of the people who do the work  Describing the different goals involved in the work  Documenting the work step by step  Creating different stories about how the various aspects of the work are done  Creating charts and diagrams of the work flow  Tracing the different stories identified with the various people through the charts and diagrams

May 22, 2007Mohamad Eid Discovery Phase Framework

May 22, 2007Mohamad Eid Exploring the Work Domain Design projects are diverse Incorporating new designs into existing workflows Improving designs already in place Designing innovative devices Work domains are diverse Tracking inventory Customer orders Billing Websites

May 22, 2007Mohamad Eid Exploring the Work Domain Identify all stakeholders There are four types of stakeholders: Primary—The person who uses the design directly Secondary—The person who either supplies input or receives output from the design Facilitator—The person who maintains or develops the design Indirect—The person who is affected by the use of the design but has no contact with it, such as the user’s superior or coworkers and the client who is paying for the project (the client may or may not also be the primary stakeholder)

May 22, 2007Mohamad Eid Organizing the Discovery Process What/How—What activities are involved and how are they accomplished? This will include the documentation of the various computer-based and non–computer-based activities and deliverables. Where/When—We need to understand the impact of physical location on the work flow. Our design may involve changes to the physical location of the people who do the work We also need to understand the temporal aspects of the work. Are there any prerequisite activities, and, if so, in what order must they be completed?

May 22, 2007Mohamad Eid Organizing the Discovery Process Who/Why—We must understand: Who is involved Why they are involved Their role in the present work flow How they may respond to any changes implemented These people are the stakeholders in the project.

May 22, 2007Mohamad Eid Collection - Methods of Collection Methods of Collection Observation: Valuable information can be obtained by watching people perform their activities in the context of the work environment. Observations can be made directly during the work day or indirectly using video and auditory recordings. Elicitation: Elicitation methods also involve direct and indirect methods of investigation, such as interviews, focus groups, and questionnaires.

May 22, 2007Mohamad Eid Collection - Methods of Collection

May 22, 2007Mohamad Eid Collection - Observation Direct —Ethnographic methods involve going to the work site and observing the people and the infrastructure that supports the work flow Indirect —You can use indirect methods of observation by setting up recording devices in the work place The use of indirect methods may require a significant degree of transparency

May 22, 2007Mohamad Eid Collection - Elicitation Tools for eliciting information from the various stakeholders: Direct Interviews Focus groups Indirect Corporate documentation Logs and notes Questionnaires

May 22, 2007Mohamad Eid Collection - Elicitation - Direct Direct methods of elicitation involve fact-to- face communication Physical aspects Cultural aspects Neutral linguistic approach Individual communication styles Tangents

May 22, 2007Mohamad Eid Collection - Elicitation – Direct - Interviews Interviews On-site interviews: may help people remember aspects of the job Away from job site interviews: not interrupted by normal work related events Be polite and courteous during interviews

May 22, 2007Mohamad Eid Interviews Open-ended questions: can be used to explore issues and elicit rich information about complex topics Closed-ended questions: can generally be answered with a polar yes/no response or a simple description. Collection - Elicitation – Direct - Interviews

May 22, 2007Mohamad Eid Collection - Elicitation – Direct - Interviews Interviews Predefined Scenarios: The interviewer can use predefined scenarios to stimulate conversation and gain insight Focus of Interview: It is important that the purpose of the interview is clearly defined Wrap-Up: It is important to share your thoughts about the results of the interview Advanced Organizers: Advanced organizers can be helpful in setting the frame of the design process

May 22, 2007Mohamad Eid Collection - Elicitation – Direct – Focus Groups Focus Groups Require a moderator/facilitator to keep discussion on track Maintain spontaneity Have clearly defined outcomes Provide participants with a context for the project

May 22, 2007Mohamad Eid Collection - Elicitation – Direct – Focus Groups The advantages of focus groups: They are relatively inexpensive and easy to set up. They can be used early in the design process to help to identify and prioritize features. They help you to gain insight into people’s attitudes and motivations. The disadvantages of focus groups: They only represent the views of one particular group. They are not statistically significant. They do not provide information about usability.

May 22, 2007Mohamad Eid Collection - Elicitation – Indirect - Questionnaires Questionnaires are familiar Questionnaires can contain open and closed questions Questionnaires can include the following: Mutually exclusive choices (radio buttons) Non–mutually exclusive choices (checkboxes) Ranges (overlapping, open-ended) Scales (Likert scales, semantic differential scales) Short-answer fill-ins Comments

May 22, 2007Mohamad Eid Collection - Elicitation – Indirect - Questionnaires Advantages of questionnaires: They do not involve face-to-face contact and can be administered remotely. They can be used to supply information for primary stakeholder profiles. They can be used to ascertain whether proposed solutions will meet with acceptance as well as to elicit new ideas. They can also be used to double-check the feedback obtained from one-on-one interviews. They can reach a large audience with relatively little expense.

May 22, 2007Mohamad Eid Collection - Elicitation – Indirect - Questionnaires Disadvantages of questionnaires: Vague questions will return ambiguous responses that will serve no useful purpose or the design. People do not like to fill out long questionnaires. Closed-ended questions can restrict responses. Open-ended questions can be hard to quantify.

May 22, 2007Mohamad Eid Collection - Elicitation – Indirect - Questionnaires Guidelines for questionnaires: Be consistent. Phrase instructions clearly. Speak the user’s language. Avoid jargon or technical terms. Order the questions beginning with the easy or less controversial ones. Use logical grouping. Avoid compound questions. Use appropriate form elements, for example, radio buttons, checkboxes, and so on. Use an appropriate scales for questions with discrete responses. Avoid overlapping ranges. Include a “None of the above” when appropriate. Be sensitive to the balance of positive and negative questions

May 22, 2007Mohamad Eid Interpretation Task Analysis Storyboarding Use Cases Primary Stakeholder Profiles

May 22, 2007Mohamad Eid Interpretation - Task Analysis Task analysis is a way of documenting how people perform tasks A task analysis includes all aspects of the work flow It is used to explore the requirements of the proposed system and structure the results of the data collection phase

May 22, 2007Mohamad Eid Interpretation - Task Analysis Task decomposition A linear description of a process that captures the elements involved as well as the prevailing environmental factors. Hierarchical task analysis (HTA) HTA provides a top-down, structured approach to documenting processes.

May 22, 2007Mohamad Eid Interpretation - Task Analysis - Task Decomposition Identify the process Describe the steps Include the following: The reasons for the actions The people who perform the actions The objects or information required to complete the actions

May 22, 2007Mohamad Eid Interpretation - Task Analysis - Task Decomposition Task decompositions should try to capture the following: The flow of information Use of artifacts Sequence of actions and dependences Environmental conditions Cultural constraints

May 22, 2007Mohamad Eid Interpretation - Task Analysis - Task Decomposition Task decompositions include: Goal—This defines the top-level goal for the analysis Information—This includes all of the information you need to perform the task Objects—These include all of the physical objects you will use to find the information Methods—These are the various ways you can proceed. Objectives—These are the subgoals Procedures—These are the triggers that may initiate contingency activities Contingencies—These will describe what you need to do if one of your methods does not work

May 22, 2007Mohamad Eid Interpretation - Task Analysis - HTA Hierarchical task analysis (HTA) Start with a specific goal and then add the tasks or subgoals required to achieve that goal. An HTA is read as follows: A box on top of another box describes what we want to do (subgoal). The box below another box describes how it is done. Plans control the flow between subgoals.

May 22, 2007Mohamad Eid Interpretation - Task Analysis First part of the HTA of the “schedule a team meeting” task.

May 22, 2007Mohamad Eid Interpretation - Task Analysis Second part of the HTA of the “schedule a team meeting” task.

May 22, 2007Mohamad Eid Interpretation - Storyboarding Storyboarding involves using a series of pictures that describes a particular process or work flow Can be used to study existing work flows or generate requirements. Can facilitate the process of task decomposition Used to brainstorm alternative ways of completing tasks.

May 22, 2007Mohamad Eid Storyboard of a computer based telephone Computer Telephone Last Name: First Name: Phone: Place CallHelp Help-> Computer Telephone Last Name: Greenberg First Name: Phone: Place CallHelp Dialling.... Cancel Call connected... Computer Telephone Last Name: Greenberg First Name: Phone: Place CallHelp Connected Hang up Call completed... Return Help Screen You can enter either the person's name or their number. Then hit the place button to call them Call by name-> Computer Telephone Last Name: Greenberg First Name: Phone: Place CallHelp Establishing connection->

May 22, 2007Mohamad Eid Interpretation – Use Cases Use cases represent a formal, structured approach to interpreting work flows and processes Designed to describe a particular goal and explore the interaction between users and the actual system components. Jacobson et al. (1992) Incorporated into the Unified Modeling Language (UML) standard.

May 22, 2007Mohamad Eid Interpretation – Use Cases The two main components of use cases are the actors and the use cases that represent their goals and tasks. Actors: similar to stakeholders, but can also include other systems, networks, or software that interacts with the proposed system. Use Cases: Each actor has a unique use case, which involves a task or goal the actor is engaged in. Describe discrete goals that are accomplished in a short time period Describe the various ways the system will be used and cover all of the potential functionality being built into the design

May 22, 2007Mohamad Eid Interpretation – Use Cases Use case diagram of “schedule a meeting” process.

May 22, 2007Mohamad Eid Interpretation – Use Cases There may be diverse paths through a Use Case Basic Path: The primary path through the use case is the one that is completed without any diversions from error conditions or extenuating circumstances Alternate Path: Alternate paths test the exception- handling capabilities of the system. They capture  premature termination of a process  choosing of a different method  possible error conditions

May 22, 2007Mohamad Eid Interpretation – Use Cases Scenarios: Each unique path through the use case is called a scenario. Scenarios represent discrete instances that combine to create the complete use case. They are the lowest level of the use case and should cover all conceivable paths and alternatives.

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles Primary Stakeholder Profiles are used to define the target user The constructs covered include: Context of use Cognitive ability Physical ability Individual profile

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles Context of Use for a common office desktop system

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles The cognitive abilities of the target user affect the design The cognitive abilities of the target user may be specific or more general Describe situations where cognitive ability must be specific and where it is more general

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles Domain expertise may not correlate with computer literacy

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles The human condition includes wide ranges of abilities visual auditory haptic Describe situations when physical ability will affect design

May 22, 2007Mohamad Eid Interpretation - Primary Stakeholder Profiles There are situations when personal user information is required Describe some design situations that require personal information

May 22, 2007Mohamad Eid Documentation Mission Statement Project goals: What is the value proposition? What needs will the new system address? How will it address these needs? Project scope What does the proposed design include or exclude? What are the external constraints such as time and finances? How will you decide when it satisfies the design proposal?

May 22, 2007Mohamad Eid Documentation Requirements Document Requirements Functional Information Physical Inputs/outputs Constraints

May 22, 2007Mohamad Eid Documentation Project Management Document Definition of the tasks involved in the project Risk Evaluation criteria and methods Implementation Training Maintenance Future needs

May 22, 2007Mohamad Eid متشکرم 谢谢 ありがとう