# 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 will include redesigns for consistency with university practices and a user interface redesign for a more natural data flow. These requirements assume Moodle will be adopted 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 potential enhancement to Moodle. The system will interface with existing university practices and utilize Moodle's APIs for integration.

### 1.3.2 Product functions
The major functions of the courseware system include managing courses, assignments, wiki pages, forums, and providing tools for electronic grading, assignment submission, and discussion. The system aims to improve the learning experience and provide new ways for professors to present material.

### 1.3.3 User characteristics
- **Students**: Primary consumers accessing information, uploading assignments, and participating in discussions.
- **Professors**: Primary content administrators uploading materials, grading assignments, and facilitating student collaboration.
- **System Administrators**: Responsible for maintaining the system, modifying configurations, and performing 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 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
### 3.1.1 Multiple File Transfer
The system must allow actors to upload and manage multiple files on certain pages, such as assignment submission pages, forum pages, and wiki pages. Course administrators should be able to configure multiple file uploads on a per-page basis.

### 3.1.2 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 voice clips into a portfolio, download them in flexible formats, and delete them as needed.

### 3.1.3 Web Feeds
The system must display web feeds for pages with new content, such as forum posts and announcements. Course administrators should be able to toggle web feed availability on a per-page basis.

### 3.1.4 Search
The system must provide search functionality to navigate Moodle pages efficiently. Actors should be able to search within courses and across all courses, with results categorized by relevance.

### 3.1.5 Gradebook
The system must allow course administrators to post grades and feedback for assignments. Grade information should be displayed to the appropriate actor, and a grade history should be maintained.

### 3.1.6 Social Networking Applications
The system should integrate robust social and collaborative components, such as a wiki and blog engine, to enhance functionality without relying on third-party services.

### 3.1.7 Notifications
The system must provide email and SMS notifications for changes to Moodle pages, with options for actors to manage their notification preferences.

## 3.2 Performance requirements
- The system should support at least 1000 concurrent users to handle peak load times, such as during midterms and finals.

## 3.3 Usability requirements
- The system should provide a simple, responsive interface with a central administrative position for configuration, reducing page clutter and enhancing usability.

## 3.5 Logical database requirements
[N/A]

## 3.6 Design constraints
- The system must be maintainable without substantial modification, given limited staff resources.

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

## 3.8 Supporting information
[N/A]

# 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 requirements are based on the assumption that Moodle will be adopted.

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