# 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, along with nonfunctional requirements and other factors necessary for a comprehensive description of the software requirements.

## 1.2 Scope
This document addresses the immediate requirements for developing core functionality currently unavailable in Moodle, the existing courseware system candidate. The enhancements to Moodle will include redesigns for consistency with university practices and a user interface redesign for a more natural data flow. These requirements assume Moodle's adoption at the University of Puget Sound and that enhancements will utilize existing Moodle APIs.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The courseware system is intended to replace the existing system, Blackboard, and is being considered as a potential solution using Moodle. The system will interface with existing university systems and utilize Moodle's APIs for enhancements.

#### System interfaces
[N/A]

#### User interfaces
The system will provide a central, easy-to-use interface for administrators to configure the user interface and features, reducing page clutter.

#### Hardware interfaces
[N/A]

#### Software interfaces
The system will utilize Moodle's existing APIs for enhancements.

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

#### Operations
The system will support user-initiated operations, data processing support functions, and backup and recovery operations.

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

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

### 1.3.2 Product functions
The courseware system will manage courses, assignments, wiki pages, forums, and more. It aims to improve the learning experience for students and provide professors with new ways to present material.

### 1.3.3 User characteristics
- **Students**: Primary consumers accessing information, uploading assignments, and discussing concepts.
- **Professors**: Primary content administrators uploading files, grading assignments, and creating discussion spaces.
- **System Administrators**: Responsible for maintaining the system, modifying configurations, and making updates.

### 1.3.4 Limitations
- The system must be maintainable without substantial modification due to limited staff.
- The system should be available 24/7 with 99% uptime.
- The system should support at least 1000 concurrent users.

## 1.4 Definitions
- **Actor**: Synonymous with user, describing users performing actions in use cases.
- **Course Administrator**: An actor acting as a professor or system administrator with course management abilities.
- **Courseware System**: Software facilitating electronic classroom management, grading, assignment submission, discussion, and learning tools.
- **System**: Refers to the existing courseware system, a new courseware system, or modifications to Moodle.

# 2 References
- **Moodle Requirements Brainstorming.pdf**: Contains results of stakeholder interviews and serves as a foundation for this document.

# 3 Requirements
[NULL]

## 3.1 Functions
- **Multiple File Transfer**: The system must allow actors to upload and manage multiple files on certain pages, configurable on a per-page basis.
- **Audio Recording**: The system must capture and organize voice clips, allowing actors to organize them into a portfolio, download in flexible formats, and delete clips.
- **Web Feeds**: The system must display web feeds for course management system pages, configurable on a per-page basis.
- **Search**: The system must provide search functionality for navigating Moodle pages, with a search box on every page.
- **Gradebook**: The system must allow course administrators to post grades and maintain a grade history.
- **Social Networking Applications**: The system must provide a wiki and blog engine for collaborative document creation and modern blog functionality.
- **Notifications**: The system must provide email and SMS notifications for page changes.

## 3.2 Performance requirements
- The system should support at least 1000 concurrent users.

## 3.3 Usability requirements
- The system should provide a simple, responsive interface with a central administrative position for configuration.

## 3.5 Logical database requirements
[N/A]

## 3.6 Design constraints
- The system must be maintainable without substantial modification.

## 3.7 Software system attributes
- **Reliability**: The system must be backed up on a configurable schedule, with options for nightly and weekly off-site backups.
- **Availability**: The system should be available 24/7 with 99% uptime.
- **Maintainability**: The system should be mostly self-sustaining to reduce maintenance hours.

## 3.8 Supporting information
[N/A]

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
- The University of Puget Sound is considering Moodle as a replacement for Blackboard.
- The document aims to determine the requirements for any viable courseware system.

## 5.2 Acronyms and abbreviations
- **API**: Application Programming Interface
- **SMS**: Short Message Service
- **FTE**: Full-Time Equivalent
- **IT**: Information Technology
- **RSS**: Really Simple Syndication
- **MPEG**: Moving Picture Experts Group
- **mp3**: MPEG Audio Layer III
