Guidelines for Eliciting Usability Functionalities

1
Guidelines for Eliciting Usability Functionalities
IEEE Transactions on Software Engg, Vol. 33, No
11, Pages 744-758, November 2007
By Natalia Juristo, Ana Maria Moreno
Maria-Isabel Sanchez-Seguro School of Computing,
Universidad Politecnica de Madrid,
Spain Presented by Mukundan Venkataraman
Mohammad Zubair Ahmad School of EECS, UCF
2
Overview

• Usability
• Functional Usability Features
• Motivations
• Guidelines for functional usability
• Pattern based solution
• Evaluation
• Thoughts

3
What is Usability?

• - Usability is a Quality attribute
• - Definition Extent to which specific users can
  use a product in order to effectively and
  efficiently achieve specific goals
• - Used in relation to presentation of information
  to the user
• - It can be argued that usability considerations
  ought to be addressed in the requirements phase
• - It is often hard, impractical or even
  impossible to for modifications to take place in
  later stages

4
Investigating Usability

• - Decomposed usability into features and examine
  which ones have a definite impact on software
  architecture
• - Determined that addressing usability features
  at the end will involve major rework
• - Some suggestions are software usability be
  dealt with at the Design phase instead of after
  testing
• - Authors suggest bring forward usability in
  the development process and consider at the
  Requirements stage itself.

5
Functional Usability Features

• - Both Human Computer Interaction (HCI) SE
  consider usability as a nonfunctional requirement
• - Usability requirements user effectiveness,
  efficiency, satisfaction levels achievable
• -Recent studies have targeted relationships
  between usability and functional requirements
  (e.g., Cysneiros et.at. 16).
• -Authors propose a complimentary approach,
  wherein usability features with implications to
  functionality are treated as functional
  requirements

6
Motivations The need for a usability elicitation
framework

• - Traditionally, HCI has been vested with the
  task of documenting and describing software
  usability.
• - HCI specs, however, mostly involve vague
  statements that are too general, and subject to
  misinterpretation
• E.g. The system should keep users informed
  about what is going on through appropriate
  feedback within reasonable time
• With present state of the art, it is rather
  difficult to elicit usability requirements users
  and developers are poor sources of information.
• An alternative is to have an HCI expert at
  interactions. However, this is simply not
  feasible for small to medium organizations.

7
Functionalities to increase usability in a
software system
8
Generating guidelines for gathering information
about Functional Usability

• - Aims to package guidelines to empower
  developers to capture functional usability
  requirements without depending on a usability
  expert
• - The authors conduct an extensive survey into
  guidelines provided by various HCI authors (the
  authors cite 7 sources).
• -The information provided by these are not
  directly applicable HCI deals with usability
  rather than software development.
• - The authors motivate a need to study the HCI
  recommendations from a development point of view.
  

9
Pattern-based solution for gathering functional
usability requirements

• - The result of the above study is a usability
  elicitation pattern.
• - Pattern based approaches are already in use to
  elicit or re-use requirements knowledge.
• - Patterns that capture general expertise to be
  reused during different requirements activities
• Capitalize upon elicitation know-how to reuse key
  usability issues intervening recurrently in
  different projects
• - Developers, when familiarized with usage of
  these patterns, can eliminate the need for a HCI
  expert.

10
An example a ticket reservation system
11
Pattern Fields

• - Identification Usability mechanism addressed
  by pattern (name, family and possible aliases)
• - Problem Problem addressed by pattern how to
  elicit information.
• - Usability Context The context in which the
  pattern will be useful.
• - Solution to the problem addressed by the
  pattern
• Usability Mechanism Elicitation Guide
  information about usability mechanism
• Usability Mechanism Specification Guide example
  specification skeleton
• - Related Patterns Other elicitation patterns
  whose context are related to the one under study.
  

12
Using patterns to elicit and specify functional
usability information

• - This walks through the ticket reservation
  system, and the further use of patterns to frame
  questions.
• -There is a need for the developer to understand
  which functions as stated in the generic patterns
  are even applicable.
• - For e.g., the client for the ticket reservation
  system declined the need for Object specific
  undo, Command aggregation and user profile
  creation
• The employee turnover for these systems is
  rather high, so profile creation and maintenance
  was not a big incentive.
• In general, questions can be grouped in three
  categories
• Questions a user/client can answer of his own
• Questions a user/client can answer following
  recommendations of a GUI expert.
• Questions a developer must answer, but a user
  should provide opinions.

13
Documenting the interview
14
Changes to the requirements specs
15
Evaluation

• - Five groups of three students each were
  considered.
• - Each group was given a different SRS document
  from a list of five possible projects
• theatre tickets, PC storage/assembly system, job
  offers management system, car dealer vehicle
  rental/sales system, travel agency booking/sales
  system
• - Within each group, the three students were
  given the following
• - one student was given the complete pattern,
  the second a reduced pattern, and third was given
  no patterns.
• - The final piece of software that emerged (15
  combinations) were then evaluated by the
  respective clients/users (non-experts) as well as
  a paid HCI expert.

16
User evaluations
Mean 4.4, 3.2 and 2.5 with SD 0.3, 0.2 and 0.4
respectively
17
Mean of functionality added
18
Drawbacks/critiques on the work

• - For most part, the work seems to be a logical
  extension of HCI recommendations in the form of a
  simple questionnaire.
• - Inclusion of this is clearly an added burned to
  the SE process
• The developer is assumed to be conversant with
  HCI specifications to judge on what might be
  relevant for a project.
• Changes to requirement specs that result might
  cascade forever.
• As the authors themselves agree, it is not a
  substitute to actually having a HCI expert on
  site.
• The evaluation is not entirely convincing
• The choice of masters students does not really
  reflect actual real world developers using the
  pattern system.
• For most part, the evaluation seems to be a
  little premature with just one representative
  project per spec.
• For any mean opinion based scoring to stabilize,
  the choice of sample space must be large. In this
  case, it is just 15.