This section of the Procurement Toolkit provides resources for developing a set of requirements for a digital repository procurement project.

The aims

  1. Assist DPC Members in defining preservation system requirements, making the process simpler, more efficient and more effective (comprehensive, precise, understandable).
  2. Assist DPC Supporters in responding to customer requirements, typically in RFI/RFT situations. The main challenge identified previously (in DPC DP Futures discussions) is that each customer draws up their own requirements and communicates them in their own way (language, structure, etc). This results in a very arduous task in responding to each new set of requirements from a customer that might contain many common requirements (probably described in unique language) but also some unique or new requirements.
  3. Assist both Members and Supporters in coming to a common understanding around their needs and solutions, in order to minimise communication challenges and mis-matched expectations.

This work will categorize, uniquely identify and capture common requirements in order to meet these aims.

Why focus on requirements?

As noted in the "Lessons learned" section (DPC Members only), a requirements led procurement process is not the only way to proceed, and may not be the best fit for you. However, many of our members do use this approach and this area has been identified by both DPC Members and Supporters as being ripe for additional development and support from the DPC.

Again, as noted in the "Lessons learned" section, low level and granular requirements alone are unlikely to sufficiently articulate the needs of a customer to a potential vendor. Feedback from Members and Supporters has emphasized the need for effectively capturing and communicating the bigger picture. This is particularly relevant in the shape and scope of the system being procured but also in how it interoperates with related systems.

A draft structure for common requirements

The following provides a simple structure for repository requirements which will be populated with specific common requirements as this work progresses. This aims to simplify communication of Members requirements while providing some indication of areas that should be considered for requirements gathing/coverage. Note that this observation is important. This work does not intend to imply that a particular organisation must document requirements in all of these sections. However, consideration should be given to whether coverage in each of these areas might be appropriate for the organisation in question. It has been developed based on requirements made available by DPC Members along with comparitive validation with related work and resources, such as DPC RAM and ISO16363.

  1. Acquisition, transfer and ingest
  2. Content preservation
  3. Bitstream preservation
  4. Management and administration
  5. Discovery and access
  6. Systems integration and interoperability
  7. System design
  8. Metadata management
  9. Security
  10. Disaster recovery and resilience
  11. Export/exit strategy
  12. Training
  13. Usability/help/documentation
  14. Contractual
  15. Supplier profile
  16. Implementation
  17. General/other

A more detailed list, incorporating a second level of requirement topics can be found in this downloadable Word document: Common Requirements Structure v1.0 .

Common requirements

This is currently a work in progress that will be examined in the associated launch event and workshop for this Toolkit.

Status and feedback

This section of the Toolkit is a work in progress. Developments will be made iteratively in conjunction with DPC Members and Supporters, particularly via workshops and interactive discussion.

Please send any comment or feedback on this work to Paul Wheatley (see contact details).


Note that this work is made available under a CC-BY Licence.

Scroll to top