Player-Computer Interaction
REQUIREMENTS ANALYSIS
UNIT 2:
Prof. Dr. Eike Langbehn
Department of Media Technology
Faculty of Design, Media and Information
Hamburg University of Applied Sciences
SECTION NAME
EXAMPLES
UNIT 2:
AGENDA
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
1. INTRO
2. REQUIREMENT
ANALYSIS
3. GAME
DESIGN
0. ORGANIZATION
4. GETTING STARTED
WITH GODOT
5. USER
STUDIES
6. ANALYSIS OF
HUMAN FACTORS
7. INTERACTION
DESIGN
8. ADVANCED PROGRAMMING
WITH GODOT
9. EVALUATION
MODELS
10. MARKET
ANALYSIS
11. NARRATIVE
DESIGN
12. GAME ENGINE
ARCHITECTURE
LEARNING outcomes
- Understanding the goals of the user
- Knowledge of techniques to assemble these goals & requirements
- Students will be able to put requirements into formal descriptions
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
USE AND CONTEXT
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
requirements
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
Requirement is ...
... something the product must do or a quality that the product must have.
Requirements must be:
- precise
- unique
- verifiable
quantitative instead of qualitative
Functional Requirements
- Speed
- Throughput
- Memory
- Precision
- ...
Example:
latency < 30ms instead of low latency
Robertson and Robertson: Mastering the Requirements Process, 2006
Non-Functional Requirements
- Adjectives: secure, reliable, stable, fast, simple...
- Usability
- User Acceptability
- Accessibility
- Appearance / Look&Feel
- User Experience
- ...
Example:
time to learn < 30min
REQUIREMENTS ANALYSIS
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
- Requirements result from goals and intentions of the user
- Goals & intentions need to be collected
- Requirements must be analyzed and understood
- Goal of the analysis is to gather information about the interactive system
- Goals of the interactive system
- User of the interactive system
- Options for implementation, e.g. technologies
- Boundary conditions, economic or organizational limitations etc.
pact framework
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
Heterogenous people do different activities in diverse contexts using several different technologies
Which people do which activities in which contexts with which technologies?
People
Technology
Activities
Context
A. Anderson: PACT Analysis and prototype design for an interactive system, 2011
understanding goals
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
- Why is the new system developed?
- What is the main purpose?
- How will the user use it?
- What is the role of the system?
- How important is it for the client?
understanding goals
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
goals in games
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
- distraction from everyday life
- competition
- satisfaction
- insight into other cultures/ages
- tension
- get scared
- experience a story
- Experience-Goals (visceral): How does the user want to feel?
- End-Goals (behavioral): What does the user want to do?
- Life Goals (reflective): Who does the user want to be
Personas
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
Description
- Persona is archetype user figure who is representative for real users
- Persona bundles user groups in concrete hypothetical person
- Persona should be described in detail, e.g. name, age, gender, education, ...
- All users in use cases & scenarios should be personas
Details
Advantages
- Personas have characteristics like a full name and a photo
- Further attributes depending on relevance for the system:
- Job
- Role
- Gender
- Marital Status
- Goals
- Education
- Skills
- Hobbies
- ....
- All team members develop common understanding of their users
- System is not alligned at subjective opinions but at requirements of target group
- Disagreement can be objectified and clarified by personas
Personas != Stereotypes
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
HIPSTER
NERD
gamer types
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
Janaki Kumar and Mario Herger. CC BY-ND 3.0
scenarios
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
- Scenario is typical procedure when persona uses interactive system
- Scenario is factual narration
- Scenario includes goals, motivation, actions, reactions, and more
- All steps of using the system are described from a user perspective
- Context information about user and usage is also described
- Scenarios can extend over variable times
Example: Counter-Strike
Scenario 1: Bomb planting
- John Doe plays a terrorist
- He places bomb
- He runs away
- Counter-Terrorist runs to bomb place
- Counter-Terrorist defuses bomb
Persona
Action
Reaction
Goal
User stories
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
- User stories are requirements that are formulated in everyday language
- User stories are simple descriptions of the goals that the user wants to reach with the interactive system
- User stories derive directly from scenarios
- Who wants what why?
- User stories focus on users, roles, goals and use
- "As <user/role> I want to <goal> to <use>
"As a terrorist I want to place a bomb to win the match"
"As a counter-terrorist I want to defuse the bomb to win the match"
Work packages
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
Work Package
User Story 1
User Story 2
Task A
Task B
Task C
collecting data
PLAYER-COMPUTER INTERACTION
UNIT 2: REQUIREMENTS ANALYSIS
User Goals
User Stories
Persona
Scenarios
How to collect data about goals, users, tasks...?
- Interviews
- User observation
- Focus groups
- Task analysis
- ...
Player-Computer Interaction
The contents of this Open Educational Resource are licensed under the Creative-Commons Attribution 4.0 International license (CC BY 4.0)
Attribution: Eike Langbehn, Anh Sang Tran, Peter Wood