Human computer interaction 3 4(revised)emaan waseem
human computer interaction Human-Computer Interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them” -ACM/IEEE
Interaction Design in Human Computer Interaction by Vrushali Dhanokar. This PPT is useful to every students who study Human Computer Interaction in detail. Specially for TE Students of Information Technology in Pune University. Thank You.
Human computer interaction 3 4(revised)emaan waseem
human computer interaction Human-Computer Interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them” -ACM/IEEE
Interaction Design in Human Computer Interaction by Vrushali Dhanokar. This PPT is useful to every students who study Human Computer Interaction in detail. Specially for TE Students of Information Technology in Pune University. Thank You.
Chapter 10: Universal design
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 2: The computer
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Human-computer interaction (HCI) is a multidisciplinary field of study focusing on the design of computer technology and, in particular, the interaction between humans (the users) and computers. While initially concerned with computers, HCI has since expanded to cover almost all forms of information technology design
Chapter 11: User support
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 9: Evaluation techniques
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
HCI 3e - Ch 6: HCI in the software processAlan Dix
Chapter 6: HCI in the software process
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 7: Design rules
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Human-Computer Interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them” -ACM/IEEE
additional slides for Chapter 4: Paradigms
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
User Interface Design- Module 2 Uid ProcessbrindaN
User Interface Design- Module 2 Uid Process
Subject Code:15CS832 USER INTERFACE DESIGN
VTU UNIVERSITY
Referred Text Book: The Essential Guide to User Interface Design (Second Edition) Author: Wilbert O. Galitz
Chapter 10: Universal design
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 2: The computer
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Human-computer interaction (HCI) is a multidisciplinary field of study focusing on the design of computer technology and, in particular, the interaction between humans (the users) and computers. While initially concerned with computers, HCI has since expanded to cover almost all forms of information technology design
Chapter 11: User support
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 9: Evaluation techniques
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
HCI 3e - Ch 6: HCI in the software processAlan Dix
Chapter 6: HCI in the software process
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 7: Design rules
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Human-Computer Interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them” -ACM/IEEE
additional slides for Chapter 4: Paradigms
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
User Interface Design- Module 2 Uid ProcessbrindaN
User Interface Design- Module 2 Uid Process
Subject Code:15CS832 USER INTERFACE DESIGN
VTU UNIVERSITY
Referred Text Book: The Essential Guide to User Interface Design (Second Edition) Author: Wilbert O. Galitz
Are you in an early stage of your product design or already have a finished product? You can apply heuristics principles and identify key interaction and usability issues its cheaper than usability testing but certainly not effective alternate as real user inputs. This could give way to detailed usability designs without having to spend more time and money.
Principles of learnability in interaction design, including predictability, synthesizability, familiarity, generalizability, and consistency.
Emphasis on the need for intuitive user interaction, where users can predict outcomes based on past interactions, apply previous knowledge, and experience consistency across similar tasks.
All content within this presentation is the property of Royal Holloway, University of London. Unauthorized use, duplication, or distribution of the materials contained herein is strictly prohibited.
Before spending your budget on Evaluating Interfaces with Users, it's essential to do a evaluation at your end.
At SwitchMe, I took a session with my team of developers to explain importance and method of Evaluating Interfaces at our end first.
Dark web markets: from the silk road to alphabay, trends and developmentsAndres Baravalle
Within the last years, governmental bodies have been futilely trying to fight against dark web hosted marketplaces. Shortly after the closing of “The Silk Road” by the FBI and Europol in 2013, new successors have been established. Through the combination of cryptocurrencies and nonstandard communication protocols and tools, agents can anonymously trade in a marketplace for illegal items without leaving any record.
This talk will presents a research carried out to gain insights on the products and services sold within one of the larger marketplaces for drugs, fake ids and weapons on the Internet, Agora, and on new developments after the demise of Agora.
Introduction to JavaScript course. The course was updated in 2014-15.
Will allow you to understand what is JavaScript, what's it history and how you can use it.
The set of slides "Introduction to jQuery" is a follow up - which would allow the reader to have a basic understanding across JavaScript and jQuery.
The Roman Empire A Historical Colossus.pdfkaushalkr1407
The Roman Empire, a vast and enduring power, stands as one of history's most remarkable civilizations, leaving an indelible imprint on the world. It emerged from the Roman Republic, transitioning into an imperial powerhouse under the leadership of Augustus Caesar in 27 BCE. This transformation marked the beginning of an era defined by unprecedented territorial expansion, architectural marvels, and profound cultural influence.
The empire's roots lie in the city of Rome, founded, according to legend, by Romulus in 753 BCE. Over centuries, Rome evolved from a small settlement to a formidable republic, characterized by a complex political system with elected officials and checks on power. However, internal strife, class conflicts, and military ambitions paved the way for the end of the Republic. Julius Caesar’s dictatorship and subsequent assassination in 44 BCE created a power vacuum, leading to a civil war. Octavian, later Augustus, emerged victorious, heralding the Roman Empire’s birth.
Under Augustus, the empire experienced the Pax Romana, a 200-year period of relative peace and stability. Augustus reformed the military, established efficient administrative systems, and initiated grand construction projects. The empire's borders expanded, encompassing territories from Britain to Egypt and from Spain to the Euphrates. Roman legions, renowned for their discipline and engineering prowess, secured and maintained these vast territories, building roads, fortifications, and cities that facilitated control and integration.
The Roman Empire’s society was hierarchical, with a rigid class system. At the top were the patricians, wealthy elites who held significant political power. Below them were the plebeians, free citizens with limited political influence, and the vast numbers of slaves who formed the backbone of the economy. The family unit was central, governed by the paterfamilias, the male head who held absolute authority.
Culturally, the Romans were eclectic, absorbing and adapting elements from the civilizations they encountered, particularly the Greeks. Roman art, literature, and philosophy reflected this synthesis, creating a rich cultural tapestry. Latin, the Roman language, became the lingua franca of the Western world, influencing numerous modern languages.
Roman architecture and engineering achievements were monumental. They perfected the arch, vault, and dome, constructing enduring structures like the Colosseum, Pantheon, and aqueducts. These engineering marvels not only showcased Roman ingenuity but also served practical purposes, from public entertainment to water supply.
Honest Reviews of Tim Han LMA Course Program.pptxtimhan337
Personal development courses are widely available today, with each one promising life-changing outcomes. Tim Han’s Life Mastery Achievers (LMA) Course has drawn a lot of interest. In addition to offering my frank assessment of Success Insider’s LMA Course, this piece examines the course’s effects via a variety of Tim Han LMA course reviews and Success Insider comments.
How to Make a Field invisible in Odoo 17Celine George
It is possible to hide or invisible some fields in odoo. Commonly using “invisible” attribute in the field definition to invisible the fields. This slide will show how to make a field invisible in odoo 17.
Palestine last event orientationfvgnh .pptxRaedMohamed3
An EFL lesson about the current events in Palestine. It is intended to be for intermediate students who wish to increase their listening skills through a short lesson in power point.
Macroeconomics- Movie Location
This will be used as part of your Personal Professional Portfolio once graded.
Objective:
Prepare a presentation or a paper using research, basic comparative analysis, data organization and application of economic information. You will make an informed assessment of an economic climate outside of the United States to accomplish an entertainment industry objective.
Embracing GenAI - A Strategic ImperativePeter Windle
Artificial Intelligence (AI) technologies such as Generative AI, Image Generators and Large Language Models have had a dramatic impact on teaching, learning and assessment over the past 18 months. The most immediate threat AI posed was to Academic Integrity with Higher Education Institutes (HEIs) focusing their efforts on combating the use of GenAI in assessment. Guidelines were developed for staff and students, policies put in place too. Innovative educators have forged paths in the use of Generative AI for teaching, learning and assessments leading to pockets of transformation springing up across HEIs, often with little or no top-down guidance, support or direction.
This Gasta posits a strategic approach to integrating AI into HEIs to prepare staff, students and the curriculum for an evolving world and workplace. We will highlight the advantages of working with these technologies beyond the realm of teaching, learning and assessment by considering prompt engineering skills, industry impact, curriculum changes, and the need for staff upskilling. In contrast, not engaging strategically with Generative AI poses risks, including falling behind peers, missed opportunities and failing to ensure our graduates remain employable. The rapid evolution of AI technologies necessitates a proactive and strategic approach if we are to remain relevant.
Operation “Blue Star” is the only event in the history of Independent India where the state went into war with its own people. Even after about 40 years it is not clear if it was culmination of states anger over people of the region, a political game of power or start of dictatorial chapter in the democratic setup.
The people of Punjab felt alienated from main stream due to denial of their just demands during a long democratic struggle since independence. As it happen all over the word, it led to militant struggle with great loss of lives of military, police and civilian personnel. Killing of Indira Gandhi and massacre of innocent Sikhs in Delhi and other India cities was also associated with this movement.
Chapter 3 - Islamic Banking Products and Services.pptx
Design rules and usability requirements
1. Cn5109 – Week 7: Design
rules and usability
requirements
Dr. Andres Baravalle
1
2. Interaction design
• The next slides are based on "Interaction
Design – Measuring the user interaction"
• By the end of this week, you should have
studied all chapters of the textbook up to
chapter 8!
2
6. Design rules: principles,
standards and guidelines
• Design rules are mechanism to restrict the
domain of design options
– Usability-related principles, standards and guidelines
support the developer
• Principles
– General understanding of design as a subject area
• Standards and guidelines
– Direction for design
• Design patterns
– Capture and reuse design knowledge
7. Types of design rules
• Design rules differ in generality and authority
• Principles
– Abstract design rules
– Low authority
– High generality
• Standards
– Specific design rules
– High authority
– Limited application
• Heuristics and guidelines
– Lower authority
– More general application
increasing authority
increasinggenerality
Standards
Guidelines
increasing authority
increasinggenerality
8. Principles to support usability
• Learnability
– The ease with which new users can begin effective
interaction and achieve maximal performance
• Flexibility
– The multiplicity of ways the user and system
exchange information
• Robustness
– The level of support provided the user in determining
successful achievement and assessment of goal-
directed behaviour
9. Principles of learnability (2)
• Predictability
– Determining effect of future actions based on
past interaction history
• Synthesizability
– Assessing the effect of past actions
– Immediate vs. eventual honesty
10. Principles of learnability (3)
• Familiarity
– How prior knowledge applies to new system
• Generalizability
– Extending specific interaction knowledge to
new situations
• Consistency
– Likeness in input/output behaviour arising
from similar situations or task objectives
11. Principles of flexibility
• Dialogue initiative
– Freedom from system imposed constraints on input
dialogue
• Multithreading
– Ability of system to support user interaction for more
than one task at a time
– Concurrent vs. interleaving; multimodality
• Task migrability
– Passing responsibility for task execution between
user and system
12. Principles of flexibility (2)
• Substitutivity
– Allowing equivalent values of input and output
to be substituted for each other (e.g. text and
audio)
– Representation multiplicity
• Customizability
– Modifiability of the user interface by user
(adaptability) or system (adaptativity)
13. Principles of robustness
• Observability
– Ability of user to evaluate the internal state of
the system from its perceivable representation
• Recoverability
– Ability of user to take corrective action once
an error has been recognized
– Reachability; forward/backward recovery;
commensurate effort
14. Principles of robustness (2)
• Responsiveness
– How the user perceives the rate of
communication with the system
• Task conformance
– Degree to which system services support all
of the user's tasks
– Task completeness; task adequacy
15. Standards
• Set by national or international bodies to
ensure compliance by a large community
of designers standards require sound
underlying theory and slowly changing
technology
• Examples include:
– W3C HTML and CSS standards
– ISO 6385:2004: Ergonomic principles in the
design of work systems
16. Guidelines and heuristics
• Guidelines are detailed rules for design,
often platform or task-specific
• (Usability) heuristics are principles and
rules of thumb that govern the overall
design approach
– Many textbooks and reports are full of
guidelines and heuristics
– Understanding justification for guidelines
aids in resolving conflicts
17. Heuristic collection
• Nielsen’s 10 Heuristics (see Chapter 9 of
Dix et al)
• Shneiderman’s 8 Golden Rules
• Norman’s 7 Principles
18. Nielsen’s heuristics
• Developed by Jacob Nielsen in the early
1990s.
– Based on heuristics distilled from an empirical
analysis of 249 usability problems.
– The heuristics have been revised for current
technology
18
19. Neilsen’s heuristics
• Visibility of system status:
The system should always keep users informed about what is going
on, through appropriate feedback within reasonable time.
• Match between system and the real world:
The system should speak the user's language, with words, phrases
and concepts familiar to the user, rather than system-oriented terms.
Follow real-world conventions, making information appear in a
natural and logical order.
• User control and freedom:
Users often choose system functions by mistake and will need a
clearly marked "emergency exit" to leave the unwanted state without
having to go through an extended dialogue. Support undo and redo.
• Consistency and standards:
Users should not have to wonder whether different words,
situations, or actions mean the same thing. Follow platform
conventions.
20. Neilsen’s heuristics (2)
• Error prevention:
Even better than good error messages is a careful design which
prevents a problem from occurring in the first place. Either eliminate
error-prone conditions or check for them and present users with a
confirmation option before they commit to the action.
• Recognition rather than recall:
Minimize the user's memory load by making objects, actions, and
options visible. The user should not have to remember information
from one part of the dialogue to another. Instructions for use of the
system should be visible or easily retrievable whenever appropriate.
• Flexibility and efficiency of use:
Accelerators -- unseen by the novice user -- may often speed up the
interaction for the expert user such that the system can cater to both
inexperienced and experienced users. Allow users to tailor frequent
actions.
21. Neilsen’s heuristics (3)
• Aesthetic and minimalist design:
Dialogues should not contain information which is irrelevant or rarely
needed. Every extra unit of information in a dialogue competes with
the relevant units of information and diminishes their relative
visibility.
• Help users recognize, diagnose, and recover from errors:
Error messages should be expressed in plain language (no codes),
precisely indicate the problem, and constructively suggest a
solution.
• Help and documentation:
Even though it is better if the system can be used without
documentation, it may be necessary to provide help and
documentation. Any such information should be easy to search,
focused on the user's task, list concrete steps to be carried out, and
not be too large.
22. Shneiderman’s 8 Golden Rules
1. Strive for consistency
2. Enable frequent users to use shortcuts
3. Offer informative feedback
4. Design dialogs to yield closure
5. Offer error prevention and simple error handling
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load
23. Norman’s 7 Principles
1. Use both knowledge in the world and
knowledge in the head
2. Simplify the structure of tasks
3. Make things visible
4. Get the mappings right
5. Exploit the power of constraints, both natural
and artificial
6. Design for error
7. When all else fails, standardise
25. 25
What is Interaction Design?
• It is a process:
– A goal-directed problem solving activity
informed by intended use, target domain,
materials, cost, and feasibility
– A creative activity
– A decision-making activity to balance trade-
offs
• Four approaches: user-centered design,
activity-centered design, systems
design, and genius design
26. What is a user-centered
approach?
• User-centered approach is based on:
– Early focus on users and tasks: directly studying
user characteristics (cognitive, behavioural,
anthropomorphic & attitudinal) and the task for which
we are designing a system
– Empirical measurement: users’ reactions and
performance to scenarios, manuals, simulations &
prototypes are observed, recorded and analysed
– Iterative design: when problems are found in user
testing, fix them and carry out more tests
26
27. 27
Importance of involving users
• Expectation management
– Realistic expectations
– No surprises, no disappointments
– Timely training
– Communication, but no hype
• Ownership
– Make the users active stakeholders
– More likely to forgive or accept problems
– Can make a big difference to acceptance and
success of product
28. 28
Degrees of user involvement
• Member of the design team
– Full time: constant input, but lose touch with
users
– Part time: patchy input, and very stressful
– Short term: inconsistent across project life
– Long term: consistent, but lose touch with users
• Dissemination devices, as newsletters
– Reach wider selection of users
– Need communication both ways
• User involvement after product is released
• Combination of these approaches
29. Interaction design activities
• Interaction design activities should be
iterative:
– Establishing requirements
– Prototyping
– Evaluating the prototypes
29
30. Used-centered design questions
• Who are the users?
• What do we mean by ‘needs’?
• How to generate alternatives?
• How to choose among alternatives?
• How to integrate interaction design
activities with other models?
30
31. Who are the stakeholders?
• Not as obvious as you think:
– Those who interact directly with the product
– Those who manage direct users
– Those who receive output from the product
– Those who make the purchasing decision
– Those who use competitor’s products
should be also considered!
31
32. Who are the stakeholders? (2)
• Three categories of stakeholders (Eason,
1987):
– Primary users: frequent hands-on
– Secondary users: occasional or via
someone else
– Tertiary users: affected by its introduction, or
will influence its purchase
32
33. What do we mean by ‘needs’?
• Users rarely know what is possible
• Users (typically) can’t tell you what they ‘need’ to help
them achieve their goals
• Instead, look at existing tasks:
– Their context
– What information they require
– Who collaborates to achieve the task
– Why is the task achieved the way it is
• Envisioned tasks:
– Can be rooted in existing behaviour
– Can be described as future scenarios
33
34. How to generate alternatives?
• Humans stick to what they know works
– Considering alternatives is important to ‘break
out of the box’
• Designers are trained to consider alternatives,
software developers generally are not
• How do you generate alternatives?
– ‘Flair and creativity’: research and synthesis
– Seek inspiration: look at similar products or look at
very different products
34
35. How to choose among
alternatives?
• Evaluation with users or with peers, e.g.
prototypes
• Technical feasibility: some are not possible
• Quality thresholds: usability goals lead to
usability criteria set early on and check regularly
– e.g.:
– Utility: which functions are superfluous?
– Effectiveness: appropriate support? task coverage,
information available
– Efficiency: performance measurements
35
37. How to integrate interaction
design in other models?
• Agile software development is one option:
– Have development and design running in
separate tracks
– Maintain a coherent vision of the interface
architecture
37
40. Requirements: how?
• Requirements are often collected in an
iterative way:
– Elicitation (also known as gathering or
collection)
– Specification
– Analysis & negotiation
• Prioritization
• Selection
• Validation (are the req. correct, are these the
correct requirements)
40
41. Requirements: why?
• Getting requirements right is crucial
– Requirement definition is the stage
where most failures are rooted
41
43. Software Requirements
Specification
• According to IEEE 830-1998, a software
requirement specification (SRS) is a
specification for a particular software
product, program, or set of programs that
performs certain functions in a specific
environment.
43
44. Requirement types
• IEEE 830-1998 organises requirements in
the following categories:
– Functional
– External interfaces
– Performance
– Attributes
– Design constraints
44
46. Non functional requirements
• External interfaces
– How does the software interact with people, the system os
hardware, other hardware, and other software?
• Performance
– What is the speed, availability, response time etc.?
• Attributes
– What are the portability, correctness, maintainability,
security, etc. considerations?
• Design constraints imposed on an implementation.
– e.g. by standards or legislation
46
47. Functional vs non functional
requirements
• Usability engineering focuses on non-
functional requirements
47
50. Requirements elicitation
• “…the process of discovering the
requirements for a system by
communication with customers, system
users and other who have a stake in the
system development.” (Ian Sommerville)
50
51. Elicitation techniques
• In the next slides we are going to look at the most
common requirements elicitation techniques that are
used in usability engineering:
– Interviews
– Group interviews
– Observation
– Task demonstrations
– Questionnaires
– Brainstorming
– Studying documentation
– Researching similar products
51
52. Elicitation techniques (2)
• The techniques used are not dissimilar from the data
collection techniques that we have seen for the past
weeks
• We are just going to focus on their suitability for
requirements collection
52
53. Interviews and observation
• Interviews
– + Getting to know the present (domain, problems) and ideas for
future systems
– - Hard to see the goals and critical issues, subjective
– - Time consuming and may be infeasible to visit
everyone
• Observation
– Look at how people actually perform a task (or a combination of tasks) –
record and review
– + Map current work, practices, processes
– - Critical issues seldom captured (e.g. you have to be observing when
something goes wrong), usability issues seldom captured, time
consuming
53
54. Group interviews and
brainstorming
• Group interviews and focus groups
– + Stimulate each other, complete each other
– + Good at gaining a consensus view and/or highlighting areas of
conflict
– - Censorship, domination (some people may not get attention)
• Brainstorming
– Gathering of stakeholders and the exchange/gathering of ideas
in an open atmosphere where no one risks being ridiculed for
their ideas and no ideas are rejected/criticized
– + Many ideas (none are rejected)
– - Many ideas (have to be sorted and prioritized), hard to create a
good atmosphere, hard to get everybody involved, small groups,
time consuming
54
55. Task demonstrations and
prototyping
• Task demonstrations
– Ask a user to perform a task and observe and study what is
done, asking questions
– + Clarify what is done and how, current work
– - Your presence and questions may influence the user, critical
issues seldom captured, usability problems hard to capture
• Prototyping
– + Visualization, stimulate ideas, usability centered, (can be
combined with e.g. use cases)
– - Solution oriented (premature design), “is it already done?!”
55
56. Questionnaires
• Often used in conjunction with other techniques
• Can give quantitative or qualitative data
• + Gather information from many users (statistical
indications, views, opinions)
• - Difficult to construct good questionnaires,
questions often interpreted differently, hard to
classify answers in open questions and closed
questions may be to narrow…
56
57. Use cases and scenarios
• Description of a particular interaction between the (proposed)
system and one or more users (or other terminators, e.g.
another system). A user is walked through the selected
operations and the way in which they would like to interact
with the system is recorded.
– + Concentration on the specific (rather than the general) which can give
greater accuracy
– - Solution oriented (rather than problem oriented), can result in a
premature design of the interface
57
58. Studying documentation
58
•Procedures and rules are often written down in manuals
•+ Good source of data about the steps involved in an
activity, and any regulations governing a task
•+ Good for understanding legislation, and getting
background information
•+ No stakeholder time, which is a limiting factor on the
other techniques
•- Not to be used in isolation
60. Problems with requirements
elicitation (1)
• Identifying and involving stakeholders
– Availability of key people
• Getting ‘real’ users, not managers:
traditionally a problem in software
engineering
60
61. Problems with requirements
elicitation (2)
• Requirements management: version control,
ownership
• Communication between parties:
– Within development team
– With customer/user
– Between users… different parts of an organisation
use different terminology
• Domain knowledge distributed and implicit:
– Difficult to dig up and understand
– Knowledge articulation: how do you walk?
61
62. Problems with requirements
elicitation (3)
• Political problems within the
organisation
• Dominance of certain stakeholders
• Economic and business environment
changes
• Balancing functional and usability
demands
62
63. Some basic guidelines
63
• Focus on identifying the stakeholders’
needs
• Involve all the stakeholder groups
• Involve more than one representative
from each stakeholder group
• Use a combination of data gathering
techniques
64. Some basic guidelines (2)
64
• Support the process with props such as
prototypes and task descriptions
• Run a pilot session!
• You will need to compromise on the data you
collect and the analysis to be done, but before
you can make sensible compromises, you need
to know what you’d really like
• Consider carefully how to record the data
65. Data interpretation and analysis
65
• Start soon after data gathering
session
• Initial interpretation before deeper
analysis
• Different approaches emphasize different
elements e.g. class diagrams for object-
oriented systems, entity-relationship diagrams
for data intensive systems
67. Establishing requirements
• Requirements typically need
clarification, refinement, completion,
re-scoping
– Input: requirements document
– Output: stable requirements
67
68. Level of detail
• The level of detail can vary:
– One sentence
– One paragraph
– A figure
– Unstructured or structured
– A table or matrix
– A legal document
– A design document
– A formal specification
68
69. Requirement specification
techniques
• A number of requirement specification
techniques are in use
• We are going to see Volere shells, user
stories and personas
69
70. Requirements specification:
Volere shells and user stories
• The Volere shells provide "template […]
sections for each of the requirements
types appropriate to today's software
systems"
70
73. User stories
• A user story is a short description of a
feature that has a clear value to a user.
• User stories represent the
requirements from the point of view of
the user, not the developer.
– They don’t fully describe design details.
73
74. User stories: template
• User stories follow a template determined
together by the team and stakeholders.
• User stories are typically written with the
following template :
– As <an actor> I would like to <action> so
that <achievement>
74
75. User stories: template (2)
• Actor: A customer type who benefits from
this story
• Action: The goal of the story. This is a
feature or function
• Achievement: The benefit to the customer
or user when this feature or function is
used.
– This is optional ant it’s typically left out when
the reason is apparent.
75
76. Personas (stereotypes)
• Capture user characteristics
– Not real people, but synthesised from real
user characteristics
– Should not be idealised
– Bring them to life with a name, characteristics,
goals, personal background
• Develop multiple personas
76
78. Developing personas: who are
your users?
78
• Characteristics:
– Ability, background, attitude to computers
• System use: novice, expert, casual, frequent
– Novice: step-by-step (prompted), constrained, clear
information
– Expert: flexibility, access/power
– Frequent: short cuts
– Casual/infrequent: clear instructions, e.g. menu paths
79. Developing personas: what are
the users’ capabilities?
• Humans vary in many dimensions:
– Size of hands may affect the size and positioning of
input buttons
– Motor abilities may affect the suitability of certain input
and output devices
– Height, if designing a physical kiosk
– Strength - a child’s toy requires little strength to
operate, but greater strength to change batteries
– Disabilities (e.g. sight, hearing, dexterity)
79
80. More on personas?
• Read this article in the MSDN web site:
– Kreitzberg, C. B. and Little, A. (2009) The
Power of Personas. Available from:
http://msdn.microsoft.com/en-us/magazine/dd5697
80
82. Working with UI designers
• User interface designers need to have
enough data to work
• Requirements tell the UI designer what the
application will do
– How are the tasks organised?
• You can use different notations, including
scenarios
82
83. Task descriptions
83
• Scenarios
― An informal narrative story, simple, ‘natural’,
personal, not generalisable
• Use cases
— Assume interaction with a system
— Assume detailed understanding of the
interaction
• Essential use cases
— Abstract away from the details
— Does not have the same assumptions as use
cases
84. Task analysis
• Task descriptions are often used to envision new
systems or devices
• Task analysis is used to investigate an existing situation
or to specify the requirements for a software
• It is important not to focus on superficial activities
– What are people trying to achieve?
– Why are they trying to achieve it?
– How are they going about it?
• Many techniques, the most popular is Hierarchical
Task Analysis (HTA)
84
85. Hierarchical Task Analysis
• Involves breaking a task down into subtasks,
then sub-sub-tasks and so on. These are
grouped as plans which specify how the tasks
might be performed in practice
– HTA focuses on physical and observable actions, and
includes looking at actions not related to software or
an interaction device
– Start with a user goal which is examined and the main
tasks for achieving it are identified
– Tasks are sub-divided into sub-tasks
85
86. Breakdown of tasks and plan
• Your HTA must include both a breakdown
of tasks and a plan.
• There are alternative techniques to
represent HTAs (textual and graphical;
see the textbook for more)
86
87. HTA examples
• We are now going to look at 3 HTA
examples:
– Example 1: Buying a DVD from a shop
– Example 2: Withdrawing cash from an ATM
– Example 3: Using Outlook Web Access to
send an email
87
88. 88
Example 1: buying a DVD
0. In order to buy a DVD
1. locate DVD
2. add DVD to shopping basket
3. enter payment details
4. complete address
5. confirm order
plan 0: If regular user do 1-2-5.
If new user do 1-2-3-4-5.
90. Example 2: withdrawing cash
from an ATM
• Withdrawing cash from an ATM requires
tasks from the user...
• What are those tasks?
90
91. Breakdown of tasks
0 Withdraw cash
1. Check machine will work
1. 1.1 Look at status indicator
2. 1.2 Look for card logo
2. Insert card
3. Enter PIN number
4. Initiate withdrawal transaction
1. 4.1 Select withdraw cash
2. 4.2 Enter amount
5. Complete transaction
1. 5.1 Take card
2. 5.2 Take cash
91
92. Adding plans
• Hierarchical diagram / text specifies what
subtasks are part of a task
– Does not specify how the subtasks are carried
out
• Plans are used to describe
– Order of subtasks
– Conditional or optional subtasks
– Repetition
– etc.
92
93. Plans
• A plan is needed for each decomposed
task
– Plan 0: do 1; if possible do 2; repeat 3 until
PIN correctly entered; do 4; do 5.
– Plan 1: do 1.1, 1.2 in any order
– Plan 4: do 4.1; do 4.2
– Plan 5: wait until card available; do 5.1; wait
until cash available; do 5.2
93
94. Example 3: filing cabinet
• You probably act differently if you have a
lot of documents to file rather than a few...
– 0. Store documents in filing cabinet
– 1. File lots of documents
– 2. File one or two documents
– Plan 0: Do 1 or 2
94
95. Filing one or two things
• Simply find the appropriate folder and put
the documents in...
– 2. File one or two documents
– 2.1. Open cabinet
– 2.2. File each document
– 2.3. Close cabinet
– Plan 2: Do 2.1., (2.2. repeatedly) then 2.3.
95
96. Filing each document
• 2.2. File each document
• 2.2.1. Find appropriate file
• 2.2.2. Open file
• 2.2.3. Place document in file
• 2.2.4. Close file
• Plan 2.2: Do 2.2.1, 2.2.2., 2.2.3., then
2.2.4.
96
97. Filing lots of documents
• Sort the documents into order first
• Then split the sorted documents up into
‘categories’ (ie all the documents whose
author begins with ‘A’)
• Then work through the filing cabinet,
putting each category into the right file
97
98. Filing lots of documents
• 1. File lots of documents
– 1.1. Choose criteria on which documents
are sorted
– 1.2. Sort all documents to be filed into order
– 1.3. Split documents up into categories
– 1.4. Open cabinet
– 1.5. Place each category of document into
file
– 1.6. Close cabinet
• Plan 1: Do 1.1., 1.2., 1.3., 1.4., (1.5.98
99. Choosing sorting criteria
• 1.1. Choose criteria on which
documents are sorted
– 1.1.1.Choose alphabetical by title of
document
– 1.1.2.Choose alphabetical by author of
document
– 1.1.3.Choose date order
• Plan 1.1: Do any one of 1.1.1., 1.1.2.,
or 1.1.3.
99
100. Placing categories in files
• 1.5. Place each category of document
into file
– 1.5.1.Open file
– 1.5.2.Place each document in file
– 1.5.3.Close file
• Plan 1.5: Do 1.5.1., (1.5.2. repeatedly)
then 1.5.3.
100