## 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 a courseware system enhancement for the University of Puget Sound, specifically focusing on the development of core functionalities currently unavailable in Moodle. The enhancements aim to align Moodle with the university's practices and improve the user interface for a more intuitive data flow. The software will facilitate electronic classroom management, including grading, assignment submission, and discussion tools. The primary objective is to address the immediate instructional and educational needs of the university, ensuring that the courseware system supports diverse teaching methods and enhances the overall learning experience. The enhancements will utilize existing Moodle APIs, assuming Moodle's adoption as a replacement for the current system.

### 1.3.1 Product perspective

The courseware system is intended to be an enhancement of 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 user experience.

#### 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, making it easier for users to navigate and interact with the system. The interface will be configurable from a central administrative position to reduce page clutter and improve usability.

#### Hardware interfaces
[N/A]

#### Software interfaces
The system will utilize Moodle's APIs to integrate additional functionalities. The enhancements will be compatible with the existing Moodle platform, ensuring seamless integration and operation.

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

#### Operations
The system will support both interactive and unattended operations, allowing users to perform tasks such as assignment submissions and grading. Backup and recovery operations will be supported to ensure data protection.

#### Site adaptation requirements
The system will be adaptable to the specific needs of the University of Puget Sound, including any data or initialization sequences required for its operation.

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

### 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 management of courses, assignments, and related content. This includes the ability to upload and manage files, create and edit course pages, and manage course-related announcements.

- **File and Media Handling**: Supports multiple file uploads and the organization of audio recordings into portfolios. This is particularly useful for assignments that require multiple parts or for language courses that involve voice clip submissions.

- **Communication and Collaboration**: Provides tools for discussion and collaboration, such as forums, wikis, and blogs. These tools are integrated within the system to ensure seamless communication and content sharing among students and professors.

- **Notification System**: Offers email and SMS notifications to keep users informed about updates to course content, assignments, and announcements.

- **Search Functionality**: Includes a robust search feature that allows users to quickly find content within the course management system, reducing the need for extensive navigation.

- **Grade Management**: Enables course administrators to post and manage grades, providing students with access to their grades and feedback.

- **Web Feeds**: Supports the display of web feeds (e.g., RSS) for various course components, allowing users to stay updated on new content.

- **Social Networking Integration**: Incorporates social networking applications to enhance the collaborative learning environment, including wikis and blogs.

These functions are designed to improve the overall learning experience by making course management more efficient and user-friendly, while also supporting diverse teaching methods.

### 1.3.3 User characteristics

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

- **Students**: As the primary consumers of the courseware system, students are expected to have varying levels of technical expertise. They will primarily use the system to access information, upload assignments, and engage in discussions. Their educational level ranges from undergraduate to graduate, and they may have diverse learning needs, including potential disabilities that the system should accommodate.

- **Professors**: Professors act as the primary content administrators. They are responsible for uploading educational materials, grading assignments, and facilitating student collaboration. Professors are expected to have a moderate to high level of technical expertise, as they will manage course content and interact with various system features.

- **System Administrators**: These users are responsible for maintaining the courseware system. They require a high level of technical expertise to configure and update the system. Their role involves minimal interaction with course content but significant involvement in system configuration and maintenance.

The system should be designed to accommodate the varying levels of technical expertise and educational backgrounds of these user groups, ensuring accessibility and ease of use for all.

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

## 2.1 Compliance
[N/A]

## 2.2 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. The document can be obtained from the University of Puget Sound's project documentation repository.

## 3.1 Functions

The courseware system must support several fundamental actions to facilitate the educational needs of the University of Puget Sound. These actions include managing file uploads, capturing audio recordings, displaying web feeds, enabling search functionality, managing grades, and integrating social networking applications. Each function is designed to enhance the user experience and improve the overall learning environment.

### 3.1.1 Multiple File Transfer
- **Input Validity Checks**: Ensure that files uploaded are of acceptable formats and sizes.
- **Sequence of Operations**: Users can upload multiple files to designated pages, such as assignment submission pages or forum pages.
- **Error Handling**: Provide feedback if file uploads fail due to size or format issues.
- **Effect of Parameters**: The ability to upload multiple files can be configured on a per-page basis by course administrators.

### 3.1.2 Audio Recording
- **Input Validity Checks**: Validate audio file formats and sizes.
- **Sequence of Operations**: Users can record and organize voice clips into a portfolio.
- **Error Handling**: Handle errors in recording or uploading audio clips.
- **Effect of Parameters**: Audio clips can be downloaded in flexible formats like MP3 for compatibility.

### 3.1.3 Web Feeds
- **Input Validity Checks**: Validate the configuration of web feeds for different pages.
- **Sequence of Operations**: Web feeds can be enabled or disabled on a per-page basis by course administrators.
- **Error Handling**: Notify users if web feeds fail to update or display correctly.

### 3.1.4 Search
- **Input Validity Checks**: Ensure search queries are valid and within acceptable length.
- **Sequence of Operations**: Users can search for pages within a course or across courses.
- **Error Handling**: Provide feedback if search results are not found or if there are issues with the search functionality.

### 3.1.5 Gradebook
- **Input Validity Checks**: Validate grade entries and ensure they are within the defined range.
- **Sequence of Operations**: Course administrators can post and update grades, with timestamps for modifications.
- **Error Handling**: Handle errors in grade entry and provide mechanisms for grade disputes.

### 3.1.6 Social Networking Applications
- **Input Validity Checks**: Validate user inputs in wikis and blogs.
- **Sequence of Operations**: Users can collaboratively create and edit documents in wikis and post blogs.
- **Error Handling**: Provide feedback for errors in document creation or blog posting.

### 3.1.7 Notifications
- **Input Validity Checks**: Validate user preferences for notification settings.
- **Sequence of Operations**: Users can receive email or SMS notifications for changes to pages.
- **Error Handling**: Notify users if there are issues with sending or receiving notifications.

These functions are designed to ensure a seamless and efficient user experience, with appropriate error handling and recovery mechanisms in place to address any issues that may arise during operation.

## 3.2 Performance requirements

The system should support at least 1,000 concurrent users to ensure reliability under load, particularly during peak times such as midterm and finals weeks. This requirement is crucial as the courseware system is integral to the courses that employ it. The system's performance should be measured to maintain 99% uptime, providing access to users 24 hours a day, 7 days a week, excluding scheduled maintenance windows.

## 3.3 Usability requirements

The system should provide a simple, responsive interface that is easy to navigate and reduces page clutter. The interface 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 frustration for users. 

The system should also include a search utility to enable users to quickly find what they are looking for, in addition to having a hierarchical approach to navigating the course management system. A search box should be displayed on every page after a user has logged in, allowing them to search for pages at the course level or across all courses, depending on their current hierarchical position.

Relevant, online documentation should be available on each page to provide users with easy access to help while interacting with the system. This documentation should be supplemented with phone and on-site support provided by the Office of Information Services to minimize the number of calls to the Help Desk about problems with the system. 

Overall, the system should aim to provide a satisfying user experience by ensuring that it is efficient, effective, and easy to use in the specific context of a courseware system.

## 3.5 Logical database requirements
[N/A]

## 3.6 Design constraints

[N/A]

## 3.7 Software system attributes

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

### 3.7.2 Availability
- The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient. This ensures access during both business and off-hours, excluding scheduled maintenance windows.

### 3.7.3 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 for Security and 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, grading systems, 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.1 Functions

[N/A]

## 4.2 Performance requirements

The system should support at least 1,000 concurrent users to ensure reliability under load, particularly during peak times such as midterm and finals weeks. This requirement is crucial as a substantial number of actors need to access the system simultaneously, given its importance to the courses that employ it. The system's performance should be measured to ensure it meets this requirement, with a focus on maintaining system responsiveness and availability during high-demand periods.

## 4.3 Usability requirements

The usability requirements for the courseware system focus on providing a simple and responsive interface that enhances the user experience for all actors, including students, professors, and system administrators. The system should be configurable from a central administrative position, allowing for easy management of the user interface and features to reduce page clutter. A single administrative interface is required to meet this usability requirement, enabling administrators to change themes and settings affecting page layout across the entire system. The goal is to ensure that the system is intuitive and easy to navigate, minimizing frustration and enhancing the overall learning experience. 

Verification of these usability requirements will involve user testing to measure the effectiveness, efficiency, and satisfaction of the interface. This will include assessing the ease of navigation, the clarity of information presentation, and the ability to perform tasks with minimal effort. Feedback from users will be collected to identify any areas of improvement and ensure that the system meets the defined usability objectives. 

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

### Availability
The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient. This ensures access during both business and off-hours, excluding scheduled maintenance windows.

### 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, Portability

## 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 able to support at least 1000 concurrent users, especially during peak times such as midterm and finals weeks.
- The system is assumed to be backed up on a configurable schedule, with a frequency that ensures system and course data is protected, and must have the ability to restore back-up data within six hours.
- The system is assumed to be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient to meet this requirement.
- The system is assumed to be maintainable without substantial modification due to limited staff in the Office of Information Services.
- The system is assumed to provide a simple, responsive interface that is configurable from a single source at a central administrative position.
- The system is assumed to have relevant, online documentation available on each page, supplemented with phone and on-site support provided by the Office of Information Services.
- The system is assumed to have comprehensive, searchable documentation for system administrators, covering all procedures necessary for regular maintenance and troubleshooting.
- The system is assumed to integrate social networking applications, such as a wiki and blog engine, to provide robust collaborative components.
- The system is assumed to provide both e-mail and SMS notifications for pages, with actors in the capacity of students able to manage their notification subscriptions.
- The system is assumed to allow actors to search through pages in a course, with a search box displayed on every page after an actor has logged in.
- The system is assumed to allow actors in the capacity of course administrator to post grades associated with assignments for a particular actor in the capacity of student, with a maintained grade history.
- The system is assumed to allow actors to organize and download their voice clips in a flexible format, with the ability to delete recorded clips.
- The system is assumed to allow web feeds to be turned on or off on a per-page basis, with actors in the course administrator role able to toggle web feed availability.
- The system is assumed to allow for multiple file uploads to be configured on a per-page basis, especially for collaborative projects.

## 5.2 Acronyms and abbreviations

- **API**: Application Programming Interface
- **FTE**: Full-Time Equivalent
- **IT**: Information Technology
- **MPEG**: Moving Picture Experts Group
- **PDF**: Portable Document Format
- **RSS**: Really Simple Syndication
- **SMS**: Short Message Service
- **TODO**: To Be Done