# 1 Introduction
[NULL]

## 1.1 Purpose
The purpose of this document is to specify the requirements for a new courseware system for the University of Puget Sound’s educational needs. This specification includes a functional description of the features required to address current instructional and educational requirements, as well as nonfunctional requirements necessary to provide a complete and comprehensive description of the software.

## 1.2 Scope
This document specifies the requirements for a set of enhancements to the Moodle courseware system for the University of Puget Sound.

The software enhancements will provide core functionality currently unavailable in the base Moodle system. This includes redesigning parts of the user interface to create a more natural flow of data and to ensure consistency with other university practices. All enhancements will utilize the existing APIs made available by Moodle.

The application of this software is to create a courseware system that addresses the current instructional and educational needs of the University. The primary goal is to implement features that stakeholders find important, thereby improving the overall learning experience for students and providing professors with better tools. The objective is to determine if an enhanced Moodle system can serve as a viable replacement for the University's existing courseware system.

These requirements are consistent with and derived from stakeholder interviews, the results of which are summarized in the `Moodle Requirements Brainstorming.pdf` document.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product is a set of enhancements to the Moodle courseware system. Moodle is being investigated by the University of Puget Sound as a potential replacement for its existing Blackboard courseware system. The enhancements described in this document are intended to add core functionality currently unavailable in Moodle and to redesign parts of the user interface for consistency with other university practices and a more natural flow of data.

#### System interfaces
[N/A]

#### User interfaces
The system's user interface will be redesigned to provide a more natural flow of data. It will provide a central, easy-to-use interface for administrators to configure the user interface and features, such as changing themes and page layouts, to reduce page clutter. A search box will be displayed on every page after a user has logged in.

#### Hardware interfaces
[N/A]

#### Software interfaces
All enhancements to the system will utilize the existing APIs made available by Moodle. The system will also integrate other freely-available software products, including a wiki engine and a blog engine, which will share authentication and notification features with Moodle.

#### Communications interfaces
The system will provide notifications to users via email and SMS. It will also provide web feeds, such as RSS 2.0, for pages containing elements like forum posts, assignment postings, and announcements.

#### Memory constraints
Finite drive space will be allotted to each professor or administrator for the purpose of storing voice clips recorded and submitted by students.

#### Operations
The system is expected to be available 24 hours a day, 7 days a week, allowing for scheduled maintenance windows. A 99% uptime is considered sufficient. The system must be backed up on a nightly basis, and it must be possible to restore backup data within six hours.

#### Site adaptation requirements
The system must be configurable from a single, central administrative interface. This interface must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.

#### Interfaces with services
The system's search page may interface with a standard external search engine, such as Google, to provide the ability to search the world wide web.

### 1.3.2 Product functions
The courseware system is designed to facilitate electronic classroom management and provide tools for electronic grading, assignment submission, discussion, and learning. A summary of the major functions includes:

*   **File Management:** The system will allow users to upload and manage multiple files for assignments, forums, wikis, and other course pages.
*   **Audio Recording and Management:** The system will provide functionality for users to record, store in a portfolio, organize, and download voice clips.
*   **Content Syndication:** The system will generate and display web feeds (e.g., RSS 2.0) for various course components such as forum posts, assignments, and announcements.
*   **Search:** The system will provide a search utility to allow users to find pages and content within a specific course or across all their courses.
*   **Gradebook:** The system will include a gradebook for course administrators to post and manage grades, provide feedback, and maintain a grade history. Students will be able to view their own grades.
*   **Collaboration Tools:** The system will integrate social networking and collaborative applications, including a wiki for document creation and a blog engine.
*   **Notifications:** The system will send email and SMS notifications to users regarding changes and updates to course content, such as new assignments or announcements.

### 1.3.3 User characteristics
*   **Students**: Students are the primary consumers of a courseware system. They are accessing information posted by professors, uploading assignments and project files, and discussing concepts.
*   **Professors**: Professors are the primary content administrators of a courseware system. They are uploading files, links, and multimedia, and grading assignments in addition to creating new places for students to discuss and collaborate.
*   **System Administrators**: System administrators are primarily responsible for maintaining the courseware system. They contribute minimally to the courses themselves, but spend more time modifying the system’s configuration and making appropriate updates.

### 1.3.4 Limitations
Any enhancements to the system must utilize the existing APIs made available by Moodle.

Due to limited staff in the Office of Information Services, the system must be mostly self-sustaining and maintainable without substantial modification.

The system is not required to be highly available. 99% uptime is considered sufficient and does not exclude maintenance windows or scheduled downtime.

## 1.4 Definitions
*   **Actor**: Synonymous with user and is used to describe users who are performing actions in use cases.
*   **Course Administrator**: An actor who is acting as a professor or system administrator and who has the ability to manage courses and course pages.
*   **Courseware System**: A piece of software meant to help facilitate electronic classroom management and provide for electronic grading, assignment submission, discussion, and other learning tools.
*   **System**: Refers to the existing courseware system, a new courseware system, or any modifications being made to Moodle while it is being considered as a replacement for the existing courseware system.

# 2 References
## Guidance
*   **Title:** Moodle Requirements Brainstorming.pdf
*   **Report Number:** [N/A]
*   **Date:** [N/A]
*   **Publishing Organization:** [N/A]
*   **Source:** [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
The priorities defined below reflect the requirements of the development team. The goal was to define those requirements that describe the core functionality required to support and facilitate diverse methods of teaching at the University of Puget Sound. Requirements have been categorized according to the following definitions:

*   Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.
*   Priority 2: Functionality not explicitly available today, but considered critical to implementing a courseware system at the University.
*   Priority 3: Just barely outside the parameters of Priority 2; considered very important to supplement critical functionality.
*   Priority 4: Outside the parameters of Priority 2; considered valuable as a supplement to other functionality, but not critical.

The initial production release of the University of Puget Sound’s enhancements to Moodle will deliver the Priority 1 (Core) and Priority 2 set of requirements, along with such Priority 3 requirements as can be developed within the project timeframe and budget constraints.

### Multiple File Transfer
The system must be able to capture and manage files where appropriate. One of the fundamental tasks of the system is to allow actors to upload and manage files on certain pages of the system. These might include assignment submission pages, forum pages, wiki pages, and announcement pages. An actor in the role of course administrator should be able to optionally upload multiple files where he or she finds that such as feature would be useful—such as on a devoted project page. For this requirement, page refers to any distinct upload point (e.g., an assignment, a wiki page, a forum post, etc.). Priority: 2.

*   The system must allow for multiple file upload to be configured on a per-page basis. Actors in the capacity of course administrator or professor should be able to enable multiple file uploads on a page of his or her choosing. For collaborative projects, it becomes important for actors to be able to upload more than one file to a given page, especially in the case of an assignment submission where the assignment might include multiple parts. Such a construct should be offered to the actor during a page’s creation and editing stages.

### Audio Recording
The system must be able to capture and organize voice clips that can be used where appropriate. One of the shortcomings of the current courseware system is that the foreign language department is unable to capture and track voice clips—recorded by students—for oral homework over the course of a student’s education. Priority: 2.

*   The system must allow actors to organize their voice clips into a portfolio. Equal and finite drive space needs to be allotted to each actor in the role of professor or administrator to allow for the storing of voice clips recorded and submitted by all actors in the roles of students. Actors in the role of professor or system administrator should be allowed to partition this space for actors in the roles of students. The actor should have the option to have the voice clip be archived after a preview has taken place. The actor should be able to optionally attach one of his or her archived items to any page where uploads are permitted.
*   The system must allow actors to download their voice clips in a flexible format. Voice clips should be optionally downloadable in a format such as MPEG Audio (mp3) format.
*   The system must store audio clips in a format conducive to speech. Voice clips should be stored in a format optimized for speech. Recordings should only be converted to MPEG Audio (mp3) format when they are being downloaded.
*   The system must allow actors to delete recorded clips. An actor should be able to examine his or her portfolio to select and delete clips if he or she chooses to.

### Web Feeds
The system must be able to display web feeds, such as RSS 2.0 feeds, for all pages of the course management system where elements such as forum posts, assignment postings, announcements, and wiki alterations are added. Actors in the role of course administrators should have the ability to determine which of these components have feeds and to whom these feeds should pertain. For this requirement, page refers to any distinct block (e.g., assignments, wikis, forum threads, etc.). Priority: 1.

*   The system must allow web feeds to be turned on or off on a per-page basis. During the creation and editing of a page, an actor in the course administrator role should be able to toggle web feed availability.

### Search
The system must be able to use search functionality as a way to navigate pages instead of using hierarchical links. A search utility enables actors to find what they are looking for quickly. For this requirement, page refers to any distinct page, such as an assignment, a wiki page, or a forum post. Priority: 2.

*   An actor must be able to search through pages in a course. A single page should be dedicated specifically to the task of searching the course management system. This page should allow an actor to filter out certain results and search specific sections of the course management system. Results should appear in categories based on relevance. When the actor clicks a search result link, they should be taken to the page corresponding to the search result.
*   The system must display a search box on every page after an actor has logged in. If the actor is hierarchically outside of a particular course, each of his or her courses should be searched and results should be grouped by course. If the actor is hierarchically inside of a course, that course should be searched with an option to search all courses.

### Gradebook
The system must allow actors in the capacity of course administrator to post grades associated with assignments for a particular student. Actors in the role of professor may want to optionally grade assignments online since they are being submitted electronically. Priority: 1.

*   A course administrator must be able to grade an assignment. Course administrators should be able to post grades for an assignment based on the ratio of points earned to points possible. The course administrator should also be able to attach feedback in the form of text or an attachment. Time stamps should be attached to the last time the grade was modified.
*   The system should display grade information to the appropriate actor. The system should display grade information such as the grade for each assignment, averages, and overall grade to the actor to whom the grades belong. No other actor should be able to view another’s grades except a course administrator for the course to which the grades belong.
*   The system should maintain a grade history. The system should maintain a history of grades for a particular assignment if the course administrator changes them.

### Social Networking Applications
The system should integrate freely-available social and collaborative solutions to provide the best functionality possible for all actors without having to use 3rd party services. Priority: 3.

*   The system must provide a wiki where actors can collaboratively create networks of documents. The wiki should provide a simple markup language that actors can use to style their input and link to other pages in the wiki.
*   The system must provide a blog engine. The blog engine should provide all modern blog functionality, such as tagging, drafting, and comments. These blogs should share authentication and notification with the main system.

### Notifications
The system must allow actors to receive SMS or email notifications of changes to pages such as assignments or announcements. Priority: 3.

*   The system must provide both e-mail and SMS notifications for pages. For this requirement, page refers to any distinct page (e.g., an assignment, a wiki page, a forum post, etc.). When a page is created, the course administrator should be able to toggle whether notifications are turned on. By default, they should be turned on for announcements. If notifications are turned off, students should be able to subscribe to notifications. Students should be able to select in their preferences whether notifications are sent to their mobile telephone (via SMS) or e-mail account. They should also be able to manage their notification subscriptions.

## 3.2 Performance requirements
*   The system shall support at least 1000 concurrent users.
*   The system shall be available 24 hours a day, 7 days a week, with a minimum of 99% uptime. This does not include scheduled downtime for maintenance.
*   The system shall be capable of restoring backed-up data within six hours.

## 3.3 Usability requirements
The system must provide a simple, responsive interface. The underlying architecture should be transparent to administrators. The system must be configurable from a single, central, easy-to-use administrative interface that allows administrators to configure the user interface and features in a way that reduces page clutter.

The system must provide search functionality as a way to navigate pages, reducing the number of clicks required to complete basic actions and minimizing user frustration.
*   A search box must be displayed on every page after an actor has logged in.
*   A dedicated search page must be available that allows an actor to filter results and search specific sections of the system.

Users must have easy access to help while interacting with the system.
*   Relevant, online documentation for users must be available on each page.
*   System administrators must have access to comprehensive, searchable documentation covering maintenance tasks, common errors, and troubleshooting.

## 3.5 Logical database requirements
The following types of information will be stored and managed by the system:
*   User and course information.
*   Files uploaded by users for assignments, forums, wikis, and announcements.
*   Configuration settings on a per-page basis for features like multiple file uploads, web feeds, and notifications.
*   Audio voice clips, organized into a portfolio for each user.
*   Content for wikis and blogs, including posts, comments, tags, and drafts.
*   Indexed content from all pages to support search functionality.
*   Gradebook information, including grades, textual feedback, timestamps of modifications, and a complete history of grade changes for each assignment.
*   User preferences for notifications, including delivery method (email or SMS) and subscription status for various pages.

The system must be capable of handling high-frequency access, particularly during peak academic periods such as midterm and finals weeks. Data will be written frequently, as evidenced by the requirement for nightly backups.

Accessing capabilities for data are as follows:
*   Users must be able to upload, download, and manage files and audio clips.
*   Course administrators must be able to create, update, and delete course content, including grades and feedback.
*   Students must be able to view their own grades and grade history.
*   All users must be able to search course content and manage their notification preferences.

Key data entities include Actors (users), Courses, and Pages (e.g., assignments, wiki pages, forum posts). Grades are associated with a specific Actor and a specific Page. Audio clips are associated with an Actor and organized into a portfolio.

[N/A]

The system must enforce strict access control on sensitive information. A user must only be able to view their own grades. A course administrator must only be able to view and manage grades for courses they administer.

The system must retain certain data for specific periods:
*   A history of all changes to a grade for a particular assignment must be maintained.
*   Audio clips must be retained in a user's portfolio for the duration of their existence in the system to allow for comparison across multiple courses.
*   All system and course data must be backed up on a nightly basis, with the ability to restore from a backup within six hours. Options for weekly, off-site backups must also be available.

## 3.6 Design constraints
*   Any enhancements to the system must utilize the existing APIs made available by Moodle.
*   The system must be maintainable without substantial modification due to limited staff in the Office of Information Services.

## 3.7 Software system attributes
### Reliability
The system must be backed up on a configurable schedule. Backups should be performed with a frequency that ensures system and course data is protected, such as on a nightly basis, with options for weekly, off-site backup. The system must be able to restore back-up data within six hours.

### Availability
The system should be available 24 hours a day, 7 days a week. This does not exclude scheduled maintenance windows. A 99% uptime is considered sufficient.

### Security
The system must protect student privacy. A student's grade information must only be viewable by that student and the course administrator for the course to which the grades belong.

### Maintainability
The system must be maintainable without substantial modification and be mostly self-sustaining to reduce the number of hours spent on maintenance tasks.

### Portability
The system should use cross-platform and widely supported technologies. For example, voice clips should be downloadable in a format such as MP3 that is supported across different web browsers and operating systems. Any custom viewer provided by the system should be implemented in a cross-platform language.

## 3.8 Supporting information
The University of Puget Sound does not believe that its current courseware system, Blackboard, is providing the functionality that students and faculty need to encourage learning. To determine what enhancements were needed, system stakeholders such as professors and students were interviewed to identify what was lacking in the existing solution. The requirements in this document are based on that feedback.

This is a working document and is subject to change. It will require continuing refinement, and requirements may be modified or added as development progresses. This document forms the basis for continuing discussions with stakeholders and sponsors.

The requirements have been categorized according to the following priority definitions. This information is provided for context and is not part of the requirements themselves.

*   Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.
*   Priority 2: Functionality not explicitly available today, but considered critical to implementing a courseware system at the University.
*   Priority 3: Just barely outside the parameters of Priority 2; considered very important to supplement critical functionality.
*   Priority 4: Outside the parameters of Priority 2; considered valuable as a supplement to other functionality, but not critical.

The initial production release will deliver the Priority 1 (Core) and Priority 2 requirements, along with such Priority 3 requirements as can be developed within the project timeframe and budget constraints.

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
The simple and responsive interface requirement will be verified by inspection. A system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page. Furthermore, this interface must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.

Verification methods for the following usability requirements are not specified in the original document:

*   Relevant, online documentation for users should be available on each page.
*   System administrators must have access to comprehensive, searchable documentation.

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
*   The requirements are based on the assumption that Moodle will be adopted at the University of Puget Sound as a replacement for the current courseware system.
*   It is assumed that any enhancements to the system will utilize the existing APIs made available by Moodle.
*   The requirements are dependent on the feedback gathered from stakeholder interviews with professors and students.
*   The supportability requirements are influenced by the limited staff resources available in the Office of Information Services.

## 5.2 Acronyms and abbreviations
[N/A]
