User Requirement Analysis and Functional Specifications

Paula Goodale (University of Sheffield), Phil Archer (i-sieve)

Work on the user requirements for the first PATHS prototype was completed in June 2011, and reported in D1.1 User Requirements Analysis.

As PATHS is intended to open up new possibilities for user engagement with cultural heritage collections, we needed to fully understand our potential users, their information behaviour traits and the tasks in which they use cultural heritage materials.

To achieve this we collected data from both expert and non-expert users across four key domains:

  • Cultural heritage - curators, museum educators and web experts
  • Education - teachers and students
  • Professional - tourism, publishing and photography industries
  • General - users engaged in leisure activities

An initial online survey was used to gather extensive data on the typical habits and preferences of people using cultural heritage resources online. Some of the most interesting findings related to people’s cognitive styles in information seeking, as illustrated by the chart below:

PATHS Survey Response – Cognitive Styles and Information Seeking Behaviour

PATHS Survey Response – Cognitive Styles and Information Seeking Behaviour

Following on from the survey, in-depth interviews were carried out with 22 expert users, discussing at length the concept of the PATHS system, what the pathway metaphor means in different contexts, how pathways are created, and how they could be used to support different work and study tasks. An important discovery from the interviews is that in creating and using pathways through collections, users will engage in one or more of five core activities, as shown in our model of User Interaction with Pathways (below):

Model of User Interaction with Paths

Model of User Interaction with Paths

The five activities include: developing  a Concept ; exploring and Collecting  items of interest; organising these items and Creating  a pathway; Communicating  their pathway by adding commentary and/or sharing with other users; and, Consuming  paths published by other users. It also became apparent however, that different types of users might approach the five activities in a variety of ways, and may not necessarily undertake all of them, depending on the task in hand.

PATHS User Profiles

PATHS User Profiles

We tested our model via some hands-on ‘path creation’ exercises, and finally pulled together all of our various data into detailed user profiles, which formed the basis of several use cases from which a comprehensive list of user requirements were derived. The user requirements have since been used to develop a functional specification for the first PATHS prototype, and will also later inform the design of the user interface and evaluation of the prototype at a later stage, ensuring a cohesive and user-centred approach throughout the project. 

PATHS began as an idea, shared among a group of people. That idea became a proposal that then became an active project. As we've seen, a lot of effort was spent researching use cases, user needs and attitudes. In other words, we were testing the ideas that had been formed in isolation a year ago against the real-world and taking careful note of what the real world had to say. The results were interesting, surprising and illuminating.

The original idea centred on the concept of Paths - trails through cultural heritage collections - and of course we discussed what they might look like. We had a concept in our minds of how Paths might be created and followed, but the users we spoke to made it clear that whether they created Paths or not, they wanted to be able to tag objects, to comment on them and to share ideas with other users. Almost as an extreme expression of that idea, users want to be able to clone Paths, edit them (i.e. improve them from their perspective) and then publish the new Path as their own work. The demand was clear: if you want us to use this new system, it needs to be very interactive.

This kind of user feedback is critical to the future success of the project and makes a valuable contribution to enable us to deliver the original idea in a way that reflects users' interests. The distillation of the user requirements into what will actually be built is the task of the Functional Specification . A typical line being "Users will be able to register on the system, thus creating a profile" and the equally thrilling: "Users will be able to login using a username and password combination." However, there are more interesting functions:

Users will be able to add objects, such as those presented in search results, into a personal workspace.

The user will be able to select what s/he wishes to search. Options will be to search: the collections; the user's workspace; for objects only, Paths only, or both; on user-generated tags.

Put alongside the much more technical system architecture, the development team have been able to begin to make PATHS a reality - that's the exciting bit that we're all looking forward to.

Share |