Library Website Functionality Requirements v1.4
Library Website Functionality Requirements v1.4
Library Website Functionality Requirements v1.4
Functional Requirements
Version 1.3
April 8, 2009
Document History
Date Modifier Version Description
March 17, 2009 Rochelle 1.1 Applied changes to the initial document
March 18, 2009 Rochelle 1.2 Applied changes to the edited document
Table of Contents
1 FUNCTIONAL REQUIREMENTS...................................................................................................................7
1.1 OVERVIEW......................................................................................................................................................7
1.2 PRIORITIES......................................................................................................................................................7
2 FUNCTIONALITY .............................................................................................................................................8
2.1 USER MANAGEMENT ......................................................................................................................................8
2.1.1 Description ............................................................................................................................................8
2.1.2 Functional Requirement List .................................................................................................................8
2.1.3 User Interface Functions / Interaction...................................................................................................8
2.1.4 Error Handling ......................................................................................................................................8
2.1.5 Assumptions ...........................................................................................................................................8
2.2 TEXT SIZING ...................................................................................................................................................9
2.2.1 Description ............................................................................................................................................9
2.2.2 Functional Requirement List .................................................................................................................9
2.2.3 User Interface Functions / Interaction...................................................................................................9
2.2.4 Assumptions ...........................................................................................................................................9
2.3 AUTHENTICATION ..........................................................................................................................................9
2.3.1 Description ............................................................................................................................................9
2.3.2 Functional Requirement List .................................................................................................................9
2.3.3 User Interface Functions / Interaction.................................................................................................10
2.3.4 Assumptions .........................................................................................................................................10
2.4 SEARCH – CATALOGUE.................................................................................................................................10
2.4.1 Description ..........................................................................................................................................10
2.4.2 Functional Requirement List ...............................................................................................................10
2.4.3 User Interface Functions / Interaction.................................................................................................10
2.4.4 Assumptions .........................................................................................................................................11
2.5 SEARCH – SCHOLAR’S PORTAL.....................................................................................................................11
2.5.1 Description ..........................................................................................................................................11
2.5.2 Functional Requirement List ...............................................................................................................11
2.5.3 User Interface Functions / Interaction.................................................................................................11
2.5.4 Assumptions .........................................................................................................................................12
2.6 SEARCH – PAST EXAMS ................................................................................................................................12
2.6.1 Description ..........................................................................................................................................12
2.6.2 Functional Requirement List ...............................................................................................................12
2.6.3 User Interface Functions / Interaction.................................................................................................12
2.6.4 Error Handling ....................................................................................................................................12
2.6.5 Assumptions .........................................................................................................................................12
2.7 SEARCH – WEBSITE ......................................................................................................................................13
2.7.1 Description ..........................................................................................................................................13
2.7.2 Functional Requirement List ...............................................................................................................13
2.7.3 User Interface Functions / Interaction.................................................................................................13
2.7.4 Assumptions .........................................................................................................................................13
2.8 SEARCH - RESERVES .....................................................................................................................................14
2.8.1 Description ..........................................................................................................................................14
2.8.2 Functional Requirement List ...............................................................................................................14
2.8.3 User Interface Functions / Interaction.................................................................................................14
2.8.4 Error Handling ....................................................................................................................................14
2.8.5 Assumptions .........................................................................................................................................14
2.9 SEARCH – GOOGLE SCHOLAR .......................................................................................................................14
2.9.1 Description ..........................................................................................................................................14
2.9.2 Functional Requirement List ...............................................................................................................15
2.9.3 User Interface Functions / Interaction.................................................................................................15
1 Functional Requirements
1.1 Overview
This document presents the functionality requirements for the University of Toronto Mississauga Library
Website Redesign project. The functional requirements define the functions that the system must perform in
order to enable the business activities defined in the Business Requirements document.
1.2 Priorities
The prioritization categories are as follows:
Priority 1 – Required
Priority 2 – Desired
Priority 3 – Optional
2 Functionality
2.1.1 Description
The user management functionality component supports a granular approach to user management for website
content contributors.
1. The system owner must have the ability to create multiple user groups 1
2. The system owner must have the ability to assign rights and functionality to user groups 1
3. The system owner must have the ability to designate pages for user group content creation/editing 1
4. The system owner can alter the user interface based on user group 2
2.1.5 Assumptions
• Most user management tasks will be accomplished via direct database interaction by scripts
• Library staff user management will be managed manually via the web interface
• A layer between the Drupal users database will import user data from a UTORauth (or other) dump at
regular intervals
• Owner will be able to create new roles for users after the installation period
2.2.1 Description
The text sizing functionality component allows users of the site to adjust the display size of text to better
accommodate their viewing preferences.
5. The user must be able to change the font size of any page through the browser. 1
2.2.4 Assumptions
o The vendor will allow for altering font sizes as part of the overall design.
2.3 Authentication
2.3.1 Description
The authentication functionality component allows users to log into the site using their UTORid and password and
be presented with a website constructed based on their user roles, preferences, courses, and program.
2. Key information (name, course enrollments, program) will feed into drupal db 1
2.3.4 Assumptions
2.4.1 Description
The search catalogue functionality component allows users of the site to search the UTL catalogue for print and
eResources.
1. Search box looks integrated to the main website, but is actually searching an external database 1
(Sirsi/Endeca)
2.4.4 Assumptions
• We can design the catalogue search as we like without conforming to style rules from Endeca/Sirsi
• We can place the catalogue search high on the page without interfering with other functions or theme
constraints
2.5.1 Description
The search – Scholar’s Portal functionality component allows users of the site to search the scholar’s portal database
for articles.
The search – Scholar’s Portal functionality component has the following requirements:
2. Search begins on the website and transfers the user to the scholar’s portal results 1
2.5.4 Assumptions
• Scholar’s Portal search will be visible depending on whether it’s chosen by librarians for inclusion in a
generic profile
2.6.1 Description
The search –past exams functionality component allows users of the site to search ERes for past exams.
The search – past exams functionality component has the following requirements:
1. System checks to see what courses a student is enrolled in and offers those course codes as prompts 3
3. Search can be relocated to more prominent locations on the main website or deeper, organic course- 3
related parts of the site as needed
• Fails gracefully; doesn’t prevent the rest of the page from loading
2.6.5 Assumptions
• We can create an external search via html that will produce valid ERes results
2.7.1 Description
The search – website functionality component allows users of the site to search the Library website.
1. Allow users to search the website and receive relevant search results 1
2.7.4 Assumptions
• Internal search within Drupal is robust and preferable (Google custom search not superior)
2.8.1 Description
The Search - Reserves functionality component allows users of the site to easily access Reserves materials for
courses.
2. Sends a search request to ERes and displays back all reserve material for a course 1
3. When used on login, displays links to all available reserves lists from the courses in which the user 3
is enrolled (undergraduate)
• Fails gracefully; doesn’t prevent the rest of the page from loading
2.8.5 Assumptions
• ERes will produce stable links per course to which we can link
• Website search can send a search query to ERes and produce results
• Results can show within ERes, but would ideally be reformatted and shown within the website
2.9.1 Description
The search - Google functionality component allows users of the site to perform a search using the Google Scholar
search function to find locally available materials.
2.9.4 Assumptions
• Library staff will accept a google scholar link on the library’s website
• Google scholar link could be added as part of a portal package, and not by default
2.10.1 Description
The E-journal management functionality component allows the website owner to create and manage e-journals, with
RSS subscription, reviewing tools, and comments.
The e-journal management availability functionality component has the following requirements:
1. Separate CSS design for each journal, and independent of the site’s CSS
2.10.4 Assumptions
• E-journal management could be used in house to manage elements of the website, including Foreword
• Library staff could employ this tool in the future as part of their communication to faculty and students
2.11.1 Description
The library hours functionality component allows users of the site to quickly determine library hours.
• Fails gracefully, defaulting to a link to hours if the auto-generated hours statement cannot load.
2.11.5 Assumptions
• We can simply create a database of the library’s hours that the website can draw from based on date
2.12.1 Description
The staff directory functionality component allows users to browse all library staff profiles.
1. Automatically updates when new library staff profiles are added or removed 1
2.12.4 Assumptions
• Staff directory would not be prominent on the website, but would act as a last-chance attempt to find a
specific person if all other available options have failed.
2.13.1 Description
The workstation availability functionality component allows users of the site to quickly locate online an available
workstation in the library.
2.13.5 Assumptions
• Labstats application will produce practically-sized flash or image content to embed in library’s website
2.14.1 Description
The loaner laptop (equipment) availability display functionality component allows users of the site to quickly
determine availability of a loaner laptop in the library. The loan information is kept in our Sirsi catalogue, and
available via a web interface without a login.
The loaner laptop availability functionality component has the following requirements:
1. Connects to Sirsi to gather information on which laptops are available for loan via: 1
a. http://search2.library.utoronto.ca/UTL/search.jsp
2. Displays: “X laptops are available. Next laptop due at: X:XX. Click here for more information.” 2
3. “More information” link should display all due dates on loaned laptops in a user-friendly fashion. 3
• Fails gracefully; provides a link to information about loaner laptops if the applicaton cannot load
2.14.5 Assumptions
2.15.1 Description
The study space availability display functionality component allows users of the site to quickly determine available
study spaces in the library.
The study space availability functionality component has the following requirements:
• Fails gracefully; if the application fails, it is replaced by a static picture and a link to a page containing all
the webcam feeds.
2.15.5 Assumptions
• View can be blurred enough to obscure individuals but display available study space
• A drupal module or third party application exists to assist with this objective
2.16.1 Description
The blogging functionality component allows the Library to easily update library patrons of items of current interest
via blogging format; the blogging functionality allows users of the site to view library created blogs of interest to
them.
3. Group blogs can be generated by pulling all posts using a particular tag 3
5. Must have flexible design tools to allow users to add elements to the sidebar 2
7. Must be searchable 1
2.16.4 Assumptions
• Many library staff will have individual blogs on which they report on their thoughts and activities
• Posts that need to be promoted to the front page could come from any blog
• Category views will be more useful to the average user than individual blog views
2.17 FAQ
2.17.1 Description
The FAQ functionality component allows users of the site to easily generate an FAQ on any topic.
1. Allow users to place such a document within any group of documents, linked to any group of 1
documents
2.17.4 Assumptions
• FAQ pages created by students may require moderation or proof-reading for accuracy
2.18.1 Description
The events calendar functionality component allows users of the site to see events and schedules relating to the
library.
4. View can be modified based on user or page: public view (events) and a view based on user, 1
location (reference schedule)
• Fails gracefully; doesn’t prevent the rest of the page from loading if the calendar fails.
2.18.5 Assumptions
• There are a variety of Drupal elements and modules that can be used to produce an events calendar
2.19.1 Description
The content aggregation-twitter functionality component allows library staff to easily embed twitter posts.
2. Allows users to easily populate sidebars of pages with the most recent twitter posts from specific 1
library twitter accounts
3. Twitter updates on the main page only appear when they are current (today’s date) 2
2.19.4 Assumptions
• Some twitter feeds will appear on the main page, some will not
• Library staff can have their twitter feed appear in multiple places as need warrants
• There is a Drupal/Twitter integration module already available; if not, Drupal will allow us to drop in
Twitter badges
2.20.1 Description
The content aggregation-RSS Feed Display functionality component allows users of the site to add external content
to the website.
The content aggregation-RSS Feed Display functionality component has the following requirements:
1. Allows library staff to add an RSS feed, and have the content of that RSS feed display, as node 1
2.20.4 Assumptions
• Librarians may add content to their profiles, or to pages created to assist students with assignments or
resources.
2.21.1 Description
The content aggregation-internal RSS Feeds functionality component allows users of the site to take content from
the library’s website and aggregate it into other websites.
The content aggregation-internal RSS Feeds functionality component has the following requirements:
1. Allows content creators to create RSS feeds based on a tag, a user, or a section of the website. 1
2.21.3 Assumptions
• Internal RSS feeds will be employed exclusively by systems, computing services or other website design
staff
• Internal RSS feeds will appear on digital signage and possibly other UTM or library websites
2.22.1 Description
The citation / bibliography functionality component allows users of the site to create bibliographies to share with the
community.
2.22.4 Assumptions
• This tool could allow librarians to create collections of resources for students;
2.23.1 Description
The WYSIWYG editing functionality component allows users of the site to not know or use any HTML code to
create rich document. The WYSIWYG editor should be bypassable so that advanced users can insert code (twitter
badges, etc.)
1. Allows content creators to insert basic style elements (bold, italics, tables, bullets) into a node 1
without the use of raw code
2.23.4 Assumptions
• We will be able to choose from a range of WYSIWYG options already created for Drupal installations
• We will be able to choose a WYSIWYG editor that allows for copying and pasting from Word documents
without getting thrown by all the additional Word code
2.24.1 Description
The content expiration functionality component allows content creators to set their data to disappear and/or become
less relevant in a search after a set time.
1. Allows content creator to set the expiry date of all created material 3
2. Demotes expired content in current searches (find content related to current course before that of a 3
previous course)
• Allow users to easily choose a date by which the content will have expired
2.24.4 Assumptions
• Content expiration removes elements from prominent view, but doesn’t prevent them from being found at
all
• Content expiration functionality is available for Drupal installations via an existing module.
2.25 Polls
2.25.1 Description
The polls functionality component allows content contributors to engage the users of the site to get their feedback on
single topics or questions; to poll for a response.
2.25.4 Assumptions
• Polls would be created by library staff and only occasionally appear on the main library page
2.26 Surveys
2.26.1 Description
The surveys functionality component allows content contributors to engage the users of the site to gather and
analyze data for multiple questions.
3. Anonymizes responses 1
6. Includes a survey building tool that allows content creators to easily generate surveys without code 1
2.26.4 Assumptions
• Use of the survey creation tool can be limited to a select number of users
2.27.1 Description
The chat functionality component allows users of the site to engage in text chat with other users. University of
Toronto Mississauga has an existing Jabber server that can be employed if needed.
1. Widget on any website that allows users to contact any specified account 1
2.27.4 Assumptions
• Drupal supports a variety of text chat options via an existing module; if it does not, that third party products
(including proprietary sources, ie, LivePerson) can be employed to support this objective
• Multiple drupal modules exist to support chat, both text and audio/video
2.28.1 Description
The discussion board functionality component allows users of the site to contribute to various discussion boards.
4. Ability to restrict access to discussion boards based on user role or course/program enrollment 1
5. Ability to easily remove all content from discussion boards after a certain date 2
10. Individual user’s posts can be moderated (not posted until approved by a moderator) 1
2.28.4 Assumptions
• A tool exists within Drupal that allows sites to support discussion boards
2.29.1 Description
The comments functionality component allows users of the site to leave comments on content posted on the website.
2. Ability to subscribe to a page in order to receive alerts about new comments (for the content creator 3
and users)
2.29.4 Assumptions
• Most of the time, content will be open to comments from the users.
• Drupal’s tools already permit content creators to choose when commenting functionality will and will not
be available
2.30.1 Description
The upload and share files functionality component allows users of the site to upload and share documents with a
group.
The upload and share files functionality component has the following requirements:
2.30.4 Assumptions
• This function may be built into other tools (ie, discussion board, etc.)
• There already exists a Drupal module that will support this functionality
2.31.1 Description
The wiki functionality component allows users of the site to collaboratively generate documents.
1. Versioning 1
4. Supports multiple instances; multiple groups using the functionality whose work does not bleed into 1
each other
6. Specific wikis can be kept private to only the participants (e.g., library staff) 1
2.31.4 Assumptions
• There is an existing Drupal wiki module that is robust enough to fill our requirements
• If there is no suitable wiki module, that there is a bridge between Drupal and another wiki product that will
allow us to support wiki functionality within our website
2.32.1 Description
The website annotation functionality component allows users of the site to make sophisticated comments on
websites produced by the library. (Assignment-related materials, readings, etc.)
2.32.4 Assumptions
• A tool exists to provide this kind of functionality within Drupal. We do not require custom work for this
functionality.
• This tool would be used experimentally; not crucial to the website launch
2.33.1 Description
The book reviews functionality component allows users of the site to add book/article/video reviews to the library’s
website.
2.33.4 Assumptions
• The University of Toronto does not buy LibraryThing for Libraries; if they do, we won’t need this function
• Book reviews would be primarily gathered through experimental assignments, and thus moderation would
be mostly built in
2.34.1 Description
The tagging / categories functionality component allows the content creators to classify their content with
keywords, and allows users of the site to find content based on those keywords.
3. Clicking a tag creates a search for all nodes with that tag 1
2.34.4 Assumptions
• Tags are built into Drupal and thus are easily available within any Drupal installation
2.35 Printer-Friendly
2.35.1 Description
A "printer friendly" version of the web page removes the navigation, header graphics, and utility menus to create a
printable format of page. A printer friendly page may also display a new header, change the styles of the page, and
have few or no graphics.
1. Content contributors must be provided the ability to insert the printer-friendly component on any 1
page
2. Pages must reference the print.css file when printing from the browser. Additionally, when a user 1
clicks on the component link on the page, the printer-friendly css is called.
3. Content contributors must be provided the ability to define the text or images of the printer-friendly 1
component
4. Content contributors must be provided the ability to define a printer-friendly component from within 1
the web publisher editor
2.35.4 Assumptions
• The designer knows how to provide this functionality as part of the overall design
2.36 Quizzes
2.36.1 Description
Patrons will be presented a series of questions with radio button, check box, or text box answer choices in a two
column structure. The answers will appear directly below the question in the first column. Each answer will have
associated feedback. Text boxes may only be used for calculations. As such the feedback associated to the text
boxes will be a range of values with feedback for each range. In the case of checkboxes and radio buttons answer
choices can range from one to many (for checkboxes) or one (for radio buttons). The user will read each question
and select or enter the answer that best answers the question for them. Users will be required to answer each
required question before proceeding to the next page of the quiz. The quiz will support branching. Once they have
completed the entire quiz the consumer is brought to an optional summary page containing the answers and answer
feedback they selected. The consumer can than print out the summary page. Note: An unchecked checkbox is
considered an answer.
Content contributors must be provided the ability to define required elements on the quiz 1
Content contributors must be provided the ability to define the order elements as the appear on the quiz 1
Content contributors must be provided the ability to specify instructions to be displayed at the top of the 1
quiz form from within the web publisher editor template.
Content contributors must be provided the ability to create a quiz with an unlimited number of
2
question/answers
Content contributors must be provided the ability to determine the next question displayed on the page
based on the answer provided to the previous question (branching)
3
Content contributors must be provided the ability to add/modify/delete questions and answers from
1
within the web publisher editor template.
Question and Answer are displayed in the first column; the answer feedback will appear in the second column
Once the consumer answers a question; the answer feedback appears in the second column. Different answer
feedback will appear in the second column based upon the answer selected in the first column.
If a consumer forgets to select an answer they are brought back to the quiz location where the error occurred. A
page error message is displayed along with an element error message. The consumer must correct the error before
proceeding in the quiz
2.36.5 Assumptions
• This functionality is supported by an existing Drupal module and requires no custom code.
2.37.1 Description
Using the RSS 2.0 syndication format, podcasts are made available to subscribers just like news feeds.
Content contributors must be provided the ability to insert the “Podcast” component on any page 1
Content contributors must be provided the ability to select the MP3 file. 1
Content contributors must be provided the ability to define the RSS feed. 1
2.37.4 Assumptions
• This functionality may be part of another tool or Drupal module, (e.g. Blogging tool)
2.38 Favourites
2.38.1 Description
Content contributors must be provided the ability to insert the “save this page to favourites” component 2
on any page
2.39.1 Description
Google analytics code embedded on each page created without any input from the user 1
2.40.1 Description
A box on the website that shows users whether or not key external systems are up or down.
4. Laptop availability (ex. 3 laptops currently available; 0 laptops available, next due at 1:15)