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

*   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 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.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 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 design of the system 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 integrate with the Moodle platform, as Moodle is the assumed courseware system candidate.
*   The scope of features for the initial production release is constrained by the project timeframe and budget.
*   Due to limited staff in the Office of Information Services, the system must be mostly self-sustaining to minimize maintenance effort.

### 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 document is a working document, subject to change and continuous refinement. Requirements may be modified and additional requirements may be added as development progresses and the system description becomes more distilled. It forms the basis for continuing discussions with stakeholders and sponsors, to enhance and further describe requirements for future enhancements.

The University of Puget Sound's current courseware system (Blackboard) is not believed to be providing the functionality that students and faculty need to encourage learning. To address this, stakeholder interviews were conducted to determine what was lacking in the existing solution, and the requirements in this document are based on that feedback.

Requirements have been categorized by priority:
*   **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**: Considered very important to supplement critical functionality.
*   **Priority 4**: Considered valuable as a supplement to other functionality, but not critical.

The initial production release of the University of Puget Sound’s enhancements 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.

## 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
Verification will confirm that the system provides a single administrative interface rather than individual links for editing each page. Furthermore, verification will confirm that this interface allows administrators to easily change themes and other settings that affect page layout across the entire courseware system.

[N/A]

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