Specifying Repository Requirements

Slides:



Advertisements
Similar presentations
Applying preservation metadata to repositories For JISC KeepIt course on Digital Preservation Tools for Repository Managers Module 3, Primer on preservation.
Advertisements

Achieve Benefit from IT Projects. Aim This presentation is prepared to support and give a general overview of the ‘How to Achieve Benefits from IT Projects’
Develop an Information Strategy Plan
Advanced Technical Writing Today in class ► Presentation guidelines ► Ideas for displaying data.
Empowering Staff Through Institute Planning (ESTIP) Executive Workshop Institute Name: XXXXXX Presenter: XXXXXX Date: XXXXXX.
Whose Job Is It? Part Two © Iowa Association of School Boards At the Board Table Discussion Tool.
Getting it Right in West Lothian
“”Capacity and services to road users” Task descriptions Paul van der Kroon, Paris November 2005.
Gender Analyze in Project cycle. The pre-planning stage of a project is the stage when you or your partner organisation start to draw up ideas for a project.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Let Ascension take your business to new heights Tender Manager Scott Warnock Andrew Smillie.
Making sense of it all analysing and interpreting data.
ITSRM Content Management Infrastructure Coordination David Foster IT June 2010.
This was developed as part of the Scottish Government’s Better Community Engagement Programme.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Middle Managers Workshop 2: Measuring Progress. An opportunity for middle managers… Two linked workshops exploring what it means to implement the Act.
Climate Change Design Challenge Global Science 2013.
Applying preservation metadata to repositories The British Library, 21 January 2008 Led by Steve Hitchcock With Bill Hubbard, Gareth Johnson.
Beyond the Repository: Research Systems, REF & New Opportunities William J Nixon Digital Library Development Manager.
How to Write a Book Review. Before You Begin Remember, there is no right way to write a book review. Book reviews are highly personal and reflect the.
What are Training Paths and how to construct them
Welcome to Scottish Improvement Skills
Improving students’ MEMORIES
Civic Practicum: Project Design and Proposal Writing
Scenarios framework – exploring ‘practice’
Step 1: Comparing governance approaches in the pilot areas
Creating an institutional repository elements for success!
Step 6: Create environmental concepts
Consultation: Your Say ….
Chapter 16 Participating in Groups and Teams.
Workshop for ART mentors
HCS 455 EDU Inspiring Minds/hcs455edu.com
Building the foundations for innovation
The Systems Engineering Context
The People’s Parliament in Sandwell:
Governor Visits to School
Curriculum Model Curriculum Model is defined as a plan of action that can be employed to structure a subject or knowledge area from a theory into practice.
INFORMATION AND PROGRESS
Building Learning Power Assembly
THE BUSINESS ANALYSIS PROCESS MODEL
Enterprise Content Management, Shared Services, & Contract Management
HCS 455 TUTORS Lessons in Excellence -- hcs455tutors.com.
Module B- Taking the Lead
NOTES FOR PRESENTERS: This presentation is designed to help people who implement shared plans of care to explain the practice to other professionals.
Telling Your SSIP Story
The Two Most Common Types of Contemporary Planning Techniques
EOSC Governance Development Forum
Integrating CSC into our Schedules
Team Up for School Nutrition Success: Skilled Helper Model
Running an Effective Club at Clark University
Unit 6: Application Development
Turning data insights into action
Who do you think they are?
Social Media Sarah Mallen Information & Guidance Coordinator The University of Manchester Careers Service.
Let’s Talk Data: Making Data Conversations Engaging and Productive
Chapter 16 Planning and Management of Health Promotion
STATE UNIVERSITY OF MAKASSAR 2011
Governor Visits to School
Process Improvement Overview
Whose Job Is It? Part Two At the Board Table Discussion Tool
L.O. To share stories about our lives that build up a deeper picture of identity and diversity within our class TLN Identity Pack L3.
The Two Most Common Types of Contemporary Planning Techniques
CYPIC Improvement Advisor Falkirk CYPIC QI Faculty
Policy Frameworks: building a firm foundation for your IR
THE PROCESS OF INTERACTION DESIGN
Re-Framing Agendas: From the Personal to the Policy Level
Using State and Local Data to Improve Results
Next steps for scenarios 9 February 2017
Engagement Planning - Communications
Levels of involvement Consultation Collaboration User control
Presentation transcript:

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 )