Specifying Repository Requirements Workshop @ 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.

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

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?

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.

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?

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.

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.

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.

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.

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?

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?

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!

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.

(Steve Hitchcock) (Email: sh94r@ecs.soton.ac.uk )