# 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. It describes required features to address current instructional and educational requirements, supplemented by nonfunctional requirements and other factors necessary to provide a complete description of the software requirements.

## 1.2 Scope
- Product identification: Enhancements to a courseware system for the University of Puget Sound, applied to Moodle (version [N/A]) as the existing courseware system candidate.
- What the product will do: Provide and refine functionality for course management, including file management, audio recording portfolios, web feeds, search, gradebook, collaborative tools (wiki/blog), and notifications; improve usability through a more natural user interface and centralized administration.
- Application, benefits, objectives, goals: Improve the overall learning experience, support diverse instructional methods, streamline navigation and grading, support language learning through voice clip portfolios, and integrate modern collaborative and notification features. This work also evaluates Moodle’s suitability and identifies enhancements needed to meet university needs.
- Consistency with higher-level specifications: [N/A]

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product comprises enhancements to a courseware system under evaluation (Moodle). Requirements are defined so they can be implemented via Moodle’s existing APIs, while remaining generally applicable to any comparable courseware system.

- System interfaces
  - [N/A]

- User interfaces
  - Provide a simple, responsive interface with a single, central administrative interface to configure UI and features and to reduce page clutter.
  - Allow easy changes to themes and other settings affecting layout across the system.
  - Display a search box and “Search” action on every page after login.

- Hardware interfaces
  - [N/A]

- Software interfaces
  - Utilize existing APIs made available by Moodle.
  - Integrate a freely available wiki and a blog engine; these should share authentication and notifications with Moodle.
  - Specific products, versions, specifications, and interface message formats: [N/A]

- Communications interfaces
  - Email and SMS channels for notifications.
  - Protocols and providers: [N/A]

- Memory constraints
  - Equal and finite drive space is allotted to each professor/administrator for storing submitted voice clips; professors/administrators can partition this space for students.
  - Additional memory constraints: [N/A]

- Operations
  - Backups performed on a configurable schedule (nightly), with options for weekly off-site backups; the system must have the ability and capacity to restore backup data within six hours.
  - Other modes of operation, processing support functions, and unattended operations: [N/A]

- Site adaptation requirements
  - [N/A]

- Interfaces with services
  - Interacts with email and SMS services for notifications; details of service providers and integration methods: [N/A]

### 1.3.2 Product functions
- Multiple file transfer: Allow per-page configuration of multiple file uploads for assignments, forums, wikis, and announcements.
- Audio recording portfolios: Capture, store, organize, download, and delete voice clips; support archiving over time for language learning.
- Web feeds: Provide RSS-style feeds for key pages (forums, assignments, announcements, wikis), configurable per page.
- Search: Provide course-level and cross-course search, including a global search page with filtering and categorized results.
- Gradebook: Post grades with points earned/possible, attach feedback and timestamps, maintain grade histories, and display grades only to the appropriate student and course administrators.
- Social networking applications: Provide an integrated wiki and blog engine with modern features (e.g., markup, tagging, drafting, comments) and shared authentication/notifications.
- Notifications: Provide opt-in/opt-out email and SMS notifications per page; allow course administrators to enable/disable notifications per page, defaulting on for announcements.
- Usability and administration: Provide a centralized administrative interface for configuration and theme/layout changes; minimize page clutter.

### 1.3.3 User characteristics
- Students: Primary consumers; access posted information, upload assignments and project files, and participate in discussions.
- Professors: Primary content administrators; upload content and multimedia, create collaboration spaces, and grade assignments.
- System administrators: Maintain and configure the system; minimally contribute to course content.

### 1.3.4 Limitations
- Assumes Moodle is adopted and enhancements will utilize existing Moodle APIs.
- The specific Moodle version to be used is not identified ([N/A]).
- Availability target is 24x7 with approximately 99% uptime and allowance for maintenance windows.
- Limited staffing in the Office of Information Services implies a need for maintainability and reduced operational burden.
- Regulatory, safety, and security requirements beyond grade privacy are not specified ([N/A]).
- Hardware, software, and communications protocol specifics are not specified ([N/A]).

## 1.4 Definitions
- Actor: Synonymous with user; used to describe users who are 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 and provide electronic grading, assignment submission, discussion, and 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.
- Page: Any distinct upload or content point in the system (e.g., an assignment, a wiki page, a forum post, an announcement, or other distinct block/component).

# 2 References
- Guidance
  - Moodle Requirements Brainstorming.pdf. Source document containing stakeholder interview results that informed these requirements. Report number, date, publishing organization, and source location: [N/A].

- Compliance
  - [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
- Multiple file transfer (Priority: 2)
  - The system must capture and manage files where appropriate (assignments, forums, wikis, announcements).
  - Multiple file uploads must be configurable on a per-page basis by course administrators during page creation and editing.

- Audio recording (Priority: 2)
  - Organize voice clips into a per-actor portfolio archived over time to enable longitudinal comparison of language proficiency.
  - Equal and finite drive space must be allotted to professors/administrators to store submitted clips; they may partition this space for students.
  - Archiving options:
    - Option 1: Allow preview before archiving and decision to archive or discard.
    - Option 2: Automatically archive upon submission; deletions occur from the archive.
  - Allow attaching archived items to any page where uploads are permitted.
  - Voice clips must be downloadable in a flexible format (e.g., MPEG Audio/mp3).
  - Store voice clips in a format optimized for speech; convert to mp3 only at download. Provide a cross-platform in-system player for playback.
  - Allow actors to browse and delete clips from their portfolios.

- Web feeds (Priority: 1)
  - Provide web feeds (e.g., RSS 2.0) for pages/components where new content appears (forums, assignments, announcements, wikis, etc.).
  - Allow course administrators to control which components expose feeds and the audiences for those feeds.
  - Allow enabling or disabling feeds on a per-page basis during page creation/editing.

- Search (Priority: 2)
  - Provide a search capability to navigate directly to content, complementing hierarchical navigation.
  - Course-level search: Search pages within a course; when outside a specific course, search across all courses with results grouped by course.
  - Provide a dedicated search page with:
    - Basic search input.
    - Filters to include/exclude component types (e.g., forums, grades).
    - Categorized results (e.g., Assignments, Wiki Pages, Forum Posts) ordered by relevance (term match count).
    - Links that navigate directly to the result page.
    - Optional world wide web search using a standard engine (e.g., Google).
  - Display a search box on every page after login; default scope is the current course with an option to search all courses.

- Gradebook (Priority: 1)
  - Allow course administrators to grade assignments based on points earned vs. points possible.
  - Allow attaching textual feedback and/or file attachments to grades.
  - Record timestamps for last grade modification.
  - Display to each student their assignment grades, averages, and overall grade; no student may view another’s grades. Course administrators may view grades for their courses.
  - Maintain a grade history for assignments when changes occur, including timestamps.

- Social networking applications (Priority: 3)
  - Provide an integrated wiki allowing collaborative creation and linking of documents with a simple markup language.
  - Provide a blog engine with modern features (e.g., tagging, drafting, comments).
  - Both tools should share authentication and notifications with the courseware system.

- Notifications (Priority: 3)
  - Provide email and SMS notifications for pages (assignments, wiki pages, forum posts, etc.).
  - For each page, course administrators can toggle notifications at creation; default is on for announcements.
  - If notifications are off at the page level, students may subscribe to notifications.
  - Students can set preferences for email vs. SMS and manage their subscriptions.

## 3.2 Performance requirements
- The system should support at least 1,000 concurrent users (Priority: 1).
- Additional throughput, latency, and response-time targets: [N/A]

## 3.3 Usability requirements
- Provide a simple, responsive interface with a single, central administrative interface to configure the UI and features and to reduce page clutter (Priority: 3).
- Allow administrators to easily change themes and other settings that affect layout across the entire system (Priority: 3).
- Provide relevant online user documentation on each page to minimize help requests; supplement with phone and on-site support (Priority: 3).
- Provide comprehensive, searchable documentation for system administrators covering regular maintenance procedures, common errors, and advanced troubleshooting, with results ordered by relevance (Priority: 3).

## 3.5 Logical database requirements
- Information types and entities
  - Users/Actors, Roles (student, professor, system administrator).
  - Courses.
  - Pages/Components (assignments, forum posts, wiki pages, announcements).
  - Files and multiple file attachments per page (where enabled).
  - Audio clips and portfolios per actor; archive entries with metadata.
  - Grade items, grades, timestamps, feedback (text and attachments), grade histories.
  - Notification preferences per user; per-page notification settings; subscriptions.
  - Web feed enablement per page/component.
  - Search index covering courses, pages, and content categories.

- Access and security
  - Only the student and course administrators for a course can view that student’s grades; no other actors may access another student’s grades.

- Integrity constraints
  - Maintain grade histories with timestamps on modifications.
  - Preserve audio clip archives unless explicitly deleted by the actor or per archiving rules.

- Data retention requirements
  - Maintain voice clip archives over multiple courses to support longitudinal comparison.
  - Backup data nightly, with options for weekly off-site backup; restore capability within six hours.
  - Specific retention durations and purging rules: [N/A]

- Frequency of use
  - [N/A]

- Accessing capabilities
  - Allow downloading of voice clips in a flexible format (e.g., mp3).
  - Allow attaching archived audio items to any page where uploads are permitted.
  - Provide course-level and cross-course search with filtering and categorized results.

- Data entities and relationships
  - [N/A] (No formal data model provided.)

## 3.6 Design constraints
- Enhancements must utilize existing Moodle APIs.
- Specific external standards, regulatory constraints, or platform limitations: [N/A]

## 3.7 Software system attributes
- Reliability
  - Back up on a configurable schedule (nightly) with options for weekly off-site backups.
  - Ability and capacity to restore backup data within six hours.

- Availability
  - Intended to be available 24 hours a day, 7 days a week, with allowance for maintenance windows; 99% uptime is sufficient to meet this requirement.

- Security
  - Grade confidentiality as specified under access controls; additional security requirements (e.g., encryption, logging) are [N/A].

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

- Portability
  - [N/A]

## 3.8 Supporting information
- Stakeholder needs were gathered via interviews and summarized in Moodle Requirements Brainstorming.pdf, which informed these requirements.
- The document is a working artifact subject to change as development progresses, serving as a basis for ongoing stakeholder and sponsor discussions.

# 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 investigating Moodle as a replacement for Blackboard and assumes Moodle is a viable choice.
- Any enhancements will utilize existing Moodle APIs.
- The University is not necessarily going to choose Moodle; requirements are framed so they can inform any courseware system.
- Work is intended to be applied to Moodle to implement features stakeholders consider important and, if possible, contribute back to the product.
- Integration with freely available wiki and blog engines is intended; specific components and versions are [N/A].

## 5.2 Acronyms and abbreviations
- API: [N/A]
- RSS: [N/A]
- SMS: [N/A]
- IT: [N/A]
- FTE: [N/A]
- MPEG Audio (mp3): As cited in the original SRS.
