[HCI] Week 06 Requirements and Models

Lecture 6

Requirements and Models

Human Computer Interaction/COG3103, 2016 Fall Class hours : Monday 1-3 pm/Wendseday 2-3 pm Lecture room : Widang Hall 209 10th October

Exercise 4-1: Flow Model Sketch for Your System

• Goal

– Get practice in making an initial flow model sketch for the work practice of an organization.

• Activities:

– For your target system sketch out a flow model diagram, in the same style as our flow model sketch for MUTTS, shown in

Figure 4-3, showing work roles, information flow, information repositories, transactions, etc.

– Draw on your raw work activity data and construct a representation of the flow of data, information, and work artifacts.

Even if there is no existing automated system, you should capture the flow of the manual work process.

– Start with representing your work roles as nodes, add in any other nodes for databases and so on.

– Label communication and flow lines.

– If you do not have enough contextual data from your limited data-gathering exercise, make some up to make this work.

• Deliverables

– A one-page diagram illustrating a high-level flow model for the existing work process of your target system.

• Schedule

– Given the simplicity of the domain, we expect this exercise to take about an hour.

Lecture #6 COG_Human Computer Interaction 2

ORGANIZING CONCEPTS: WORK ROLES AND FLOW MODEL


Figure 4-3 An initial flow model sketch of the MUTTS system.

Homework


Finish the Class Exercise 3-1

Complete Flow Model Sketch for

Your System

Finish the Class Exercise 4-1

1 2 3

Your Blog Post #5 - 150 words or fewer

Iterate your concept and flow models - Upload sketches and diagrams

on your pinterest boards - Boards can be divided into a

few such as - Users/Actors - Entities - Context - Benchmark system cases - flow diagrams

Your Blog Post #6 - A one-page Diagram - 5 Benchmark Cases You

may wish to refer

EXTRACTING INTERACTION DESIGN REQUIREMENTS

Textbook Chapter 5.


INTRODUCTION


Figure 5-1 You are here; the chapter on extracting interaction requirements, within understanding user work and needs in the context of the overall Wheel lifecycle template.

INTRODUCTION

• Gap between Analysis and Design

– Information coming from contextual studies describes the work domain

but does not directly meet the information needs in design.

– There is a cognitive shift between analysis-oriented thinking on one side

of the gap and design-oriented thinking on the other.

– The gap is the demarcation between the old and the new—between

studying existing work practice and existing systems and envisioning a

new work space and new system design space.


INTRODUCTION


Figure 5-2 Overview of the bridge to design.

NEEDS AND REQUIREMENTS: FIRST SPAN OF THE BRIDGE

• What Are “Requirements”?

• Requirements “Specifications”

– Detailed formal requirements cannot ever be complete.

– Detailed formal requirements cannot ever be 100% correct.

– Detailed formal requirements cannot be prevented from changing

throughout the lifecycle.

• Software and Functional Implications of Interaction Design

Requirements


FORMAL REQUIREMENTS EXTRACTION

• Walking the WAAD for Needs and Requirements

• Switching from Inductive to Deductive Reasoning

• Preparation

• Systematic Deduction of Needs as “Hinges” to Get at Requirements

• Terminology Consistency

• Requirement Statements

• Requirement Statement Structure

• Requirements Document Structure




Name of major feature or category Name of second-level feature or category Requirement statement [WAAD source node ID] Rationale (if useful): Rationale statement Note (optional): Commentary about this requirement

Security Privacy of ticket–buyer transactions Shall protect security and privacy of ticket-buyer transactions [C19] Note: In design, consider timeout feature to clear screen between customers.

Figure 5-3 Generic structure of a requirement statement.

Figure 5-4 Example requirement statement.


• Continue the Process for the Whole WAAD

• Keep an Eye out for Emotional Impact Requirements and Other Ways

to Enhance the Overall User Experience

• Extrapolation Requirements: Generalization of Contextual Data

• Other Possible Outputs from the Requirements Extraction Process

– Questions about missing data

– System support needs

– Marketing inputs



• Constraints as Requirements

• Prioritizing Requirements

• Taking Requirements Back to Customers and Users for Validation

• Resolve Organizational, Sociological, and Personal Issues with the

Customer


ABRIDGED METHODS FOR REQUIREMENTS EXTRACTION

• Use the WAAD Directly as a Requirements Representation

• Anticipating Needs and Requirements in Contextual Analysis

• Use Work Activity Notes as Requirements (Eliminate the WAAD

Completely)


CONSTRUCTING DESIGN-INFORMING MODELS

Textbook Chapter 6.


INTRODUCTION


Figure 6-1 You are here; the chapter on constructing design informing models, within understanding user work and needs in the context of the overall Wheel lifecycle template.

DESIGN-INFORMING MODELS: SECOND SPAN OF THE BRIDGE

• What Are Design-Informing Models and How Are They Used?

– help integrate and summarize the contextual data

– point back to the data, to maintain the “chain of custody” to ensure that

the design is based on real contextual data

– provide a shared focus for analysis now and, later, design

– provide intermediate deliverables, which can be important to your

working relationship with the customer

• Envisioned Design-Informing Models


SOME GENERAL “HOW TO” SUGGESTIONS

• Maintain Connections to Your Data

• Extract Inputs to Design-Informing Models

• Use Your “Bins” of Sorted Work Activity Notes from Contextual Inquiry

and Contextual Analysis

• Represent Barriers to Work Practice


USER MODELS

• Work Roles

– Sub-roles

– Mediated work roles

– Envisioned work roles

– Relationship of work roles to

other concepts


Figure 6-2 Concepts defining and related to work roles.

USER MODELS

• User Classes

– Knowledge- and skills-based characteristics

– Physiological characteristics

– Experience-based characteristics

• novice or first-time user: may know application domain but not specifics of the

application

• intermittent user: uses several systems from time to time; knows application

domain but not details of different applications

• experienced user: “power” user, uses application frequently and knows both

application and task domain very well


USER MODELS


Figure 6-3 Relationships among work roles, sub-roles, and user class characteristics.

USER MODELS

• Social Models

– Identify active entities and represent as nodes

– Identify concerns and perspectives and represent as attributes of nodes

– Identify influences and represent as relationships among entities

– Social models in the commercial product perspective

– The envisioned social model

• User Personas


USER MODELS


Figure 6-4 Depiction of entities in the slideshow presentation social model. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack,& Myers, 1999) on which this example is based.

USER MODELS


Figure 6-6 Depiction of influences in the slideshow presentation social model.

USER MODELS


Figure 6-7 Example social model for MUTTS.

USAGE MODELS

• Flow Model

– Creating a flow model diagram

– Flow models in the product perspective

– The envisioned flow model

• Task Models

– Tasks vs. functions

• Task Structure Models—Hierarchical Task Inventory

– Task inventories

– Task naming in hierarchical task inventories

– Avoid temporal implications in hierarchical task inventories

– Envisioned task structure model


USAGE MODELS


Figure 6-8 Example flow model from the slideshow presentation contextual inquiry. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack,& Myers, 1999) on which this is based.

USAGE MODELS


Figure 6-9 Flow model of our version of MUTTS.

USAGE MODELS


Figure 6-10 Envisioned flow model for the Ticket Kiosk System.

USAGE MODELS


Figure 6-11 Hierarchical relationship of task A, the super-task, and tasks B and C, subtasks.

Figure 6-12 An incorrect hierarchical relationship attempting to show temporal sequencing.

USAGE MODELS


Figure 6-13 Sketch of the top levels of a possible hierarchical task inventory diagram for MUTTS.

USAGE MODELS


Figure 6-14 Partial HTI for MUTTS “sell tickets” task.

USAGE MODELS

• Task Interaction Models

– Usage scenarios as narrative task interaction models

– Elements of scenarios.

• Agents (users, people in work roles, often in personas, system, sensors)

• User goals and intentions

• User background, training, needs, etc.

• Reflections on work practice, including user planning, thoughts, feelings, and reactions to system

• User actions and user interface artifacts

• System responses, feedback

• User tasks, task threads, workflows, including common, representative, mission critical, and error and

recovery situations

• Environmental and work context (e.g., phone ringing)

• Barriers, difficulties encountered in usage

• And, of course, a narrative, a story that plays out over time


USAGE MODELS

• Task Interaction Models

– Envisioned usage scenarios or design scenarios

– Step-by-step task interaction models

– Essential use case task interaction models

– Envisioned task interaction models

• Information Object Model

– Analyzing scenarios to identify ontology


USAGE MODELS


Figure 6-15 Branching and looping structures within step-by step task interaction models.

USAGE MODELS


Figure 6-16 Task interaction branching and looping for MUTTS.

USAGE MODELS


User Intention System Responsibility

1. Ticket seller to computer: Express intention to pay 2. Request to insert card

3. Ticket seller or ticket buyer: Insert card 4. Request to remove card quickly

5. Withdraw card 6. Read card information

7. Summarize transaction and cost

8. Request signature (on touch pad)

9. Ticket buyer: Write signature 10. Conclude transaction

11. Issue receipt

12. Take receipt

Table 6-1 Example essential use case: Paying for a ticket purchase transaction (with a credit or debit card)

WORK ENVIRONMENT MODELS

• Artifact Model

– Constructing the artifact model

• Physical Model

– Envisioned physical model




Figure 6-17 Part of a restaurant flow model with focus on work artifacts derived from the artifact model.



Figure 6-18 Physical model for one slideshow presentation case. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their example (Cross, Warmack, & Myers, 1999) on which this is based.



Figure 6-19 A physical model for MUTTS.

BARRIER SUMMARIES


# Trigger Goal Barrier

18 Question from remote audience member

Answer questions Audio unintelligible. Local members instruct remote members to adjust audio setting.

19 Comment from remote member

Respond to comment Audio unintelligible. Local members instruct remote members to reconnect.

20 Comments from local members

Respond to comments by referring to slide from earlier in presentation

Presenter tries to return to slide. Presenter searches through slides rapidly but cannot find it.

21 Question from local member

Answer question Presenter tries again and eventually finds slide.

22 Local member asks presenter to bring up previous slide.

Go backward one slide Presenter tries to go back one slide but goes forward one slide instead.

23 Remote audience reconnected

Continue discussion

24 Question from remote member

Answer question

25 Comment from local member

Respond to question Presenter flips through slides searching for “system architecture” slide.

Table 6-2 Summary of selected barriers discovered within the step-by-step task interaction models for slideshow presentations

BARRIER SUMMARIES


Description Model % of Talks Count (Over all Talks)

Average Severity

Average Duration (Each Time)

1. Changing slides is difficult and awkward because of the placement of the mouse or laptop. Physical 67 166 1.2 2 sec

2. Presenter loses track of time, must ask for verbal update. Sequence 44 6 1.5 55 sec

3. Reference provided is incomplete or skimmed over, audience members would be unable to find it after the talk.

Cultural 44 6 1 19 sec

4. Camera view is unclear or pointed at wrong information. Flow 33 3 1.7 60 sec

5. Audio level for demos is not set correctly. Flow 33 3 2 46 sec

Table 6-3 Summary of most frequent barriers observed in presentation cases

MODEL CONSOLIDATION


Figure 6-20 Flow model from a group who observed and interviewed the event manager, event sponsors, the financial manager, and the database administrator.

MODEL CONSOLIDATION


Figure 6-21 Flow model from a group who mainly observed and interviewed ticket buyers and ticket sellers.

MODEL CONSOLIDATION


Figure 6-22 Flow model from a group who observed and interviewed the office manager, the advertising manager, and external advertisers.

ABRIDGED METHODS FOR DESIGN-INFORMING MODELS EXTRACTION

• Be Selective about the Modeling You Need to Do

• Designer-Ability-Driven Modeling

• Use a Hybrid of WAAD and Relevant Models

• Create Design-Informing Models on the Fly during Interviews


Exercise 6-3: A Social Model for Your System

• Goal

– Get a little practice in making a social model diagram.

• Activities

– Identify active entities, such as work roles, and represent as nodes in the diagram.

– Include groups and subgroups of roles and external roles that interact with work roles.

– Include system-related roles, such as a central database.

– Include workplace ambiance and its pressures and influences.

– Identify concerns and perspectives and represent as attributes of nodes.

– Identify social relationships, such as influences between entities, and represent these as arcs between nodes in the

diagram.

– Identify barriers, or potential barriers, in relationships between entities and represent them as red bolts of lightning .

• Deliverables

– One social model diagram for your

• Schedule

– This could take a couple of hours.


USER MODELS


Figure 6-7 Example social model for MUTTS.

Exercise 6-5: Creating a Flow Model for Your System

• Goal: Get a little practice in creating a flow model for an enterprise.

• Activities:

– Follow up on your flow model initial sketch that you did in Exercise 4-1.

– Again represent each work role or system entity as a node in the diagram.

– Use arcs between nodes to show all communication and coordination necessary to do the work of the

enterprise.

– Use arcs to represent all information flow and flow of physical artifacts.

– Include all forms of communication, including direct conversations, email, phones,

• letters, memos, meetings, and so on.

– Include both flow internally within the enterprise and flow externally with the rest of the world.

• Deliverables

– One flow model diagram for your system, with as much detail as feasible.

• Schedule

– This could take a couple of hours.


Flow Model 1


Figure 4-3 An initial flow model sketch of the MUTTS system.

Flow Model 2.1


Figure 6-9 Flow model of our version of MUTTS.

Flow Model 2.2


Figure 6-10 Envisioned flow model for the Ticket Kiosk System.

Midterm Presentation Guideline

• Date/Time/Duration

– 1-2:50 pm Monday, 24th October 2015

– 2-2:50 pm Wendesday, 26th October 2015

– The length of a presentation : 5 mins

• Presentation Document Content

– System Concept Statement (Exercise 3-1)

– Flow Model I (Exercise 4-1)

– Social Model (Exercise 6-3)

– Flow Model II (Exercise 6-5)

• Post on your blog

– Due until 11:59 pm (Sun) 23rd Oct.

– Embed the presentation file from slideshare.


[HCI] Week 06 Requirements and Models

Education

Transcript of [HCI] Week 06 Requirements and Models