Repository deposit: specifying user requirements and test cases
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Repository deposit: specifying user requirements and test cases

  • 1,169 views
Uploaded on

This presentation is being used to inform user panel meetings intended to specify user requirements for the design and test of enhanced repository deposit interfaces being developed by the......

This presentation is being used to inform user panel meetings intended to specify user requirements for the design and test of enhanced repository deposit interfaces being developed by the DepositMO project. These slides continue to be updated following each meeting, and include the findings from previous meetings.

More in: Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,169
On Slideshare
1,169
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Repository deposit: specifying user requirements and test cases
    Notes for a DepositMO projectmeeting
    21 January 2011, University of Southampton
    Aim of meeting
    To establish a preliminary plan for user testing and evaluation of the products and services from the DepositMO project
    This plan will be taken forward in stages, and is subject to further consultation
    This is a working document, to be used and updated at later meetings
  • 2. Requirements cycle
    Requirements
    -> Test plan
    -> Test cases
    -> Test
  • 3. Requirements cycle
    Product
    Requirements
    -> Test plan
    -> Test cases
    -> Test
  • 4. Requirements cycle
    User
    Product
    Requirements
    -> Test plan
    -> Test cases
    -> Test
  • 5. Requirements cycle
    User
    Product
    |Requirements
    |-> Test plan
    | -> Test cases
    | -> Test
    |What does it say on our tin?
  • 6. Requirements cycle
    User
    Product
    |Requirements
    |-> Test plan
    | -> Test cases
    | -> Test
    |What does it say on our tin?
    |Does it work? (user testing)
    |Will users ‘buy’ it? (market research)
  • 7. DepositMO requirements
    Key target: to change the way authors think about the repository
    How: embed repository processes into the author’s current environment
    Which: key targets have been identified, such as the Microsoft Office suite, as well as the operating system environments including Windows, Ubuntu and OS X
    Source
  • 8. DepositMO requirements (cont.)
    Target: objects should remain under author control, the repository should provide useful feedback processes related to the object as well as other information which can help authors in their day to day work.
    How: SWORD
    + propose a further 3 “levels of conformance”
  • 9. DepositMO simple schematic
    Deposit
    Author app/ computing environment
    Repository
    (EPrints, DSpace)
    SWORD
  • 10. Building a test plan: user requirements
    Use cases? Which user requirements can we frame? What do users want? What do users want to do? We represent user interests in chemistry, materials science, archaeology; also repository users (ePrintsSoton, EdShare)
  • 11. Use cases (from meeting 21Jan2011)
  • 12. SWORD + 3 layers of conformance
  • 13. Conformance
    Level 0 – Deposit with Specific Receipt
    Current SWORD + persistent URI (available now)
    Level 1 – Interaction with URI (CRUD)
    Create (level 0), retrieve, update, delete
    Level 2 – Obtaining Metadata
    Level 3 – Utilising Client Processes
  • 14. Level 1 – RUD, function
    MUST BE able to provide a variety of serialised forms of the itemback to the client (R in CRUD) using the returned URI from level 0
    When the item is public as well as when not yet public domain and requires authorisation
    Support retrieval of the entire object where possible, e.g. via a compressed format or via ORE.
    Access useful information about the item: e.g. no. views, downloads, citations
  • 15. Level 1 – RUD, consequences
    Update and Delete (UD in CRUD) can now be supported by PUT/POST to the URI which was returned in Level 0. When an update is performed, repository policy to decide if it creates a new version or updates the version at the current URI.
    Clients need to draw the connection between what is in the repository and what is local to them (on disk).
    Repositories need to expose an OAI-PMH style (paginated) list of recently submitted/updated publications to the clients
  • 16. Level 2 – Obtaining Metadata
    Prompting users for metadata not already submitted in Level 0.
    This can be a multi-stage fully interactive process whereby the repository defines the contents of the form and where to POST it.
    Define a method whereby each repository can specify what metadata it requires such that if two repositories request the same metadata, the user is only prompted for it once.
  • 17. Level 3 – Utilising Client Processes
    Similar to Level 2, except that the interaction is with the client application and not with the user.
    The repository is able to query the client application for processes it can perform and request these to be done (e.g. format conversion, create PPT slide images).
    (This level may not be tackled extensively in the current project)
  • 18. DepMO schematic
    Deposit
    Author app/ computing environment
    Repository
    (EPrints, DSpace)
    SWORD
    V1.3 + URI
    V2.0 inc. CRUD
  • 19. DepMO ‘product’ list (tbc)
    Word author add-in, aimed at Word 2010 (target: 'regular' users)
    Windows Explorer add-in (target: 'regular' users)
    Use "Mac-native" features to specify the files, for example:
    Selecting the files using a dialog
    Dragging the files onto an icon in the Mac OS X dock
    Right-clicking the files and selecting a "deposit with SWORD" item in the context menu.
  • 20. Building a test plan: parameters
    For each testable product from DepMO
    What (additional) functions define the product?
    What does it do?
    Relative evaluation
    Is it better than native repository interfaces?
    Is it better than alternative SWORD interfaces?
    It is hard to find implemented SWORD GUI interfaces, but see e.g.
    How does the Facebook SWORD client actually work?
  • 21. Building a test plan: test cases and methods
    Target and select users
    Specify tasks
    Methods, e.g.
    Observed test, small groups (usability)
    Web questionnaire, larger survey (market research)
    Need to test what users do rather than what users think:
    First Rule of Usability? Don't Listen to Users http://www.useit.com/alertbox/20010805.html