Requirements and Specifications
More information about system selection is available from our System Selection infoKit
Specifying a repository system involves choices that should be led by a general requirements analysis: what is the repository required to do, and for whom? This section describes how to identify the broad requirements that can inform a system specification.
A systems requirements analysis is an essential pre-requisite to choosing the right software to build a repository. Repository software choices span a range of costs, support different needs, customisation and quality, and serve a range of stakeholders. The analysis that leads to the specification is not predominantly technical, and should involve all members of the repository team, even though systems requirements may ultimately be expressed in technical terms.
Defining the requirements
UK Examples
To define your requirements you have to ask some questions. Your list should start with high level questions such as
- What is the repository for?
- Who are the stakeholders - those people with a vested interest in how the repository represents the institution, and themselves, to the world, and what do they want from the repository? In the case of an institutional repository, stakeholders will include senior institutional managers, departmental leaders, and those who are expected to contribute content. This approach is likely to reveal a series of questions: What is the target content of the repository?
- Are all content types to be managed in a single repository, or more than one?
- What other systems and services might the repository be required to share information with? This is often referred to as 'interoperability'.
- Is there appropriate budget and staffing to support the requirements?
- What will the repository store? For a higher education institution, repository content could include research papers and data, electronic theses, as well as teaching and learning resources, perhaps including some audio-visual content
The most obvious consideration governing a system specification is the budget: how much money is available to support the system? Repositories are a long-term investment for the institution. Establishing a working repository that is easy to use for the purpose intended must be the first target if it is to have an impact and develop working practices and cultures. Almost every decision will be influenced by cost. Be realistic, but remember that a requirements analysis based on a full stakeholder consultation will result in a stronger position to secure the funds needed to fulfil the needs the stakeholders have identified.
Once you have defined your high level requirements, you should start to define the lower level requirements, and the technical requirements to provide the features you need. These are often described as 'functional requirements'. Examples of these lower level requirements include:
Interoperability requirements
For repositories, efficiency and flexibility in getting data in and out, in a variety of formats, are key requirements. Interoperability of institutional repositories has largely been founded on the Open Archives Initiative (OAI), which first defined how repositories as data providers could collectively become visible and searchable through OAI service providers. Now interoperability is also likely to embrace OAI-Object Reuse and Exchange (ORE), content deposit protocols such as SWORD, as well as web services standards, including RSS/Atom, Web 2.0, digital library systems and other institutional systems, as well as personal information systems such as citation applications. Standards can enable interoperability. OAI, Dublin Core, and W3C accessibility are core standards for research repositories. Greater interoperability with services can provide flexibility for upgrading the repository in future.
Software options
A key factor in cost considerations is not only which software but how it is delivered and supported. Open source software (OSS) is free to download, install and use, but there is an ongoing cost to implement and maintain the repository, depending on the complexity or ease of use of the software chosen and the ability to install and configure it for use. Good support services and documentation can reduce implementation costs. OSS providers do not typically promise to support end-users directly, but support lists and communities can often assist. Hosted software providers, on the other hand, often charge a fee to provide a supported software environment. Repository Service Providers are another model where users can pay for specified services such as repository building, hosting, customisation and optimisation, rather than software. In this way they could combine OSS with paid support to improve cost efficiency of the repository. More information about the choice between OSS and hosted software is available in the section on platform choices. Decisions about software and support may rest on the systems support available locally. That support may, in turn, influence other requirements such as your chosen operating system.
Platform requirements
Which server operating system? Typically, OSS repositories use other open source components, such as a web server, and a database.
Programming requirements
Does the repository need programming skills? Programming helps develop, customise and extend the repository.
As well as defining your functional requirements, you may also wish to define other types of requirements. These could include:
Performance requirements
How many items will you want to store in your repository, and how many users will be using your repository. You need to ensure that your requirements define these metrics to ensure that your chosen solution can meet these needs.
Quality requirements
Do you have standards that must be met? For example you may have an institutional requirement for web accessibility standards that must apply to all web systems, or language requirements to support a bilingual language policy.
When defining your requirements you might find that they vary in importance. You can describe them using terminology such as 'essential', 'desirable', and 'nice to have'. This will allow you to rank your requirements and to describe which must be met by a potential solution, and which are just niceties that you could go without.
