## 1.1 Purpose

The purpose of the software is to provide a courseware system for the University of Puget Sound that facilitates electronic classroom management and improves the overall learning experience. The system will support electronic grading, assignment submission, discussion, and collaborative tools (e.g., wikis and blogs), and will add university-specific enhancements to Moodle where needed. It aims to streamline navigation and user interface flow, enable features such as multiple file transfers, audio recording portfolios for language learning, web feeds, search-based navigation, gradebook management, and configurable email/SMS notifications, and to better meet the instructional needs of students, professors, and system administrators.

## 1.2 Scope

This SRS defines the scope of enhancements to Moodle, the courseware system candidate for the University of Puget Sound, and specifies the core capabilities required of any courseware system deployed at the University. The scope emphasizes immediate requirements for functionality currently unavailable in Moodle, small redesigns for consistency with University practices, and a user interface redesign to support a more natural flow of data. All enhancements are assumed to utilize existing Moodle APIs and integrations.

Products to be produced:
- Moodle-based courseware deployment for the University of Puget Sound (configured Moodle instance using existing APIs).
- Moodle enhancements and integrations providing:
  - Multiple file transfer at upload points (e.g., assignments, forums, wiki pages).
  - Audio recording with per-user portfolios of voice clips, download support, and deletion.
  - Web feeds (e.g., RSS) for course components with per-page enablement.
  - Course and cross-course search with an always-available search box and a dedicated search page.
  - Gradebook capabilities for posting, viewing, and maintaining grade histories.
  - Integrated social networking applications (wiki and blog engines) sharing authentication and notifications.
  - Notifications via e-mail and SMS with user-managed subscriptions.
- Centralized administrative configuration and user-facing online documentation to support usability and maintainability.

What the software will do:
- Provide electronic classroom management, including assignment submission and grading, discussion, collaboration, content management, and course communications.
- Improve discoverability and timeliness of information through search, web feeds, and notifications.
- Support instructional needs such as voice clip collection and longitudinal portfolios for language learning.
- Offer a simplified, responsive interface consistent with University practices while remaining maintainable by IT staff.

Application, benefits, objectives, and goals:
- Application: University-wide teaching and learning activities used by students (primary consumers), professors (content administrators and graders), and system administrators (system configuration and maintenance).
- Benefits: Improved learning experience and communication; reduced navigation overhead; integrated collaboration; better tracking of student progress (e.g., voice portfolios); and alignment with University workflows.
- Objectives and goals:
  - Deliver Priority 1 (Core) and Priority 2 requirements in the initial release, with feasible Priority 3 items within project constraints.
  - Redesign the user interface for clarity and efficiency and provide a single, central administrative configuration experience.
  - Meet operational expectations such as regular backups and high availability appropriate for academic schedules.

Consistency with higher-level assumptions:
- This scope aligns with the University’s ongoing evaluation of Moodle as a viable replacement for Blackboard and assumes enhancements will be implemented via Moodle’s existing APIs, while also articulating the core capabilities required of any courseware system considered by the University.

### 1.3.1 Product perspective

The product is a set of enhancements and configurations to Moodle intended to meet the University of Puget Sound’s courseware needs and to replace or improve upon the current Blackboard-based solution. These enhancements utilize Moodle’s existing APIs and extend Moodle with improved file handling, audio portfolio management, web feeds, search, gradebook functions, integrated wiki/blog engines, and notifications (email and SMS).

As part of the larger university courseware environment, the product operates as Moodle plus enhancements. It interfaces with:
- Moodle core (via Moodle APIs).
- Integrated social applications (wiki and blog) that share authentication and notifications with Moodle.
- Outbound communication services (email and SMS) for notifications.
- External consumers of web feeds (e.g., RSS readers).
- Backup/restore mechanisms (including optional off-site backup).

Major elements and interconnections (conceptual):
- Users (students, professors, administrators) interact via Moodle’s UI.
- Moodle core provides course, assignment, forum, wiki/blog, and gradebook services.
- Enhancements plug into Moodle via its APIs (file transfer, audio portfolio, search, feeds, notifications, grade history).
- External services include email/SMS delivery and off-site backup; external consumers subscribe to RSS/feeds.

#### System interfaces
- Moodle core APIs
  - Functionality: All enhancements (file upload options, search, feeds, gradebook, notifications, audio portfolio) are implemented as modules/plugins using Moodle’s existing APIs.
  - Interface description: Invocation of Moodle-provided extension points, authentication, authorization, and data access mechanisms. Specific API details: [N/A].
- Wiki engine (integrated)
  - Functionality: Collaborative content creation with simple markup; shares authentication and notifications with Moodle.
  - Interface description: Integrated component with shared login and notification hooks. Specific integration protocol/details: [N/A].
- Blog engine (integrated)
  - Functionality: Blogging (tagging, drafts, comments); shares authentication and notifications with Moodle.
  - Interface description: Integrated component with shared login and notification hooks. Specific integration protocol/details: [N/A].
- Notification gateways (email and SMS)
  - Functionality: Deliver page-level notifications to users via email or SMS according to user preferences and subscriptions.
  - Interface description: Outbound message submission to email and SMS services. Addressing, formats, and gateway details: [N/A].
- Web feeds (e.g., RSS 2.0)
  - Functionality: Publish feeds for assignments, forums, announcements, wikis, etc., on a per-page basis.
  - Interface description: Standards-based feed endpoints (e.g., RSS 2.0). Specific endpoint structure: [N/A].
- Backup/restore system
  - Functionality: Scheduled backups (nightly) with optional weekly off-site backup; restore within six hours.
  - Interface description: Invocation of backup jobs and restore procedures. Storage targets and tooling: [N/A].
- Audio portfolio subsystem
  - Functionality: Store speech-optimized recordings; provide cross-platform playback in Moodle; convert to MP3 for download.
  - Interface description: Internal storage and on-demand conversion process. Codec and viewer details: [N/A].

#### User interfaces
- Consistent, simple, responsive interface with reduced page clutter and a single administrative interface for system-wide configuration (themes, layout, features).
- Course-level search and a global search page; search box visible on every page after login.
- Per-page controls for enabling/disabling:
  - Multiple file upload.
  - Web feeds.
  - Notifications (email/SMS), with defaults enabled for announcements.
- Gradebook UI supports posting points-earned/points-possible, timestamped changes, feedback (text or attachments), and grade history review.
- Audio portfolio UI supports recording submission, preview, optional auto-archive, download (MP3), and deletion by owners.
- Integrated wiki and blog UIs with shared authentication and notification.
- Style guide: [N/A].

#### Hardware interfaces
[N/A]

#### Software interfaces
- Moodle (base platform)
  - Name: Moodle
  - Mnemonic: Moodle
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Host platform; provides course, assignment, forum, authentication, and plugin APIs consumed by the enhancements.
  - Interface definition: Moodle extension/plugin APIs and authentication/session mechanisms. Detailed API references: [N/A].
- Wiki engine (freely available)
  - Name: [N/A]
  - Mnemonic: Wiki
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Collaborative document creation integrated within Moodle.
  - Interface definition: Shares authentication/notification with Moodle. Integration specifics: [N/A].
- Blog engine (freely available)
  - Name: [N/A]
  - Mnemonic: Blog
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Blogging with tagging, drafts, comments; integrated with Moodle.
  - Interface definition: Shares authentication/notification with Moodle. Integration specifics: [N/A].
- Web feed specification
  - Name: RSS 2.0
  - Mnemonic: RSS
  - Specification number: [N/A]
  - Version number: 2.0
  - Source: [N/A]
  - Purpose: Expose updates (assignments, forums, announcements, wikis) for subscription.
  - Interface definition: Feed documents containing item metadata per RSS 2.0; specific element mappings: [N/A].
- Email service
  - Name: [N/A]
  - Mnemonic: Email
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Delivery of notification messages to user email accounts.
  - Interface definition: Outbound email submission; message format/content: [N/A].
- SMS service
  - Name: [N/A]
  - Mnemonic: SMS
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Delivery of notification messages to user mobile devices.
  - Interface definition: Outbound SMS submission; message format/limits: [N/A].
- Audio codec/format
  - Name: MPEG Audio
  - Mnemonic: MP3
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Download format for voice clips; storage uses a speech-optimized format internally.
  - Interface definition: On-demand conversion to MP3 for download; internal storage format details: [N/A].
- Optional external web search
  - Name: [N/A] (e.g., a standard search engine)
  - Mnemonic: Web Search
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Allow searching the world wide web from within the search page.
  - Interface definition: Query submission and results display; protocol details: [N/A].
- Backup/restore tooling
  - Name: [N/A]
  - Mnemonic: Backup
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Execute scheduled backups and restores.
  - Interface definition: Job scheduling, data export/import; storage interface details: [N/A].

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

#### Operations
- Modes of operation:
  - User-initiated interactive operations: browse courses; upload multiple files where enabled; submit/view assignments; post to forums; edit wikis/blogs; record, preview, download, and delete audio clips; subscribe/unsubscribe to notifications; search within a course or across courses.
  - Administrative operations: configure per-page features (feeds, notifications, multi-file upload); manage gradebook entries and feedback with timestamps; manage themes and system-wide settings via a single administrative interface; partition storage for student audio portfolios.
- Periods of operation:
  - Primarily interactive during user activity.
  - Unattended operations include nightly backups and optional weekly off-site backups.
- Data processing support:
  - Maintain grade histories with timestamps; provide feeds for subscribed pages.
- Backup and recovery:
  - Back up on a configurable schedule (nightly recommended) with optional weekly off-site backup; restore capability within six hours.

#### Site adaptation requirements
- Site/course configuration:
  - Enable/disable per-page web feeds and notifications; default notifications enabled for announcements.
  - Enable/disable multiple file upload per page.
  - Configure system-wide themes and layout via a single administrative interface.
  - Define backup schedules (including optional off-site targets).
- Storage and quotas:
  - Allocate equal, finite drive space for audio portfolios to professors/administrators; allow partitioning of this space for students.
  - Choose archival behavior for audio clips (preview-then-archive vs auto-archive).
- Mission/installation specifics: [N/A] (no site-specific initialization sequences provided).

#### Interfaces with services
- Email delivery service for notifications: [N/A] (provider and protocol not specified).
- SMS delivery service for notifications: [N/A] (provider and protocol not specified).
- Off-site backup storage service: [N/A] (provider and interface not specified).
- External RSS consumers (feed readers/aggregators) subscribe to published feeds.
- Optional external web search service: [N/A] (provider and protocol not specified).

### 1.3.2 Product functions

The courseware system provides the following major functional capabilities, organized by domain and user role.

- Content and file management
  - Upload and manage files at designated upload points (e.g., assignments, forum posts, wiki pages, announcements).
  - Configure multiple-file upload on a per-page basis (course administrators/professors).

- Audio recording and portfolio
  - Record, store, and organize voice clips in a per-user portfolio for longitudinal review.
  - Allow professors/administrators to partition storage and choose archival workflow (preview-then-archive or auto-archive).
  - Attach archived clips to any page where uploads are permitted.
  - Download clips in a widely supported format (e.g., MP3) and play clips within the system.
  - Store clips in a speech-optimized format and allow users to delete clips from their portfolio.

- Search and navigation
  - Provide a search box on every page after login.
  - Search within a specific course or across all courses, with results grouped by component (e.g., Assignments, Wiki Pages, Forum Posts).
  - Offer a dedicated search page with filters by component and relevance-ranked results.
  - Optionally include searching the web via a standard search engine.

- Web feeds and subscriptions
  - Generate feeds (e.g., RSS) for pages/components with updates (forums, assignments, announcements, wikis).
  - Enable or disable feeds on a per-page basis and target them to appropriate audiences (course administrators).

- Notifications
  - Send email and SMS notifications for page changes.
  - Toggle notifications per page at creation/edit time (default on for announcements).
  - Allow students to subscribe/unsubscribe and set delivery preferences (SMS or email).

- Assessment and gradebook
  - Enter grades for assignments based on points earned vs. possible, with timestamps for changes.
  - Attach feedback (text and/or file) to graded work.
  - Display assignment grades, averages, and overall grades only to the appropriate student and course administrators.
  - Maintain a grade change history with timestamps.

- Collaboration and social tools
  - Provide an integrated wiki with simple markup and cross-linking for collaborative authoring.
  - Provide an integrated blog engine with tagging, drafting, and comments.
  - Share authentication and notifications across these tools and the core system.

- Administration and support
  - Offer a central administrative interface to configure system-wide settings (e.g., themes, layout) and reduce page-level editing.
  - Schedule and execute backups (e.g., nightly, with weekly/off-site options) and restore data within required timeframes.
  - Provide page-relevant online user help and comprehensive, searchable administrator documentation.

Example user scenarios:
- A professor enables multiple-file uploads for a project, posts an announcement with notifications on by default, grades submissions with file-based feedback, and exposes forum updates via RSS.
- A student searches within a course to find an assignment, subscribes to SMS updates, submits multiple files, and reviews graded feedback.
- A language professor reviews a student’s archived voice clips over time, previews new submissions before archival, and downloads selected clips in MP3 format.

### 1.3.3 User characteristics

The system serves three primary user groups. In this SRS, “actor” is synonymous with “user.”

- Students
  - General characteristics: Primary consumers of the courseware; access information posted by professors, upload assignments and project files, and participate in discussions.
  - Educational level: [N/A]
  - Prior experience with courseware/e-learning systems: [N/A]
  - Disabilities and accessibility needs: [N/A]
  - Technical expertise: [N/A]

- Professors (Course administrators)
  - General characteristics: Primary content administrators; upload files, links, and multimedia; grade assignments; create and manage discussion and collaboration areas.
  - Educational level: [N/A]
  - Prior experience with courseware/e-learning systems: [N/A]
  - Disabilities and accessibility needs: [N/A]
  - Technical expertise: [N/A]

- System administrators (may act as course administrators)
  - General characteristics: Primarily responsible for maintaining the courseware system; modify configuration and perform updates; contribute minimally to course content.
  - Educational level: [N/A]
  - Prior experience with courseware/e-learning systems: [N/A]
  - Disabilities and accessibility needs: [N/A]
  - Technical expertise: [N/A]

### 1.3.4 Limitations

- a) Regulatory requirements and policies
  - [N/A]
- b) Hardware limitations
  - Equal and finite drive space must be allotted for voice-clip portfolios per professor/administrator, with partitioning for students (implies storage quotas for audio).
- c) Interfaces to other applications
  - Enhancements must utilize the existing APIs made available by Moodle.
  - Integrated wiki and blog engines must share authentication and notification with Moodle.
  - Web feeds should use a standard such as RSS 2.0 for pages where applicable.
- d) Parallel operation
  - [N/A]
- e) Audit functions
  - Grade changes must be timestamped, and a history of grades per assignment must be maintained for review and dispute.
- f) Control functions
  - [N/A]
- g) Higher-order language requirements
  - [N/A]
- h) Signal handshake protocols
  - [N/A]
- i) Quality requirements
  - Availability target is 99% uptime, allowing scheduled maintenance.
  - Nightly backups are required, with options for weekly off-site backup; restoration must be possible within six hours.
  - The system should support at least 1,000 concurrent users.
  - The system must be maintainable without substantial modification due to limited IT staff (self-sustaining operation desired).
- j) Criticality of the application
  - The system is expected to be accessible 24/7 including off-hours, but is not required to be highly available; 99% uptime is sufficient.
- k) Safety and security considerations
  - Grade information must be visible only to the student to whom it belongs and course administrators for the relevant course.
- l) Physical/mental considerations
  - [N/A]
- m) Limitations sourced from other systems (including real-time constraints)
  - The solution assumes Moodle as the base platform and that enhancements will operate within Moodle’s plugin architecture and API constraints.
  - Integration of external collaborative components (wiki/blog) is constrained by their ability to share authentication/notification with Moodle.

## 1.4 Definitions

- Actor: Synonymous with user; used to describe users who perform actions in use cases. Often qualified by role (e.g., actor in the role of student).
- Role: The permissioned context in which an actor operates (e.g., student, professor, system administrator, course administrator).
- Course administrator: An actor acting as a professor or system administrator who can manage courses and course pages.
- System administrator: An actor primarily responsible for configuring, maintaining, and updating the courseware system; minimal direct contribution to course content.
- Professor: An actor who creates and manages course content, assesses work, and administers course activities.
- Student: An actor who consumes course content, submits work, and participates in course activities.
- Courseware system / Course management system: Software that facilitates electronic classroom management, including grading, assignment submission, discussion, and related learning tools. These terms are used interchangeably.
- System: The existing courseware system, a new courseware system, or any modifications to Moodle considered as part of the replacement effort.
- Moodle: The candidate courseware system platform to be adopted and enhanced for University needs.
- Blackboard: The incumbent courseware system being considered for replacement.
- University: The University of Puget Sound.
- Office of Information Services: The University’s IT support organization responsible for operating and supporting the system.
- Course: A logical container within the system that groups pages, content, activities, and users for a particular class offering.
- Page: Any distinct item, block, or upload point within the system (e.g., assignment, wiki page, forum post, announcement) that can be created, edited, viewed, or configured.
- Per-page basis: A configuration approach allowing a setting (e.g., multiple file upload, web feeds, notifications) to be enabled or disabled individually for each page/component.
- Upload point: A page that accepts file submissions (e.g., assignment submission, forum post with attachments).
- Assignment: A page or activity for distributing work requirements and collecting student submissions, with associated grading and feedback.
- Gradebook: The part of the system where assignment grades, averages, overall grades, timestamps, and grade history are stored and displayed to authorized actors.
- Voice clip: An audio recording captured or submitted by an actor (typically a student) for instructional purposes (e.g., language assignments).
- Portfolio (audio): A persistent, actor-specific collection of archived voice clips intended to support longitudinal review and comparison; may also be referred to as an archive.
- Archive (audio): See Portfolio (audio); the terms are used interchangeably.
- Web feed: A machine-readable stream of updates (e.g., RSS 2.0) for a page/component, optionally enabled per page by a course administrator.
- Notifications: E-mail or SMS alerts about changes to pages (e.g., new assignments, announcements), which can be enabled by course administrators and managed by users.
- Subscription (notifications): An actor’s opt-in/opt-out preference to receive notifications for specific pages or courses.
- Priority levels: Requirement categorization used in this document:
  - Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.
  - Priority 2: Functionality not explicitly available today but critical for implementing a courseware system at the University.
  - Priority 3: Very important functionality that supplements critical features.
  - Priority 4: Valuable functionality that supplements other features but is not critical.

# 2 References

## Compliance
[N/A]

## Guidance
- Moodle Requirements Brainstorming.pdf
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: [N/A]

## 3.1 Functions

This section partitions the functional requirements into sub-functions. For each sub-function, the following are stated as available from the original SRS: inputs, validity checks, sequence of operations, responses to abnormal situations, effect of parameters, and the relationship of outputs to inputs. Where the original SRS does not specify the requested content, it is marked [N/A].

### 3.1.1 Multiple file transfer (per-page)

- Inputs
  - One or more files uploaded by an actor to a specific page (assignment, wiki page, forum post, announcement).
  - A per-page configuration set by a course administrator/professor to enable multiple file uploads.
- Validity checks on inputs
  - Actor role/permissions: only course administrators/professors can enable multiple file uploads. Other validation: [N/A].
- Exact sequence of operations
  - During page creation or editing, the course administrator/professor enables or disables multiple file uploads.
  - An actor uploads one or more files to the page.
  - The system captures and associates the files with that page.
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - The per-page toggle determines whether multiple files may be attached at that page.
- Relationship of outputs to inputs
  - Input: files; Output: stored files associated with the target page and available for that page’s workflows.
  - Input/output sequences: upload request → validation of role/configuration → store and associate files → confirmation. Additional details: [N/A].
  - Formulas for input to output conversion: [N/A].

### 3.1.2 Audio recording and portfolio

- Inputs
  - Student-submitted voice clips.
  - Professor/system administrator space partitioning for student clips.
  - Archiving mode: preview-then-archive or auto-archive.
  - Requests to download clips and to delete clips.
- Validity checks on inputs
  - Actor role/permissions: professors/system administrators partition space; students submit clips; deletion by the owner of the portfolio. Other validation (format, size, duration): [N/A].
- Exact sequence of operations
  - Student records and submits a voice clip.
  - If preview mode is selected, professor previews and chooses whether to archive; otherwise, the clip is archived automatically on submission.
  - Archived clips remain in the actor’s portfolio and may be attached to any page permitting uploads.
  - Actor may request download (provided as MP3) or delete selected clips from the portfolio.
- Responses to abnormal situations
  - Overflow: finite drive space is allotted per professor/administrator; behavior on quota exceedance: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - Archiving mode selection determines whether manual approval is required before archiving.
  - Space partitioning by professors/administrators affects available storage per student.
- Relationship of outputs to inputs
  - Storage format is optimized for speech; on download, the system converts the stored clip to MP3.
  - Input/output sequences: submit clip → (optional) preview decision → archive to portfolio → optional attach/delete/download.
  - Formulas for input to output conversion: conversion to MP3 on download; specific encoding parameters: [N/A].

### 3.1.3 Web feeds (per-page)

- Inputs
  - Content creation/updates for pages containing assignments, wiki edits, forum posts, announcements, etc.
  - Course administrator setting to enable/disable feeds per page and define to whom feeds pertain.
- Validity checks on inputs
  - Actor role/permissions: only course administrators control feed availability and scope. Other validation: [N/A].
- Exact sequence of operations
  - On page creation or edit, the course administrator toggles feed availability.
  - When feed-enabled content changes, the system updates the corresponding web feed.
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - Per-page feed toggle determines whether changes generate feed items.
  - Administrator can specify which components have feeds and their intended audience.
- Relationship of outputs to inputs
  - Input: content changes; Output: updated feed entries representing those changes.
  - Input/output sequences: page change → feed generation/update → feed consumption by subscribers. Additional delivery details: [N/A].
  - Formulas for input to output conversion: [N/A].

### 3.1.4 Search

- Inputs
  - Search queries entered from the search box on any page after login or from the dedicated search page.
  - Optional filters (e.g., include/exclude forum posts, grades, specific sections).
  - Scope: within a specific course when inside that course; across all courses when outside any course (with option to broaden scope).
- Validity checks on inputs
  - Actor must be logged in; scope respects the actor’s course enrollments and access rights. Other validation: [N/A].
- Exact sequence of operations
  - Actor enters a query (and optional filters) via search box or dedicated search page.
  - System determines scope (current course or all courses, per location and options).
  - System searches and returns results grouped by category (Assignments, Wiki Pages, Forum Posts, etc.), ranked by relevance.
  - Actor selects a result; the system navigates to the corresponding page.
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - Filters affect which item types appear in results.
  - Scope selection affects which repositories (course/all courses) are searched.
- Relationship of outputs to inputs
  - Relevance is determined by the number of query terms matched; results with a higher count of matching terms rank higher.
  - Input/output sequences: query + filters + scope → search → grouped, ranked results → navigation to selected item.
  - Formulas for input to output conversion: relevance = function of count of matching terms; precise scoring beyond this definition: [N/A].

### 3.1.5 Gradebook

- Inputs
  - Course administrator entries: points earned and points possible per assignment; optional text or file feedback.
  - Grade change operations by course administrators.
- Validity checks on inputs
  - Actor role/permissions: only course administrators may post/change grades; grade visibility restricted to the student owner and course administrators. Other validation: [N/A].
- Exact sequence of operations
  - Course administrator records a grade as a ratio of points earned to points possible and optionally attaches feedback.
  - The system timestamps the grade’s last modification.
  - The system displays grade information (assignment grades, averages, overall grade) to the appropriate student.
  - On grade changes, the system records history with timestamps.
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - [N/A].
- Relationship of outputs to inputs
  - Assignment grade is derived from points earned / points possible; display of averages and overall grade is required; exact overall grade formula: [N/A].
  - Input/output sequences: grade entry → timestamp → student-facing display → optional subsequent changes → history updated.
  - Formulas for input to output conversion: per-assignment ratio; other aggregation formulas: [N/A].

### 3.1.6 Social networking applications (wiki and blog)

- Inputs
  - Wiki: actor edits using simple markup; links to other wiki pages.
  - Blog: actor creates posts with tagging, drafting, and comments.
  - Shared authentication and notification with the courseware system.
- Validity checks on inputs
  - [N/A].
- Exact sequence of operations
  - Wiki: actor creates/edits pages; system stores revisions and links pages. Detailed revision behavior: [N/A].
  - Blog: actor drafts/publishes posts; actors comment; system associates tags. Detailed workflows: [N/A].
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - Integration with the system’s authentication and notification affects access and notifications.
- Relationship of outputs to inputs
  - Wiki/blog content reflects actor inputs and is available within Moodle with integrated notifications. Detailed mappings: [N/A].
  - Input/output sequences and formulas: [N/A].

### 3.1.7 Notifications (email and SMS)

- Inputs
  - Page creation/updates on distinct pages (assignment, wiki page, forum post, etc.).
  - Per-page notification toggle set by the course administrator; default ON for announcements.
  - Student subscription requests when notifications are OFF.
  - Student preferences for delivery channel (SMS or email) and subscription management actions.
- Validity checks on inputs
  - Actor role/permissions for toggling notifications (course administrator); subscription changes by the student owner. Other validation: [N/A].
- Exact sequence of operations
  - On page creation/edit, the course administrator sets notification availability (default ON for announcements).
  - If notifications are OFF, students may subscribe to that page.
  - Students configure delivery preference (SMS or email) and manage subscriptions.
  - On subsequent page changes, the system sends notifications per subscriptions and preferences.
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities (email/SMS delivery failures): [N/A].
  - Hardware faults and failures: [N/A].
  - Error handling and recovery: [N/A].
- Effect of parameters
  - Per-page toggle and user delivery preferences determine whether and how notifications are sent.
- Relationship of outputs to inputs
  - Input: page change events + subscription state; Output: notifications via selected channel(s).
  - Input/output sequences: event → determine eligible subscribers → deliver via chosen channels. Delivery guarantees: [N/A].
  - Formulas for input to output conversion: [N/A].

### 3.1.8 Backup and restore

- Inputs
  - Configurable backup schedule (nightly; optional weekly off-site).
  - Restore initiation when needed.
- Validity checks on inputs
  - [N/A].
- Exact sequence of operations
  - System performs backups per configured schedule to protect system and course data.
  - When restoration is required, the system restores backup data within six hours.
- Responses to abnormal situations
  - Overflow: [N/A].
  - Communication facilities: [N/A].
  - Hardware faults and failures: restoration of backup data within six hours is required to minimize downtime.
  - Error handling and recovery: restore operation as above; additional procedures: [N/A].
- Effect of parameters
  - Backup frequency (nightly; optional weekly off-site) affects recovery point objectives.
- Relationship of outputs to inputs
  - Input: scheduled backup; Output: backup artifacts usable for restoration.
  - Input/output sequences: schedule triggers → backup execution → on fault → initiate restore → system state recovered within six hours.
  - Formulas for input to output conversion: [N/A].

## 3.2 Performance requirements

Static numerical requirements:
- Simultaneous users supported: The system should support at least 1,000 concurrent users.
- Number of terminals to be supported: [N/A]
- Amount of information to be handled (e.g., total storage, per-user quotas): [N/A]
- Types of information handled: assignments, uploaded files, forum posts, wiki pages, announcements, voice/audio clips, grades, notifications.

Dynamic numerical requirements:
- Availability: The system should be available 24 hours a day, 7 days a week, with at least 99% uptime (excluding scheduled maintenance).
- Backup and restore:
  - Backup schedule: The system should support a configurable schedule and be backed up on a nightly basis, with options for weekly off-site backups.
  - Restore time: The system must have the ability and capacity to restore backup data within 6 hours.
- Transactions/tasks throughput under normal and peak workload conditions: [N/A]
- Response times for user interactions (e.g., page loads, searches, submissions): [N/A]
- Data processed per time period (e.g., uploads/downloads per hour, feed updates per minute): [N/A]

## 3.3 Usability requirements

- The system should provide a simple, responsive interface that reduces page clutter and is easy to use.
- The system should be configurable from a single, central administrative interface, allowing administrators to edit pages without navigating individual links and to change themes and other layout settings across the entire system.
- A search box must be displayed on every page after an actor has logged in. If the actor is within a course, the default search scope is that course with an option to search all courses; if outside any course, all of the actor’s courses should be searched with results grouped by course.
- The system must provide a dedicated search page that allows filtering by component (e.g., assignments, wiki pages, forum posts), shows results grouped by category based on relevance, and navigates the actor to the selected page when a result is chosen.
- Relevant, online user documentation should be available on each page, with modifications reported via the main page; this electronic documentation is to be supplemented with phone and on‑site support.
- System administrators must have access to comprehensive, searchable documentation with results ordered by relevance, covering all procedures necessary for regular maintenance, common errors, and advanced troubleshooting.

- Measurable effectiveness criteria: [N/A]
- Measurable efficiency criteria: [N/A]
- Measurable satisfaction criteria: [N/A]
- Avoidance of harm in specific contexts of use: [N/A]

## 3.5 Logical database requirements

This section specifies the logical requirements for information to be persisted to support the described functions.

- Types of information used by various functions
  - Users/Actors and roles: actor identity and role(s) (student, professor/course administrator, system administrator).
  - Courses: course identity and membership (actors enrolled or administering).
  - Pages (generic content units): assignments, wiki pages, forum posts, announcements, and similar items where uploads and interactions occur; per-page settings (e.g., multiple-file-upload enabled/disabled; web feed enabled/disabled; notifications enabled/disabled).
  - File uploads/attachments: files uploaded to pages (e.g., assignment submissions, forum post attachments).
  - Audio voice clips and portfolios: audio recordings, association to an actor’s portfolio, and option to attach an archived clip to any page permitting uploads; storage format optimized for speech; download format (e.g., mp3) generated at download time.
  - Web feeds: feed configuration per page and feed items reflecting additions/changes to pages such as forum posts, assignment postings, announcements, and wiki alterations; intended audience as determined by course administrators.
  - Search: searchable page content at course scope and across courses; result categorization by component (e.g., Assignments, Wiki Pages, Forum Posts) and ordering by relevance.
  - Gradebook: grades per assignment per student with points earned, points possible, optional textual feedback, optional feedback attachment, and timestamps for last modification; grade history for changed grades.
  - Notifications: per-page notification setting, student subscriptions when notifications are off, and delivery preferences (SMS or e-mail); default notifications on for announcements.
  - Online help and documentation: page-relevant user help; comprehensive, searchable administrator documentation.
  - Backup/restore metadata: schedules and capabilities necessary to meet backup frequency and restore time.

- Frequency of use
  - Backups must run on a nightly basis, with options for weekly, off-site backup when necessary.
  - Search is available from every page after login and at course scope and cross-course scope.
  - Web feeds are updated when new content is added to or changed on relevant pages.
  - Notifications are generated for pages where notifications are enabled; notifications default to on for announcements; students may subscribe when notifications are off.
  - Grade history entries are created whenever a grade is changed.
  - Quantitative rates (e.g., transactions per hour for uploads, searches, or notifications) [N/A].

- Accessing capabilities
  - Role-based access to courses and pages; course administrators manage courses and pages.
  - Search access from every page after login; search within a course or across all courses, with results grouped by course when searching outside a specific course.
  - Download access for audio voice clips in a common format (e.g., mp3) for archival or presentation; in-application playback via a cross-platform viewer.
  - Grade viewing restricted to the student owner and the course administrator(s) for the course; course administrators can create/modify grades and view grade history.
  - Subscription management for notifications by students (subscribe/unsubscribe; SMS or e-mail preference).
  - Course administrators can toggle web feeds per page and determine intended audiences.
  - Users have access to relevant help on each page; system administrators can search administrator documentation.

- Data entities and relationships
  - Actor (User): has one or more Roles; enrolls in zero or more Courses; owns one Portfolio; has zero or more Notification Subscriptions; may have Feed access as permitted.
  - Role: Student, Professor/Course Administrator, System Administrator; associated to Actors.
  - Course: contains Pages; associated with Course Administrators and enrolled Students.
  - Page: represents Assignments, Wiki Pages, Forum Posts, Announcements, etc.; belongs to a Course; has per-page settings (multiple-file-upload flag; web feed enabled/disabled; notifications enabled/disabled); has zero or more File Attachments; may have associated Help content; may have an associated Web Feed.
  - Assignment (Page subtype): associated with zero or more Grades (each for a Student).
  - Grade: links a Student, an Assignment, and a Course Administrator (as grader); stores points earned, points possible, optional textual feedback, optional feedback attachment, and last-modified timestamp; has zero or more Grade History records.
  - Grade History: records changes to a Grade with timestamp and prior values necessary to audit changes.
  - File Attachment: uploaded by an Actor; attached to a Page or to Grade feedback as applicable; subject to per-page multiple-upload setting.
  - Portfolio: belongs to an Actor; contains zero or more Voice Clips.
  - Voice Clip: belongs to a Portfolio (Actor); can optionally be attached to any Page that permits uploads; stored in a speech-optimized format; downloadable as mp3.
  - Web Feed: belongs to a Page; contains zero or more Feed Items; availability toggled per Page; audience as configured by Course Administrator.
  - Feed Item: represents an event (e.g., new forum post, assignment posting, announcement, wiki alteration) with timestamp.
  - Notification Subscription: per Actor per Page; stores delivery preference (SMS or e-mail); present only when notifications are off and a student subscribes or when notifications are on and the Actor opts to manage subscription.
  - Help Content: relevant documentation associated with a Page.
  - Administrator Documentation: comprehensive help content for system administrators; searchable repository.
  - Searchable Content: derived from Pages for search and categorization; persistent indexing requirements [N/A].

- Integrity constraints
  - Each Grade must record points earned and points possible.
  - Each Grade modification must record a last-modified timestamp, and Grade History must preserve prior values for auditing changes.
  - Notification default for Announcements pages is enabled.
  - Web Feed availability must be configurable per Page (on/off).
  - Multiple-file upload must be configurable per Page (enabled/disabled) and enforced for attachments on that Page.
  - Voice Clips must be stored in a format optimized for speech; conversion to mp3 occurs only at download time.
  - Storage quotas: equal and finite drive space must be allotted per Professor/System Administrator for storing student-submitted voice clips; this space must be partitionable by those actors for their students.
  - Users must be able to delete their own Voice Clips from their Portfolio.
  - Result categorization by component type (e.g., Assignments, Wiki Pages, Forum Posts) and ranking by relevance must be supported in search results; calculation/persistence specifics [N/A].
  - Keys, uniqueness, and referential integrity details beyond the relationships listed above [N/A].

- Security
  - Grade privacy: only the student to whom grades belong and the course administrator(s) for the course may view those grades.
  - Access to configure Pages (feeds, notifications, multiple-file upload) is restricted to Course Administrators.
  - Blogs and wikis must share authentication with the courseware system (single sign-on) so that access is consistent with roles.
  - Web Feed access must be limited to the intended audience as determined by Course Administrators.
  - Security controls such as encryption at rest/in transit, auditing beyond grade history, and detailed authorization models [N/A].

- Data retention requirements
  - Voice Clips should be maintained in each Actor’s Portfolio over the Actor’s existence in the system, to enable longitudinal comparison across courses; users may delete clips.
  - Grade History must be retained for changed grades to support review and dispute resolution timelines; specific retention duration [N/A].
  - Backups: nightly backups with options for weekly, off-site backup; backup retention duration and rotation policy [N/A].
  - Online user and administrator documentation availability is required; archival/retention policies for documentation [N/A].

## 3.6 Design constraints

- Platform and integration
  - Enhancements must utilize existing Moodle APIs and operate within Moodle.
  - Integrated social features (wiki, blog) must share authentication and notifications with Moodle and avoid reliance on external third-party services.

- Standards and data formats
  - Web feeds should use RSS 2.0.
  - Audio clips must be downloadable as MPEG Audio (MP3); clips should be stored in a format optimized for speech, with a cross-platform in-browser player.

- Operational and project limitations
  - Due to limited Office of Information Services staff, the system must be maintainable without substantial modification and largely self-sustaining.
  - Administration should be centralized via a single interface to configure UI themes and system-wide settings to reduce maintenance overhead.
  - Backups must be on a configurable schedule (nightly with optional weekly off-site), with the ability to restore within six hours.
  - Intended availability is 24x7 with approximately 99% uptime.

- Regulatory and compliance constraints
  - [N/A]

- Licensing constraints
  - Preference for freely available solutions to be integrated into Moodle; specific licensing requirements are otherwise [N/A].

## 3.7 Software system attributes

### Reliability
- The system must be backed up on a configurable schedule.
- The system should be backed up nightly, with options for weekly, off-site backup when necessary.
- The system must have the ability and capacity to restore backup data within six hours so the system is not offline for an inordinate period of time.

### Availability
- The system should be available 24 hours a day, 7 days a week.
- Scheduled maintenance windows and downtime are permitted.
- 99% up-time is sufficient to meet this availability requirement.
- Recovery from backups must restore service within six hours when required.

### Security
- Grade confidentiality: the system should display grade information (e.g., per-assignment grades, averages, overall grade) only to the actor to whom the grades belong and to course administrators for the corresponding course.
- Auditability: the system should maintain a history of grade changes with timestamps so changes can be reviewed and disputed if necessary.
- Authentication consistency: integrated wiki and blog components must share authentication with the courseware system.
- Administrative control over information exposure: course administrators must be able to enable or disable web feeds on a per-page basis.
- Cryptographic techniques: [N/A]
- Module/function segregation for security: [N/A]
- Communication restrictions between subsystems: [N/A]
- Data integrity checks for critical variables: [N/A]
- Assurances of data privacy beyond grades: [N/A]

### Maintainability and supportability
- The system must be maintainable without substantial modification and should be mostly self-sustaining to reduce staffing effort.
- A single, central administrative interface must allow administrators to configure the user interface and features, including system-wide theme and layout settings, to reduce page clutter.
- Relevant online user documentation should be available on each page; modifications should be reported via the main page; phone and on-site support will supplement electronic documentation.
- System administrators must have access to comprehensive, searchable documentation that covers all procedures necessary for regular maintenance, common errors, and advanced troubleshooting, with search results displayed based on relevance.

### Portability
- [N/A]

## 3.8 Supporting information

This section collates supporting and background information referenced or implied by the SRS to aid readers’ understanding.

- a) Sample input/output formats and related artifacts
  - Example data formats referenced in the SRS:
    - Web feeds: RSS 2.0.
    - Audio: stored in a speech-optimized format; downloadable as MPEG Audio (mp3).
    - Notifications: e-mail and SMS.
    - Grades: points earned/possible with modification timestamps; grade history retained.
    - Search results: grouped by category (e.g., Assignments, Wiki Pages, Forum Posts) and ordered by relevance.
  - Cost analysis studies: [N/A]
  - User surveys/interviews:
    - Stakeholder interviews were conducted and summarized in “Moodle Requirements Brainstorming.pdf” (referenced in Section 1.4.1).
    - Detailed survey results within this SRS: [N/A]

- b) Supporting/background information helpful to readers
  - Context and scope:
    - The University is evaluating Moodle as a candidate replacement for Blackboard; enhancements are intended to use Moodle’s existing APIs.
    - The SRS focuses on core functionality currently unavailable or inadequate in the existing solution and proposes UI redesigns to improve the flow of data.
    - This is a working document subject to refinement; initial delivery targets Priority 1 and Priority 2 requirements, with some Priority 3 items as feasible.
  - Stakeholders and users:
    - Primary users: Students (consumers of course content), Professors (content administrators and graders), System Administrators (system maintenance).
  - Operational expectations (informative summary of requirements stated elsewhere):
    - Availability target: 24x7 access with 99% uptime expectation.
    - Performance target: support at least 1,000 concurrent users.
    - Reliability/backup: nightly backups (with options for weekly off-site), ability to restore within six hours.
    - Support: relevant online help on each page; comprehensive, searchable admin documentation.

- c) Description of the problems to be solved by the software
  - Navigation and usability: Moodle can be difficult to navigate; too many steps for common tasks (e.g., assignment submission); need for integrated search and streamlined UI.
  - Awareness of changes: Lack of timely notifications (e-mail/SMS) for new or updated content (assignments, announcements, forum posts, wikis).
  - Content syndication: Need for configurable web feeds so users can track updates efficiently.
  - Submission flexibility: Need for multiple file uploads on a per-page basis (e.g., assignments with multiple parts, collaborative projects).
  - Language learning support: Foreign language programs need to capture, store, organize, and review student voice clips across courses.
  - Collaboration tools: Built-in social/collaborative features (wikis, blogs) are insufficient and need to be more robust and integrated.
  - Assessment management: Faculty need grade posting with feedback, visibility controls, timestamps, and grade history for audit/dispute resolution.

- d) Special packaging instructions (security, export, initial loading, media)
  - [N/A]

Unless an item above is explicitly stated as a requirement in Section 3 (Requirements) or otherwise cross-referenced as mandatory, the information in this Supporting Information section is provided for background only and is not itself a requirement.

## 4.1 Functions

This section defines the planned verification approaches for the functional requirements in 3.1 Functions (corresponding to Specific Requirements 3.1–3.7). For each function, verification is organized per items a–e: a) validity checks on inputs; b) exact sequence of operations; c) responses to abnormal situations (overflow, communication facilities, hardware faults/failures, error handling and recovery); d) effect of parameters; e) relationship of outputs to inputs (input/output sequences; formulas for input-to-output conversion). Where the original SRS does not specify the item, it is marked [N/A]. The primary methods include requirements and design reviews, UI walkthroughs, functional test cases, integration/system tests, and stakeholder acceptance tests.

- 3.1 Multiple File Transfer (incl. 3.1.1 per-page configuration)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Verify a course administrator can enable/disable multiple file upload during page creation and editing.
    - Verify an actor can upload multiple files to enabled pages and only a single file when disabled.
    - Method: UI test scripts and end-to-end tests per page type (assignments, forums, wikis, announcements).
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters:
    - Verify the per-page toggle controls availability of multiple file upload for that page only.
    - Method: configuration change test; regression test across different pages.
  - e) Relationship of outputs to inputs:
    - Input/output sequences: Upload n files; confirm n distinct attachments are stored and visible on the target page and downloadable without alteration.
    - Formulas: [N/A]

- 3.2 Audio Recording (incl. 3.2.1 portfolio and archiving, 3.2.2 download format, 3.2.3 storage format and viewer, 3.2.4 deletion)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Archiving modes: verify both options
      - Preview-then-archive: record clip, preview, choose to archive, confirm inclusion in portfolio or discard when rejected.
      - Auto-archive: record clip, confirm automatic inclusion in portfolio.
    - Partitioning: verify professors/administrators can allocate/partition storage space for students.
    - Attaching archived items: verify an actor can attach an archived clip to any page that permits uploads.
    - Deletion: verify an actor can browse portfolio and delete selected clips.
    - Method: scenario-based acceptance tests with portfolio state assertions.
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters:
    - Verify selected archiving mode affects whether preview is required and when archiving occurs.
    - Verify storage partition settings constrain portfolio capacity as configured.
    - Method: configuration-driven tests.
  - e) Relationship of outputs to inputs:
    - Input/output sequences: record → archive per selected mode → list in portfolio → attach to page → download.
    - Formulas:
      - Verify downloads are provided in MPEG Audio (mp3) format as specified; verify storage remains in a speech-optimized format and conversion to mp3 occurs only at download time.
      - Viewer: verify clips play via the provided cross-platform viewer within Moodle.

- 3.3 Web Feeds (incl. 3.3.1 per-page toggle)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Verify a course administrator can enable/disable feeds during page creation/editing.
    - Verify that creating/updating items (e.g., assignments, wiki edits, forum posts, announcements) publishes corresponding feed entries when enabled.
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters:
    - Verify per-page feed toggle governs feed generation only for that page/component and can be scoped “to whom feeds pertain” per the administrator’s selection.
  - e) Relationship of outputs to inputs:
    - Input/output sequences: content change → feed entry created → feed consumers can retrieve and view entries containing accurate titles, timestamps, and links back to source pages.
    - Formulas: [N/A]

- 3.4 Search (incl. 3.4.1 course search and dedicated page, 3.4.2 search box on every page)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Global vs in-course context: verify that searching outside any course queries all courses with grouping by course; verify that searching within a course limits results to that course with an option to expand to all courses.
    - Dedicated search page: verify presence of filters to include/exclude result types (e.g., forum posts, grades) and sections; verify navigation from results to target pages.
    - Presence: verify search box appears on every page after login.
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters:
    - Verify selected filters and scopes affect the returned result set accordingly.
  - e) Relationship of outputs to inputs:
    - Input/output sequences: enter query → apply filters → submit → results grouped by category (Assignments, Wiki Pages, Forum Posts, etc.) and by course when applicable → select result → navigate to target page.
    - Formulas:
      - Relevance ordering: verify results are ranked by the number of terms matching the search terms as specified.

- 3.5 Gradebook (incl. 3.5.1 grading and feedback, 3.5.2 visibility, 3.5.3 history)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Grading: verify course administrators can enter points earned and points possible, post grades, and attach feedback as text or file; verify timestamps on last modification.
    - Visibility: verify only the grade owner (student) and course administrators can view a student’s grades; verify display of assignment grades, averages, and overall grade to the appropriate actor.
    - History: verify grade changes are versioned with timestamps and are reviewable.
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters:
    - Verify changes to points possible/earned affect displayed grades and history appropriately.
  - e) Relationship of outputs to inputs:
    - Input/output sequences: enter grade components → compute and display grade → update timestamps → restrict visibility.
    - Formulas:
      - Verify per-assignment grade is based on the ratio of points earned to points possible, as specified.
      - Overall grade formula: [N/A]

- 3.6 Social Networking Applications (incl. 3.6.1 wiki, 3.6.2 blog)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Wiki: verify creation/editing of pages using simple markup; verify linking between pages; verify in-Moodle authentication and notifications integration.
    - Blog: verify drafting, publishing, tagging, and commenting; verify shared authentication and notification with Moodle.
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters: [N/A]
  - e) Relationship of outputs to inputs:
    - Input/output sequences: author content → save/publish → content visible with correct tags/links and notifications where applicable.
    - Formulas: [N/A]

- 3.7 Notifications (incl. 3.7.1 e-mail and SMS for pages)
  - a) Validity checks on inputs: [N/A]
  - b) Exact sequence of operations:
    - Per-page toggle: verify course administrator can enable/disable notifications at page creation; verify default ON for announcements.
    - Subscriptions: with notifications OFF, verify students can subscribe; verify students can manage subscriptions (e.g., unsubscribe).
    - Delivery preference: verify students can set SMS or e-mail preference and receive notifications accordingly when pages are created/changed.
  - c) Responses to abnormal situations:
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: [N/A]
  - d) Effect of parameters:
    - Verify page-level settings and user preferences govern whether, how, and to whom notifications are sent.
  - e) Relationship of outputs to inputs:
    - Input/output sequences: page event (create/update) → evaluate page toggle and user subscriptions/preferences → dispatch e-mail or SMS → recipients receive message with link to source page.
    - Formulas: [N/A]

## 4.2 Performance requirements

This section defines the verification approaches and methods to qualify the software against the performance requirements in 3.2. Items are organized in parallel with the recommended static and dynamic performance topics.

- Static performance requirements
  - a) Number of terminals to be supported
    - Requirement: [N/A]
    - Verification method: [N/A]
  - b) Number of simultaneous users to be supported
    - Requirement: The system should support at least 1,000 concurrent users.
    - Verification method: Load and concurrency testing using representative user workflows (for example, login, navigate course pages, upload/download assignments, post to forums, execute searches, view grades, and subscribe to feeds).
    - Test setup: Production-representative environment and data seeding (typical numbers of users, courses, assignments, forums). Centralized logging and resource monitoring enabled.
    - Procedure: Ramp to and sustain 1,000 concurrent authenticated sessions executing the defined workflow mix during a period representative of peak usage (e.g., midterm/finals). Include negative/ramp-down and recovery observations.
    - Pass/fail criteria: No load-induced outages or service restarts; all scripted transactions complete successfully for all virtual users; no data loss or corruption; error logs contain no critical errors attributable to load.
    - Evidence: Test plan, test scripts, raw and summarized load results, application/OS metrics, and execution logs.
  - c) Amount and type of information to be handled
    - Requirement: [N/A]
    - Verification method: [N/A]

- Dynamic performance requirements (throughput/latency under normal and peak workloads)
  - Requirement(s): [N/A]
  - Verification method(s): [N/A]

- General performance verification practices (applicable to all above where defined)
  - Instrumentation: Enable application and infrastructure metrics (CPU, memory, I/O, network), request/error rates, and timing at key endpoints.
  - Data readiness: Seed realistic datasets and file sizes consistent with intended course usage patterns.
  - Repeatability: Automate test execution and environment provisioning to allow re-runs and regression comparisons.
  - Reporting: Provide a verification report mapping results to each stated performance requirement in 3.2, with objective pass/fail determinations and collected evidence.

## 4.3 Usability requirements

This subsection defines the planned verification approaches and methods for the usability requirements identified in section 3.3 Usability requirements. Verification is organized in parallel to those requirements. Where quantitative acceptance targets are not defined in the original SRS, they are noted as [N/A].

- Simple, responsive interface with centralized administration (origin: 4.1.1)
  - Verification methods:
    - Expert heuristic evaluation against established usability heuristics, focusing on simplicity, consistency, and reduction of page clutter.
    - Cognitive walkthroughs of core administrative and instructional tasks performed from a single central interface (e.g., configure site/course UI, change themes, enable per-page features).
    - Task-based usability testing with representative course administrators and professors to complete common tasks using only the central administrative interface; collect steps, time-on-task, success rate, and error incidence.
    - Configuration propagation check: change a global theme/setting and verify it applies across the system without per-page edits.
  - Evidence to collect:
    - Heuristic evaluation findings, task success/failure logs, click/step counts, time-on-task, and participant feedback.
  - Acceptance criteria: [N/A]
  - Avoidance of harm (from use): [N/A]

- Contextual online user documentation on each page (origin: 4.6.1)
  - Verification methods:
    - Systematic page-type audit (e.g., assignments, forums, wikis, gradebook, announcements, administrative pages) to verify presence of page-relevant help links or panels.
    - Content relevance review to confirm help matches the current page’s functionality; broken-link and accessibility checks for help entry points.
    - Change notification check: perform representative modifications and verify that a notice appears on the main page informing users of unexpected changes.
  - Evidence to collect:
    - Coverage matrix of pages audited, link integrity report, sample screenshots, and traceability from page types to corresponding help topics.
  - Acceptance criteria: [N/A]
  - Avoidance of harm (from use): [N/A]

- Comprehensive, searchable administrator documentation (origin: 4.6.2)
  - Verification methods:
    - Documentation completeness review against required topic areas (regular maintenance procedures, common errors, advanced troubleshooting), including presence of links to additional information.
    - Search quality testing with predefined administrative queries; assess whether expected documents are returned and appropriately ranked for relevance.
    - Usability inspection of the documentation interface for findability (navigation, categorization, cross-linking).
  - Evidence to collect:
    - Completeness checklist with coverage status, search test logs with retrieved results and ranks, and navigation/cross-linking review notes.
  - Acceptance criteria: [N/A]
  - Avoidance of harm (from use): [N/A]

General notes:
- Effectiveness, efficiency, and satisfaction targets for usability testing are [N/A].
- Accessibility-specific verification is [N/A].

## 4.5 Logical database requirements

This section describes how the logical database requirements will be verified. The verification items align with the recommended aspects a) through g). Where the original SRS does not specify a needed detail, it is identified as [N/A].

### a) Types of information used by various functions — Verification
- Items to verify (as implied by requirements):
  - Users and roles (students, professors/course administrators, system administrators).
  - Courses and course pages (assignments, forums, wiki pages, announcements, blogs).
  - Files/attachments (including multiple uploads per page when enabled).
  - Voice clips and portfolios (owner, storage format optimized for speech).
  - Grades with feedback attachments and timestamps; grade history entries.
  - Web feed configuration per page.
  - Notification preferences and subscriptions (e-mail/SMS) per user and page.
  - Storage quotas for portfolios and partitioning by professors/administrators.
- Methods:
  - Requirements-to-schema traceability review to confirm each item is represented in the logical model.
  - Schema and data dictionary inspection.
  - CRUD test cases per entity via application/API (e.g., create assignment, upload multiple files, record voice clip, post grade with timestamp, subscribe/unsubscribe to notifications).
- Acceptance criteria:
  - Each listed information type can be created, read, updated, and deleted as permitted by roles and functions described in the SRS.
  - Timestamps are persisted where required (e.g., grades, grade history).
  - Storage of voice clips is in a non-MP3, speech-appropriate format; MP3 is produced only on download.

### b) Frequency of use — Verification
- Items to verify:
  - System supports at least 1,000 concurrent users accessing and modifying the above data during peak periods (midterms/finals).
  - [N/A] for per-entity operation frequencies (not specified).
- Methods:
  - Load and stress testing with realistic mixes of read/write operations: assignment submissions (file uploads), grade posting/updates (with history), voice clip recording/playback/download, search, and notification subscription changes.
  - Peak-hour test scenarios aligned to midterms/finals.
- Acceptance criteria:
  - Meets or exceeds performance target of supporting 1,000 concurrent users without data loss or constraint violations.
  - No data anomalies under load (e.g., lost grade history entries, corrupted uploads).

### c) Accessing capabilities — Verification
- Items to verify:
  - Role-appropriate access to data (e.g., students view only their grades; course administrators access course data).
  - Search access at course level and across courses as specified.
  - Voice clip download in MP3; in-system playback via provided viewer.
  - Per-page toggles for multiple file upload, web feeds, and notifications; student self-subscription when notifications are off.
- Methods:
  - Functional test cases for read/list/filter actions (e.g., course-level search returning categorized results; gradebook views).
  - Role-based access tests (positive and negative).
  - Configuration toggle tests per page, verifying resulting data access behavior.
- Acceptance criteria:
  - Data is retrievable in the scopes and groupings specified (e.g., by course).
  - Unauthorized access attempts are denied and auditable.
  - Configuration toggles reliably change access to related data (feeds, uploads, notifications).

### d) Data entities and their relationships — Verification
- Items to verify (relationships implied by requirements):
  - Users enrolled in Courses.
  - Courses contain Pages (assignments, forums, wiki pages, announcements, blogs).
  - Pages may have Files/attachments (including multiple files where enabled).
  - Assignments have Grades; Grades have GradeHistory entries with timestamps and editor.
  - Users own VoiceClips in a Portfolio; clips are attributable to the user and can be associated to coursework over time.
  - Pages have WebFeed configuration.
  - Users have NotificationPreferences and Subscriptions tied to Pages.
  - Professors/administrators have storage quotas that can be partitioned to students.
- Methods:
  - ERD/schema inspection against the above relationships.
  - Referential integrity tests with sample data (e.g., cannot create grade without corresponding assignment and student; cannot orphan voice clips from their owner).
  - End-to-end scenario tests spanning entities (e.g., create assignment → submit files → grade → update grade → verify history).
- Acceptance criteria:
  - All required relationships exist and enforce referential integrity (no orphaned records).
  - Relationship constraints allow the specified user actions and prevent nonspecified ones.

### e) Integrity constraints — Verification
- Items to verify:
  - Grade visibility limited to the student owner and course administrators.
  - Grade history preserved with timestamps for each change.
  - Default: notifications on for announcements; off elsewhere unless enabled or subscribed.
  - Per-page enablement for web feeds and multiple file uploads.
  - Quotas: equal and finite storage space for portfolios per professor/administrator, with ability to partition to students.
  - Voice clip deletion permitted by the owner.
- Methods:
  - Security and authorization tests for grade visibility.
  - Data mutation tests validating grade history immutability and completeness upon edits.
  - Configuration default tests on page creation for announcements vs. other pages.
  - Quota enforcement tests (upload until limit, partitioning behavior).
  - Delete-operation tests for voice clips (including portfolio consistency).
- Acceptance criteria:
  - Constraints consistently enforced across UI/API; violations are prevented and logged.
  - Historical records are append-only and accurately timestamped.
  - Default and per-page settings behave as specified.

### f) Security — Verification
- Items to verify:
  - Access control rules for sensitive data (grades, portfolios).
  - Shared authentication across integrated wiki/blog components.
  - [N/A] for encryption, auditing, and other security controls (not specified).
- Methods:
  - Role-based access control tests (positive/negative) across all data entities.
  - SSO/integration tests verifying shared authentication for wiki/blog with Moodle accounts.
- Acceptance criteria:
  - Only authorized actors can access protected data per SRS.
  - Integrated components honor Moodle authentication without duplicating or bypassing access rules.

### g) Data retention requirements — Verification
- Items to verify:
  - Voice clips retained in the user’s portfolio across the actor’s tenure, with ability for the actor to delete selected clips.
  - Grade history retained across changes.
  - Backups executed on a nightly schedule with option for weekly off-site and restoration capability within six hours.
  - MP3 generation occurs on download only; stored format remains optimized for speech.
  - [N/A] for explicit retention periods (e.g., number of years) beyond the above.
- Methods:
  - Longitudinal tests: create and modify over time; confirm persistence of portfolios and grade history.
  - Backup/restore drills using production-like data volumes; timed restoration.
  - Content inspection tests verifying stored vs. delivered audio formats.
- Acceptance criteria:
  - Required data persists and remains accessible until explicitly deleted by authorized actors.
  - Backup jobs complete per schedule; full restoration within six hours is demonstrable.
  - Audio storage complies with format and delivery requirements.

## 4.6 Design constraints

This section defines the verification approaches and methods planned to qualify the software against the Design constraints in Section 3.6.

- Conformance to Moodle-based architecture and APIs
  - Constraint source: Enhancements must be implemented within Moodle and utilize existing Moodle APIs; assume adoption of Moodle as the base platform.
  - Verification methods:
    - Architecture/design review to confirm plugin/theme-based implementation and no direct core modifications.
    - Code inspection to verify exclusive use of Moodle public APIs.
    - Deployment demonstration showing installation, enablement, and operation within Moodle.
    - Compatibility smoke tests on the target Moodle version ([N/A]).

- UI alignment with University practices and natural data flow
  - Constraint source: Redesigns should be consistent with University practices and reflect a more natural flow of data.
  - Verification methods:
    - Stakeholder UI review sessions with sign-off from designated University representatives.
    - Heuristic walkthroughs against an agreed UI/practice checklist ([N/A]).

- Use of freely available, integrated wiki and blog; avoid reliance on external hosted services
  - Constraint source: Integrate freely available solutions into Moodle; avoid use of third-party hosted services; share authentication and notifications with Moodle.
  - Verification methods:
    - License/commercial terms review to confirm “freely available” status.
    - Deployment architecture review confirming self-hosted integration.
    - Integration tests for single sign-on and shared notification mechanisms.

- Cross-platform in-browser audio playback; server-side format handling
  - Constraint source: Provide a cross-platform in-browser viewer for audio clips; store speech-optimized format and convert to MP3 only on download.
  - Verification methods:
    - Design/code review to confirm technology choice is cross-platform.
    - Cross-browser/OS compatibility testing for the embedded audio player.
    - Download verification tests to confirm MP3 conversion occurs on download and not in storage.

- Maintainability with limited IT staff; avoid substantial modification
  - Constraint source: System must be maintainable without substantial modification due to limited staff.
  - Verification methods:
    - Change-impact analysis demonstrating no invasive core changes.
    - Plugin lifecycle tests: install, upgrade, and uninstall without core patches.
    - Administrative operations dry-runs to validate routine maintenance effort is minimal.

- External standards and regulatory constraints
  - [N/A]

- Licensing requirements
  - [N/A]

- Applicable standards
  - [N/A]

## 4.7 Software system attributes

This section defines how the software system attributes will be verified to demonstrate compliance with the corresponding requirements.

### Reliability
- Scope under test:
  - Configurable backup scheduling.
  - Nightly backups with options for weekly, off-site backups.
  - Ability and capacity to restore backup data within six hours.
- Verification methods:
  - Configuration inspection: Review administrative settings and job schedules to confirm backup frequency options (nightly, weekly, off‑site) are available and configurable.
  - Execution evidence: Collect and review backup job logs over an observation period to confirm successful completion at the configured intervals.
  - Disaster recovery test: Perform a full restore into a clean environment from the latest backup; measure end‑to‑end time to restored service availability. Acceptance: restore completes within six hours.

### Availability
- Scope under test:
  - Service availability 24x7 with at least 99% uptime (requirement does not exclude maintenance windows).
- Verification methods:
  - Monitoring: Instrument production (or representative staging) with an availability monitor at suitable intervals.
  - Measurement: Compute uptime percentage over the agreed evaluation window, including scheduled maintenance windows. Acceptance: uptime ≥ 99%.
  - Evidence: Provide monitoring reports and incident summaries for the measurement window.

### Security
- [N/A]

### Maintainability
- Scope under test:
  - Maintainable without substantial modification (i.e., routine administration and upkeep without source code changes).
- Verification methods:
  - Administrative task demonstrations: Execute routine maintenance tasks (e.g., configuration changes, theme/layout updates, user/course administration, backup policy updates) via the central administrative interface. Acceptance: tasks completed without modifying source code.
  - Change management review: For a representative maintenance activity (e.g., minor update or plugin installation), follow documented procedures and verify completion without source code changes; review change records and diffs to confirm no substantial modifications.
  - Evidence: Maintenance runbooks/procedures, execution records, and change logs.

### Portability
- [N/A]

## 5.1 Assumptions and dependencies

The following assumptions and dependencies underpin the requirements and, if they change, the SRS may require revision:

- Adoption of Moodle as the base courseware system at the University of Puget Sound, with enhancements implemented via existing Moodle APIs.
- Availability and selection of a specific Moodle version compatible with the required enhancements (version TBD), and continued compatibility/stability of Moodle’s plugin/API model.
- Feasibility of implementing required features (e.g., multiple file upload, audio portfolios, search, web feeds, notifications, gradebook enhancements) using Moodle’s available capabilities and extension points.
- Stakeholder needs as captured in “Moodle Requirements Brainstorming.pdf” remain valid; material changes to stakeholder priorities will affect functional and nonfunctional requirements.
- Availability of institutional email services and an SMS delivery mechanism to support notification requirements, and students’ ability to provide/manage valid email addresses and mobile numbers.
- Availability of cross-platform, browser-accessible audio recording/playback within Moodle, storage of speech-optimized audio formats, and on-demand conversion to MP3 for downloads.
- Sufficient storage capacity to support per-user file quotas for uploads and audio portfolios, and corresponding backup storage capacity (including off-site).
- Existence of backup and restore infrastructure and processes capable of nightly backups and restoration within six hours, with options for weekly off-site backups.
- Data center and campus network capacity/reliability sufficient to meet 24×7 availability expectations (with maintenance windows) and 99% uptime targets.
- Server, database, and network resources adequate to support at least 1,000 concurrent users during peak periods (e.g., midterms and finals).
- Availability of freely available wiki and blog engines that can be integrated within Moodle and can share authentication and notification mechanisms.
- Limited staffing in the Office of Information Services; maintainability and administrative simplicity requirements assume constrained IT support resources.
- University practices and policies guiding user interface consistency and configuration (e.g., central administrative interface, theming) remain in effect.
- Use of standard web feed formats (e.g., RSS 2.0) for notifications of changes, and acceptance of such formats by users and tools.

## 5.2 Acronyms and abbreviations

- API: Application Programming Interface
- FTE: Full-Time Equivalent
- IT: Information Technology
- MP3: MPEG-1/2 Audio Layer III (compressed digital audio format)
- MPEG: Moving Picture Experts Group (family of multimedia standards)
- PDF: Portable Document Format
- RSS: Really Simple Syndication (web feed format; version 2.0 referenced)
- SMS: Short Message Service