# 1 Introduction
[NULL]

## 1.1 Purpose
The purpose of the software is to enhance the Moodle courseware system to better meet the University of Puget Sound's educational needs. It aims to refine Moodle's functionality to improve the overall learning experience for students and help professors present material in new ways. These enhancements will embody redesigns for consistency with other university practices and a redesigned user interface to reflect a more natural flow of data. The system will facilitate electronic classroom management, electronic grading, assignment submission, discussion, and other learning tools.

## 1.2 Scope
This document specifies the requirements for the University of Puget Sound's Moodle Enhancements, a software product aimed at augmenting the Moodle courseware system. The enhancements will focus on developing core functionality currently unavailable in Moodle, redesigning certain aspects for consistency with other university practices, and improving the user interface to facilitate a more natural flow of data.

The primary application of this software is to provide a viable courseware solution for the University of Puget Sound, addressing current instructional and educational requirements that are not met by the existing system, Blackboard. The objective is to refine Moodle to improve the overall learning experience for students and empower professors with new methods for presenting educational material. This initiative seeks to implement features deemed important by stakeholders that are currently lacking in Moodle, with the broader goal of fostering a new learning experience and contributing to the Moodle platform.

These requirements are based on the assumption that Moodle will be adopted by the University of Puget Sound, and that any enhancements will leverage Moodle's existing APIs. While Moodle is being investigated as a potential replacement for Blackboard, the University's final choice of courseware system is not definitively Moodle.

[N/A]

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product described in this SRS is a set of enhancements to Moodle, which serves as the existing courseware system for the University of Puget Sound. These enhancements are designed to integrate directly with Moodle, leveraging its existing APIs to extend its core functionality and improve the overall learning experience for students and professors. The new system will embody redesigns for consistency with university practices and a more natural user interface flow, operating as an integral part of the larger Moodle ecosystem.

#### System interfaces
The system will interface with the existing Moodle courseware system through its available APIs.

#### User interfaces
The system will provide a redesigned user interface to reflect a more natural flow of data. It should provide a simple, responsive interface and a single administrative interface to configure the user interface and features, reducing page clutter. This interface must allow administrators to easily change themes and other settings affecting page layout across the entire courseware system.

#### Hardware interfaces
[N/A]

#### Software interfaces
The system will interface with the Moodle platform, utilizing its existing APIs.
The system will integrate with freely available wiki and blog engines to provide social networking functionality. These integrated components should share authentication and notification with Moodle.
Voice clips should be optionally downloadable in MPEG Audio (mp3) format. A separate viewer should be provided in a cross-platform language for listening to clips in Moodle.

#### Communications interfaces
The system must provide both e-mail and SMS notifications for changes to pages.
The system must be able to display web feeds, such as RSS 2.0 feeds, for all pages where elements are added.
Voice clips should be downloadable in MPEG Audio (mp3) format, which is widely supported across different web browsers and operating systems.

#### Memory constraints
Equal and finite drive space needs to be allotted to each actor in the role of professor or administrator for storing voice clips.
The system must have the ability and capacity to restore back-up data within six hours.

#### Operations
The system should be backed up on a configurable schedule, with assignments submitted via the system backed up nightly, and options for weekly, off-site backup.
The system must have the ability and capacity to restore back-up data within six hours.
The system should be available 24 hours a day, 7 days a week, allowing for maintenance windows or scheduled downtime, with 99% uptime considered sufficient.

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

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

### 1.3.2 Product functions
The software will perform the following major functions:

*   **Course Content Management**: Enable professors to upload and manage various types of course content, including files, links, and multimedia. This includes the ability to configure multiple file uploads on a per-page basis for assignments, forums, wikis, and announcements.
*   **Assignment Submission and Management**: Facilitate electronic submission of assignments by students and allow professors to manage these submissions.
*   **Collaborative Learning Tools**: Provide tools for student collaboration, including a wiki for collaborative document creation and a blog engine with features such as tagging, drafting, and comments.
*   **Electronic Grading**: Allow course administrators to post, manage, and maintain a history of grades for assignments, including feedback and timestamps. It will also display grade information (individual grades, averages, overall grade) to students.
*   **Communication and Notification**: Support communication through forums and announcements, and provide web feeds (e.g., RSS 2.0) for new content. It will also offer email and SMS notifications for changes to course pages, with options for students to subscribe and manage their preferences.
*   **Multimedia Integration**: Enable the capture, organization, and management of audio recordings (voice clips) for educational purposes, particularly for language learning. This includes allowing students to create and manage a portfolio of voice clips, download them in flexible formats, and delete recorded clips.
*   **Enhanced Navigation and Search**: Improve user navigation within the courseware system through comprehensive search functionality across courses and pages, including a search box displayed on every page after login.
*   **User Interface Redesign**: Offer a redesigned user interface to enhance the overall learning experience and provide a more natural flow of data.

### 1.3.3 User characteristics
The intended users of the courseware system include:

*   **Students**: These are the primary consumers of the system. They access information posted by professors, upload assignments and project files, and participate in discussions.
*   **Professors**: These are the primary content administrators of the system. They upload files, links, and multimedia, grade assignments, and create new spaces for student discussion and collaboration.
*   **System Administrators**: These users 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
The following items limit the supplier's options for the courseware system:

*   **Integration with Moodle**: Any enhancements to the system must utilize the existing APIs made available by Moodle.
*   **Usability**: The system should provide a simple, responsive interface and be configurable from a single source at a central administrative position.
*   **Reliability**:
    *   The system must be backed up on a configurable schedule, with nightly backups for assignment data and options for weekly off-site backup.
    *   The system must have the ability and capacity to restore backup data within six hours.
    *   The system should be available 24 hours a day, 7 days a week, with 99% uptime.
*   **Performance**: The system should support at least 1000 concurrent users, especially during peak times like midterm and finals weeks.
*   **Supportability**: The system must be maintainable without substantial modification and be mostly self-sustaining due to limited staff in the Office of Information Services.

## 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
## 2.1 Compliance
[N/A]

## 2.2 Guidance
- **Moodle Requirements Brainstorming.pdf**
    - Description: This document contains the results of stakeholder interviews and feedback that served as a foundation for the requirements in this SRS.
    - Report Number: [N/A]
    - Date: [N/A]
    - Publishing Organization: [N/A]
    - Source: [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
### Multiple File Transfer

The system must be able to capture and manage files. Actors must be able to upload and manage files on specific pages, including assignment submission pages, forum pages, wiki pages, and announcement pages.

*   **Multiple File Upload Configuration:**
    *   The system must allow actors in the role of course administrator or professor to enable multiple file uploads on a per-page basis.
    *   This configuration option must be available during a page's creation and editing stages.

### Audio Recording

The system must be able to capture and organize voice clips for use where appropriate, specifically to support the foreign language department in capturing and tracking student-recorded voice clips for oral homework.

*   **Voice Clip Portfolio Management:**
    *   The system must allow actors to organize their voice clips into a portfolio.
    *   Equal and finite drive space must be allotted to each actor in the role of professor or administrator for storing student voice clips.
    *   Actors in the role of professor or system administrator must be able to partition this space for students.
    *   Actors must have the option to preview a voice clip before it is archived and determine whether to archive it, or newly created voice clips can be automatically archived.
    *   Actors must be able to optionally attach one of their archived voice clips to any page where uploads are permitted.
*   **Voice Clip Download:**
    *   The system must allow actors to download their voice clips in a flexible format, such as MPEG Audio (mp3).
*   **Voice Clip Storage Format:**
    *   The system must store audio clips in a format optimized for speech.
    *   Voice clips should only be converted to MPEG Audio (mp3) format when they are being downloaded.
    *   A separate, cross-platform viewer must be provided within Moodle for listening to clips.
*   **Voice Clip Deletion:**
    *   Actors must be able to examine their portfolio, select, and delete recorded voice clips.

### Web Feeds

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

*   **Web Feed Configuration:**
    *   Actors in the role of course administrator must have the ability to determine which components have feeds and to whom these feeds should pertain.
    *   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.

### Search

The system must provide search functionality to navigate Moodle pages.

*   **Course-Level Search:**
    *   Actors must be able to search through pages within a course.
    *   A search box and "Search" button must be displayed on the top or bottom of every page after an actor has logged in.
    *   A dedicated search page must be provided, allowing actors to filter results (e.g., forum posts, grades) and search specific sections or components of the course management system.
    *   Search results must appear in categories (e.g., Assignments, Wiki Pages, Forum Posts) based on relevance, determined by the number of matching search terms.
    *   Clicking a search result link must navigate the actor to the corresponding page.
    *   The search page may allow for searching the world wide web using a standard search engine.
*   **Global Search:**
    *   If an actor is hierarchically outside of a particular course, all of their courses should be searched, and results grouped by course.
    *   If an actor is hierarchically inside 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 students.

*   **Assignment Grading:**
    *   Course administrators must be able to post grades for an assignment based on the ratio of points earned to points possible.
    *   Course administrators must be able to attach feedback in the form of text or an attachment.
    *   Time stamps must be attached to the last time a grade was modified.
*   **Grade Information Display:**
    *   The system should display grade information, including the grade for each assignment, averages, and overall grade, to the actor to whom the grades belong.
    *   Only an actor in the role of course administrator for the relevant course should be able to view another student's grades.
*   **Grade History Maintenance:**
    *   The system should maintain a history of grades for a particular assignment if the course administrator changes them, including timestamps for each change.

### Social Networking Applications

The system must integrate social and collaborative components.

*   **Wiki Provision:**
    *   The system must provide a wiki where actors can collaboratively create networks of documents.
    *   The wiki should provide a simple markup language for styling input and linking to other wiki pages.
    *   The wiki must integrate with Moodle for notifications and logins.
*   **Blog Engine Provision:**
    *   The system must provide a blog engine with modern blog functionality, including tagging, drafting, and comments.
    *   The blog engine must share authentication and notification with Moodle.

### Notifications

The system must provide a mechanism for actors to receive notifications of changes to Moodle pages.

*   **Email and SMS Notifications:**
    *   The system must provide both e-mail and SMS notifications for pages (e.g., assignments, wiki pages, forum posts).
    *   When a page is created, the course administrator must be able to toggle whether notifications are turned on (default on for announcements).
    *   If notifications are turned off, students must be able to subscribe to notifications.
    *   Students must be able to select in their preferences whether notifications are sent to their mobile telephone (via SMS) or e-mail account.
    *   Students must be able to manage their notification subscriptions.

## 3.2 Performance requirements
The system must support at least 1,000 concurrent users.

## 3.3 Usability requirements
The system shall provide a simple and responsive user interface.

The system shall provide a central, easy-to-use administrative interface that allows administrators to configure the user interface and features in a way that reduces page clutter. This administrative interface shall allow administrators to easily change themes and other settings that affect page layout across the entire courseware system. The system shall present a single administrative interface rather than individual links for editing each page.

The system shall improve navigation efficiency by reducing the number of clicks required to complete basic actions, such as submitting an assignment, thereby reducing user frustration.

The user interface shall be redesigned to reflect a more natural flow of data.

The system shall provide functionality that improves the overall learning experience of students and helps professors to make students aware of new ways of presenting material.

## 3.5 Logical database requirements
The system will manage various types of information to support its core functions.

*   **a) Types of information used by various functions:**
    *   **Course Content:** Files (e.g., assignment submissions, project files, forum attachments, wiki content, announcement attachments), text-based content (e.g., forum posts, wiki pages, blog posts, comments, announcements, assignment descriptions).
    *   **User-Generated Media:** Voice clips (audio data), associated metadata (e.g., user, page, timestamp).
    *   **Grading Information:** Grades (points earned, points possible), textual feedback, attached feedback files, modification timestamps, assignment identifiers, student identifiers.
    *   **Historical Data:** Grade history (previous grades, modification timestamps), wiki page revision history.
    *   **Configuration Data:** Settings for multiple file uploads (per-page), web feed availability (per-page), notification preferences (per-user, per-page, default settings).
    *   **User Preferences:** Notification method (SMS/email), notification subscriptions.
    *   **System Documentation:** Maintenance tasks, help files, common errors, troubleshooting guides.

*   **b) Frequency of use:**
    *   Course content (files, posts, pages) will be frequently created, modified, and accessed by students and professors.
    *   Voice clips will be frequently recorded and submitted by students, and accessed by professors.
    *   Grades will be posted by professors and viewed by students, with modifications occurring less frequently.
    *   Search functionality will be used frequently by all actors.
    *   Notification settings and subscriptions will be accessed and modified periodically by users and course administrators.
    *   System documentation will be accessed by system administrators as needed for maintenance and troubleshooting.

*   **c) Accessing capabilities:**
    *   **Students:** Access course content, submit assignments, record and manage their voice clip portfolios, view their own grades, participate in forums/wikis/blogs, manage their notification subscriptions.
    *   **Professors (Course Administrators):** Manage course content, configure page settings (e.g., multiple file uploads, web feeds, notifications), post and modify grades, provide feedback, access student voice clips, manage course-level notification settings.
    *   **System Administrators:** Maintain system configuration, manage user accounts (implicitly), access comprehensive system documentation, perform data backups and restores.
    *   **Search:** All actors can search for course content within their accessible courses.
    *   **Grade Security:** Only the student to whom the grades belong and the course administrator for that course can view specific grade information.

*   **d) Data entities and their relationships:**
    *   **Users:** (Students, Professors, System Administrators)
    *   **Courses:** Associated with Users (enrollment, administration).
    *   **Pages/Content Blocks:** (Assignments, Wiki Pages, Forum Posts, Announcements, Blog Posts) Contained within Courses.
    *   **Files:** Associated with Users (uploader) and Pages (upload location).
    *   **Voice Clips:** Associated with Users (recorder) and organized into User Portfolios; can be optionally attached to Pages.
    *   **Grades:** Associated with Users (student), Assignments, and Courses.
    *   **Grade History:** Associated with specific Grades.
    *   **Notification Subscriptions:** Link Users to Pages.
    *   **System Configuration:** Global and page-specific settings.
    *   **Documentation:** Maintenance tasks, help files.

*   **e) Integrity constraints:**
    *   Grades must adhere to a valid range (e.g., points earned <= points possible).
    *   Timestamps must be accurately recorded for grade modifications and data backups.
    *   Storage quotas for voice clips must be enforced per user.
    *   Referential integrity must be maintained between entities (e.g., an assignment grade must link to an existing student and assignment).

*   **f) Security:**
    *   Grade information must be secured such that only the student and the course administrator for that specific course can view it.
    *   Authentication for social networking applications (wikis, blogs) must be integrated with the main courseware system.
    *   Access to course content and administrative functions must be restricted based on user roles and course enrollment.

*   **g) Data retention requirements:**
    *   **Voice Clips:** Must be retained in a portfolio for each actor for the duration of their existence in the course management system to allow for long-term comparison of language skills.
    *   **Grade History:** Must be maintained for a particular assignment if grades are changed, allowing for review and dispute resolution.
    *   **Backups:** System and course data must be backed up nightly, with options for weekly off-site backup. The system must support data restoration within six hours.
    *   **General Course Data:** Implied long-term retention for academic record-keeping, though specific durations are not defined beyond voice clips and grade history.

## 3.6 Design constraints
The system design is subject to the following constraints:

*   All enhancements to the courseware system must utilize the existing APIs made available by Moodle.
*   The system must be designed to be mostly self-sustaining to minimize maintenance efforts due to limited staff in the Office of Information Services.

## 3.7 Software system attributes
#### a) Reliability
The system must be backed up on a configurable schedule. Back-up requirements will need to be determined, based on individual components of the system. The system should be backed up with a frequency that ensures system and course data is protected. Since assignments will be submitted via the system, it should be backed up 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 so that the system is never offline for an inordinate period of time.

#### b) Availability
The system should be available 24 hours a day, 7 days a week. This statement provides a general sense of system availability. It is not intended to demand the system maintain reliability, or to require the system to be highly available. It should not exclude maintenance windows, or scheduled downtime. It is only intended to convey the expectation that our customers should have access to the system during off-hours as well as business hours. 99% up-time should be considered sufficient to meet this requirement.

#### c) Security
[N/A]

#### d) Maintainability
The system must be maintainable without substantial modification. Due to limited staff in the Office of Information Services, it is important that the system be mostly self-sustaining. This will reduce the number of FTE hours spent maintaining the system and simplify maintenance tasks.

#### e) Portability
[N/A]

## 3.8 Supporting information
This section provides additional context and background to aid readers in understanding the requirements outlined in this document. The information presented here is for informational purposes and is not considered part of the formal requirements unless explicitly stated otherwise.

Each requirement in this document is accompanied by a short discussion, designed to add the background and framework necessary to explain the functionality.

This is a working document and, as such, is subject to change. In its initial form, it is incomplete by definition and will require continuing refinement. Requirements may be modified, and additional requirements may be added as development progresses and the system description becomes more distilled. This document also forms the basis for continuing discussions with stakeholders and sponsors, to enhance and further describe those requirements to be included in future enhancements to Moodle. This information will serve as a framework for the current definition and future evolution of the University of Puget Sound’s courseware system.

The primary problem to be solved by the software is that the University does not believe that Blackboard, the existing courseware system, is providing the functionality that students and faculty need to encourage learning. The goal of this document and the associated work is to determine what any courseware system would need to qualify as a viable solution for the University, and to implement features that Moodle lacks but are important to stakeholders.

To determine the necessary enhancements, system stakeholders (e.g., professors and students) were interviewed to identify what, if anything, is lacking in the existing courseware solution. The requirements and supplementary requirements in this document are based on that feedback, which is summarized in the "Moodle Requirements Brainstorming.pdf" document (referenced in section 1.4.1).

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.

[N/A] for sample input/output formats.
[N/A] for descriptions of cost analysis studies.
[N/A] for special packaging instructions for the code and the media.

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
### 4.2.1 Support for Concurrent Users
The system's capability to support at least 1000 concurrent users will be verified through load testing. A simulated environment will be established to mimic 1000 simultaneous users interacting with various functionalities of the courseware system. During these tests, the system's stability, response times, and error rates will be continuously monitored. The system will be deemed to satisfy this requirement if it maintains an acceptable level of performance, such as average page load times remaining below a specified threshold (e.g., 3 seconds) and an error rate of less than 1%, under the simulated load.

## 4.3 Usability requirements
A system will be considered to meet the usability requirement for a simple, responsive interface if it has a single administrative interface rather than individual links for editing each page.

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
### 4.7.1 Reliability
Verification approaches and methods for reliability are not specified in the original requirements.

### 4.7.2 Availability
Verification approaches and methods for availability are not specified in the original requirements.

### 4.7.3 Maintainability
Verification approaches and methods for maintainability are not specified in the original requirements.

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
*   Moodle will be adopted at the University of Puget Sound.
*   Any enhancements to the system will utilize the existing APIs made available by Moodle.
*   Moodle is of interest to the University as a viable choice to replace Blackboard.

## 5.2 Acronyms and abbreviations
*   **Actor**: Synonymous with user and 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.
