# 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 courseware system to address the University of Puget Sound’s instructional and educational needs. It describes functional and nonfunctional requirements necessary to provide a complete description of the software.

## 1.2 Scope
The software under consideration comprises enhancements to Moodle (version [N/A]) or a comparable courseware system to:
- Provide core course management (courses, assignments, forums, wikis).
- Improve usability and alignment with university practices, including redesigned user interface flows.
- Add missing capabilities (e.g., multiple file uploads per page, audio recording portfolios, web feeds, search, gradebook improvements, notifications, integrated wiki/blog).

Application and benefits:
- Improve overall learning experience for students.
- Enable professors to present materials and grade electronically more efficiently.
- Address shortcomings observed in the current solution (Blackboard) based on stakeholder feedback.
- Where Moodle is adopted, utilize its existing APIs for enhancements.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product may be:
- An enhancement layer to Moodle using existing Moodle APIs, or
- A specification for any courseware system meeting the stated requirements.

System interfaces
- [N/A]

User interfaces
- Provide a simple, responsive interface with a single central administrative interface for configuration (themes and settings affecting layout across the system).
- Display a search box on every page after login, searching either within the current course or across courses, with an option to access a dedicated search page providing filters and categorized, relevance-ranked results.
- Allow per-page toggles for web feed availability.
- Allow per-page toggles for notifications (default on for announcements).
- Provide gradebook views showing per-assignment grades, averages, overall grade to the owning student, with modification timestamps and history visible to course administrators.
- Support per-page configuration for multiple file uploads where appropriate.

Hardware interfaces
- [N/A]

Software interfaces
- Utilize existing Moodle APIs where Moodle is the platform.
- Provide RSS 2.0 web feeds for supported components (e.g., assignments, forums, wikis, announcements).
- Support e-mail and SMS delivery channels for notifications.
- Provide a cross-platform audio clip viewer for listening within the system.

Communications interfaces
- [N/A]

Memory constraints
- Equal and finite drive space must be allotted per professor or system administrator to store student-submitted voice clips; support partitioning that space among students.
- [N/A] for other memory constraints.

Operations
- Support centralized administration for configuration and theme management.
- Support scheduled backups (nightly recommended) and restoration within six hours; options for weekly off-site backups.
- Provide normal user-initiated operations for content creation, submission, grading, and collaboration.

Site adaptation requirements
- [N/A]

Interfaces with services
- [N/A]

### 1.3.2 Product functions
Major functions include:
- Multiple file transfer per page, configurable by course administrators.
- Audio recording portfolio management for students’ voice clips, including storage, preview/archival behavior, download in MP3, playback via a cross-platform viewer, and deletion.
- Web feeds (e.g., RSS 2.0) for course components, configurable per page.
- Search across pages within a course (and optionally all courses), with filters, categorized results, and a global search box on every page.
- Gradebook capabilities: grade entry with points earned/possible, feedback attachments, timestamps, visibility to the appropriate student only, and grade history.
- Social networking applications: integrated wiki and blog engine with shared authentication and notifications.
- Notifications: per-page e-mail and SMS notifications, with default ON for announcements, course-admin toggles, and student preferences and subscription management.

### 1.3.3 User characteristics
- Students: primary consumers; access posted information, upload assignments and project files, discuss concepts.
- Professors: primary content administrators; upload files/links/multimedia, grade assignments, create collaborative spaces.
- System administrators: maintain the courseware system; focus on configuration and updates; minimal contribution to course content.

### 1.3.4 Limitations
- Enhancements, where applied to Moodle, shall utilize existing Moodle APIs.
- [N/A] for regulatory, hardware, or other external constraints not otherwise specified.

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

# 2 References
- Moodle Requirements Brainstorming.pdf — Stakeholder interview results used as foundation for this document. Source: [N/A]. Date: [N/A]. Compliance/Guidance classification: Guidance.

# 3 Requirements
[NULL]

## 3.1 Functions
Priorities:
- Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.
- Priority 2: Not explicitly available today but critical for implementation.
- Priority 3: Important to supplement critical functionality.
- Priority 4: Valuable but not critical.

Multiple file transfer (Priority 2)
- The system must allow actors to upload and manage files where appropriate (e.g., assignment submissions, forum posts, wiki pages, announcements).
- The system must allow multiple file upload to be configured on a per-page basis by course administrators during page creation and editing.

Audio recording (Priority 2)
- The system must capture and organize student voice clips for oral homework and longitudinal tracking.
- The system must allow actors to organize voice clips into a portfolio:
  - Allocate equal and finite storage per professor/system administrator to store student-submitted clips.
  - Professors/system administrators can partition this space among students.
  - Two archival behaviors:
    - Option 1: Professor previews a clip before archiving and chooses whether to archive; may archive after preview.
    - Option 2: Clips are archived automatically upon submission; deletions occur from the archive post-submission if needed.
  - Actors must be able to attach archived items to any page permitting uploads.
- The system must allow actors to download voice clips in a flexible format (e.g., MP3) for archival or presentation purposes.
- The system must store audio clips in a format optimized for speech; provide an in-system cross-platform viewer; convert to MP3 only on download.
- The system must allow actors to view their portfolio and delete recorded clips.

Web feeds (Priority 1)
- The system must display web feeds (e.g., RSS 2.0) for pages where items are added (e.g., forum posts, assignment postings, announcements, wiki edits).
- Course administrators must be able to determine which components have feeds and to whom the feeds pertain.
- Web feeds must be configurable per page (on/off during creation and editing).

Search (Priority 2)
- The system must provide search to navigate pages rather than relying solely on hierarchical links.
- An actor must be able to search through pages within a course:
  - Provide a search box and “Search” button on every page.
  - Provide a dedicated search page with filters (e.g., exclude forums or grades), scoping (specific sections/components), and categorized results (Assignments, Wiki Pages, Forum Posts) ranked by relevance (term match count).
  - Clicking a result navigates to the corresponding page.
  - Optionally include capability to search the web via a standard search engine.
- If searching from outside a specific course, search across the actor’s courses and group results by course; inside a course, search that course with an option to search all courses.

Gradebook (Priority 1)
- Course administrators must be able to grade an assignment based on points earned/possible, attach feedback (text or attachment), and have modification timestamps recorded.
- The system should display grade information (per-assignment grades, averages, overall grade) only to the owning student; only the course’s administrators can view others’ grades.
- The system should maintain a history of grade changes for each assignment with timestamps to support review and dispute handling.

Social networking applications (Priority 3)
- Provide an integrated wiki where actors collaboratively create linked documents with simple markup; integrated notifications and single login reduce confusion.
- Provide an integrated blog engine with modern functionality (tagging, drafting, comments) sharing authentication and notifications.

Notifications (Priority 3)
- Provide both e-mail and SMS notifications for pages (e.g., assignment, wiki page, forum post).
- On page creation, course administrators can toggle notifications (default ON for announcements).
- If notifications are OFF at the page level, students can subscribe individually.
- Students can set preferences for delivery channel (SMS or e-mail) and manage their subscriptions (e.g., unsubscribe).

## 3.2 Performance requirements
- The system should support at least 1,000 concurrent users to accommodate peak periods (e.g., midterms, finals). (Priority 1)

## 3.3 Usability requirements
- The system should provide a simple, responsive interface and a single central administrative interface to configure UI and features across the system, including theme changes and layout-affecting settings. (Priority 3)

## 3.5 Logical database requirements
Information types and access
- Files and attachments: uploaded per page (assignments, forum posts, wiki pages, announcements); support multiple files where enabled.
- Audio portfolios: per-user collections of voice clips with metadata (owner, course/assignment context, timestamps, archival status); clips stored in speech-optimized format; downloadable as MP3.
- Gradebook data: per-course, per-assignment grades with points earned/possible, feedback artifacts, modification timestamps, and a change history.
- Search index: index of pages and content across courses to support relevance-ranked queries and filtering. [N/A for index structure]
- Web feed settings: per-page flags determining feed availability and scope/recipients.
- Notification preferences and subscriptions: per-user delivery channel preferences and per-page/course subscriptions.

Frequency of use
- Frequent read/write for assignments, grades, discussions; frequent read for search; periodic writes for portfolios and notifications. [N/A for quantitative frequencies]

Accessing capabilities
- Role-based access:
  - Students: access to own grades, own portfolios, content pages; ability to subscribe to notifications where allowed.
  - Course administrators: access to manage pages, grades (all students in their courses), portfolios (as required for review), and configuration toggles.

Data entities and relationships
- Users (students, professors, admins)
- Courses
- Pages (assignments, forums, wiki pages, announcements)
- Files (attachments)
- AudioClips (belong to Users; may be linked to Pages)
- Grades (per User per Assignment) with GradeHistory
- NotificationPreferences (per User)
- Subscriptions (User–Page/Course)
- FeedSettings (per Page)

Integrity constraints
- Grade visibility restricted to the owning student and course administrators.
- Grade history is append-only; updates create new history entries with timestamps.
- Storage quotas apply to voice clip archives as configured per professor/administrator.

Security
- Enforce role-based access control for grades and configuration settings.
- [N/A] for additional security controls.

Data retention requirements
- Backups must enable restoration within six hours; nightly backups recommended; optional weekly off-site backups. [N/A for retention periods of specific entities]

## 3.6 Design constraints
- Enhancements must utilize existing Moodle APIs when Moodle is the platform.
- The in-system audio clip viewer must be implemented in a cross-platform language.
- [N/A] for licensing requirements and applicable standards.

## 3.7 Software system attributes
Reliability
- The system must be backed up on a configurable schedule (nightly recommended) with options for weekly off-site backups. It must support restoration within six hours. (Priority 2)

Availability
- The system should be available 24x7 with 99% uptime, excluding reasonable maintenance windows. (Priority 1)

Security
- Grades and grade-related information must only be visible to the owning student and course administrators of the course. (Derived from Gradebook requirement)

Maintainability
- The system must be maintainable without substantial modification to reduce IT staff effort. (Priority 3)

Portability
- [N/A]

## 3.8 Supporting information
- This is a working document subject to change and refinement based on ongoing stakeholder discussions.
- Requirements are based on stakeholder feedback summarized in Moodle Requirements Brainstorming.pdf.

# 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 is evaluating Moodle as a potential replacement for Blackboard.
- This document identifies what any courseware system would need to qualify as a viable solution for the University.
- Where Moodle is adopted, enhancements will utilize existing Moodle APIs.
- The University may ultimately choose a courseware system other than Moodle.

## 5.2 Acronyms and abbreviations
[N/A]
