## 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
The software product under consideration is the University of Puget Sound’s enhancements to Moodle, which is being investigated as a candidate for a new courseware system.

These enhancements will focus on developing core functionality currently unavailable in Moodle, redesigning parts of the user interface to reflect a more natural flow of data, and embodying small redesigns for consistency with other university practices. The goal is to refine Moodle to provide functionality that improves the overall learning experience for students and helps professors present material in new ways.

The application of this software is to serve as a viable courseware solution for the University of Puget Sound, addressing immediate instructional and educational requirements. The objectives include replacing the existing Blackboard system, implementing features that Moodle currently lacks but are important to stakeholders, and ultimately contributing to a new learning experience for the University community.

### 1.3.1 Product perspective

The product described in this document consists of enhancements to Moodle, which is currently being investigated as a viable courseware system to replace the University of Puget Sound's existing system, Blackboard. These enhancements are designed to provide core functionality currently unavailable in Moodle and to improve the overall learning experience for students and professors, addressing shortcomings identified in the current courseware solution. The goal is to refine parts of Moodle to meet the University's instructional and educational requirements.

The enhancements are designed to integrate with Moodle and will utilize its existing APIs.

#### System interfaces
The software product integrates with Moodle, the existing courseware system candidate. The enhancements will utilize the existing APIs made available by Moodle.

#### User interfaces
The enhancements will include a redesign of the user interface to reflect a more natural flow of data and consistency with other university practices. The system should provide a simple, responsive interface. It must be configurable from a single, central administrative position, allowing administrators to configure the user interface and features to reduce page clutter. The administrative interface must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system. Relevant, online documentation for users should be available on each page to minimize calls to the Help Desk.

#### Hardware interfaces
[N/A]

#### Software interfaces
The product is an enhancement to Moodle, a courseware system. The enhancements will utilize the existing APIs provided by Moodle (version TODO: Version of Moodle). Moodle is intended to replace Blackboard.

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

#### Operations
The system should be available 24 hours a day, 7 days a week, with an expectation of 99% uptime, allowing for scheduled maintenance windows. The system must be backed up on a configurable schedule, such as nightly, with options for weekly, off-site backup. The system must have the ability and capacity to restore backup data within six hours. The system should support at least 1000 concurrent users, particularly during peak times like midterm and finals weeks. The system must be maintainable without substantial modification, aiming to be mostly self-sustaining due to limited staff. Comprehensive, searchable documentation for system administrators must be available, covering maintenance procedures, common errors, and advanced troubleshooting.

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

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

### 1.3.2 Product functions
The courseware system will perform the following major functions:

*   **Course and Content Management**: Facilitate electronic classroom management, allowing course administrators (professors) to manage courses, upload files, links, and multimedia, and create new spaces for discussion and collaboration.
*   **Assignment and Grading Management**: Enable electronic assignment submission by students and allow course administrators to post, manage, and maintain a history of grades for assignments.
*   **File and Media Handling**: Provide capabilities for capturing and managing files, including support for multiple file uploads on various pages. It will also allow for the capture, organization, storage, and management (including download and deletion) of student voice clips for educational purposes.
*   **Communication and Collaboration Tools**: Offer features for discussion, collaborative document creation through a wiki, and a blog engine with modern blogging functionality.
*   **Information Dissemination and Notification**: Display web feeds (e.g., RSS 2.0) for new content such as forum posts, assignment postings, announcements, and wiki alterations. It will also provide email and SMS notifications for changes to course pages.
*   **Navigation and Search**: Implement search functionality to allow users to efficiently navigate course pages, including course-level searches and a readily available search box on all logged-in pages.
*   **User Interface Enhancement**: Redesign the user interface to provide a more natural flow of data and improve the overall learning experience for students and professors.

### 1.3.3 User characteristics
*   **Students**: Students are the primary consumers of a courseware system. They access information posted by professors, upload assignments and project files, and discuss concepts.
*   **Professors**: Professors are the primary content administrators of a 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**: 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
The following items limit the supplier's options for the courseware system:

*   All enhancements to the system must utilize the existing APIs made available by Moodle.
*   The initial production release will be limited to Priority 1 (Core) and Priority 2 requirements, along with Priority 3 requirements that can be developed within project timeframe and budget constraints.
*   Social networking components should integrate freely-available solutions into Moodle.
*   Audio clips must be stored in a format optimized for speech and only converted to MPEG Audio (mp3) format upon download. A separate cross-platform viewer must be provided for listening to clips within Moodle.
*   The system must be mostly self-sustaining and maintainable without substantial modification due to limited staff.

## 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 served as a foundation for the requirements described in this SRS.
    - 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 must allow actors to upload and manage multiple files on specific pages, such as assignment submission pages, forum pages, wiki pages, and announcement pages.
Course administrators must be able to optionally upload multiple files where useful, such as on a devoted project page.
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 must be able to enable multiple file uploads on a page of their choosing.
*   This configuration option must be offered to the actor during a page’s creation and editing stages.
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Configuration during page creation/editing, followed by file upload by actors.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: Enabling multiple file uploads on a per-page basis allows actors to submit multiple files for a single item.
*   Relationship of outputs to inputs: Uploaded files are captured and managed by the system on the specified pages.

### 3.1.2 Audio Recording
The system must be able to capture and organize voice clips for use where appropriate.
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 voice clips recorded and submitted by students.
*   Actors in the role of professor or system administrator must be allowed to partition this space for students.
*   Actors must be allowed to preview a voice clip before it is archived and determine whether to archive it, or a newly created voice clip can be automatically archived. The actor should have the option to have the voice clip archived after a preview.
*   The actor must be able to optionally attach one of their 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).
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.
*   A separate viewer should be provided in a cross-platform language for listening to clips within Moodle.
The system must allow actors to delete recorded clips.
*   Actors must be able to examine their portfolio to select and delete clips.
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Record voice clip, choose archiving method (preview/auto), manage portfolio (attach/delete), download clip.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: User choices for archiving (preview vs. auto) determine the immediate state of the recorded clip. Download format parameter (e.g., mp3) affects the output file type.
*   Relationship of outputs to inputs: Recorded voice clips are stored, organized into portfolios, and can be downloaded or deleted.

### 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 are added.
Actors in the role of course administrators 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, the course administrator must be able to toggle web feed availability.
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Course administrator configures web feed availability during page creation/editing, then the system automatically generates and displays feeds based on new content.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: Per-page configuration determines which pages generate web feeds and their visibility.
*   Relationship of outputs to inputs: Configuration settings result in the display or suppression of web feeds for specific content.

### 3.1.4 Search
The system must be able to use search functionality as a way to navigate Moodle pages.
An actor must be able to search through pages in a course.
*   The search feature must be present in the form of a search box and a “Search” button on the top or bottom of every page.
*   A single page must be dedicated specifically to the task of searching the course management system.
*   This dedicated search page must allow an actor to filter out certain results (e.g., forum posts or grades) and search specific sections (or components) of the course management system.
*   Results must appear in categories (e.g., Assignments, Wiki Pages, Forum Posts) based on relevance, determined by the highest number of terms matching the search terms.
*   When the actor clicks a search result link, they must be taken to the page corresponding to the search result.
*   The search page might allow for the possibility of searching the world wide web using a standard search engine such as Google.
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 their courses should be searched, and results grouped by course.
*   If the actor is hierarchically inside of a course, that course should be searched with an option to search all courses.
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Actor enters search query, clicks search button, system processes query, displays categorized results, actor clicks result link, system navigates to the corresponding page.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: Search filters and scope (current course/all courses) narrow down the search results.
*   Relationship of outputs to inputs: A search query input generates a list of relevant, categorized search results, which can then be used to navigate to specific pages.

### 3.1.5 Gradebook
The system must allow actors in the capacity of course administrator to post grades associated with assignments for students.
A course administrator must be able to grade an assignment.
*   Course administrators must be able to post grades for an assignment based on the ratio of points earned to points possible.
*   The course administrator must be able to attach feedback in the form of text or an attachment.
*   Time stamps must 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 student 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.
*   Timestamps associated with each change to the gradebook must be maintained.
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Course administrator inputs grade and feedback, system records grade with timestamp, system displays grade information to student, system maintains history upon grade modification.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: Inputted points earned/possible determine the calculated grade. Feedback text/attachments provide additional context.
*   Relationship of outputs to inputs: Inputted grades and feedback are stored, displayed to students, and a history of changes is maintained.

### 3.1.6 Social Networking Applications
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 and link to other pages in the wiki.
*   The wiki must integrate with Moodle for notifications and logins.
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 must share authentication and notification with Moodle.
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Actors create/edit wiki pages or blog posts, system stores and displays the content.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: Markup language parameters affect the styling and linking within wiki documents. Tags and comments affect blog post organization and interaction.
*   Relationship of outputs to inputs: User input (text, markup, tags, comments) is processed and displayed as collaborative wiki documents or blog posts.

### 3.1.7 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 actor in the role of course administrator must be able to toggle whether notifications are turned on.
*   By default, notifications should be turned on for announcements.
If notifications are turned off by the administrator, 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 (e.g., remove themselves from notifications).
*   Validity checks on the inputs: [N/A]
*   Exact sequence of operations: Course administrator configures notification settings for a page, students set their notification preferences and manage subscriptions, system sends e-mail or SMS notifications upon changes to subscribed pages.
*   Responses to abnormal situations: [N/A]
*   Effect of parameters: Administrator toggle determines default notification status. Student preferences (SMS/email) determine the delivery method. Subscription management allows granular control over received notifications.
*   Relationship of outputs to inputs: Page changes, combined with administrator settings and student preferences/subscriptions, trigger the generation and sending of e-mail or SMS notifications.

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

The system shall have the ability and capacity to restore backup data within six hours.

## 3.3 Usability requirements
The system must provide a simple, responsive, and easy-to-use interface for all actors.

For administrators, the system must offer a central, single administrative interface for configuration, rather than requiring individual links for editing each page. This interface must allow administrators to easily configure the user interface and features in a way that reduces page clutter and facilitates easy changes to themes and other settings affecting page layout across the entire courseware system.

The objective is to enhance user satisfaction and efficiency by minimizing complexity and navigation steps.

## 3.5 Logical database requirements

The system will manage various types of information within its database to support core courseware functionalities.

### a) Types of Information Used by Various Functions

*   **User Data**: Student, Professor, and System Administrator profiles, roles, and associated preferences.
*   **Course Data**: Course configurations, settings, and content organization.
*   **Page Data**: Information related to distinct content blocks such as assignments, wiki pages, forum posts, and announcements. This includes configuration settings like multiple file upload enablement, web feed availability, and notification toggles on a per-page basis.
*   **File Data**: Uploaded files for assignments, projects, multimedia, and feedback attachments.
*   **Voice Clip Data**: Audio recordings, stored in a speech-optimized format, with an option for MP3 download. This includes metadata for organization into user portfolios.
*   **Grade Data**: Points earned, points possible, textual feedback, attached feedback files, and timestamps for grade modifications.
*   **Web Feed Data**: Configuration for web feeds, specifying components with feeds and target recipients.
*   **Search Index Data**: Indexed content from course pages (assignments, wikis, forum posts) for efficient search functionality.
*   **Notification Data**: User notification preferences (SMS/email), and subscriptions to specific page notifications.
*   **Social Networking Data**: Wiki page content, links between wiki pages, blog posts, tags, drafts, and comments.
*   **System Documentation**: Comprehensive maintenance tasks, help files, common errors, and troubleshooting information for system administrators.

### b) Frequency of Use

*   **Course Content (Assignments, Forum Posts, Wiki Alterations, Announcements)**: Frequently added, modified, and accessed by students and professors.
*   **Grades**: Posted by professors, viewed by students, and potentially modified by professors.
*   **Voice Clips**: Captured by students, organized and reviewed by students and professors.
*   **User Preferences/Subscriptions**: Modified less frequently by individual users.
*   **System Backups**: Performed nightly.

### c) Accessing Capabilities

*   **File and Voice Clip Management**: Actors can upload, download, organize, and delete files and voice clips.
*   **Content Management**: Actors can create, edit, and delete course content such as wiki pages, blog posts, forum posts, assignments, and announcements.
*   **Grade Management**: Course administrators can post, modify, and view grades for their courses. Students can view their own grades.
*   **Search**: Actors can search course content at the course level or across all courses, with filtering and categorization of results. System administrators can search comprehensive documentation.
*   **Notification Management**: Students can subscribe to/unsubscribe from notifications and manage their delivery preferences.
*   **Data Restoration**: The system must have the ability to restore backup data.

### d) Data Entities and Their Relationships

*   **Actor (User)**:
    *   Associated with roles (Student, Professor, System Administrator).
    *   Owns a portfolio of Voice Clips.
    *   Has Notification Preferences (SMS/email).
    *   Manages Notification Subscriptions to Pages.
    *   Submits Assignments (which may include Files).
    *   Has Grades for Assignments.
*   **Course**:
    *   Contains multiple Pages.
    *   Managed by Professors/Course Administrators.
*   **Page**:
    *   A generic entity representing distinct content blocks (e.g., Assignment, Wiki Page, Forum Post, Announcement).
    *   Can have attributes for Multiple File Upload enabled, Web Feed enabled, and Notifications enabled.
    *   Can contain Files and attached Voice Clips.
    *   Can be associated with Grades (if an Assignment).
    *   Can have Web Feeds and Notification Subscriptions.
*   **Assignment**:
    *   A specific type of Page.
    *   Has attributes for points possible.
    *   Associated with Grades for Students.
*   **Grade**:
    *   Belongs to a specific Assignment and a Student.
    *   Includes points earned, points possible, feedback (text/attachment), and modification timestamps.
    *   Maintains a history of changes.
*   **Voice Clip**:
    *   Belongs to an Actor's portfolio.
    *   Can be optionally attached to a Page.
*   **System Documentation**:
    *   Comprises maintenance tasks, help files, common errors, and troubleshooting information.

### e) Integrity Constraints

*   **Grade History**: The system must maintain a history of grade changes for auditing and dispute resolution.
*   **Timestamps**: Timestamps must be attached to grade modifications.
*   **Storage Allocation**: Equal and finite drive space must be allotted to each professor or administrator for student voice clips.
*   **Data Consistency**: Integrated social networking applications (wiki, blog) must share authentication and notification mechanisms with the core Moodle system.

### f) Security

*   **Grade Access Control**: Only the student to whom grades belong, or a course administrator for that specific course, should be able to view grade information.
*   **Authentication Integration**: Integrated blog and wiki engines must share authentication with Moodle.

### g) Data Retention Requirements

*   **Grade History**: A history of grades for a particular assignment must be maintained if changed by a course administrator.
*   **Voice Clip Portfolio**: Voice clips should be stored in a portfolio for each actor during their entire existence in the course management system.
*   **System Backups**: The system and course data must be backed up nightly, with options for weekly off-site backup. Backup data must be restorable within six hours.

## 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.1 Functions
[N/A]

## 4.2 Performance requirements
### 4.2.1 Support for Concurrent Users
The system's ability to support at least 1000 concurrent users will be verified through load testing. This will involve simulating 1000 simultaneous users performing a representative set of common system interactions (e.g., logging in, navigating course pages, accessing content, submitting assignments). The system will be deemed to meet this requirement if it maintains stable operation and acceptable response times for these simulated users, without significant degradation in performance or system errors.

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

### Availability
[N/A]

### Security
[N/A]

### Maintainability
[N/A]

### Portability
[N/A]

### Performance
[N/A]

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