# 1 Introduction
[NULL]

## 1.1 Purpose
The purpose of this document is to capture the functional and nonfunctional requirements for a new courseware system for the University of Puget Sound’s educational needs. This system will provide the features required to address current instructional and educational requirements.

## 1.2 Scope
This document specifies the requirements for a set of enhancements to the Moodle courseware system. The application of this software is to provide a courseware system that addresses the current instructional and educational requirements of the University of Puget Sound.

The enhancements will add core functionality currently unavailable in Moodle, redesign the user interface to reflect a more natural flow of data, and incorporate small redesigns for consistency with other university practices. The primary goals are to improve the overall learning experience for students and help professors present material in new ways. All development will utilize the existing APIs made available by Moodle.

Consistency with higher-level specifications is [N/A].

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product described in this document is a set of enhancements to the Moodle courseware system. The University of Puget Sound is considering Moodle as a replacement for its existing Blackboard system. The goal of these enhancements is to add core functionality currently unavailable in Moodle and to redesign parts of the user interface for consistency with other university practices and to reflect a more natural flow of data. All enhancements will utilize the existing APIs made available by Moodle.

#### System interfaces
[N/A]

#### User interfaces
The system's user interface will be a redesign of the standard Moodle interface to provide a more natural flow of data. The system should provide a simple, responsive interface. It should be configurable from a single, central administrative interface that allows administrators to change themes and other settings affecting page layout across the entire system.

#### Hardware interfaces
[N/A]

#### Software interfaces
The system will interface with the Moodle courseware system via its existing APIs. The system will also integrate other freely available software products, including a wiki engine and a blog engine.

#### Communications interfaces
The system will provide interfaces for sending notifications to users via email and SMS.

#### Memory constraints
[N/A]

#### Operations
The system is expected to be available 24 hours a day, 7 days a week, excluding scheduled downtime for maintenance. The system must be backed up on a nightly basis, with the capacity to restore back-up data within six hours.

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

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

### 1.3.2 Product functions
The courseware system is designed to facilitate electronic classroom management. A summary of the major functions the software will perform includes:
*   **File Management:** Allow users to upload and manage single or multiple files for assignments, forums, and wikis.
*   **Audio Recording and Management:** Capture, store, and organize voice clips into a portfolio, primarily for foreign language courses. This includes downloading and deleting clips.
*   **Content Updates and Feeds:** Provide web feeds (e.g., RSS) for various course components like forums, assignments, and announcements to notify users of new content.
*   **Search:** Enable users to search for content within a course or across all their courses to improve navigation and information retrieval.
*   **Gradebook:** Allow course administrators to post, manage, and provide feedback on grades for assignments. Students can view their own grades and grade history.
*   **Collaboration Tools:** Integrate social and collaborative components such as wikis for document creation and blogs for communication.
*   **Notifications:** Send users email or SMS notifications about changes to course pages, such as new assignments or announcements.

### 1.3.3 User characteristics
The intended users of the courseware system fall into three main groups:

*   **Students**: The primary consumers of the system. Their main activities include accessing course information posted by professors, uploading assignments and project files, and participating in online discussions.
*   **Professors**: The primary content administrators for their courses. Their main activities include uploading educational materials (files, links, multimedia), creating and grading assignments, and setting up spaces for student discussion and collaboration.
*   **System Administrators**: Responsible for the overall maintenance of the courseware system. Their activities focus on modifying the system's configuration and applying updates, with minimal direct contribution to course content.

### 1.3.4 Limitations
*   All enhancements must be developed for the Moodle platform.
*   Any enhancements to the system are limited to using 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.

## 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 SRS and contains the results of stakeholder interviews.
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: [N/A]
    *   Source: [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
### 3.1.1 Multiple File Transfer

The system must be able to capture and manage files. One of the fundamental tasks of the system is to allow actors to upload and manage files on pages such as assignment submissions, forums, wikis, and announcements.

An actor in the role of course administrator must be able to optionally enable multiple file uploads on a per-page basis. For this requirement, page refers to any distinct upload point (e.g., an assignment, a wiki page, a forum post, etc.). This option should be offered to the course administrator during a page’s creation and editing stages.

### 3.1.2 Audio Recording

The system must be able to capture and organize voice clips. This function is required to allow the foreign language department to capture and track voice clips recorded by students for oral homework over the course of a student’s education.

*   **Portfolio Management**: The system must allow actors to organize their voice clips into a portfolio.
    *   Drive space shall be allotted to each professor or administrator for storing student voice clips, and they shall be able to partition this space for students.
    *   The system shall support two methods for archiving a submitted voice clip: manual archiving after a preview, or automatic archiving. The professor should have the option to select the method.
    *   Actors shall be able to optionally attach an archived voice clip to any page where uploads are permitted.
*   **Downloading Clips**: The system must allow actors to download their voice clips in a flexible format, such as MPEG Audio (mp3), for archival or presentation purposes.
*   **Storage Format**: The system must store audio clips in a format optimized for speech. Recordings should only be converted to MPEG Audio (mp3) format when they are being downloaded. A separate viewer should be provided for listening to clips within the system.
*   **Deleting Clips**: The system must allow actors to delete recorded clips from their portfolio to manage their archived voice clips.

### 3.1.3 Web Feeds

The system must be able to display web feeds, such as RSS 2.0, for pages where content is added, such as forum posts, assignment postings, announcements, and wiki alterations.

Course administrators must have the ability to determine which components have feeds. They must also be able to turn web feeds on or off on a per-page basis during the creation and editing of a page. For this requirement, page refers to any distinct block (e.g., assignments, wikis, forum threads, etc.).

### 3.1.4 Search

The system must provide search functionality as a way to navigate pages. For this requirement, page refers to any distinct page, such as an assignment, a wiki page, or a forum post.

*   **Course Search**: An actor must be able to search through pages at the course level. A dedicated search page shall be provided that allows an actor to filter results (such as forum posts or grades) and search specific sections of the system. Results should appear in categories (e.g., Assignments, Wiki Pages, Forum Posts, etc.) based on relevance, which is determined by the number of matching search terms. Clicking a search result link shall take the user to the corresponding page.
*   **Global Search Box**: The system must display a search box on every page after an actor has logged in. If the actor is outside of a particular course, each of their courses should be searched and results should be grouped by course. If the actor is inside of a course, that course should be searched by default, with an option to search all courses.

### 3.1.5 Gradebook

The system must allow a course administrator to post grades associated with assignments for a student.

*   **Grading Assignments**: A course administrator must be able to grade an assignment by posting points earned out of points possible. The course administrator must also be able to attach feedback in the form of text or an attachment. Timestamps must be attached to the last modification of the grade.
*   **Displaying Grades**: The system must display grade information, such as the grade for each assignment, averages, and overall grade, only to the student to whom the grades belong and to the course administrator for that course.
*   **Grade History**: The system must maintain a history of grades for an assignment if the course administrator changes them.

### 3.1.6 Social Networking Applications

The system shall integrate freely-available solutions for social and collaborative components.

*   **Wiki**: The system must provide a wiki where actors can collaboratively create networks of documents. The wiki must provide a simple markup language for styling input and linking to other pages in the wiki.
*   **Blog**: The system must provide a blog engine with modern blog functionality, such as tagging, drafting, and comments. The blogs must share authentication and notification with the main system.

### 3.1.7 Notifications

The system must provide both e-mail and SMS notifications for changes to pages, such as assignments or announcements. 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 must be able to toggle whether notifications are turned on. By default, notifications shall be turned on for announcements. If notifications are turned off by the administrator, students must still be able to subscribe to them. Students must be able to select in their preferences whether notifications are sent via SMS or e-mail and must be able to manage their notification subscriptions.

### 3.1.8 On-line User Documentation and Help System

*   **User Documentation**: Relevant, online documentation for users must be available on each page. Modifications to the system must be reported via the main page to inform actors of unexpected changes.
*   **Administrator Documentation**: System administrators must have access to comprehensive, searchable documentation. This documentation must cover all procedures for regular maintenance, common errors, and advanced troubleshooting. Search results must be displayed based on relevance.

## 3.2 Performance requirements
*   The system shall support at least 1,000 concurrent users, particularly during peak load times such as midterm and finals weeks.
*   The system shall be available 24 hours a day, 7 days a week, with 99% uptime being sufficient. This does not exclude scheduled maintenance windows.
*   The system must be able to restore back-up data within six hours.

## 3.3 Usability requirements
The system must provide search functionality as a way to navigate pages instead of using hierarchical links. This is intended to reduce the number of clicks required to complete basic actions and reduce user frustration.

*   An actor must be able to search through pages in a course.
*   A search box must be displayed on every page after an actor has logged in.
*   A single page must be dedicated to searching, allowing an actor to filter results and search specific sections of the system.

As far as possible, the system should 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. A system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page.
*   The administrative interface must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.

Users must have easy access to help while interacting with the system.

*   Relevant, online documentation for users should be available on each page.
*   System administrators must have access to comprehensive, searchable documentation covering regular maintenance procedures, common errors, and advanced troubleshooting.

## 3.5 Logical database requirements
The following logical requirements apply to information stored by the system:

*   **Types of information used by various functions**
    *   Gradebook: The system shall store grades for assignments, including points earned, points possible, textual feedback, file attachments for feedback, and timestamps for the last modification.
    *   Audio Recording: The system shall store metadata for student voice clips, organizing them into a portfolio associated with each student.
    *   Social Networking: The system shall store content for wikis and blogs, including page content, links, blog tags, drafts, and comments.

*   **Frequency of use**
    *   [N/A]

*   **Accessing capabilities**
    *   Students shall be able to view their own grades, averages, and overall grade.
    *   Course administrators shall be able to post and modify grades for students in their courses.
    *   Students shall be able to organize, download, and delete voice clips from their personal portfolio.

*   **Data entities and their relationships**
    *   A grade shall be associated with a single student and a single assignment.
    *   A history of changes, with associated timestamps, shall be associated with each grade.
    *   A voice clip shall be associated with the student who recorded it and belong to that student's portfolio.

*   **Integrity constraints**
    *   [N/A]

*   **Security**
    *   A student's grade information shall only be accessible to that student and the course administrator(s) of the corresponding course.

*   **Data retention requirements**
    *   The system shall maintain a history of grades for an assignment if a course administrator changes them.
    *   Voice clips shall be stored in a student's portfolio for the duration of the student's existence in the system to allow for tracking improvement over time.
    *   The system database shall be backed up on a configurable schedule, such as nightly, to ensure data is protected. The system must support restoring backed-up data within six hours.

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

## 3.7 Software system attributes
### Reliability
[N/A]

### Availability
The system should be available 24 hours a day, 7 days a week. This excludes scheduled downtime for maintenance. An uptime of 99% is considered sufficient.

The system must be backed up on a configurable schedule. To protect system and course data, backups should occur on a nightly basis, with options for weekly, off-site backups. The system must be able to restore back-up data within six hours.

### Security
The system must ensure that a student's grade information is only viewable by that student and the course administrator for the course to which the grades belong.

The system must maintain a history of grades for an assignment if they are changed by a course administrator. Timestamps should be associated with each change.

### Maintainability
The system must be maintainable without substantial modification to reduce the staff hours required for maintenance tasks.

Comprehensive, searchable documentation for system administrators must be provided. This documentation must cover all procedures for regular maintenance, common errors, and advanced troubleshooting.

### Portability
[N/A]

## 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. The goal is to refine a courseware system, Moodle, to provide functionality that improves the overall learning experience and helps professors present material in new ways. The requirements specified in this document are based on feedback gathered from interviews with system stakeholders (professors and students). The results of these interviews are summarized in the referenced document *Moodle Requirements Brainstorming.pdf*.

The requirements have been categorized according to the following priority definitions to aid in development planning:
*   **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.

This is a working document and is subject to change. Requirements may be modified and additional requirements may be added as development progresses and the system description becomes more distilled.

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
*   Verification of the simple, responsive interface requirement: 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 of on-line user documentation and help system requirements: [N/A]
*   Verification of search functionality 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
[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 viable choice to replace the existing Blackboard courseware system.
*   It is assumed that any enhancements to the system will be built upon the Moodle platform.
*   It is assumed that the development of these enhancements will utilize the existing APIs made available by Moodle.

## 5.2 Acronyms and abbreviations
[N/A]
