Categories: Home | General | Requirements Report | Design
|The I-WIRE Project - A Repository Enhancement Project|
This is the final in a series of blog entries that has summarised the findings of the I-WIRE project's User Needs Analysis phase, ending with this summary of the requirements captured during the Future State modelling group session, and during interviews with Research Administrators.
1 Guiding Principles
Considering the I-WIRE project’s objectives, the following guiding principles were applied when analysing the User Needs and assessing whether or not they should be accepted into the project’s scope and taken forward into the design phase.
The deposit process should be author centric. Authors are the best equipped people to provide all the metadata associated with their publications. The further removed the depositor is from the author themself, the bigger the overhead associated with populating the required metadata.
The deposit process must be as simple as possible, require minimal entry from the depositor and auto-complete as much of the data as possible on behalf of the depositor. Auto-completion will not only save time for the depositor, but also help improve the quality of the data captured.
Full text deposit is desirable, however, should not stand in the way of metadata deposit as a minimum in order for the repository to support the REF in parallel to its role as an Open Access repository.
Deposits should be made as early in the publication lifecycle as is reasonable, making the item available to as wide an audience as possible. This can be a lot earlier than the item appearing in one of the subject repositories or commercial databases, however, depends on the publisher’s copyright policy and can dictate which version of the item is deposited (pre-print, post-print or publisher’s final version).
Data should be re-usable for as many different purposes – by as many different processes and systems – as possible. Therefore, the data should be made available in a standard format that can be processed by its consumers.
With the above points in mind, the project team worked through each requirement (grouped into themes), and produced User Stories for the requirements that can be delivered in the project's timescales. The User Stories express the requirements in a neutral manner, written from the end users point of view to ensure the requirements are linked to genuine value, and written with Acceptance Criteria that can be used when it comes to testing the solution and piloting it with the partner Schools.
2 Summary of Requirements
This section summarises the User Needs identified during the interviews and sessions, along with the outcome of the analysis that has been carried out and an indication of which User Needs are being taken forward to the Design phase.
This has been an objective from the inception of the I-WIRE project and is essential for its successful outcome. Integration means surfacing the deposit process, and the browse / search functions, in the MWE portal, enabling data and process integration. Including the more specialised admin and review EPrints functions in the portal is not feasible in the project’s timescales and is seen as lower value as it does not contribute to the primary objective of an enhanced deposit process.
All Research Administrators and authors have stated that the deposit process must be as simple as possible and require minimal effort from the depositor, as authors do not have the time to spend on this activity. If possible, metadata should be automatically retrieved from the dOI entered by the depositor when available.
Being able to upload publication data from other repositories and databases is seen as valuable in saving the authors from having to enter it themselves. Importing data into ORCA - Cardiff's repository - is the responsibility of a separate Retrospective project, and the I-WIRE project is focusing on enhancing the deposit process for authors to be able to deposit as early as permissible and not have to wait for publication data to appear on various databases. However, the project will explore the opportunities for an enhanced deposit process that this type of system integration may provide.
This function would need considerable changes to EPrints and cannot be achieved in the I-WIRE project timescales. However, Research Administrators will be able to identify new deposits for their School using the ORCA data feed that will be implemented by the project.
Research Administrators would like to be able to export publication data into their own databases (MS Access and Excel have been mentioned) for analysis and to use in various other processes such as reports, performance management and funding applications. Due to the supplementary data and rules that will vary by School, the data should be useable in a variety of different processes and systems.
Every School interviewed raised automatic web page updates as a priority need or agreed that it would provide value. The Schools have varying different processes and systems for this currently, ranging from manually intensive to maintaining their own databases. The structure of the Schools research organisations varies too, with data having to be re-used across a variety of pages that serve different Research Groups, Research Centres and Themes.
While discussing this user need, it emerged that authors and Schools will want to be selective over which publications are included in their web pages, as complete publication lists can be too exhaustive. This would require giving users the facility to manage deposits that are already live.
Authors have listed many different processes and systems that require re-use of their publication data, including CVs, web pages, performance management documents and funding applications. The design phase will explore providing an author’s top or most recent publications in the default Portal view, supported by an export facility that could allow check-box selection of individual items.
The I-WIRE project will explore ways that the Cardiff University unique person identifier can be added to ORCA during the deposit process in order to facilitate integration between ORCA and other MWE systems that want to access publication lists. Use of this identifier will be transparent to users as they will not generally be aware of it, using instead items such as email address and name for browsing and searching ORCA
ORCA has very limited metadata for funding and is likely to be a component in the overall solution for management of funding data (and other research data), with links between each component system. Note that ORCA’s role in CRIS (Current Research Information Systems) is being looked at outside the I-WIRE project.
There are issues with including citation data in repositories that I-WIRE will not have time to resolve. The DSpace repository team attempted to include citation counts but encountered licensing constraints. However, the I-WIRE project will explore the various EPrints plugins that have been produced for this purpose. Note that citation data and other metrics are available from established databases (there are more than one) and are under consideration for REF support but usage of these has not been clarified yet.
One Research Administrator would be happy to review the author’s deposits for completion, accuracy and copyright, before promoting them to the live archive, as long as there is confidence that authors are actually depositing their publications on a regular basis. The project will explore this. However, the ‘reviewer’ role is currently carried out within the Libraries Cataloguing team, and will remain in that team for the majority of Schools.
There was also a view that some Schools would want to vet all deposits before they became available in ORCA, and indeed be responsible for the deposit process on behalf of authors, however, this contradicts one of the guiding principles of an enhanced author deposit process.
Many Schools are already using their Staff Appraisal processes to capture and update publication data. The I-WIRE project will look at providing a standard data feed that can be used in this process.
ARCCA would like the deposit process to ask a mandatory question that identifies outputs of research that have made use of ARCCA facilities. This would save the ARCCA team from having to identify these themselves directly with the Schools when producing the annual report. While useful to ARCCA, this is not crucial to the deposit workflow and in fact could be seen as contradictory to the simplified deposit, particularly if the user is presented with a question about ARCCA when they are not familiar with it. However, this will be explored during design.
The School of Medicine have invested in the Symplectic publication management system and are currently integrating it with their School web pages. Symplectic harvests publication data from Web of Science and presents it to authors for validation, minimising the amount of effort required for deposit. However, Symplectic is not a repository of full texts, for which a connector is being produced by the Symplectic team to integrate Symplectic with EPrints. The I-WIRE project will explore the integration between Symplectic and EPrints with a view to identifying opportunities for enhanced deposit, bearing in mind that early deposit into the repository is one of the guiding principles.
It is noted also that the Business School is in the process of implementing Digital Measures which manually captures and stores publication data, alongside other School data such as performance metrics.
The varying copyright policies of different publishers, and the terminology around different versions of articles, are seen as confusing and blockers to the deposit of full text and subsequently use of the repository. Sherpa’s RoMEO database goes some way to helping identify publisher’s copyright policies, and will be looked at in the design phase, but the wider issue of understanding and negotiating copyright will be looked at outside the I-WIRE project.
Various types of links have been requested, including between web page publication lists and the full text articles, and from articles in the repository to the School’s web page. The standard data feed will provide enough data for the consuming system to be able to construct links to the article in the repository (and to highlight Cardiff authors). However, linking from the repository to elsewhere would require a complex configuration feature if it were to satisfy the many different and conflicting requirements that Schools would have, and would therefore not be achievable in the I-WIRE project’s timescales.
Some publishers allow embargos. There would be value in system storing these publications and automatically making them available at the embargo expiry date. The project will explore the current embargo function but believe it to be limited and therefore more effective for depositors to submit metadata ahead of the full text in these scenarios.
Data that is related to the repository but is not within its scope includes funding bodies and sources, and the impacts of research needed by the REF. Note that ORCA will be just one component in the overall solution required to support the various calls for this type of data, but the I-WIRE project is not looking at solutions for identifying, modelling or storing this data.
3 User Stories
The User Needs that are being taken forward to the Design phase have been written as a set of User Stories, an example of which is shown below for illustrative purposes.
The full set of User Stories is available from the I-WIRE project team on request.
There is no guarantee that a particular User Story or Acceptance Criteria within the story will be fully delivered by the project, as the Design work package itself will have to conduct a deeper level of analysis in order to design a solution that is feasible to deliver within the project’s timescales. Each User Story has been prioritised with this in mind, to allow the project to continue with flexibility, and also to adapt to changes that are beyond the control of the project.
This is the second in a series of three blog entries that will summarise the findings of the I-WIRE project's User Needs Analysis phase, continuing with this summary of the Current State process that was captured during the group session with academic authors, and the issues associated with it.
1 Lean Group Session
During the Lean group session with academic authors, the management of research publications was examined end-to-end, from the initial research opportunity through to the various reports that are produced by the Schools. While the scope of the I-WIRE project is only one part of the end-to-end process - specifically around the deposit of items into the Repository - the end-to-end process was examined in order to identify any opportunities for improvement or automation of the deposit workflow by potentially integrating with other processes, and also to identify opportunities for re-use of the publication data and elimination of wasted effort.
The following two diagrams illustrate the main steps in the end-to-end process.
2 Summary of Issues with Current State Process
The following issues were raised during the group session and continually throughout the interviews, and are perceived as blockers to Open Access depositing:
- Complexity and uncertainty around the whole area of copyright policies and which version of articles can be deposited where. Some authors admit to often signing away copyright with little attention to it, and would like the School or University to manage copyright negotiations on their behalf, freeing them up to get on with the next piece of research. This could include retention of copyright (particularly for conference papers) or permission for deposit in Institutional Repositories.
- The final version of an article is 'king', and generally cannot be deposited anywhere other than with the publisher. And it's important to be published in the right journal that has a good impact and the right audience. However, there can be up to a year between submission and publication, and differences between on-line and paper versions.
- The perception that target audiences will have access to articles through journal subscriptions anyway, so depositing to an Institutional Repository is an unnecessary step.
- Academics don't have the time to deposit so anything beyond a single click is too time consuming, and there are databases that already collect this data (Web of Science, etc.) on behalf of the author.
The current process is seen as taking too long and requiring too much data to be keyed by the depositor. Academics want 'maximum output with minimum effort'.
Any new process needs to be flexible enough to cater for different approaches and requirements across the different schools. For example, the School of Medicine are running Symplectic which gathers their publication data for them, and are happy that final versions are available from the publishers through existing subscriptions. In contrast, outputs from the School of Journalism, Media & Cultural Studies won't neccessarily be covered by a single database, and therefore have to be deposited manually. Plus they have a lot of conference papers that could be included in the repository if an expert could help with the less-than straightforward copyright policies.
It's not feasible for the repository to serve the needs of every School in terms of the reports that they have to produce. This is due to local organisational hierarchies and the application of local data and rules to enhance the publication data, and therefore there will be a need for ORCA to provide raw publication data for the Schools to enhance and manipulate themselves. However, the many different outputs proposed, and access to metrics, may not be as valuable for the humanities based Schools as the sciences.
Research Administrators often have to chase academics for up to date publication lists to be used in a variety of processes such as reports to School Boards, web site updates and appraisals. Academics get annoyed if they feel they are giving the same information to a variety of places.
Balancing the needs of:
The science based Schools, focussed almost exclusively on final versions in journals made available through subscriptions; with little concern for copyright and wanting to have very little manual input (if any at all).
The social science and humanities Schools, with a variety of output types and destinations and no single database giving them complete coverage, so more open to having to capture their publication data themselves, and therefore with more concern for copyright.
The next and final blog entry in this series will summarise the requirements captured during the Future State modelling group session, and during interviews with Research Administrators.
This is the first in a series of three blog entries that will summarise the findings of the I-WIRE project's User Needs Analysis phase, starting with this entry on the approach taken by the project team.
1 Project Overview
The I-WIRE project aims to develop a workflow and toolset, integrated into a Portal environment, for the submission, indexing, and re-purposing of research outputs in ORCA (Online Research @ Cardiff) - Cardiff University’s Institutional Repository. This will be based on requirements gathered from academic Schools and administrative Directorates in the University during a User Needs Analysis phase - the subject of this Requirements Report.
The impetus for the project comes from a decision by the University Research Committee to approve the mandatory deposit of new publications in ORCA, subject to detailed consideration as to the means by which staff up-load data to the repository.
The I-WIRE project’s primary aim is to develop a submissions and metadata workflow that minimises staff effort and offers other value added services that will encourage use and in particular author self deposit of new publication data. There is also an increasing need for the University to create and maintain an up to date, central publications database in preparation for the REF
2 Stakeholder Identification
The following communities were identified by the project team as current or potential users of ORCA, and therefore key Stakeholders in the I-WIRE project:
- Researchers and academic authors in all Schools through their need to make their research outputs available on an Open Access basis.
- Research Administrators in all Schools through their need to provide reports on the School's research outputs.
- The Repository Manager and Subject Librarians through their responsibility to ensure the quality of metadata in ORCA.
Other Cardiff University staff in the Schools and Directorates who expressed an interest in either ORCA or the project itself during project initiation - but fell outside the above communities - were also included as Stakeholders. For example, interest in the project was expressed by Web Managers looking for ways to automate the population of publication lists on web pages.
3 User Needs Analysis Approach
By the time the I-WIRE project team was in place and the User Needs Analysis work package was able to start in October 2009, the project was six months into its two year fixed life cycle and was at risk of missing the scheduled delivery of the Requirements Report at the end of December 2009
The project team gave full attention to the User Needs Analysis work package and agreed the methods that would be used to provide as much coverage of the stakeholders as possible in as short a time as possible. A schedule was drawn up that would see the majority of stakeholder interviews completed by the end of December 2009 and the analysis take place during January.
Giving consideration to the key stakeholders being spread across 29 Schools - of which each School has its own systems and processes - and numerous supporting Directorates, and the short window of opportunity, the project team agreed to carry out the following key activities in parallel through October to December 2009:
The project team arranged for a series of communications and agenda items at related meetings and committees to ensure awareness of the project and its objectives, and to seek support from key stakeholders where required.
3.2 Interview Research Administrators
A structured questionnaire was developed and piloted with the partner Schools in order to consistently capture requirements during each interview, and to steer the conversation to provide maximum coverage of all topics.
With the assistance of Subject Librarians, the project team arranged to interview the Research Administrator in each School. Some of these interviews also captured the requirements of authors through the attendance of Research Directors or Heads of Schools.
Due to the short window of opportunity, the Schools were scheduled in order to give a good cross-section of science based and social-science / humanities based Schools, with the intention of covering a minimum of one third of the Schools by the end of the work package, and more if feasible.
The project team agreed to capture all requirements raised during the interviews, regardless of whether the requirement was within the scope of the project or not, with the intention of passing out-of-scope requirements to the Repository Manager during the analysis phase to inform the longer term repository roadmap and other projects.
3.3 Group Sessions with Academic Authors
The project team brought together a group of authors from the partner Schools - identified by the Research Administrators - in two workshops facilitated by the Cardiff University Lean team, to:
capture and document the Current State process that authors follow for the management of their publications, along with associated issues. The process was looked at end-to-end from identification of research opportunities to production of reports for Schools management, in order to identify any opportunities for linking the deposit process with other processes such as Performance Management. The Current State process has been documented as the project baseline in order to assist with evaluation of the project’s outcomes; and
agree and document an enhanced and simplified Future State process that the same set of authors agreed would encourage them to self-deposit in the repository, along with other requirements that they may have.
3.4 Interview Other Interested Stakeholders
The project team also arranged to interview staff in the Schools or Directorates that expressed an interest in the project or ORCA through the communications sessions or other groups and committees.
Key learning from the Lean Group Sessions
The following diagram illustrates the stakeholders interviewed and the interview schedule.
4 User Needs Analysis
Analysis of the captured User Needs - as expressed during the interviews and group sessions - is critical to ensure the scope of the project is sized appropriately and to give the project the best chance of a successful outcome.
The project would be at risk of delivering a disjoint and overly complex solution if requirements were taken at face value without analysis. The analysis took place in the form of a series of group sessions during January 2010 made up of the project team and the technical development team, and focussed on:
the most frequently occurring requirements expressed during the interviews;
implementing the requirements in as neutral a manner as possible to ensure the most value can be obtained by multiple Schools being able to use the solution, and not delivering bespoke solutions that cater to the needs of just one School or stakeholders;
what can feasibly be delivered in the project's timescales, bearing in mind available budget and resource; and
solutions that utilise EPrints functionality and features as it is delivered ‘out-of-the-box’, and remain aligned with the EPrints software roadmap and do not deviate from that to such an extent that the EPrints upgrades become difficult and costly in the future.
With these points in mind, the project team worked through each requirement (grouped into themes), and produced User Stories for the requirements that can be delivered in the project's timescales. The User Stories express the requirements in a neutral manner, written from the end users point of view to ensure the requirements provide value to the end user, and written with Acceptance Criteria that can be used when it comes to testing the solution.
Requirements that the team agreed are not in scope of the project have been notified to the Repository Manager for consideration in the longer term repository roadmap and other projects.
The next blog entry in this series will explain the Current State process that was captured during the group session with the academic authors, and the issues associated with it.
© Tracey Andrews. Powered by Apache Roller 4.0.1-dev.
|« June 2013|