This is part of a series of posts which is based on a 3-hour hands-on workshop I offer on this topic. Be sure and check out the preceding post:
Technology Solutions Planning in Libraries: Overview
Technology Solutions Planning in Libraries: Part One – Develop the Project Plan
Technology Solutions Planning in Libraries: Part Two – Establish a Planning Committee
Technology Solutions Planning in Libraries: Part Three – Gain Market Intelligence
The purpose of gathering requirements is to determine what your library’s needs are, and what it “requires” of the software or system.
- Create a Library Profile
- Number of staff who will use system
- Estimated number of simultaneous patron usage (if applicable)
- A snapshot of your organization/library
- Sets scale for the scope of the technology solution needed
These are the global system requirements. They deal with the critical business/operational issues that are impetus for this project. These should focus on the high-level goals of the solution. Business requirements often overlap with functional requirements and actually serve to drive their direction. They consist of answers to questions such as:
- What functions do we want to automate?
- Cataloging, Circulation, Serials Management, Acquisitions, etc? (ILS)
- Do we want any level of self-service, renewals, recalls, etc.? (ILS)
- What is the expected lifespan of the system, what is the expected growth during that time period? (ILS)
- Will this system need to interact with systems from other libraries, interlibrary loan, etc.? (ILS)
- Will we need permissions or levels of security, or will this be open? (wiki)
- Do we expect user-generated content? (blog)
- Do we expect users to access this remotely? (calendar)
- Will there need to be any level of moderation, approvals, or workflow? (any)
- Can be assigned to a business subcommittee
What are the functions which will be necessary of the technology? The functional requirements address what the features are of a solution, as well as the way that it functions. These should address all of the concerns of the business requirements. The first step to discovering these is to:
- Develop Use Cases
- Workflow analysis documents outlining tasks you wish to automate
- Checking out a book, entering an appointment into a calendar, posting an article to the website, etc.
- These document both on and offline steps taken to complete tasks
- By analyzing your existing workflow, you will be able to determine how your software needs to work (map out inefficiencies, etc.)
- The biggest mistake you can make is to choose a technology solution which cannot do at least what your process was capable of doing before!
- If this is a new process/solution, you should match your functional expectations with feature sets from various existing software in the market
- Can be assigned to a functional subcommittee
Functional Requirements deal with questions such as:
- Does the software need to conduct copy-cataloging via Z39.50 protocol? (ILS)
- Does the system need to have an inventory feature? (ILS)
- Does the calendar need to have group sharing capabilities? (calendar)
- Should the program allow for recurring events? (calendar)
- Does the blog need to have RSS feeds? (blog)
- Should the wiki allow for reverting to previous versions? (wiki)
- Is a WYSIWYG editor necessary? (any)
- Can be decided on by functional subcommittee
These requirements deal with the detailed technical considerations of the software/solution. They are driven by the business and functional requirements. They vary greatly from project to project. It is important to get this subcommittee involved early as they may also have some limitations which may change the earlier business requirements, etc. They address questions such as:
- How many workstations are required?
- How many simultaneous end-users are necessary?
- How many simultaneous staff users are necessary?
- Traditional Client-server architecture or ASP?
- Mac or PC compatible?
- Can be decided on by technical subcommittee