user ethnographies: informing requirements specifications for ireland's, national, trusted...
DESCRIPTION
Presented at DH2013, Lincoln University, Nebraska (17 July 2013). The diversity of DRI’s community, that is national cultural institutions, university libraries and other higher education institutions, as well as their respective research institutes, national broadcasters and various independent and state bodies, requires reconciliation between their various perspectives. This paper will discuss requirements specifications in light of these stakeholder interviews and the national report, which form a crucial part of the information gathering phase of requirements engineering, and consider how user ethnographies can enhance our understanding of the user and their software needs.TRANSCRIPT
Dr Sharon WebbRequirements Analyst, Digital Repository of Ireland (An Foras Feasa, National University of Ireland Maynooth)
Dr John G. KeatingPrincipal 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.
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
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
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.
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.
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”).
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
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).
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).
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.
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.)
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
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].”
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)
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”
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.
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).
Access - Use Case and Requirements
Features developed with demo projects
Acceptance tests - part of agile development.
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)
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).
Thank you for your attention
Comments, Questions?