1. Specifying Repository Requirements
Brunel University, 8 November 2007
Led by Steve Hitchcock
With Jackie Knowles and Pete Cliff
This presentation is allied to a workshop that seeks to identify repositry requirements from three perspectives.
The original idea for the presentation was to consider ‘user requirements’. What are these? On investigation we found no single answer to this, so we decided to broaden the presentation to cover the various types of requirements that were put forward to us, and which taken as a whole seem to cover ‘repository requirements’.
Since we don’t claim to have all the answers to these requirements, we decided to turn the presentation into a workshop.So we are consulting those who have experience in this area: you!
[Author’s note] This talk is designated ADVANCED level in content.

2. Workhop Overview What are repository requirements?
Institutional/stakeholder, user, system requirements
Teams work on different requirements analyses
Team report back and synthesis of findings
Conclusions: the whole picture?
This workshop will have five main stages

3. Institutional (stakeholder) requirements
Stakeholders Who are the institutional stakeholders?
Policy How can institutional repository policy impact requirements?
Workflow Can repositories tie in to existing institutional practices and workflow?
Systems framework Will systems integration drive requirements?
What are institutional stakeholder requirements, and who produces these?
A note about systems integration. This might be driven by the institution; known examples are driven by library systems. How does this affect the repository?

4. Team task: stakeholders
Your team could include senior institutional managers, research managers, library and information systems manager, and heads of research schools.
Your task is to decide what the repository is for, what you want it to achieve. You have to set some parameters to direct the repository towards the aims and objectives you set. These can be sketched quite broadly, e.g. resources, coverage, longevity, etc.
Each team needs to have some idea of what they and the other teams will be doing. Here is the outline of the stakeholder’s task
This information is also provided on the handout to be given to the ‘stakeholders’ at the start of the task.

5. Who are the repository users? How can we determine user requirements?
Anticipating user requirements: Scenarios, user stories
Who are repository users, and how can we know what their requirements are?

6. Team task: users
You are a team of repository users, that is, you use the repository to perform tasks. Your group could include authors, administrators, searchers.
Your task is to specify some ways in which the repository could better serve your needs. This could concern deposit, or the management of materials already deposited. What tasks might you need to perform on your data that might be supported by the repository?
Here is the outline of the user’s task.
This information is also provided on the handout to be given to the ‘users’ at the start of the task.

7. System requirements
The following broad themes were common to some invitations to tender we have seen offered to repository services organizations
Interoperability
Upgradeability
Standards
Open source software (OSS) or supported?
Platform requirements
Programming requirements
We often think of systems in terms of: which repository software should we choose? Or, now, we may need to decide which repository services to use. Either way, we cannot make such decisions until we have some idea of the system requirements. This seems like a technical process, but it need not be, and the system requiremnts ought initially to be expressed in terms understandable by the repsoitory manager.

8. Team task: systems
You are a repository management team that is responsible for procuring or setting up a new repository. Your group could include managers, administrators, editors, systems staff.
Your task is to map and prioritise some requirements that will enable you to choose the tools, software or services needed for the repository. These do not need to be specified in technical terms, but in broader terms that can be handed to a systems or services team.
Each team now has some idea of what they and the other teams will be doing.
This information is also provided on the handout to be given to the ‘systems’ team at the start of the task.

9. Some helpful advice
Remember, we are not trying to construct the ideal repository. We want to see how different types of broad requirements can interact , leading to systems decisions and implementations.
When we regroup for the synthesis part of the workshop we will see how the requirements produced by each team might fit with those from the other teams. THE BIGGER PICTURE.
Good luck with your team tasks!
This slide can be left to display during the team tasks.

10. Synthesis
The aim is to try and synthesise the respective team results into broad repository requirements,
What kind of repository can we see emerging, if any? There may not be one as we have been working as independent teams, rather than a coordinated requirements gathering team. It doesn’t matter.
Can we see ways to handle requirements gathering? Which order? Which requirements take priority? Did we miss anything? Has anything surprised in this approach?
It’s time to regroup and find out what requirements each of the teams have specified. After each short team presentation, can we synthesise the results into a bigger picture?

11. What about your repositories?
How did requirements gathering work in practice?
Who has followed such an approach with their repository?
What other approaches have been used?
How successful have your repositories been at satisfying requirements?
Or were you under pressure to build something before you have the chance for a full requirements analysis?
We have constructed requirements for an unspecified repository. Now we want to compare this with practice and experience by inviting the deegates to tell us about their repositories. We assume they have working repositories. How did they produce requiremenst for those repositories?

12. Aside: Acceptance testing
Having implemented the system, we have to determine how successfully the system serves the requirements. This could involve e.g.
Test strategy
Roles
Scripts
"Process Flow diagrams"
Outcomes
Expectations
Regression tests
Something we didn’t have time to cover in the team tasks, but it needs to be done. You can begin to see why we didn’t cover this here!

13. Reflection & Recap
Did looking at all three types of requirements – institutional stakeholder,user, system – show us anything new and useful?
Will any of your practices change as a result of the workshop?
Did we see the bigger picture?
Time to conclude the workshop. Hopefully we all learned something we can apply, and we have develpoed a bigger picture than can be reported for others to consider.

14. (Steve Hitchcock)
( )