User requirements modelling: Motivation

1
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

2
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

3
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

4
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

5
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

6
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 managements 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)
  customers 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)

7
Participatory Design
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

8
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 walkthroughtypical
  tasks using paper mock-ups of design

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

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