# 1 Introduction
[NULL]

## 1.1 Purpose
The purpose of this document is to capture, in natural language and at a functional level, the description and requirements of a new courseware system for the University of Puget Sound’s educational needs. This document provides a functional description of the features required to address current instructional and educational requirements. It also describes nonfunctional requirements and other factors necessary to provide a complete and comprehensive description of the requirements for the software.

## 1.2 Scope
The software product under consideration is an enhanced courseware system for the University of Puget Sound, based on Moodle. The primary objective is to develop core functionalities currently unavailable in Moodle to meet the University's educational needs. The enhancements will include redesigns for consistency with university practices and a more intuitive user interface. The software will facilitate electronic classroom management, grading, assignment submission, and other learning tools. The enhancements assume Moodle's adoption and will utilize its existing APIs. The goal is to provide a system that supports diverse teaching methods and improves the learning experience for students and faculty.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The courseware system is intended to be an enhancement to Moodle, which is being considered as a replacement for the existing courseware system at the University of Puget Sound. The system will integrate with Moodle's existing APIs to provide additional functionality and a redesigned user interface. The enhancements aim to align with the university's practices and improve the flow of data.

#### System interfaces
The system will interface with Moodle's existing APIs to implement enhancements. These interfaces will allow the system to manage courses, assignments, and other educational tools.

#### User interfaces
The user interface will be redesigned to provide a more natural flow of data. It will include features such as multiple file uploads, audio recording, web feeds, search functionality, and gradebook management. The interface will be configurable from a central administrative position to reduce page clutter.

#### Hardware interfaces
[N/A]

#### Software interfaces
The system will utilize Moodle's APIs for integration. It will also support various software components such as a wiki and blog engine for social networking applications. The system will be compatible with widely supported formats like MPEG Audio (mp3) for audio recordings.

#### Communications interfaces
The system will support web feeds, such as RSS 2.0, to notify users of new content. It will also provide email and SMS notifications for changes to Moodle pages.

#### Memory constraints
[N/A]

#### Operations
The system will support both interactive and unattended operations. It will include backup and recovery operations to ensure data protection, with options for nightly and weekly off-site backups.

#### Site adaptation requirements
The system will be adaptable to the specific needs of the University of Puget Sound, utilizing Moodle's APIs to customize features and user interfaces.

#### Interfaces with services
The system will interact with Moodle as a service, leveraging its existing infrastructure to provide enhanced functionality.

### 1.3.2 Product functions
The courseware system for the University of Puget Sound is designed to enhance the educational experience by providing several key functions:

- **Course Management**: Facilitates the creation and management of courses, assignments, and course pages by course administrators, who can be professors or system administrators.

- **File Management**: Allows users to upload and manage multiple files on various pages, such as assignment submissions, forums, and wikis.

- **Audio Recording**: Enables the capture and organization of voice clips, particularly useful for language courses, allowing students to submit oral homework and track their progress over time.

- **Web Feeds**: Provides the ability to display web feeds (e.g., RSS) for course updates, enabling users to stay informed about new content and changes.

- **Search Functionality**: Offers a search utility to help users quickly find pages and content within the course management system, reducing navigation complexity.

- **Gradebook**: Allows course administrators to post and manage grades, providing students with access to their grades and feedback.

- **Social Networking Applications**: Integrates collaborative tools such as wikis and blogs to enhance communication and interaction among users.

- **Notifications**: Sends email and SMS notifications to users about changes to course pages, ensuring they are aware of important updates.

These functions are designed to support diverse teaching methods and improve the overall learning experience for students and faculty at the University.

### 1.3.3 User characteristics
The intended users of the courseware system include students, professors, and system administrators, each with distinct roles and characteristics that influence usability:

- **Students**: As the primary consumers of the courseware system, students access information posted by professors, upload assignments and project files, and engage in discussions. Their technical expertise may vary, but they are generally expected to have basic computer literacy and familiarity with online learning platforms.

- **Professors**: Professors act as the primary content administrators, responsible for uploading files, links, and multimedia, grading assignments, and creating spaces for student collaboration. They are expected to have a moderate level of technical expertise to effectively manage course content and utilize the system's features.

- **System Administrators**: These users are responsible for maintaining the courseware system, focusing on system configuration and updates. They require a high level of technical expertise to ensure the system's smooth operation and to address any technical issues that arise.

The system is designed to accommodate users with varying levels of technical expertise, ensuring accessibility and ease of use across all user groups. [N/A]

### 1.3.4 Limitations
[N/A]

## 1.4 Definitions
- **Actor**: Synonymous with user, used to describe users who are performing actions in use cases.
- **Course Administrator**: An actor who acts as a professor or system administrator with the ability to manage courses and course pages.
- **Courseware System**: Software designed to facilitate electronic classroom management, including electronic grading, assignment submission, discussion, and other learning tools.
- **System**: Refers to the existing courseware system, a new courseware system, or any modifications being made to Moodle while it is being considered as a replacement for the existing courseware system.

# 2 References
## Guidance

- **Moodle Requirements Brainstorming.pdf**: This document was generated as a foundation for the current SRS and contains the results of stakeholder interviews. It is referenced in section 1.4.1 of the original SRS. [N/A for report number, date, publishing organization, and source details]

# 3 Requirements
[NULL]

## 3.1 Functions
The courseware system must support several fundamental actions to facilitate the educational needs of the University of Puget Sound. These functions include:

- **Multiple File Transfer**: The system must allow actors, particularly course administrators, to upload and manage multiple files on specific pages such as assignment submission pages, forum pages, and wiki pages. This feature should be configurable on a per-page basis, allowing for multiple file uploads where necessary.

- **Audio Recording**: The system must capture and organize voice clips for use in assignments, particularly for the foreign language department. Actors should be able to organize these clips into a portfolio, download them in flexible formats, and delete them as needed. The system should store audio clips in a format optimized for speech and allow for conversion to MPEG Audio (mp3) format upon download.

- **Web Feeds**: The system must display web feeds, such as RSS 2.0, for various pages like forum posts and announcements. Course administrators should have the ability to enable or disable these feeds on a per-page basis.

- **Search Functionality**: The system must provide a search utility to navigate Moodle pages efficiently. This includes a search box on every page and a dedicated search page with filtering options. The search results should be categorized based on relevance.

- **Gradebook**: The system must allow course administrators to post grades for assignments, attach feedback, and maintain a history of grade changes. Grades should be displayed to the appropriate actors, ensuring privacy and security.

- **Social Networking Applications**: The system should integrate robust social networking features, including a wiki for collaborative document creation and a blog engine with modern functionalities like tagging and comments.

- **Notifications**: The system must provide email and SMS notifications for changes to Moodle pages. Course administrators should be able to toggle notifications, and students should manage their notification preferences.

These functions are designed to enhance the learning experience by providing necessary tools for course management, communication, and collaboration. The system must handle inputs and outputs efficiently, ensuring data integrity and user satisfaction. [N/A] for specific details on validity checks, exact sequence of operations, responses to abnormal situations, and formulas for input to output conversion.

## 3.2 Performance requirements
The system should support at least 1,000 concurrent users. This requirement ensures that a substantial number of actors can access the system simultaneously, particularly during peak periods such as midterm and finals weeks. The system's performance under load is crucial for maintaining the functionality of the courseware system, which is integral to the courses that employ it. 

The system should be available 24 hours a day, 7 days a week, with a 99% uptime. This availability requirement ensures that users have access to the system during both business and off-hours, although it does not exclude maintenance windows or scheduled downtime. 

The system must be backed up on a configurable schedule to protect system and course data. A nightly backup is required, with options for weekly, off-site backup when necessary. The system must have the ability to restore backup data within six hours to minimize downtime. 

[N/A]

## 3.3 Usability requirements
The system should provide a simple, responsive interface that is easy to navigate and reduces page clutter. It should be configurable from a single source at a central administrative position, allowing administrators to easily change themes and settings that affect page layout across the entire courseware system. This will ensure that the system is user-friendly and minimizes the number of steps required to complete basic actions, thereby reducing user frustration. The system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page. 

Priority: 3.

## 3.5 Logical database requirements
[N/A]

## 3.6 Design constraints
[N/A]

## 3.7 Software system attributes
### Reliability
- The system must be backed up on a configurable schedule to ensure data protection. It should be backed up nightly, with options for weekly, off-site backup when necessary. The system must have the ability to restore backup data within six hours to minimize downtime.

### Availability
- The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient. This availability should not exclude maintenance windows or scheduled downtime but should ensure access during both business and off-hours.

### Maintainability
- The system must be maintainable without substantial modification to reduce the number of full-time equivalent (FTE) hours spent on maintenance. This is crucial due to limited staff in the Office of Information Services.

[N/A] Security

[N/A] Portability

## 3.8 Supporting information
a) [N/A]

b) The document "Moodle Requirements Brainstorming.pdf" was generated as a foundation for this SRS and contains the results of stakeholder interviews. This document does not make any further reference to the requirements brainstorming document.

c) The problems to be solved by the software include the need for enhanced functionality in the existing courseware system to better support the educational needs of the University of Puget Sound. This includes improvements in file management, audio recording capabilities, web feed integration, search functionality, gradebook management, social networking applications, and notification systems.

d) [N/A]

The SRS does not explicitly state whether these information items are to be considered part of the requirements.

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
The system's performance will be verified by ensuring it can support at least 1,000 concurrent users, as specified in the requirements. This will be tested under both normal and peak workload conditions, such as during midterm and finals weeks, to ensure the system remains reliable and responsive. The verification process will involve simulating user load to measure system response times and resource utilization, ensuring that the system meets the specified performance criteria.

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
### Reliability
The system must be backed up on a configurable schedule to ensure data protection. It should be backed up nightly, with options for weekly, off-site backup when necessary. The system must have the ability to restore backup data within six hours to minimize downtime. The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient.

### Availability
The system should be available 24/7, excluding maintenance windows or scheduled downtime, to ensure users have access during both business and off-hours.

### Maintainability
The system must be maintainable without substantial modification to reduce the number of full-time equivalent (FTE) hours spent on maintenance. It should be mostly self-sustaining due to limited staff in the Office of Information Services.

[N/A] Security, Portability

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
- The University of Puget Sound is currently seeking a new courseware system and is investigating Moodle as an option. It is assumed that Moodle is of interest to the University as a viable choice to replace Blackboard.
- The requirements are based on the assumption that Moodle will be adopted at the University of Puget Sound and that any enhancements to the system will utilize the existing APIs made available by Moodle.
- The document assumes that the University will use the platform to have a new learning experience and contribute back to a real product, regardless of whether Moodle is ultimately chosen as the courseware system.
- It is assumed that the enhancements to Moodle will embody several small redesigns for consistency with other university practices and will take the opportunity to redesign the user interface to reflect a more natural flow of data.
- The system is assumed to be backed up on a nightly basis, with options for weekly, off-site backup when necessary, to ensure system and course data is protected.
- The system is expected to support at least 1,000 concurrent users, particularly during peak times such as midterm and finals weeks.
- The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient to meet this requirement.
- The system must be maintainable without substantial modification due to limited staff in the Office of Information Services.
- The system should provide a simple, responsive interface that is configurable from a single source at a central administrative position.
- Relevant, online documentation for users should be available on each page, supplemented with phone and on-site support provided by the Office of Information Services.
- System administrators must have access to comprehensive, searchable documentation to make the courseware system easier to maintain from an IT staff point-of-view.
- The social, collaborative components of Moodle are assumed to be integrated with better, freely-available solutions to provide the best functionality possible for all actors without having to use third-party services.
- The system must provide both e-mail and SMS notifications for pages, with students able to manage their notification subscriptions.
- The system must allow actors to organize their voice clips into a portfolio, with equal and finite drive space allotted to each actor in the role of professor or administrator.
- The system must allow for multiple file uploads to be configured on a per-page basis, especially for collaborative projects and assignment submissions.

## 5.2 Acronyms and abbreviations
- **Actor**: Synonymous with user, used to describe users performing actions in use cases.
- **Course Administrator**: An actor acting as a professor or system administrator with the ability to manage courses and course pages.
- **Courseware System**: Software meant to facilitate electronic classroom management, grading, assignment submission, discussion, and other learning tools.
- **System**: Refers to the existing courseware system, a new courseware system, or modifications being made to Moodle.
