User requirements modelling: Motivation Source: Textbook (Dix et al.), ch. 6.1-6.5. Traditional SW lifecycle begins with Requirements Analysis: Requirements elicitation Requirements specification Problem 1: usability issues may be neglected Problem 2: may not get enough input from actual users Problem 3: may fail to consider how new system fits into organization

User requirements modelling: 3 approches Source: Textbook (Dix et al.), ch. 6.1-6.5. Socio-technical models (ex. USTM/CUSTOM) Soft Systems Methodology Participatory Design

Socio-technical models Source: Textbook (Dix et al.), ch. 6.1-6.5. Examples: USTM/CUSTOM, OSTA, ETHICS Considers both social (organizational) & technical issues good technical solution can fail if we do not take the social context into account Important to identify all stakeholders, not just end users Stakeholder: anyone effected by success/failure of system

Socio-technical model: USTM Source: Textbook (Dix et al.), ch. 6.1-6.5. USTM (User Skills & Task Match) /CUSTOM defines 4 categories of stakeholders: Primary: use the system (ex. UNCG students using Genie to register) Secondary: provide input or use output from system (ex. UNCG Registrars Office puts Fall course info into Genie) Tertiary: others affected by success/failure (ex. UNCG administration) Facilitating: designers/implementers/maintainers

Socio-technical model: USTM (2) Source: Textbook (Dix et al.), ch. 6.1-6.5. Process (can be time-consuming): Describe organization (ex. its goals, political/economic background) Describe all stakeholders (ex. their motivation, skills, power in organization) Describe workgroups (groups of people who work together on task) Describe what objects used for each task Analyze stakeholder requirements in view of above

Soft Systems Methodology (SSM) Source: Textbook (Dix et al.), ch. 6.1-6.5. Another approach to user requirements modelling that considers the social context, including different stakeholder perspectives (“root views”) Example: airline management’s perspective of new reservation system for travel agents Clients (those who receive output or benefit): customer Actors (those who perform activities within system): travel agents Transformations (from input to output): customer’s need for transportation transformed to sale of seat on plane (and profit for airline) Weltanschauung (world view of this perspective): increase profit through system efficiency Owner (who controls system): airline management Environment: airline regulations (local, national, international)

Participatory Design Another approach to user requirements modelling Source: Textbook (Dix et al.), ch. 6.1-6.5. Another approach to user requirements modelling future users are members of design team arguments for participatory design since users know most about work context, more effective design will result from their active participation if changes created by new system are not acceptable to users, then system will fail

Participatory Design (2) Source: Textbook (Dix et al.), ch. 6.1-6.5. Techniques to help users & designers communicate: Brainstorming: goal is to come up with ideas from everyone and record them (do not judge them yet) Storyboarding Workshops: users tell designers about his/her work and designers tell users about technical capabilities Pencil and paper exercises: ‘walkthrough’typical tasks using paper mock-ups of design

Adding HCI Methods to Traditional SW Lifecycle: Requirements Analysis Analyze & document users’ current tasks: Task Analysis (ch. 7) Gather & document requirements (especially non-functional requirements) for proposed system: Usability specification (ch. 5) User modelling: Socio-technical, Soft Systems, Participatory Design (ch. 6) Validation (designing the right product) of user interface Rapid prototyping (ch. 5)

Adding HCI Methods to Traditional SW Lifecycle: High-Level Design Suggest/eliminate ideas for design of user interface: Task Analysis, Usability specification (Use documents created by these methods during Requirements Phase) Participatory Design (Users continue working on design team after Requirements Phase) (ch. 6) Dialogue design notation (STN) (ch. 8) Interaction Paradigms (ch. 4), Design guidelines (ch. 5) Validation (designing the right product) of user interface Rapid prototyping (ch. 5)