The document discusses usability requirements and their elicitation. It introduces concepts from requirements engineering and defines usability and usability requirements. It describes different styles of usability requirements and how usability testing relates to eliciting requirements. Two methodologies for eliciting and analyzing requirements - the Usability Engineering Lifecycle and Delta Method - are characterized based on factors like expertise needed, effort required, and quality of results. The conclusion emphasizes the importance of usability requirements and testing in achieving a high level of usability.

1. Usability requirements
and their elicitation
Lucas Machado
Menglin Xu
Muhammad Qasim
Silvia Rubio
School of Information Sciences
University of Tampere

2. Introduction
Concepts

3. Requirements Engineering
•
An engineering discipline of establishing
users requirements and specifying software
systems
•
Involves identification of stakeholders and
their needs
•
Needs of stakeholders (requirements) are
analyzed and implemented to produce a
usable software system
!3

4. Usability
•
Usability is a quality attribute of a system used to
assess how much efficiently and effectively a
user can perform a specific task in a specific
context
•
Crucial factor in determining acceptability and
success of a software system

5. Usability Requirements
•
Specifications to ensure usability of a software
system
•
Non-functional requirements describing how
functional requirements are perceived by the users
•
Must be complete in order to achieve intended
usability of a system
•
Accurateness of usability requirements is directly
proportional to the acceptance of a system by users

6. Usability Testing
•
A technique used for testing usability of a
software system to reveal usability problems
•
Real users with relevant background test the
system or prototype by performing specific
tasks
•
Observers record their efficiency and count the
user interaction problems encountered to
perform the tasks

7. Usability Requirements
Elicitation
•
Gathering usability requirements with the help of
different techniques or methods/methodologies
•
Usability requirements must be addressed from the
requirements elicitation stage and must be
implemented during the development process of a
software system
•
Issues: How usability testing is incorporated to verify
usability requirements? and which approach to
choose for usability requirements elicitation and
analysis?

8. What is the relation between usability
testing and usability requirements
elicitation?
•
Six Styles for Usability
Requirements.
[2]

9. Usability Requirements
Styles
•
Performance-based requirements!
- Users
- Based on tasks-> that users must complete with system's help
- Performance objectives-> that indicate how well users should perform in task
Example: !
"Customers with ATM experience from other banks: In their first attempt, they must be able to
withdraw a preset amount of cash within an average of 2 minutes." [2]
Usability testing in performance-based requirements!
! - Validation
- Modification /Refinement (especially performance objectives)
- Elicitation

10. Usability Requirements
Styles
•
Defect-style requirements!
- Users
- Based on tasks-> that users must complete with system's help
- Limit of usability problems-> that the user must encounter while using the system
Example!
"Customers with ATM experience from other banks: In their first attempt, no more than 0.2 task
failures can be encountered. " [2]
Usability testing in defect-style requirements!
! - Validation
- Modification /Refinement (especially usability problems limit)
- Elicitation

11. Usability Requirements
Styles
•
Process-style requirements!
- Requirements that ensure usability
- Guide the design process
- Chosen by developers
Example: !
"During design, a sequence of 3 prototypes has to be made. Each prototype must be usability tested and the most important defects corrected." [2]
Usability testing in process-style requirements!
! - Validation (Inspections are important for verification)
- Modification/Refinement
- Elicitation

12. Usability Requirements
Styles
•
Subjective-style requirements!
- Related to subjective satisfaction
- Difficult to measure
Example: !
"80% of customers having tried the ATM at least once must and the system helpful.
60% must recommend it to friends if asked." [2]
Usability testing in subjective-style requirements!
! - Validation (particularly hard to evaluate the actual problems)
- Modification/Refinement
- Elicitation

13. Usability Requirements
Styles
•
Design-style requirements!
- Describe the look of the design prototypes
- Can be considered functional requirements of the prototypes
Example: !
"The menu points and push buttons shall function as shown in App. yy." [2]
Usability testing in design-style requirements!
! - Validation
- Modification/Refinement
- Elicitation (tested initial requirements)

14. Usability Requirements
Styles
•
Guideline-style requirements!
- Based on preset usability and style guidelines
- Do not ensure usability
- Require a lot of inspections from the development
Example: !
"The system shall follow the MS-Windows style guide." [2]
Usability testing in guideline-style requirements!
! - Validation
- Modification/Refinement
- Elicitation (a good practice: prototype and get initial requirements out of feedback)

15. How to identify the most suitable Usability
Requirements Elicitation Methodology according
to the needs of different projects/situations?
•
A Framework for
Characterizing Usability
Requirements Elicitation and
Analysis Methodologies.
[1]

16. Two Methodologies of Requirements
Elicitation and Analysis
•
M1: The Usability Engineering Lifecycle!
•
M2: The Delta Method
!16

17. The framework
•
Step 1: Each methodology is decomposed into
methods.
•
Step 2: Each method is assessed using a set of
criteria.
•
Step 3: The results of the assessment of each
method are combined to obtain the result for a
methodology.

18. Four categories of criteria
•
Category 1: External Factors!
•
•
Category 2: Characteristics!
•
•
Strict Guidance, User feedback
Category 3: Maintaining the Integrity of the Specifications!
•
•
HCI Expert, User Expert, Non experts
Effort, Common in SDP
Category 4: Quality and Effectiveness!
•
Info for fit, Dependencies

19. M1: The Usability Engineering
Lifecycle Methodology
9 Methods:!
•
Know the user
•
Competitive analysis
•
Setting usability levels
•
Participatory design
•
Coordinated design
•
Guidelines and heuristic analysis
•
Prototyping
•
Empirical testing
•
Collect feedback from field use

20. Result of UEL Methodology
[1]

21. M2: The Delta Method
5 Methods:!
•
Pre-study
•
User profiling
•
Task Analysis
•
Usability specification
•
Prototyping and Usability Testing

22. Results of the Delta
methodology
[1]

23. Comparing the results
M1: The Usability Engineering Lifecycle
M2: The Delta Method
1 - Needs advice from a HCI expert
1 - Does not need advice from a HCI expert
2 - Needs frequent access to the representative
users in most of the methods
2 - Needs access to the representative users in all
the methods
3 - Does not require experienced users
3 - Requires moderate experience from users
4 - Does not provide strict guidance to developers
4 - Provides strict guidance to developers
5 - Gets users’ feedback to improve usability
5 - Get users’ feedback to improve usability in
some of the methods
6 - Requires a lot of effort from the developer
team
6 - Does not require a lot of effort from the
developer team
7 - Does not provide a lot of methods commonly
used
7 - Some methods are commonly used
8 - Provides enough information to elicit
requirements
8 - Provide enough information to elicit
requirements
9 - Provides enough information to elicit the
dependencies between requirements
9 - Does not provide enough information to elicit
the dependencies between requirements

24. Example
•
The manager of a new mobile app project who has his/her
customers spread in five different countries and needs to
launch this product in less than two months with a small
group of novice programmers.
•
M1: It demands a lot of time and effort, it requires constant
access to the users and it provides no guidance for the
novice developers. (NOT SUITABLE)
•
M2: It does not require a lot of effort, it requires less
experience from the developers as it provides guidance
and even though it still needs involvement from the
representative users it can be completed faster. (SUITABLE)

25. Practical experience
from one of the group members

26. First stage
No well defined requirements
System is not working!
But… How should it work?
!26

27. Second stage
Well defined functional requirements, but no
attention to usability requirements
System interface in inconsistent…
Why do we need that page?
Why they are have different styles?
I don’t know how to do some task

28. Third stage
Well defined requirements, guidelines, checklists,
usability testing
With good requirements, project could be finished
Loss of project resources and time!

29. Conclusion
What we should remember

30. Conclusion
•
Usability requirements are often neglected, but
they are important → Usability is important!!
•
There are specific requirements engineering
techniques for their elicitation
•
Usability testing can also be used to prevent or
correct usability problems
!30

31. Conclusion
•
There are differences between the
methodologies
•
•
•
Usability Engineering Lifecycle
Delta Method
It is also possible to skip some of the methods

32. Conclusion
•
The different styles of usability requirements
elicitation are all aimed at improving the usability
of a system
•
Usability testing can be closely involved with the
requirements elicitation as a way to improve the
general usability

33. Conclusion
With a proper selection of the usability
requirements methodology and/or methods,
along with integrated usability testing,
depending on the style of these methods of
requirements elicitation, it is possible to
minimize the problems and improve or
achieve a high level of usability in a system.

34. References
•
[1] Rob Kusters Jos Trienekens. A framework for characterizing usability requirements elicitation and analysis methodologies
(uream). In ICSEA 2012, The Seventh International Conference on Software Engineering Advances, page 308 to 313, Lisbon,
Portugal, November 2012. IARIA. http://www.thinkmind.org/index.php?view=article&articleid=icsea_2012_11_30_10254.!
•
[2] Søren Lauesen and Houman Younessi. Six styles for usability requirements. In Eric Dubois, Andreas L. Opdahl, and Klaus
Pohl, editors, REFSQ, pages 155–166. Presses Universitaires de Namur, 1998. ISBN 2-87037-272-8. http://dblp.uni-trier.de/
db/conf/refsq/refsq1998.html#LauesenY98.!
•
[3] P. Carlshamre and J. Karlsson. A usability-oriented approach to requirements engineering. In Requirements Engineering,
1996., Proceedings of the Second International Conference on, pages 145–152, 1996. doi: 10.1109/ICRE. 1996.491439.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=491439.
•
[4] ISO. ISO 9241-11:1998 Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance
on usability. Technical report, International Organization for Standardization, 1998. http://www.userfocus.co.uk/resources/
iso9241/part11.html.
•
[5] Anthony J. Lattanze Judith A. Stafford Charles B. Weinstock William G. Wood Mario R. Barbacci, Robert J. Ellison. Quality
attribute workshops (qaws), third edition. Technical report, Software Engineering Institute, 2003. http://resources.sei.cmu.edu/
library/asset-view.cfm?assetID=6687.
•
[6] J. Nielsen. The usability engineering life cycle. Computer, 25(3):12–22, 1992. ISSN 0018-9162. doi: 10. 1109/2.121503.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=121503.
•
[7] Bashar Nuseibeh and Steve Easterbrook. Requirements engineering: a roadmap. In Proceedings of the Conference on
The Future of Software Engineering, ICSE ’00, pages 35–46, New York, NY, USA, 2000. ACM. ISBN 1-58113-253-0. doi: 10.
1145/336512.336523. http://doi.acm.org/10.1145/336512.336523.
•
[8] Alistair G. Sutcliffe. Requirements Engineering from an HCI Perspective. The Interaction Design Foundation, Aarhus,
Denmark, 2013. http:// www.interaction-design.org/encyclopedia/requirements_engineering.html.

35. Thank you!
Any questions?