Opus: University of Bath Online Publication Store · PDF fileDarlington, M. and Ball, A. (2012) Research Data Management Plan Requirements Specification for the Department of Mechanical

Darlington, M. and Ball, A. (2012) Research Data Management Plan Requirements Specification for the Department of Mechanical Engineering, University of Bath. Other. University of Bath, Bath. (Submitted)

Link to official URL (if available):

Opus: University of Bath Online Publication Store

http://opus.bath.ac.uk/

This version is made available in accordance with publisher policies. Please cite only the published version using the reference above.

See http://opus.bath.ac.uk/ for usage policies.

Please scroll down to view the document.



RESEARCH DATA MANAGEMENT PLAN

REQUIREMENTS SPECIFICATION

FOR

THE DEPARTMENT OF MECHANICAL ENGINEERING, UNIVERSITY OF BATH

MANSUR DARLINGTON & ALEX BALL

redm1rep120105mjd10.pdf

ISSUE DATE: 10 February 2012

RESEARCH DATA MANAGEMENT REQUIREMENT SPECIFICATION

Catalogue Entry

Title Research Data Management Plan RequirementsSpecification for the Department of Mechanical Engineering, University of Bath

Creator Mansur Darlington

Contributor Alex Ball

Subject research data management; data management plans

Description The primary purpose of this document is to specify what is required of data management plans written in relation to research projects undertaken in the Department of Mechanical Engineering at the University of Bath. It will also inform the creation of an intermediate document that will serve both as a template for such plans, and as a plan for the Department as a whole. The requirements are derived in part from a requirements elicitation process conducted with representative stakeholders within the Department, and in part from a study of best practice drawn from the literature.

Publisher University of Bath

Date 5 January 2012 (creation)

Version 1.0

Type Text

Format Portable Document Format version 1.5

Resource Identifier redm1rep120105mjd10

Language English

Rights © 2012 University of Bath

Citation Guidelines

Mansur Darlington & Alex Ball. (2012). Research Data ManagementPlan Requirements Specification for the Department of Mechanical Engineering, University of Bath (version 1.0). REDm-MED Project Document redm1rep120105mjd10. Bath, UK: University of Bath.

2 of 15


1. INTRODUCTION

The REDm-MED Project (Research Data Management for Mechanical Engineering Departments) Project aims to scope, specify, design and implement a research data management plan suited especially to the needs of the Department of Mechanical Engineering at the University of Bath. This document constitutes the rationale for and the requirement specification for the Research Data Management Plan.

For the purpose of clarity the specification developed below will be referred to in full henceforth as the Department of Mechanical Engineering Research Data Management Plan Requirements Specification, and in short as the RDMP Requirement Specification (RDMPRS).

2. THE RESEARCH DATA MANAGEMENT PLAN REQUIREMENT SPECIFICATION

A data management plan (DMP) is an expression of an intention to carry out a process the particulars of which are given in the plan in order to achieve a data management goal. The development of a requirement specification for such a DMP is an engineering-based approach to clarifying and recording what the purpose, function, aim, etc. is of the DMP – together with source or motivation for providing such – so that development of a plan can be guided and there is a basis for judging whether the end product fulfils the specified requirement.

The Engineering Research Information Management (ERIM) Project1 introduced the idea of data management planning documentation moving from generalized guidance and instruction (for example principles and specifications) to specialization through the implementation of such guidance and instruction. In this way a general specification for a plan may be implemented as a plan for, for example, a research centre or group, which responds to and predicts the particular needs of that group. This implementation can be then be seen as a specification for further specialized implementation at the level of, say, the DMP for a particular project, where the plan is especially contrived to ensure best fit with the predicted management needs of the project’s data. This requirements specification, then, continues that approach.

It is intended that the requirements specification detailed below will result in development of a research DMP specialized at the level of the Department of Mechanical Engineering; this in turn will then be available for use for the production of plans written and executed at the level of an individual project.

The requirements specified at the project level will themselves imply higher-level requirements in terms of services, guidance and other support that must be made available at the departmental or, in some instances, institutional level. Thus, there will be requirements identified at a Departmental Level which will be assumed to have been met, and which constitute some element of the support required and that will be expected to be available for DM planning and execution at the project level.

1 ERIM Project Website, URL: http://www.ukoln.ac.uk/projects/erim/

2 of 15

http://www.ukoln.ac.uk/projects/erim/


2.1 Purpose of the RDMP for the Department of Mechanical Engineering

The DMP that is produced under this requirement specification will have the function of providing research data management planning support to those such as principal investigators, project, data and research managers and researchers and others, such as service providers, who have a need to develop, manage, execute, or to provide support for, project-level data management plans.

It is intended that such DMPs will fulfil the needs of:

data management planning,

data management execution,

bid submission,

project planning,

doing the research,

collaboration with colleagues, industry and others,

supporting data re-use, re-purposing,

preparation for long-term preservation,

end-of-life,

in accordance with the policies, procedures and provisions laid down by the institution and the department’s funders as motivated by the desire to maximize the value of research data both during its first use and thereafter.

The items identified above constitute the research project life-cycle tasks, some of these being continuous and overlapping during the life of a project.

The plan will include provision for the management of both physical (paper documents and research artefacts) and digital records.

It is the intention that the development of the RDMP from this specification will inform as part of an iterative process the development of a model data management plan which can be used for the purposes of data management planning in other institutions engaged in engineering research.

3. EXTERNAL INFLUENCES AND SCOPE OF THE USER-DRIVEN SPECIFICATION

User-derived Requirements are those requirements which are expressed by users as a result of their need to satisfy their own plans/needs for data and those, additionally, driven by the need to conform to the requirements levied on them by external entities. These include those such as funders and internal service providers. Some legitimate data management requirements may stem from influences of which researchers are, currently, unaware (for example the need conform to the particulars of external or institutional data management requirements) as well as more local influences (their own desires for data re-use, and the requirements of the data themselves). As such, direct input and guidance from the users themselves constitutes only a part of the user-driven input to the final specification.

From the above it can be seen a research data management requirements specification will be derived both top down and bottom-up.

3 of 15


3.1 Local/internally motivated requirements and influences

The ‘internal’ requirements are those that arise directly from the work undertaken by researchers in the course of their research.

1. Data generation for data management.

2. Data organization for data management.

3. Data-related issues on storage, organization, security, access for data first use.

4. Preparation for archiving and curation.

3.2 Externally motivated requirements and influences

The ‘external’ requirements and influences can be seen to be those which cascade down directly as a result of higher mandate, or are generated as part of a procedure designed to satisfy a higher mandate. Such requirements will be derived from some part of the hierarchy: Funder, Institution, Service Provider, Faculty, Department, Group, Project and will include such things as:

1. DMP responsibility and roles.

2. Departmental and institutional policies

3. Requirements from the place of archival deposit

4. Constraints from computer services provider

5. Local resources and funds

4. INFORMATION GATHERING AND SOURCES

The data management plan requirements specification is a synthesis of information from a number of sources, including:

1. Interaction with a panel of users through, principally, the CARDIO data management provision assessment ‘health-check’, semi-structured interviews and responses to directed questions.

2. The precursor outputs from the ERIM Project, in particular the Principles for Engineering Data Management (Darlington, et al., 2010) and the Engineering Research Data Management Plan Requirements Specification (ERDMPRS) (Ball, et al., 2010). These themselves were synthesized from earlier sources including output from the DCC, especially the DMP template and checklist (now implemented in the DMP Online tool). It should be recorded here that much of what has been derived directly from the intended users has been anticipated in the DCC checklist and other guidance.

3. The remit of the ERDMPRS was limited to provision of data management for the purposes of data re-purposing, supporting data re-use and data re-use. To this will be added for the RDMP Requirement Specification (RDMPRS) consideration also of such things as data management itself, bid preparation, project planning, preparation for archiving, and end-of-life.

4. Ad hoc knowledge drawn from the REDm-MED Project team members’ previous experience in information and data management, especially with respect to the research data character of and the management needs for engineering research data.

4 of 15

http://dmponline.dcc.ac.uk/


5. The draft Data Management Policy produced by the IDMB Project for the University of Southampton; this, alongside a roadmap for infrastructure development, a three-tier metadata model and a project to improve data storage, resulted from a requirements elicitation process similar to the present one (Brown, et al., 2011).

5. OBSERVATIONS FROM USER INTERACTION AND OUTCOME OF THE CARDIO RATING EXERCISE

As noted above a panel of participants were invited to engage in the CARDIO process in order to elicit their views about the current capacities, as they see them, of the data management support provided by the University of Bath Department of Mechanical Engineering, and the University-provided services which underpin them.

The CARDIO process consists first of a Research Support Officer (RSO) rating on a score of 5 (where 5 is best) sets of questions relating to data management capability as they experience it across each of three dimensions, namely Organization, Technology and Resources. Following this, each participant carries out the same task. The ratings are aggregated to give an overall rating for each of these three aspects of data management capability. The three dimensions are described in the CARDIO documentation as follows:

Organisational infrastructure covers the policies, procedures, systems, and skills needed for research data management

Technology covers the requisite equipment, software, hardware, a secure environment, and skills to enable research data management

Resources. The maintenance and development of a range of resources is required for effective research data management. Elements covered in the Resources section include human resources, financial sustainability, business planning and risk management.

The panel of participants were selected carefully across a spectrum of research-active disciplines in the Department in order to properly represent the sorts of data which are generated by the research. The research sub-disciplines represented include: aero-structures, micro-aerodynamics, bio-mimetics, information and knowledge for engineering design, vibration and noise control, materials science, constraint-based simulation and modelling and general mechanical engineering. This is not a complete coverage of the Department’s research activity, but can be said to be usefully representative. Entities in the research hierarchy represented included post-graduate students, research officers, research fellows, readers and members of the professoriate.

It was very clear from the responses in the CARDIO rating exercise that the general level of knowledge and interest in data management represented by the panel is of a fairly low order. This was reinforced by other members of the Department in their response to a questionnaire-driven conversation specifically on the subject of data storage requirement.

The extent to which the participating individuals have engaged in any sort of data management is dictated essentially by the local needs of their research or their data – rather than any best-practice guidance, which is currently absent – and there is generally a low understanding of the dimensions required to paint a complete picture of data

5 of 15


management and associated tasks across the data life cycle. The participants have little experience on which to respond in an informed way and difficulty is shown in trying to make useful predictions about future data management support needs based on current understanding and experience. A concomitant level of understanding of the terminology used is demonstrated. In fact, the knowledge of the participants is no better than might be expected given the limited extent of data management with which they have hitherto been expected to engage.

Given the above, it is necessary to interpret the results from CARDIO exercise with caution with respect to the participants’ rankings.

In may be useful to consider the system-derived rating (i.e. that based on the overall rating of all participants including that of the RSO) with the RSO’s original rating.

The average rating for Organization was 2 out of 5: 5/11 items were unchanged by the system, 1/11 items were demoted by the system by 1 point, and 5/11 promoted by 1.

The average rating for Technology was 2 out of 5: 4/10 items were unchanged by the system, 5/10 items promoted by 1 point and in 1/10 items the question was not understood by the RSO.

The average rating for Resources was 1: 2/9 items were unchanged by the system, 5/9 the system promoted by 1 point and 2/9 items promoted by 2.

Throughout, some of the promotions were agreed by the RSO after deliberation, but a number (and all promotions by 2 points) were disallowed after discussion.

In general it can be said that the participants are not sufficiently well informed about the now-expected data management practices nor have enough experience of data management in the past to make good guesses about what support might be needed in the future. Nevertheless the system-derived ranking was not grossly different from that made by the RSO. Instructively, one participant represents a group of researchers who feel that they have little need for data management and therefore even modest data management capability exceeds their requirements. As a result ratings as high as 5 were given in some instances. This tended to skew the results somewhat!

In the final rankings, only two items were rated higher than 2, these being ‘Ensuring Availability’ and ‘Security Processes’; both were rated at 3. Therefore, nothing was ranked at either 4 or 5.

Eighteen items were rated at 2, and 10 at 1.

It can be seen from this that overall that the current capability of the Department with respect to data management is low, even given the quite modest expectations of the participants of their data management duties. Were the participants better informed of the greater data management duties that will shortly fall to them, there is no doubt that their ranking of the current capabilities would be lower than recorded since that capability would meet the demands less well. There is then, ample room for improvement, the current situation being one that should be easily improved as a result of the introduction of improved data management measures.

6 of 15


With the exception of storage management within the department and its resultant effect of data availability, both of which were rated at level 3 and therefore show evidence of fairly widespread capability, all other topics are either not supported at all or supported only in a limited fashion.

In addition to eliciting the views of participants on current data management capability in the Department of Engineering, it was hoped that evidence would be obtained of good practice that might be more widely adopted. Participant comments suggest that some data management activity occurs, but the scope is limited and the extent varied between projects. Most data management is informal in that the practices are ad hoc and not dependent on clearly laid down and carefully followed procedures; it would be difficult to build directly on these practices.

6. DATA LIFE CYCLE MODELS

It is clearly the case that any design requirement specification should relate to and provide support for the development of data, and associated (management) processes to which they are subject during the data life cycle. Ball (2012) identifies and describes a number of what can broadly described as data life-cycle models. The models are various by virtue of the motivations for their creation, though naturally intersect to some extent in content and coverage. For the purposes of guiding the development of a requirement specification, the Capability Maturity Model for Scientific Data Management (Crowston and Qin, 2011) was selected. The model is similar to, but more detailed, than the UK Data Archive model, of which it has been selected in preference, not least because it was expressly developed for the purpose suggested in its title, that is a reflection of capability maturity of data management. The other models described in Ball (2012) were not considered useful for this purpose.

The elements of the model are shown here:

1. Data acquisition, processing and quality assurance

Goal: Reliably capture and describe scientific data in a way that facilitates preservation and reuse

a) Capture/acquire data

b) Process and prepare data for storage, analysis and distribution

c) Assure data quality (e.g. validate and audit data)

2. Data description and representation

Goal: Create quality metadata for data discovery, preservation, and provenance functions.

a) Develop and apply metadata specifications and schemas

b) Contextualize, describe and document data

c) Document data, software, sensors and mission

d) Create descriptive and semantic metadata for datasets

e) Design mechanisms to link datasets with publications

f) Ensure interoperability with data and metadata standards

g) Ensure compliance to standards

7 of 15


3. Data dissemination

Goal: Design and implement interfaces for users to obtain and interact with

data

a) Identify and manage data products

b) Encourage sharing

c) Distribute data

d) Provide access (e.g., by creating and piloting service models)

4. Repository services/preservation

Goal: Preserve collected data for long-term use

a) Store, backup and secure data (e.g., by backing up databases, preserving

datasets and enforcing security of data systems)

b) Manage schedules for archive generation, validation and delivery

c) Curate data

d) Perform data migration

e) Build digital preservation network

f) Validate data archives

g) Package and deliver data archives

Whilst the full embrace is outside the remit of the REDm-MED Project, this model is nevertheless useful as a check that the key aspects of data management – at the data and data record level – are supported in the requirement specification and thus will be supported by the emergent data management plan.

7. STRUCTURE OF THE RDMPRS

The structure of the RDMPRS will make provision for inclusion of the following information:

The Requirement.

The Rationale for inclusion of the requirement.

Indication of the relation of the requirement to existing DCC Checklist heading content.

Research project life-cycle task supported.

Data life-cycle stage supported with respect to the Data Life-cycle Capability Maturity model.

Principal rôle(s) supported.

Organizational Level.

Identification of information or resource that might be necessary to support the implementation of the requirement.

8 of 15


8. THE REQUIREMENTS SPECIFICATION TABLE

DCC Checklist headings (column 3): Introduction and Context; Data Types Format, Standards and Capture Methods; Ethics and Intellectual Property; Access, Data Sharing and Reuse; Short-term Storage and Data Management; Deposit and Long-term Preservation; Resourcing; Adherence and Review.

Research Project life-cycle Task headings (column 4):

data management planning; data management execution; bid submission; project planning; doing the research; collaboration with colleagues, industry and others; supporting data re-use, re-purposing; preparation for long-term preservation; end-of-life,

Data Management Capability Model headings (column 5): Data acquisition, processing and quality assurance; Data description and representation; Data dissemination; Repository services/preservation.

Principal Rôle(s) Supported (column 6): Principal Investigator or Project Manager (PI), Data Manager (DM), Data Creator or Researcher (R).

9 of 15


Requirement Motivation Requirement Validation RDMP Focus

Requirement Rationale DCC Checklist reference

Research Project life-cycle task

Data life-cycle Stage Principal Rôle(s) Supported

Organizational Level

Implied information /resource requirement

Identify location of support available for each project for data management planning development and execution

To provide a project plan at the project level which conforms to the DMP requirements and can be executed as specified in the plan

n/a Data management planning & execution

n/a PI Institution, Dept.

DM policies, procedures and best-practice guidance together with tools

Identify location of guidance policies wrt to data storage

Project DMP will rely on prescribed criteria

n/a Bid submission, data management planning & Project planning

n/a PI, DM, R Institution, Dept.

Policy document on institutional data storage

Identify location of guidance procedures wrt access to data storage facilities

Project DMP execution will rely on prescribed facilities

n/a Bid submission, data management planning & Project planning

n/a PI, DM. R Institution, Dept.

Storage access procedure document

Identify location of guidance on budgeting and resources for data management

Between-project variation will mean support will be required case-by-case

n/a Bid submission, Project planning

n/a PI Institution, Dept.

Guidance document or tool for assessing budget/resources

Provide guidance on funding body requirement wrt to DM planning and which elements of the DMP these relate to.

To ensure contractual conformance

n/a Bid submission, Project planning

n/a PI Dept. Classification applied to DMP elements

Identify DM requirements arising from statutory and contractual legal obligations

To ensure legal compliance Ethics and Intellectual Property

Data management planning, Project planning

n/a PI Dept. Contracts, licences, summary of known legal issues

10 of 15








Consider budgeting and resources for Data Management

Project data management will require appropriate resources

Resourcing Bid submission, project planning

n/a PI Project n/a

Identify guidance on the identification and selection of appropriate data archive/repository/centre locations

Non-local archiving is not well supported and It is unlikely that researchers, and perhaps PIs, will have special knowledge of data repositories

Deposit and Long-term Preservation

Bid submission, preservation

n/a PI, DM, R Project Selection procedures, criteria, esp. in relation to data character, security, sensitivity considerations.

Consider identification of roles and responsibilities associated with management at departmental and project level

Management of the data management requirements of a project at project and departmental/institutional level

Resourcing, and Adherence and Review

Bid submission, project planning

n/a PI Project These will include ‘functional’ as well as contractual responsibilities and roles, e.g. who is responsible for security of data; preparation for supporting re-use and for preservation/archiving

Consider identification of long-term preservation strategy

Required to meet potential funder requirements and to support longer-term data sharing

Deposit and Long-term Preservation, Resourcing

Preservation Repository services/preservation

PI Project n/a

Consider identification of during-project storage needs

These needs will be project-specific, mediated by institutional and departmental support policies and practice.

Short-term Storage and Data Management

Data management planning and Project planning

Repository services/preservation

PI, R Project Assumption of provision of appropriate storage

11 of 15








Consider identification of post-project storage needs

Required to ensure that suitable in-house storage support – is specified prior to project end.

Deposit and Long-term Preservation, Resourcing

Data management & Project planning


PI, DM Project n/a

Consider identification of data security issues

Data must be secured as appropriate, wrt back-up and sensitivity, IP issues and collaborator requirements.

Ethics and Intellectual Property;

Possibly: Short-term Storage and Data Management

Data management & Project planning, collaboration


PI, DM Project The assumption will be that the Dept.. will provide the infrastructure to support the needs.

Consider the identification of access and sharing constraints

As above Ethics and Intellectual Property

Project planning, collaboration

n/a PI Project n/a

Consider collaborator agreement appropriate to the project wrt data sensitivity and collaborator requirements

As above Ethics and Intellectual Property; Access, Data Sharing and Re-use

Project planning and Collaboration

n/a PI Project This should be considered in relation to external sharing mandates.

These will influence considerations of access

Consider identification of guidance to execute and review data management plans

Planning alone will not provide the basis for maximizing data value: execution is necessary

Adherence and Review

Data management planning

n/a PI, DM Project n/a

12 of 15








Consider the identification and acquisition of existing data sets to support the planned research

Re-use of existing data sets is the motivation for data management

Data Types Format, Standards and Capture Methods


n/a PI, R Project The existence of suitable data sets, and the information necessary for its location and identification

Consider the provision of detailed description of data acquisition and generation methods

Provides the basis for regeneration of source data, rather than its long-term curation and concomitant overheads.



Data description and representation

DM, R Project n/a

Consider actual or potential relationships between prior and new data

Part of the provision of context necessary for future comprehension and interpretation.


Data management execution, preparation for long-term preservation


DM, R Project n/a

Provision of record of data organization during research and of final data case

Part of the provision of context necessary for future data access, comprehension and interpretation.


Research, Data management execution, preparation for long-term preservation

Data acquisition, processing and quality assurance

DM, R Project n/a

Provision of contextual data records

Part of the provision of context necessary for future data access, comprehension and interpretation.


Research, Supporting data re-use & repurposing


DM, R Project Might imply the need for appropriate record-making software.

13 of 15








Provision of assurance procedures and standards

Promotes and provides evidence of data quality and validity


Data management planning, data management execution


DM, R Project Might imply pre-existing assurance procedures and standards applicable to the intended research

Documentation of project data sets

Supports sharing, access and interpretation


Research, data re-use/repurposing, Preservation


DM, R Project n/a

Consideration of what other bodies/groups/individuals are likely to be interested in the data

Supports sharing and future discovery

Access, Data Sharing and Re-use

Research, preservation

Data dissemination PI, R Project Implies current knowledge or existence of and access to supporting information

Consideration of contemporary or future uses for the data

Provides motivation for data management for re-use and may provide indicator of best management approach.

Access, Data Sharing and Re-use

Research, preservation

Data dissemination PI, R Project n/a

Provision of guidance on the disposal (that is the deletion) of research data

The management and physical storage provision overheads are sufficiently high as to warrant consideration of what data may discarded

Deposit and long-term preservation

End of life Repository services/preservation

PI Institutional, Project

The existence of such guidance

14 of 15


9. REFERENCES

Ball, A. (2012) Review of Data Management Lifecycle Models (version 1.0) REDm-MED Project Document redm1rep120110ab10. Bath, UK: University of Bath.

Ball, A., Darlington, M., Howard, T., McMahon, C. and Culley, S. (2010). Engineering Research Data Management Plan Requirement Specification (version 1.1). ERIM Project Document erim6rep100901ab11. Bath, UK: University of Bath. http://opus.bath.ac.uk/21280/

Darlington, M., Ball, A., Howard, T., Culley, S. and McMahon, C. (2010). Principles for Engineering Research Data Management (version 1.0). ERIM Project Document erim6rep101028mjd10. Bath, UK: University of Bath. http://opus.bath.ac.uk/22201/

Brown, M., Parchment, O. and White, W. (2011). Institutional Data Management Blueprint. IDMB Project Document. Southampton, UK: University of Southampton. http://eprints.soton.ac.uk/196241/

Crowston, K. and Qin, J. (2011). ‘A Capability Maturity Model for Scientific Data Management: Evidence from the Literature’. In: Proceedings of the American Society for Information Science and Technology. Vol. 48. DOI: 10.1002/meet.2011.14504801036.

15 of 15

http://dx.doi.org/10.1002/meet.2011.14504801036

http://eprints.soton.ac.uk/196241/

http://opus.bath.ac.uk/22201/

http://opus.bath.ac.uk/21280/

Documents

Opus: University of Bath Online Publication Store · PDF fileDarlington, M. and Ball, A. (2012) Research Data Management Plan Requirements Specification for the Department of Mechanical