# 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 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, assuming Moodle's adoption and leveraging its existing APIs. The enhancements will provide a more consistent and natural user experience, ultimately supporting diverse teaching methods and improving the overall 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 the existing Moodle platform, which is being considered as a replacement for the current system at the University of Puget Sound. The enhancements aim to address the limitations of the current system and improve the overall learning experience. The product will integrate with Moodle's existing APIs and will be consistent with other university practices.

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

#### User interfaces
The user interface will be redesigned to provide a more natural flow of data, making it easier for students and professors to 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 as the underlying platform, interfacing with its APIs to extend functionality. The enhancements will be compatible with the existing Moodle version adopted by the University.

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

#### Operations
The system will support both interactive operations, such as user-initiated actions by students and professors, and unattended operations, such as automated backups and updates.

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

#### 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 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 create portfolios of their recordings.

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

- **Search Functionality**: Offers a search utility to help users navigate the system efficiently, reducing the need for hierarchical navigation.

- **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 interaction and content creation within the courseware system.

- **Notifications**: Supports email and SMS notifications for updates to course pages, ensuring users are promptly informed of changes.

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 characteristics that may influence usability:

- **Students**: They are the primary consumers of the courseware system, accessing information posted by professors, uploading assignments and project files, and engaging in discussions. Students are expected to have varying levels of technical expertise, but generally possess the necessary skills to navigate online platforms for educational purposes.

- **Professors**: As the primary content administrators, professors upload files, links, and multimedia, grade assignments, and create spaces for student collaboration. They are expected to have a moderate level of technical expertise to manage course content effectively.

- **System Administrators**: Responsible for maintaining the courseware system, system administrators have a high level of technical expertise. They focus on system configuration and updates, contributing minimally to course content but ensuring the system's smooth operation.

These user groups are expected to have a basic to advanced understanding of digital tools, with system administrators requiring the most technical proficiency. The system's design should accommodate varying levels of technical expertise to ensure usability across all user groups.

### 1.3.4 Limitations
- **Quality Requirements**: The system should be available 24 hours a day, 7 days a week, with a 99% uptime to ensure accessibility during both business and off-hours.
- **Reliability**: The system must be backed up on a configurable schedule, with nightly backups and options for weekly, off-site backups to protect system and course data.
- **Performance**: The system should support at least 1000 concurrent users, especially during peak times such as midterm and finals weeks.
- **Maintainability**: The system must be maintainable without substantial modification to reduce the number of FTE hours spent on maintenance.
- **Usability**: The system should provide a simple, responsive interface with a central administrative position for configuration to reduce page clutter.
- **Documentation**: Relevant, online documentation for users should be available on each page, and system administrators must have access to comprehensive, searchable documentation.
- **Interfaces**: [N/A]
- **Safety and Security Considerations**: [N/A]
- **Regulatory Requirements and Policies**: [N/A]
- **Hardware Limitations**: [N/A]
- **Parallel Operation**: [N/A]
- **Audit Functions**: [N/A]
- **Control Functions**: [N/A]
- **Higher-Order Language Requirements**: [N/A]
- **Signal Handshake Protocols**: [N/A]
- **Criticality of the Application**: [N/A]
- **Physical/Mental Considerations**: [N/A]
- **Limitations from Other Systems**: [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 SRS. The document can be obtained from the University of Puget Sound's project documentation repository.

# 3 Requirements
[NULL]

## 3.1 Functions
The courseware system must perform several fundamental actions to accept and process inputs, and generate outputs. These functions are essential for the system to meet the educational needs of the University of Puget Sound.

### 3.1.1 Multiple File Transfer
- **Input Validity Checks**: Ensure that files uploaded are of acceptable formats and sizes.
- **Sequence of Operations**: Allow actors to upload multiple files on designated pages, such as assignment submission pages.
- **Error Handling**: Provide feedback if file uploads fail due to size or format issues.
- **Output Relationship**: Uploaded files should be accessible on the respective pages for review and grading.

### 3.1.2 Audio Recording
- **Input Validity Checks**: Validate audio formats and ensure recordings are within size limits.
- **Sequence of Operations**: Capture and organize voice clips into a portfolio for each actor.
- **Error Handling**: Notify users of recording failures and provide options to retry.
- **Output Relationship**: Allow actors to download and manage their voice clips, ensuring they are stored in a format conducive to speech.

### 3.1.3 Web Feeds
- **Input Validity Checks**: Validate the configuration of web feeds for each page.
- **Sequence of Operations**: Enable or disable web feeds on a per-page basis.
- **Error Handling**: Alert administrators if feed configurations fail.
- **Output Relationship**: Ensure that web feeds accurately reflect updates to pages like forums and assignments.

### 3.1.4 Search
- **Input Validity Checks**: Validate search queries for appropriate syntax and length.
- **Sequence of Operations**: Provide a search utility on every page, allowing actors to find content quickly.
- **Error Handling**: Handle empty or malformed search queries gracefully.
- **Output Relationship**: Display search results categorized by relevance and allow navigation to the corresponding pages.

### 3.1.5 Gradebook
- **Input Validity Checks**: Ensure grades entered are within valid ranges.
- **Sequence of Operations**: Allow course administrators to post and update grades, with timestamps for modifications.
- **Error Handling**: Provide alerts for invalid grade entries.
- **Output Relationship**: Display grades to students and maintain a history of changes for review.

### 3.1.6 Social Networking Applications
- **Input Validity Checks**: Validate content entered into wikis and blogs.
- **Sequence of Operations**: Facilitate collaborative document creation and blog posting within the system.
- **Error Handling**: Notify users of content submission errors.
- **Output Relationship**: Integrate social networking features with course content for enhanced collaboration.

### 3.1.7 Notifications
- **Input Validity Checks**: Validate notification settings for each user.
- **Sequence of Operations**: Send SMS or email notifications for page updates.
- **Error Handling**: Alert users if notification delivery fails.
- **Output Relationship**: Ensure timely delivery of notifications to keep users informed of changes.

[N/A for responses to abnormal situations, effect of parameters, and formulas for input to output conversion as these details are not provided in the original SRS.]

## 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 by its ability to handle this number of simultaneous users effectively.

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

A system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page. The interface should also allow for easy configuration of user interface features to enhance the overall user experience. 

Priority: 3. 

[N/A]

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

[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 a courseware system that addresses current instructional and educational requirements, enhances user interface design for a more natural data flow, and provides functionalities currently lacking in the existing system, such as multiple file uploads, audio recording, web feeds, search capabilities, and improved social networking applications.

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 should support at least 1,000 concurrent users. This requirement ensures that a substantial number of actors can access the system simultaneously, especially during peak periods such as midterm and finals weeks. The performance requirement is stated in measurable terms to provide a clear benchmark for system capacity and reliability.

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

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

[N/A] 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.
- Any enhancements to the system will utilize the existing APIs made available by Moodle.
- The University intends to apply this document to Moodle to determine whether some of the features that Moodle lacks can be implemented.
- The University is not necessarily going to choose Moodle as a courseware system, but the platform is being used for a new learning experience and to contribute back to a real product.
- The enhancements to Moodle will embody several small redesigns for consistency with other university practices.
- The redesign of the user interface will reflect a more natural flow of data.
- The system must be maintainable without substantial modification due to limited staff in the Office of Information Services.
- The system should support at least 1000 concurrent users, especially during peak times like midterm and finals weeks.
- The system should be backed up on a nightly basis, with options for weekly, off-site backup when necessary.
- The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient.
- The system must have the ability and capacity to restore backup data within six hours to ensure minimal downtime.
- 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 to minimize the number of calls to the Help Desk.
- System administrators must have access to comprehensive, searchable documentation to facilitate maintenance tasks.
- The social, collaborative components of Moodle are not very robust, and better, freely-available solutions should be integrated.
- There is no current system that allows actors to receive SMS or email notifications of changes to Moodle pages.
- The system must provide both email and SMS notifications for pages, with default notifications turned on for announcements.
- The system must allow actors to download their voice clips in a flexible format, such as MPEG Audio (mp3).
- The system must store audio clips in a format conducive to speech and provide a viewer for listening to clips in Moodle.
- The system must allow actors to delete recorded clips to manage archived voice clips effectively.
- The system must allow web feeds to be turned on or off on a per-page basis.
- The system must display a search box on every page after an actor has logged in.
- The system must maintain a grade history for assignments if the course administrator changes them.
- The system must provide a wiki and a blog engine for collaborative document creation and modern blog functionality.
- The system must allow actors in the capacity of course administrator to post grades associated with assignments.
- The system should display grade information to the appropriate actor, ensuring privacy and security of grades.

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