Prepared by: Deposit Functional Requirements Group

Last Revised: March 2018

Status: Approved

Overview

The Deposit Functional Requirements Group’s charge was to provide system functional requirements related to different methods of deposit/ingest into the repository, such as end-user deposit, staff deposit, mediated submission workflows, and batch ingest:

• Gather requirements for self-deposit (submitted by end-users)…
• Gather requirements related to staff deposit…

For the Deposit FRG’s work, the charter also designated specific activities as out of scope:

• Determining scope of material eligible for ingest to the repository (in scope for Digital Collections Steering Committee or existing operational service agreements)
• Design of workflows, processes, or tools to construct SIPs for staff deposit scenarios

This document contains a summary of Working Group activities supporting deposit-related software requirements and presents a summarized analysis of software features identified through user stories and other information gathered.

Process

The process to achieve these outputs was supported by software development concepts that would carry over into future project phases:

• Features (or requirements) - desired software functionality needed to perform deposit work
• User Stories - short, simple descriptions of a feature told from the perspective of the person who desires the capability
• Epics - large, complex user stories that may be broken out into multiple, more granular stories

User stories were selected as a default way of capturing requirements in multiple DLP Working Groups because of their brevity, their ability to capture either high-level or more granular needs, and their being a familiar technique to Working Group participants and the PMO. 

The following team definitions were also established to help group members discuss current deposit services and functionality currently active across the institution, as well as potential shared gaps that need to be addressed in the future state repository:

• Services - the existing deposit-related business agreements and functions you provide to your customers
• Future State - the software features you will need from DLP in order to provide and enhance your existing services, whether you have those features now or not

In order to produce future state requirements, the group performed a sequence of preparatory activities. A number of these are documented as separate deliverables:

• Stakeholder representation and inputs – As documented in the approved charter, the group included members representing the interest of various operational units needing to provide requirements. The membership of this group was determined and approved by steering in consultation with library directors at the start of the Discovery Phase.
• Current state discussion and reviews – As an introductory measure, the group performed a review of current state ingest processes in order to provide background on active services and workflows across the institution. The process identified alignments and with the goal of bringing together disparate services. (Process Maps Review)
• LITS Business Analyst workshops – The group participated in two workshops facilitated by a LITS Business Analyst in order to begin requirements drafting. The initial workshop discussed a Business Canvas Model framing template in order to explicate activities and services in the current vs. future state. In a second workshop, the group reviewed guidelines for writing effective user stories, and began drafting stories.
• User Profiles – The group collaborated on user profiles to help frame the user stories and abstract the functional elements of the roles discussed in the current state review.
• Requirements drafting – The group went through a period of user story drafting, in coordination with their units.
• Analysis and alignment – The group went through several rounds of iterations as user stories were assessed and clarified and overlaps in requirements were identified. In some cases, similar stories were merged after consulting with team members, and in other cases closely related stories were left distinct if the user need was different. The revised stories were then mapped to the Deposit User Profiles, and team members did another collective review to indicate broader applicability of stories/features to their respective areas. (Inventory of Normalized User Stories)

Requirements

The user stories spreadsheet documents the following:

• Category for Functionality
• User Story (based on Scrum practices)
  • Who (mapped to User Profiles identified by the Deposit members)
  • What (proposed feature for the future state repository)
  • Why (business need for the feature)
  • Original Author (who submitted the story)
  • Originating Unit (e.g. Rose, Content, Scholarly Communications Office)
  • Applicability to Additional Units to which the story applies (affinity/applicability)

Highest Ranked Functionality

The following features were identified as applicable to all reviewers’ units:

• Upload large files greater than 2GB
• Create or augment Descriptive metadata for an object
• Review repository-generated technical metadata for an object’s files
• Generate a checksum while files are uploaded
• Generate a persistent identifier for deposited material
• Add link(s) to supplemental file(s) associated with the deposited work
• Embargo deposited work for a specific duration

Major Categories of Functionality Identified

The following categories reflect priority areas for software features needed, with selected representative examples selected from user stories and stakeholder consultations.

Integration with external data sources to support data entry

• SHERPA/RoMEO
• Emory Shared Data
• Creative Commons Licenses
• Additional metadata authority sources (also indicated through the Metadata IWG’s work)

Metadata creation/editing

• Enter/import Descriptive metadata as part of deposit
• Edit/correct metadata as part of mediated deposit
• Auto-populate Emory user information as part of deposit

Automated creation of objects, supplemental content or metadata

• Generate coversheet
• Generate checksum
• Generate standards-based persistent identifiers
• Generate technical/characterization metadata
• Store deposit agreement assent
• Ingest objects and metadata in batch from a spreadsheet
• Ingest objects from Bags
• Ingest large files from a server
• Batch-ingest files from a server
• Auto-populate journal titles from SHERPA/RoMEO data
• Provide citation export capabilities (e.g. Zotero or EndNote)

Linking Capabilities

• Enable linkages to related material or related publications (partially addressed in Metadata IWG work)
• Enable linkages with EmoryFIRST profiles
• Enable linkages between primary and supplemental content deposited

User Interface Guidance

• Provide submitters with guidance for how to perform steps in the deposit process
• Provide progress/completion indicators to depositors about the ingest of very large files

Reporting/Analytics

• Receive confirmation/notifications for successful deposits
• Receive emailed reports for self-depositors’ usage statistics (relates to Repository Management FRG work)
• View on-demand usage statistics for material deposited (relates to Repository Management FRG work 

Workflow/Mediation Capabilities

• Review, edit and approve submissions before they are ingested
• See activity/audit trails for mediated deposits

Support for Depositing Compound/Complex Objects

• Support for parent/child relationships
• Support for Primary and Supplemental Files

Support for a wide variety of file formats and content types

• Support for a range of file formats created by Emory scholars
• Support for a range of file formats utilized by digital curators

Support for ingesting large files

• Ability to ingest files greater than 2GB in size

Assign Access Controls and Permissions

The following requirements in some cases overlap with requirements gathering in the Repository Management FRG’s work:

• Enable flexible, configurable embargo capabilities
• Enable restricting access to material at the file-level
• Assign access controls in batch
• Withdraw/delete a deposited file
• Impersonate users/serve as proxy for deposit
• Ability to create or designate Collections to deposit material into

Other Features Identified - Beyond Scope of Deposit Charge

The following features identified are beyond the scope of the Deposit FRG’s charge, but were retained for long term documentation. 

Disseminate Material to External Services

• Send works to ProQuest
• Send works to HathiTrust

Specialized SIP Creation/Validation

• Transform/package digitized books into HathiTrust SIP
• Validate digitized book objects against HathiTrust guidelines

Additional Recommendations for Implementation

The implementation of deposit-related functionality identified by the Deposit FRG will depend on the Samvera/Hyrax feature set. Although custom development is expected in order to meet local requirements, the Deposit group is aware of pending Samvera community work that should satisfy some of these. For example, a bulk ingest/edit/import Working Group is soon to be chartered in the Samvera Community.

Community-centered work such as Distributed Usability Research Testing may also have future iterations of testing related to deposit functionality. For this reason, the group emphasizes the planned commitment to monitor the Samvera/Hyrax roadmap, and to maintain active participation in Working Groups of relevance.

Additional activity will also be required outside of software features and requirements. Implementing Hyrax is also expected to require that DLP revisit existing workflows. Although outside the purview of the Deposit group, our current-state analysis also noted a number of granularly defined repository object models that may become more streamlined in the future state, as the DLP infrastructure adopts the Portland Common Data Model standard.

Finally, discussion of future state features and functionality surfaced interest in expanding current deposit services linked to the repository to new units and customers. While this was explicitly out of scope for the Deposit FRG to address, we advise that DLP and related governance establish a process to establish new deposit-related service agreements.