# 1 Introduction
## 1.1 Purpose
The purpose of this document is to capture, in natural language and at a functional level, the description and requirements of a new courseware system for the University of Puget Sound’s educational needs. This is a functional description of those features required to address current instructional and educational requirements. It also describes nonfunctional requirements and other factors necessary to provide a complete and comprehensive description of the requirements for the software.

## 1.2 Scope
This document specifies the requirements for enhancements to the Moodle courseware system.

The software product is a set of enhancements to Moodle, which is being considered as a replacement for the University of Puget Sound's existing Blackboard courseware system.

The software enhancements will provide core functionality currently unavailable in Moodle, redesign certain features for consistency with university practices, and improve the user interface to reflect a more natural flow of data. The goal is to determine what any courseware system would need to qualify as a viable solution for the University and to implement some of the features that Moodle lacks but stakeholders find important.

The application of the software is to improve the overall learning experience of students at the University and help professors to make students aware of new ways of presenting material.

## 1.3 Product overview
### 1.3.1 Product perspective
The product is a set of enhancements to the Moodle courseware system. Moodle is being investigated as a potential replacement for the University's current courseware system, Blackboard. The enhancements described in this document are based on the assumption that Moodle will be adopted and that any enhancements will utilize the existing APIs made available by Moodle.

#### System interfaces
[N/A]

#### User interfaces
As far as possible, the system should provide a simple, responsive interface. The underlying architecture should be transparent to the administrators. The system should be configurable from a single source at a central administrative position, and should provide a central, easy-to-use interface that will allow administrators to configure the user interface and features in a way that reduces page clutter.

#### Hardware interfaces
[N/A]

#### Software interfaces
The enhancements will interface with the existing Moodle courseware system. All enhancements will utilize the existing APIs made available by Moodle.

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

#### Operations
The system is expected to be available during off-hours as well as business hours to support students and faculty. The system must support backup and recovery operations.

#### Site adaptation requirements
[N/A]

#### Interfaces with services
[N/A]

### 1.3.2 Product functions
The software will perform the following major functions:
*   Allow for the upload and management of multiple files for assignments, forums, and other pages.
*   Enable the recording, storage, and organization of audio clips into a user portfolio, primarily for foreign language courses.
*   Provide web feeds (e.g., RSS 2.0) for course updates, such as new forum posts, assignments, and announcements.
*   Implement a comprehensive search function to allow users to find course content, assignments, and other information quickly.
*   Provide a gradebook for course administrators to post and manage student grades and feedback for assignments submitted electronically.
*   Integrate social networking applications, such as a wiki for collaborative document creation and a blog engine for student and faculty use.
*   Deliver notifications to users via email and SMS for important course events and content changes.

### 1.3.3 User characteristics
*   **Students**: The primary consumers of the courseware system. They access information posted by professors, upload assignments and project files, and discuss concepts.
*   **Professors**: The primary content administrators of the courseware system. They upload files, links, and multimedia, and grade assignments in addition to creating new places for students to discuss and collaborate.
*   **System Administrators**: 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
All enhancements to the system are limited by the capabilities of the existing APIs made available by Moodle.

## 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
*   Moodle Requirements Brainstorming.pdf: This document was generated as a foundation for this document and contains the results of stakeholder interviews.

# 3 Requirements
## 3.1 Functions
### 3.1.1 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.).

*   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. Such a construct should be offered to the actor during a page’s creation and editing stages.

### 3.1.2 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.

*   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. 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.

### 3.1.3 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, wiki alterations and other blocks of information that an actor may view 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.).

*   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.

### 3.1.4 Search
The system must be able to use search functionality as a way to navigate Moodle pages instead of using hierarchical links. For this requirement, page refers to any distinct page, such as an assignment, a wiki page, or a forum post.

*   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.
*   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.

### 3.1.5 Gradebook
The system must allow actors in the capacity of course administrator to post grades associated with assignments for a particular actor in the capacity of student.

*   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 an actor in the role of 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.

### 3.1.6 Social Networking Applications
The system shall integrate freely-available social and collaborative solutions into Moodle.

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

### 3.1.7 Notifications
The system shall allow actors to receive SMS or email notifications of changes to Moodle pages.

*   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 actor in the role of 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, actors in the capacity of student 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 should support at least 1000 concurrent users.

## 3.3 Usability requirements
The system should provide a simple, responsive interface. The system should be configurable from a single source at a central administrative position, and should provide a central, easy-to-use interface that will allow administrators to configure the user interface and features in a way that reduces page clutter. A system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page.

Relevant, online documentation for users should be available on each page. Modifications should be reported via the main page to inform actors of unexpected changes.

System administrators must have access to comprehensive, searchable documentation. This documentation must cover all procedures necessary for regular maintenance with links to additional information, all common errors, and links or documentation for advanced troubleshooting.

## 3.5 Logical database requirements
*   The system must store and organize voice clips for each user in a portfolio.
*   The system must store grades for assignments, including feedback in the form of text or attachments.
*   The system must maintain a history of grade changes for each assignment, including timestamps for each modification.
*   The system must enforce data integrity such that a student can only view their own grades. A course administrator can view grades for all students in their course.
*   The system must support the backup and restoration of all course and system data.

## 3.6 Design constraints
Any enhancements to the system must utilize the existing APIs made available by Moodle.

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

### 3.7.2 Availability
The system should be available 24 hours a day, 7 days a week. This is intended to convey the expectation that customers should have access to the system during off-hours as well as business hours. It does not exclude maintenance windows or scheduled downtime. 99% up-time should be considered sufficient to meet this requirement.

### 3.7.3 Security
The system must protect the privacy of student grade information. The system should display grade information only to the actor to whom the grades belong. No other actor should be able to view another’s grades except an actor in the role of course administrator for the course to which the grades belong.

### 3.7.4 Maintainability
The system must be maintainable without substantial modification. Due to limited staff, it is important that the system be mostly self-sustaining to reduce the number of hours spent maintaining the system and to simplify maintenance tasks.

### 3.7.5 Portability
[N/A]

## 3.8 Supporting information
The requirements are based on stakeholder feedback which is summarized in the document `Moodle Requirements Brainstorming.pdf`.

Requirements have been categorized according to the following priority 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.

# 4 Verification
## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

# 5 Appendices
## 5.1 Assumptions and dependencies
*   The University of Puget Sound is currently seeking a new courseware system and is investigating Moodle as an option.
*   It is assumed that Moodle is of interest to the University as a viable choice to replace Blackboard.
*   It is assumed that Moodle will be adopted at the University of Puget Sound.
*   Any enhancements to the system will depend on the existing APIs made available by Moodle.

## 5.2 Acronyms and abbreviations
[N/A]