Transcript User requirements modelling: 3 approaches

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:
approches
Source: Textbook (Dix et al.), ch. 6.1-6.5.
• Socio-technical
• Soft
models (ex. USTM/CUSTOM)
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
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
administration)
•
affected by success/failure (ex. UNCG
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
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 nonfunctional 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)