This document summarizes the use of user ethnographies to inform requirements for Ireland's national digital repository, the Digital Repository of Ireland (DRI). It discusses how ethnographies of various stakeholders were conducted through interviews and site visits to understand current practices and needs regarding preservation, access, and interaction with digital materials. Key findings include the tension between open access and restrictions, the need for improved user engagement and interaction beyond basic access, and requirements to support access controls and authorization. The ethnographies helped identify core requirements for DRI from the user perspective and foster relationships with stakeholders.

1. Dr Sharon Webb
Requirements Analyst, Digital Repository of Ireland (An Foras Feasa,
National University of Ireland Maynooth)
Dr John G. Keating
Principal Investigator, Digital Repository of Ireland (Associate Director,
An Foras Feasa, National University of Ireland Maynooth)
DH2013, Lincoln University, Nebraska (17 July 2013)
User ethnographies: informing requirements
specifications for Ireland’s, national, trusted digital
repository.

2. Objectives
Introduction to DRI
Our Requirements Engineering Methodology (What
is R.E.)
What and Why User Ethnography
Preservation, Interaction and Access (findings)
Access use case and requirements

3. What/Who is DRI?
The Digital Repository of Ireland is an interactive
national trusted digital repository (TDR) for
contemporary and historical, social and cultural
data held by Irish institutions.
It is a four-year exchequer funded project,
comprising of six Irish academic partners - see
www.dri.ie
Requirements Analyst - majored in CS and History,
PhD in CS and History

4. Current Status
Requirements specification completed - moving to
requirements fulfilment. Meaningful mid-point.
Prototype of repository (HYDRA)
National Agenda - reporting on standards,
guidelines, policy.
Metadata Task Force, IP/copyright Task Force,
Business Task Force.

5. Requirements Engineering (RE)
RE specifies what the system or product should do.
It ensures that the system is built upon authentic
user requirements.
Defines a projects objectives and helps to produce
resources/projects/software that considers both the
context (the user, the environment of use, the
problem domain) and the software development
effort.
Concerned with real-world goals, functions and
constraints.

6. DRI Stakeholder Engagement & Requirements
Stakeholder interviews served two purposes -
requirements elicitation and policy development
(understand the domain - the “problem”).
We asked about current practices in “analogue” and
digital archiving.
Interviews captured core DRI requirements (from
the content providers perspective) but more
importantly helped foster relationships (and “trust”).

7. Qualitative Method of Requirements Gathering
Ethnographies - the process as well as the findings.
Observing the practices, activities in a particular
social and cultural setting (methodology/process).
Understand the context of use (technical/non-
technical)
The big picture - a holistic approach

8. Ethnography
Ethnography (the process): “Participant
observation” was not possible but site visits (out in
the field) often lead to demos (physical archive &
digital) (“inventories”).
Ethnography (the methodology): The report. A
descriptive understanding rather than a prescriptive
(Payne, 2012). What they are doing rather than
what they are supposed to be doing. (Users &
readers).

9. Problem domain
Understanding the “inside” perspective.
What social, practical, cultural activities do we need
to take into consideration? What are the institutional
social and cultural constructs (institutional eco-
systems)
To build software that is “usable, useful and used”...
(HCI, 2004).

10. Problem domain: the “inside” perspective on...
Preservation: long-term preservation of digital
objects.
Access: access (and access restrictions) to digital
objects, reuse and repurpose, also sustainable
access.
Interaction: user engagement and interaction with
content.

11. Long-term (Digital) Preservation (the problem domain)
“Preservation in my case is just making sure you
have a back-up...”
“...the other issue, is that digitisation is not a proven
technology and microfilming is and when we are
thinking in terms of really long term preservation we
have to be prudent with the material.”
Applicable to digitised material - what about born
digital material? Conflict between “traditional”
artefacts and new digital artifacts (sources, etc.)

12. Long-term (Digital) Preservation
“Digital documents last forever...or five years, which
every comes first” (Rothenberg, 1997).
Interviewees spoke of reviewing formats, etc., 5
years...
Seen as a future activity. While cognisant of the
(future) problem not an immediate (proactive)
activity (because of resources - technical, funding,
staff).
_______________Short-term

13. Interaction - engaging the audience (the problem
domain)
“Access” not enough - need to enhance the user’s
experience.
Noticeable shift in user expectations:
“A PDF format...is not good enough anymore in
terms of how people interact with [material]...[New]
undergraduate[s] that come in...access and use the
material in a very different form than perhaps ...
even three years ago. And how they expect it to be
delivered, how they want to manipulate it, how they
want to use it [have changed].”

14. Interaction - user engagement
Finding aids quoted as most important tool to
support user interaction:
“the main user interaction...consist[s] of
interrogating the online catalogue...”
60% provided additional tools
Multiple channels (iTunesU, YouTube, social
media) and devices (mobile friendly services).
A growth area (future requirements)

15. Access - content retrieval, reuse (problem domain).
Access Controls for a variety of reasons (IP,
copyright, content, funding...)
Tension between openness and discoverability
versus restricted access. (Humanities & Social
Science domain).
“it’s our nations heritage & people should be able to
see it and use it” but it is difficult to strike a balance
because you don’t know “how people will [re]use it”

16. Access - content retrieval, reuse.
Authorisation (verifying a user) and Authentication
(granting or denying access)
Deposit agreements and end-user licenses
(copyright, IP and reuse restrictions). Reuse and
repurposing of content.
“Sustainable access” - essential feature of long
term preservation.

17. Access: Use Case & req. to support access controls
Grant or deny access - need to think about mis-use
cases and the un-trusted user.
REQ-9 Implement Access Rights (Actor: Un-
authorised User)
REQ-9.2 Grant Access Rights (Actor: Collection
Manager)
REQ-12 REST Based API (Actor: Expert User)
REQ-51 Single Sign-on/Authorisation (Actor: Third-
level student).

18. Access - Use Case and Requirements
Features developed with demo projects
Acceptance tests - part of agile development.

19. Things to consider:
User ethnographies and use cases (even
requirements) versus features and acceptance
tests (executable specifications/requirements-
competing methodologies (agile versus traditional)
Feature development also user engagement
Acceptance tests - user “accepts” the behaviour of
a feature (requirements fulfillment)

20. Things to consider:
Diverse interests and concerns...but actually share
similar problems (access, storage, preservation,
user tools).
The perspective might be different but the solution
may be the same.
Managing user’s expectations - scope of the project
(requirements drift, creep).

21. Thank you for your attention
Comments, Questions?
sharon.webb@nuim.ie
john.keating@nuim.ie