Usability requirements and their elicitation
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Usability requirements and their elicitation

on

  • 780 views

 

Statistics

Views

Total Views
780
Views on SlideShare
777
Embed Views
3

Actions

Likes
2
Downloads
16
Comments
0

2 Embeds 3

https://www.facebook.com 2
http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Usability requirements and their elicitation Presentation Transcript

  • 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?