# 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 is a functional description of those features required to address current instructional and educational requirements. Each requirement is accompanied by a short discussion to add background and explain the functionality. 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
This document addresses the immediate requirements for the development of core functionality currently unavailable in Moodle (version [N/A]), the existing courseware system candidate. The University’s enhancements to Moodle will embody several small redesigns for consistency with other university practices. Additionally, the enhancements will redesign the user interface to reflect a more natural flow of data. These requirements assume that Moodle will be adopted at the University of Puget Sound and that any enhancements will utilize Moodle’s existing APIs. The goal is to define what any courseware system would need to qualify as a viable solution, and to assess whether needed features can be implemented via Moodle.

## 1.3 Product overview

### 1.3.1 Product perspective
The product is a courseware system or enhancements to Moodle to meet University of Puget Sound needs, potentially replacing Blackboard. Requirements apply to any candidate courseware, with specific intent to utilize Moodle’s APIs if Moodle is adopted.

#### System interfaces
- [N/A]

#### User interfaces
- A simple, responsive interface with reduced page clutter.
- A single, central administrative interface that allows configuration of themes and settings affecting page layout across the entire system rather than per-page editing links.
- A search box present on every page after login.
- A dedicated search page supporting filtering by content type and grouping of results.

#### Hardware interfaces
- [N/A]

#### Software interfaces
- Integrations shall utilize existing Moodle APIs.
- Web feeds (e.g., RSS 2.0) for pages such as assignments, forums, announcements, and wikis.
- Optional integration of freely available wiki and blog engines that share authentication and notifications with Moodle.
- E-mail and SMS notification facilities.
- An in-system audio clip viewer implemented in a cross-platform language.

#### Communications interfaces
- Use of web feeds for syndication (e.g., RSS 2.0).
- Use of e-mail and SMS as notification channels.
- [N/A] for protocol-level details.

#### Memory constraints
- Equal and finite drive space allotted to each professor/administrator for storing student-submitted voice clips, with the ability to partition this space among students.

#### Operations
- Normal operations include course administration, content upload, grading, assignment submission, discussion, and search.
- Backup and recovery operations include nightly backups, with options for weekly off-site backup when necessary, and the ability to restore within six hours.
- The system should be available 24×7 with allowable maintenance windows.

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

#### Interfaces with services
- Optional linkage to a standard web search engine (e.g., Google) from the dedicated search page.
- Potential integration with third-party wiki and blog engines.
- Use of e-mail and SMS services for notifications.

### 1.3.2 Product functions
- Multiple file upload configurable per page (assignments, wikis, forums, announcements, and other upload points).
- Audio recording portfolio for students’ voice clips, including organization, storage, deletion, and flexible download.
- Web feeds (e.g., RSS) for course content components, configurable per page by course administrators.
- Course- and system-wide search with on-page search box and a dedicated search page with filters and grouped results.
- Gradebook enabling assignment grading with feedback, student-only visibility, and grade history with timestamps.
- Social networking tools integrated into the system: a wiki and a blog engine with shared authentication and notifications.
- Notifications via e-mail and SMS for page changes, with subscription and preference controls.

### 1.3.3 User characteristics
- Students: Primary consumers who access posted information, upload assignments and project files, and participate in discussions.
- Professors (course administrators): Primary content administrators who upload materials, create collaborative spaces, and grade assignments.
- System administrators: Maintain system configuration and perform updates; minimal contribution to course content.

### 1.3.4 Limitations
- Enhancements should use Moodle’s existing APIs.
- Limited staffing in the Office of Information Services necessitates a system that is mostly self-sustaining and maintainable without substantial modification.
- Privacy constraints: Only the student user and course administrators for a course can view that student’s grades.
- Availability target is 99% up-time (non–high-availability; allows maintenance windows).
- The University may not ultimately choose Moodle; requirements are framed to apply to any viable courseware system.

## 1.4 Definitions
- Actor: Synonymous with user; used to describe users performing actions in use cases.
- Course administrator: An actor acting as a professor or system administrator who can manage courses and course pages.
- Courseware system: Software to facilitate electronic classroom management, grading, assignment submission, discussion, and other learning tools.
- System: The existing courseware system, a new courseware system, or any modifications being made to Moodle while it is being considered as a replacement.

# 2 References

- Compliance
  - [N/A]
- Guidance
  - Moodle Requirements Brainstorming.pdf. Origin: Results of stakeholder interviews. Details (report number, date, publishing organization, source): [N/A]. Note: Used as background; no further references made within this document.

# 3 Requirements

Priorities are used to indicate delivery expectations:
- Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.
- Priority 2: Not explicitly available today but critical to implementing a courseware system at the University.
- Priority 3: Important enhancements that supplement critical functionality.
- Priority 4: Valuable supplements but not critical.

## 3.1 Functions

- Multiple file transfer (Priority 2)
  - The system must allow actors to upload and manage files at upload points such as assignment submissions, forum posts, wiki pages, and announcements.
  - Course administrators must be able to enable multiple file uploads on a per-page basis during page creation and editing.

- Audio recording and portfolio (Priority 2)
  - The system must capture and organize student voice clips for oral homework over time.
  - Portfolios
    - Professors/administrators have equal and finite drive space to store student-submitted clips and can partition this space among students.
    - Option A: Professors can preview a clip before archiving and decide whether to archive it; with an option to archive post-preview.
    - Option B: Clips are automatically archived upon submission; deletion, if needed, must be performed from the archive.
    - Actors should be able to attach archived clips to any page where uploads are permitted.
  - Download formats
    - Voice clips should be downloadable in a flexible format, such as MP3, for archival and presentation purposes.
  - Storage format and playback
    - Clips should be stored in a format optimized for speech.
    - Conversion to MP3 should occur on download.
    - A cross-platform in-system viewer should be provided for listening.
  - Deletion
    - Actors must be able to review their portfolio and delete clips.

- Web feeds (Priority 1)
  - The system must be able to display web feeds (e.g., RSS 2.0) for pages where content is added (e.g., forum posts, assignments, announcements, wiki edits).
  - Course administrators must be able to enable/disable feeds on a per-page basis and determine the applicable audience.

- Search (Priority 2)
  - A system-wide search utility must allow users to navigate by searching instead of hierarchical links.
  - Course-level search
    - A search box and button must appear on every page after login.
    - If outside a specific course, searches span all courses with results grouped by course; if inside a course, default to that course with an option to search all courses.
  - Dedicated search page
    - Provides a basic search field, filtering by content type (e.g., forum posts, grades), and scoping to specific components.
    - Results should appear in categories (e.g., Assignments, Wiki Pages, Forum Posts) based on relevance (matching terms).
    - Clicking a result navigates to the corresponding page.
    - May optionally support web search using a standard search engine.

- Gradebook (Priority 1)
  - Grading
    - Course administrators must be able to grade assignments using points earned vs. points possible.
    - Feedback may be attached as text and/or attachments.
    - Timestamps must be recorded for the last modification to each grade.
  - Display
    - The system should display, to each student, their assignment grades, averages, and overall grade.
    - Only the student and course administrators for that course can view the student’s grades.
  - History
    - The system should maintain a history of grade changes for each assignment with timestamps.

- Social networking applications (Priority 3)
  - Wiki
    - Provide a freely available wiki with simple markup and page linking for collaborative document networks.
    - Integration within Moodle reduces confusion and enables integrated notifications and logins.
  - Blog engine
    - Provide a freely available blog engine with modern features such as tagging, drafting, and comments.
    - Blogs should share authentication and notifications with Moodle.

- Notifications (Priority 3)
  - The system must provide both e-mail and SMS notifications for pages (e.g., assignment, wiki page, forum post).
  - Per-page control
    - When a page is created, the course administrator can toggle notifications; defaults on for announcements.
  - Subscriptions and preferences
    - If notifications are off, students can subscribe to notifications.
    - Students can select notification channel (SMS or e-mail) and manage their subscriptions.

## 3.2 Performance requirements
- The system should support at least 1,000 concurrent users, particularly during peak periods such as midterms and finals.

## 3.3 Usability requirements
- The system should provide a simple, responsive user interface, minimizing page clutter.
- Configuration should be accessible from a single, central administrative interface to adjust themes and layout across the system.
- A search box should be present on every page after login to reduce navigation steps.

## 3.5 Logical database requirements
- Types of information and entities
  - Users: students, professors, system administrators.
  - Courses and pages: assignments, forums, wikis, announcements, and other upload points.
  - Files and attachments: single and multiple uploads per page.
  - Voice clips: per-user portfolio entries; archive metadata; association to pages when attached.
  - Grades: per-assignment grades, averages, overall grades; timestamps for last modification; grade change history.
  - Feeds: per-page feed enablement metadata and audience configuration.
  - Notifications: per-page notification settings; per-user subscription preferences and channels (e-mail, SMS).
- Frequency of use
  - [N/A]
- Accessing capabilities
  - Students: view own grades; upload assignments; manage own portfolios; manage notification subscriptions.
  - Professors/course administrators: manage courses/pages; enable multi-file uploads and feeds; grade and provide feedback; manage voice clip storage partitions; manage notifications.
  - System administrators: configure and maintain system-wide settings.
- Data entities and relationships
  - Users associated to courses with roles; courses contain pages; pages accept files and may have feeds; grades relate students to assignments; voice clips belong to a user’s portfolio and may be attached to pages; notifications link users to pages and channels.
- Integrity constraints
  - Grade privacy: only the student and course administrators for the course can view the student’s grades.
  - [N/A] for additional constraints.
- Security
  - Access restrictions as stated for grades.
  - [N/A] for additional security controls.
- Data retention requirements
  - Nightly backups with options for weekly off-site backup.
  - Voice clip portfolios maintained over multiple courses to enable longitudinal comparisons.
  - [N/A] for specific retention durations.

## 3.6 Design constraints
- Enhancements must utilize existing Moodle APIs.
- The user interface should be redesigned for consistency with University practices and a more natural flow of data.
- The system must be maintainable without substantial modification due to limited staffing.
- Audio playback within the system must use a cross-platform viewer.
- Licensing requirements: [N/A]
- Applicable standards: [N/A]

## 3.7 Software system attributes
- Reliability
  - The system must be backed up on a configurable schedule, with nightly backups and options for weekly off-site backups.
  - The system must be able to restore from backup within six hours.
- Availability
  - The system should be available 24×7 with a target of 99% up-time, excluding maintenance windows.
- Security
  - Grade information must be visible only to the owning student and relevant course administrators.
  - [N/A] for additional security controls (e.g., cryptography, logging).
- Maintainability
  - Centralized administrative interface for configuration.
  - System should be mostly self-sustaining to reduce support effort.
- Portability
  - [N/A]

## 3.8 Supporting information
- This is a working document subject to change; requirements may be modified and additional requirements added as development progresses.
- Stakeholder needs were gathered via interviews and summarized in the Moodle Requirements Brainstorming.pdf.
- The initial production release will deliver Priority 1 and Priority 2 requirements, along with selected Priority 3 requirements within time and budget constraints.

# 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 seeking a new courseware system and is investigating Moodle as an option; Moodle is assumed to be a viable choice to replace Blackboard.
- Any enhancements will utilize Moodle’s existing APIs.
- The University is not committed to choosing Moodle; Moodle is used as a platform for experience and to contribute back to a real product.
- Peak usage periods (midterms and finals) drive concurrency requirements.
- Delivery scope dependency: Initial release focuses on Priority 1 and 2 requirements, with some Priority 3 items subject to time and budget.

## 5.2 Acronyms and abbreviations
- API: Application Programming Interface.
- FTE: Full-Time Equivalent.
- RSS: Really Simple Syndication.
- SMS: Short Message Service.
- UPS: University of Puget Sound.