Guidelines for Eliciting Usability Functionalities - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

Guidelines for Eliciting Usability Functionalities

Description:

Used in relation to presentation of information to the user ... car dealer vehicle rental/sales system, travel agency booking/sales system ... – PowerPoint PPT presentation

Number of Views:93
Avg rating:3.0/5.0
Slides: 19
Provided by: dam134
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com