## 1.1 Purpose
The purpose of the software is to provide a new courseware system for the University of Puget Sound’s educational needs. The system is intended to facilitate electronic classroom management and provide for electronic grading, assignment submission, discussion, and other learning tools 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 software enhancements will add core functionality currently unavailable in the base Moodle system. The product will also include small redesigns for consistency with other university practices and a redesign of the user interface to reflect a more natural flow of data.

The goal of this product is to create a viable courseware solution for the University of Puget Sound that addresses current instructional and educational needs. The enhancements aim to improve the overall learning experience for students and help professors present material in new ways. All enhancements will utilize the existing APIs made available by Moodle.

### 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 of Puget Sound's current courseware system, Blackboard. The enhancements are intended to provide functionality that is currently unavailable in Moodle, redesign the user interface for consistency with other university practices, and create a more natural flow of data. These enhancements will be developed utilizing the existing APIs made available by Moodle.

#### System interfaces
The system's enhancements will interface with the Moodle courseware system using its available APIs.

#### User interfaces
The user interface will be redesigned to provide a simple, responsive experience and a more natural flow of data. A single, central administrative interface will be provided for administrators to configure the user interface, features, and themes across the entire system 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
The system is an enhancement to the Moodle courseware system. It will integrate other required software products, including a freely available wiki engine and a freely available blog engine. The search functionality may interface with an external web search engine like Google.

#### Communications interfaces
The system will provide interfaces for sending notifications to users via email and SMS. It will also provide web feeds, such as RSS 2.0, for various types of content.

#### Memory constraints
The system will allot equal and finite drive space 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, excluding scheduled maintenance windows. The system will be backed up on a configurable schedule, such as nightly. The system must be capable of restoring data from a backup within six hours.

#### Site adaptation requirements
The system will allow course administrators to configure features on a per-page basis. This includes enabling multiple file uploads, toggling web feed availability, and managing notifications for specific pages. A central administrative interface will allow for system-wide adaptation of themes and page layouts.

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

### 1.3.2 Product functions

The courseware system will provide the following major functions:

*   **File Management:** The system will allow users to upload and manage multiple files for course activities such as assignment submissions, forum posts, and wiki pages.
*   **Audio Recording:** The system will enable users to record, submit, and organize audio clips into a personal portfolio, primarily to support foreign language instruction.
*   **Content Syndication:** The system will provide web feeds (e.g., RSS) for various course components like forums, assignments, and announcements to notify users of new content.
*   **Search:** The system will feature a search utility to allow users to find content and pages within a course or across all their courses.
*   **Gradebook:** The system will include a gradebook for instructors to post grades, provide feedback on assignments, and maintain a history of grade changes.
*   **Collaborative Tools:** The system will integrate social networking and collaborative applications, including a wiki for collaborative document creation and a blog engine.
*   **Notifications:** The system will send email and SMS notifications to users about changes and updates to course content.

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

## 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.1 Functions

### 3.1.1 Multiple File Transfer
*   The system shall allow course administrators to configure individual pages to accept multiple file uploads.
*   Users shall be able to upload multiple files to pages where this feature is enabled.
*   The option to enable multiple file uploads shall be available during page creation and editing.

### 3.1.2 Audio Recording
*   The system shall allow users to capture and submit voice clips.
*   The system shall provide a personal portfolio for each user to store and organize their voice clips.
*   Users shall be able to preview a voice clip before it is saved to their portfolio.
*   Users shall be able to attach a saved voice clip from their portfolio to any page that permits file uploads.
*   Users shall be able to download their voice clips in MP3 format.
*   Users shall be able to select and delete clips from their portfolio.

### 3.1.3 Web Feeds
*   The system shall provide web feeds (e.g., RSS 2.0) for course content, including forum posts, assignment postings, announcements, and wiki alterations.
*   Course administrators shall have the ability to enable or disable web feeds on a per-page basis during page creation and editing.

### 3.1.4 Search
*   The system shall provide a search box on every page for logged-in users.
*   The system shall provide a dedicated search page that allows users to filter results by content type and search specific sections of the course system.
*   Search results shall be categorized by content type (e.g., Assignments, Wiki Pages, Forum Posts) and ranked by relevance.
*   When a user is within a specific course, the search shall default to that course with an option to search all of the user's courses.
*   When a user is not within a specific course, the search shall cover all of the user's courses, and the results shall be grouped by course.

### 3.1.5 Gradebook
*   Course administrators shall be able to enter grades for assignments based on points earned out of the total points possible.
*   Course administrators shall be able to attach feedback to a grade in the form of text or a file attachment.
*   The system shall display grade information, including individual assignment grades, averages, and the overall grade, only to the student to whom the grades belong and to the course administrator.
*   The system shall maintain a timestamped history of any changes made to a student's grade for an assignment.

### 3.1.6 Social Networking Applications
*   The system shall provide an integrated wiki where users can collaboratively create and edit documents using a simple markup language and link to other pages within the wiki.
*   The system shall provide an integrated blog engine that includes functionality for tagging, drafting posts, and commenting.

### 3.1.7 Notifications
*   The system shall be capable of sending notifications via both email and SMS for changes to course pages.
*   Course administrators shall be able to enable or disable notifications for each page. Notifications for announcements shall be enabled by default.
*   Students shall be able to subscribe to notifications for pages where they are not enabled by default.
*   Students shall be able to manage their notification subscriptions and select their preferred notification method (email or SMS) in their user preferences.

## 3.2 Performance requirements
The system should support at least 1000 concurrent users.

The system should be available 24 hours a day, 7 days a week. 99% up-time is considered sufficient to meet this requirement.

The system must have the ability and capacity to restore back-up data within six hours.

## 3.3 Usability requirements
The system must provide a simple, responsive, and easy-to-use interface. The underlying architecture should be transparent to administrators. The system must be configurable from a single, central administrative interface that allows administrators to configure the user interface and features in a way that reduces page clutter. This interface must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.

To improve navigation efficiency and reduce user frustration from requiring too many clicks for basic actions, the system must provide search functionality as an alternative to hierarchical navigation.
*   A search box shall be displayed on every page after a user has logged in. If the user is within a specific course, the search should default to that course with an option to search all courses.
*   A dedicated search page shall be provided, allowing users to filter results (such as forum posts or grades) and search specific sections of the system. Results should be displayed in categories based on relevance.

The system must provide accessible online documentation and help to minimize support calls.
*   Relevant, online documentation for users must be available and easily accessible from 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 system must store and manage information related to users, courses, and course activities.

*   **Types of information used by various functions:**
    *   User information, including roles (student, professor, course administrator).
    *   Course content, including pages, assignments, forum posts, wiki pages, and announcements.
    *   Files uploaded by users for assignments or other course activities.
    *   Audio recordings (voice clips) organized into a portfolio for each user.
    *   Configuration settings on a per-page basis for features like multiple file uploads, web feeds, and notifications.
    *   Gradebook data, including points earned, points possible, textual feedback, feedback attachments, and timestamps for modifications.
    *   A history of changes for each grade.
    *   Blog posts, including tags, drafts, and comments.
    *   User preferences for notifications (e.g., SMS or email).
    *   User subscriptions to notifications for specific pages.

*   **Frequency of use:**
    *   Data will be accessed and modified frequently, with peak usage expected during midterm and finals weeks.
    *   The database must support nightly backups to protect data that changes daily, such as assignment submissions.

*   **Accessing capabilities:**
    *   Users must be able to upload, manage, and delete their own files and audio clips.
    *   Students must be able to view their own grades and grade history.
    *   Course administrators must be able to post and modify grades for students in their courses.
    *   Users must be able to search course content.
    *   Users must be able to manage their notification preferences and subscriptions.

*   **Data entities and their relationships:**
    *   [N/A]

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

*   **Security:**
    *   A student's grade information must only be accessible to that student and the course administrator(s) for the relevant course.
    *   Authentication for integrated components like wikis and blogs must be shared with the main courseware system.

*   **Data retention requirements:**
    *   A user's portfolio of voice clips must be retained for the duration of their existence in the system to allow for tracking progress over multiple courses.
    *   A complete history of changes to a grade for a particular assignment must be maintained.
    *   The system must be backed up with a frequency that ensures course data is protected, such as on a nightly basis. Backup data must be restorable within six hours.

## 3.6 Design constraints
Any enhancements to the system must utilize the existing APIs made available by Moodle. Social networking components, such as wikis and blog engines, should be integrated from freely-available solutions.

## 3.7 Software system attributes
### Reliability
The system should support at least 1000 concurrent users, especially during peak usage times such as midterm and finals weeks.

### Availability
The system should be available 24 hours a day, 7 days a week, with an expectation of 99% uptime. This does not exclude scheduled downtime for maintenance.

The system must be backed up on a configurable schedule, with a nightly backup frequency to protect course and system data. The system must be capable of restoring back-up data within six hours.

### Security
The system must restrict access to a student's grade information. Only the student to whom the grades belong and the course administrator for that course shall be able to view the grades.

The system must maintain a history of grade changes for any given assignment. This history should include timestamps to allow for the review of modifications over time.

### Maintainability
The system must be maintainable without substantial modification and be mostly self-sustaining to simplify maintenance tasks and reduce the staff hours required for its upkeep.

### Portability
Voice clips must be downloadable in a format that is widely supported across different web browsers and operating systems, such as MPEG Audio (MP3).

A viewer for listening to audio clips within the system must be provided in a cross-platform language.

## 3.8 Supporting information
The following information provides context and background for the requirements specified in this document but is not considered part of the formal requirements themselves.

The primary problem to be solved is that the University's current courseware system is not providing the functionality that students and faculty need to encourage learning. The proposed enhancements to the Moodle system are intended to address these shortcomings. Specific problems identified include:
*   The inability of the foreign language department to capture and track student voice clips for oral homework over time.
*   Difficult navigation that requires too many clicks to complete basic actions, leading to user frustration.
*   Social and collaborative components that are not robust.
*   The lack of a system for SMS or email notifications about changes to course pages, such as new assignments or announcements.

The requirements detailed in this document are based on feedback gathered from stakeholder interviews with professors and students. The results of these interviews are summarized in the document `Moodle Requirements Brainstorming.pdf`.

To aid in development planning, requirements have been categorized according to the following priority definitions:
*   Priority 1 (Core): Core functionality.
*   Priority 2: Functionality not explicitly available today, but considered critical.
*   Priority 3: Considered very important to supplement critical functionality.
*   Priority 4: Considered valuable as a supplement to other functionality, but not critical.

Special packaging instructions for the code and media are [N/A].

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
*   **Simple and Centralized Administrative Interface**: Verification will be done by inspection. The system must demonstrate a single administrative interface for configuration, rather than individual links for editing each page. This interface must also allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.
*   **Efficient Navigation via Search**: [N/A]
*   **Online User Documentation and Help**: [N/A]

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

## 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]