# 1 Introduction

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

### 1.3.1 Product perspective
The courseware system is intended to replace the existing system, Blackboard, and is being considered as a viable solution for the University of Puget Sound. The system will integrate with existing university practices and utilize Moodle's APIs for enhancements.

### 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. Key functions include file management, audio recording, web feeds, search functionality, gradebook management, social networking applications, and notifications.

### 1.3.3 User characteristics
- **Students**: Primary consumers accessing information, uploading assignments, and participating in discussions.
- **Professors**: Content administrators uploading materials, grading assignments, and facilitating student collaboration.
- **System Administrators**: Responsible for system maintenance, configuration, and updates.

### 1.3.4 Limitations
[N/A]

## 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 capabilities.
- **Courseware System**: Software facilitating electronic classroom management, grading, assignment submission, 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

## 3.1 Functions
- **Multiple File Transfer**: Allows actors to upload and manage multiple files on certain pages.
- **Audio Recording**: Captures and organizes voice clips for educational purposes.
- **Web Feeds**: Displays web feeds for course management system pages.
- **Search**: Provides search functionality for navigating Moodle pages.
- **Gradebook**: Allows course administrators to post and manage grades.
- **Social Networking Applications**: Integrates wikis and blogs for collaborative learning.
- **Notifications**: Provides email and SMS notifications for page changes.

## 3.2 Performance requirements
- The system should support at least 1000 concurrent users to handle peak periods like midterms and finals.

## 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 due to limited staff resources.

## 3.7 Software system attributes
- **Reliability**: The system must be backed up on a configurable schedule and be available 24/7 with 99% uptime.
- **Maintainability**: The system should be mostly self-sustaining to reduce maintenance efforts.

## 3.8 Supporting information
- The document is a working document subject to change and refinement as development progresses.

# 4 Verification

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

## 5.1 Assumptions and dependencies
- The University of Puget Sound is considering Moodle as a replacement for Blackboard, and 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
- **RSS**: Really Simple Syndication
- **mp3**: MPEG Audio Layer III