usability requirements and their elicitation
TRANSCRIPT
Usability requirements and their elicitationLucas Machado
Menglin XuMuhammad Qasim
Silvia Rubio
School of Information Sciences University of Tampere
IntroductionConcepts
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
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
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
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
Usability Requirements Elicitation
• Gathering usability requirements with the help of different techniques or methods/methodologies
• Usability requirements must be addressed from the requirements el icitation 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?
What is the relation between usability testing and usability requirements elicitation?
• Six Styles for Usability Requirements.
[2]
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
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
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 us- ability tested and the most important defects corrected." [2]
Usability testing in process-style requirements!
! - Validation (Inspections are important for verification) - Modification/Refinement
- Elicitation
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
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)
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)
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]
Two Methodologies of Requirements Elicitation and Analysis
• M1: The Usability Engineering Lifecycle!
• M2: The Delta Method
!16
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.
Four categories of criteria• Category 1: External Factors!
• HCI Expert, User Expert, Non experts
• Category 2: Characteristics!
• Strict Guidance, User feedback
• Category 3: Maintaining the Integrity of the Specifications!
• Effort, Common in SDP
• Category 4: Quality and Effectiveness!
• Info for fit, Dependencies
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
Result of UEL Methodology
[1]
M2: The Delta Method5 Methods:!
• Pre-study
• User profiling
• Task Analysis
• Usability specification
• Prototyping and Usability Testing
Results of the Delta methodology
[1]
Comparing the resultsM1: 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
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)
Practical experiencefrom one of the group members
First stage
No well defined requirements
!26
System is not working!
But… How should it work?
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
Third stageWell defined requirements, guidelines, checklists, usability testing
With good requirements, project could be finished
Loss of project resources and time!
ConclusionWhat we should remember
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
Conclusion
• There are differences between the methodologies
• Usability Engineering Lifecycle
• Delta Method
• It is also possible to skip some of the methods
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
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.
Conclusion
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.
Thank you!
Any questions?