# 1 Introduction
[NULL]

## 1.1 Purpose
The purpose of the software is to provide a courseware system—based on Moodle and enhanced via its existing APIs—that meets the University of Puget Sound’s instructional and educational needs by facilitating electronic classroom management (e.g., assignment submission, grading, discussion, collaboration) and addressing gaps identified in current solutions. The system aims to improve the overall learning experience, align with university practices, and offer a more natural user interface flow while delivering key capabilities such as multiple file uploads, audio recording portfolios for language learning, web feeds, course-wide search, a secure and auditable gradebook, integrated wiki and blog tools, and e‑mail/SMS notifications for course updates.

## 1.2 Scope
This SRS defines the immediate requirements for a courseware solution at the University of Puget Sound, focusing on enhancements to Moodle (version TODO: Version of Moodle). The scope is to specify core functionality currently unavailable in Moodle, small redesigns for consistency with university practices, and a user interface redesign to reflect a more natural flow of data. The requirements are based on the assumption that Moodle will be adopted and that enhancements will utilize Moodle’s existing APIs; however, they also articulate what any courseware system would need to qualify as a viable solution for the University.

Products to be produced
- University of Puget Sound’s enhancements to Moodle: modifications and extensions to the existing Moodle courseware system using Moodle APIs.
- Integrated functional modules: Multiple File Transfer, Audio Recording with portfolio management, Web Feeds, Course and cross-course Search, Gradebook (with feedback and history), Social Networking Applications (wiki and blog integration), and Notifications (email and SMS).
- Usability and administration improvements: a streamlined, centralized administrative interface and user interface redesign for reduced page clutter and a more natural flow of data.
- Operational support assets: configurable backup/restore capabilities, availability and performance targets sufficient for academic use, and online user and administrator documentation.

What the software will do
- Enable multi-file uploads configurable per page (e.g., assignments, forums, wikis).
- Capture, store, organize, preview, download, and delete voice clips in user portfolios, optimized for speech and downloadable in widely supported formats (e.g., MP3).
- Provide configurable web feeds (e.g., RSS) per page/component (assignments, forums, wikis, announcements).
- Offer course-level and cross-course search with quick-access search boxes and an advanced search page with filtering and categorized results.
- Support grading workflows: posting grades, attaching feedback, timestamping changes, and maintaining grade history with appropriate visibility controls.
- Integrate collaborative tools: a wiki (with simple markup and internal linking) and a blog engine (tagging, drafts, comments) sharing authentication and notifications with Moodle.
- Deliver notifications via email and SMS with per-page toggles, subscriptions, and user preferences.

Application, benefits, objectives, and goals
- Application: University of Puget Sound academic courses, serving students (content consumption, submissions, collaboration), professors (content management, grading, collaboration facilitation), and system administrators (configuration and maintenance).
- Benefits and objectives: improve the overall learning experience; reduce navigation friction and excessive clicks; align courseware workflows with university practices; support foreign language coursework through voice clip portfolios for longitudinal assessment; keep stakeholders informed through feeds and notifications; and consolidate collaborative activities within Moodle to reduce reliance on third-party services.
- Goals and delivery focus: deliver Priority 1 (Core) and Priority 2 requirements, plus select Priority 3 items subject to time and budget; refine Moodle to meet stakeholder needs identified through interviews, while ensuring maintainability and operational reliability appropriate for academic use.

Consistency with higher-level direction
- This scope is consistent with the stated assumptions that Moodle is under consideration as a replacement for Blackboard, that enhancements will use Moodle’s public APIs, and that the work is informed by stakeholder feedback summarized in Moodle Requirements Brainstorming.pdf. It also reflects that the University is evaluating Moodle while defining requirements applicable to any candidate courseware system.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product is a courseware system for the University of Puget Sound, defined as either a new system or a set of enhancements to Moodle. It is intended to replace Blackboard and address instructional needs by improving functionality such as assignments, grading, discussions, wikis, blogs, notifications, search, multiple file transfer, audio recording/portfolios, and web feeds. The enhancements are assumed to utilize existing Moodle APIs and include user interface refinements for a more natural flow of data.

Major elements and interconnections (textual overview):
- Core courseware functions: courses, assignments, forums, wikis, gradebook.
- Enhancements: multiple file upload per page, audio recording and portfolio management, RSS web feeds, course/site search, notifications (email/SMS), integrated wiki and blog engines, centralized administrative configuration and theming.
- External-facing interfaces: RSS 2.0 feeds for content, email and SMS delivery for notifications.
- Operations: scheduled backups and restorations; availability targets.

No larger enterprise system dependencies are specified beyond the assumption of adopting Moodle and using its APIs.

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

#### User interfaces
- A search box is displayed on every page after login; a dedicated search page supports filtering by component (e.g., assignments, forums, wikis) and shows categorized results by relevance.
- Per-page controls allow course administrators to:
  - Enable/disable multiple file uploads during page creation/editing.
  - Enable/disable web feeds per page.
  - Enable/disable notifications per page (default on for announcements); students may subscribe/unsubscribe.
- Gradebook:
  - Course administrators can enter grades (points earned/possible), attach feedback (text or attachment), and grades are timestamped.
  - Students can view their own grades, averages, and overall grade; privacy is enforced.
- Audio portfolio:
  - Users can record, preview, archive, download, and delete voice clips; clips can be attached to pages where uploads are permitted.
- Administrative UI:
  - A single, central administrative interface supports system-wide configuration, theming, and reduction of page clutter; the interface should be simple and responsive.

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

#### Software interfaces
- Moodle APIs (for extension/enhancement)
  - Name: Moodle APIs
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: Moodle
  - Purpose: Provide the extension points for implementing the University’s enhancements within Moodle.
  - Interface definition: [N/A]
- Wiki engine (integrated)
  - Name: [N/A]
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: Freely available wiki engine
  - Purpose: Collaborative document creation within Moodle; shares authentication and notifications with Moodle.
  - Interface definition: [N/A]
- Blog engine (integrated)
  - Name: [N/A]
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: Freely available blog engine
  - Purpose: Provide modern blogging (tagging, drafting, comments) within Moodle; shares authentication and notifications with Moodle.
  - Interface definition: [N/A]
- RSS web feeds
  - Name: RSS 2.0 feeds
  - Mnemonic: RSS
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: Standard RSS 2.0 format
  - Purpose: Expose updates for assignments, forums, wikis, announcements, and similar pages.
  - Interface definition: Content published in RSS 2.0 format; details of feed endpoints/configuration are [N/A].
- Audio viewer/conversion
  - Name: [N/A]
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Provide cross-platform playback for stored speech-optimized clips and convert clips to MP3 on download.
  - Interface definition: [N/A]
- Optional external web search
  - Name: [N/A] (e.g., a standard web search engine)
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: The search page might allow searching the world wide web.
  - Interface definition: [N/A]

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

#### Memory constraints
- Storage quotas: Equal and finite drive space is allotted to each professor/administrator for storing student voice clips, and may be partitioned for students’ submissions. No primary memory constraints are specified.
- Other memory constraints: [N/A]

#### Operations
- Availability: The system should be available 24/7 with 99% uptime, allowing maintenance windows.
- Backup and recovery:
  - Backups occur nightly, with options for weekly off-site backups when necessary.
  - The system must be able to restore backup data within six hours.
- Maintenance: The system must be maintainable without substantial modification; a single administrative interface supports configuration and theming.
- Modes of operation and unattended operation periods: [N/A]
- Data processing support functions beyond backups/recovery: [N/A]

#### Site adaptation requirements
- Administrative configuration via a single, central interface, including theming and settings that affect layout across the courseware system.
- Per-page/course configuration for enabling multiple file uploads, web feeds, and notifications.
- Backup schedule configuration (e.g., nightly, weekly off-site options).
- Audio storage allocation can be partitioned by professors/administrators for student voice clips.
- Other site-specific data/initialization sequences: [N/A]

#### Interfaces with services
- E-mail services: Used to deliver notifications to users’ email accounts. Specific service details are [N/A].
- SMS services: Used to deliver notifications to users’ mobile phones via SMS. Specific service details are [N/A].
- RSS consumption: Exposed RSS 2.0 feeds may be consumed by external feed readers/aggregators.
- Optional web search service: The search page might integrate a standard web search engine; specifics are [N/A].

### 1.3.2 Product functions
- Content and submission management
  - Upload and manage files on assignments, forums, wikis, announcements, and similar pages.
  - Enable or disable multiple-file uploads on a per-page basis (configured by course administrators/professors).

- Audio capture and portfolio management
  - Record, store, and organize student voice clips in portfolios over time to support longitudinal assessment (e.g., language learning).
  - Allocate and partition storage for voice clips; allow preview-before-archive or auto-archive workflows.
  - Attach archived clips to any page that permits uploads.
  - Download clips in a widely supported format (e.g., MP3) while storing them in a speech-optimized format.
  - View and delete clips from a personal portfolio.

- Collaboration tools
  - Provide an integrated wiki for collaboratively creating and linking documents with simple markup.
  - Provide an integrated blog engine supporting modern blog features (e.g., tagging, drafting, comments) with shared authentication and notifications.

- Communication and awareness
  - Provide web feeds (e.g., RSS 2.0) for course components such as forum posts, assignments, announcements, and wiki changes.
  - Allow course administrators to enable/disable feeds per page and control their audience.
  - Send e-mail and SMS notifications for page changes; allow per-page notification toggles (on by default for announcements), student subscriptions, delivery preferences, and subscription management.

- Assessment and feedback (Gradebook)
  - Enter and update assignment grades (points earned vs. points possible) with timestamps.
  - Attach feedback as text and/or files.
  - Maintain grade change history.
  - Display grades, averages, and overall grade privately to the appropriate student and course administrators.

- Search and navigation
  - Provide a search box on every page after login.
  - Support course-level and cross-course search with results grouped by course when applicable.
  - Offer a dedicated search page with filters by component (e.g., assignments, wiki pages, forum posts) and results grouped by category and relevance.
  - Optionally support web search from the dedicated search page.

- Administration and configuration
  - Configure the system from a central administrative interface (e.g., themes and layout settings) to reduce page-level editing overhead.
  - Control per-page features such as multiple file upload and web feeds during creation and editing.

- Data protection and continuity
  - Schedule and run system backups (e.g., nightly) with options for weekly, off-site backup.
  - Restore system and course data within a defined recovery window (e.g., within six hours).

- Help and documentation
  - Provide relevant, online user help on each page and notify users of modifications via the main page.
  - Offer comprehensive, searchable administrator documentation covering maintenance procedures, common errors, and advanced troubleshooting.

### 1.3.3 User characteristics
The product serves the University of Puget Sound community and is used by three primary groups. In this SRS, “course administrator” refers to a professor or system administrator with the ability to manage courses and course pages.

- Students
  - Overview: Primary consumers of course content; access information posted by professors, upload assignments and project files, participate in discussions, and use search to find course materials. In some courses (e.g., foreign languages), students record and manage voice clips as part of coursework.
  - Educational level: University students.
  - Experience with courseware: [N/A]
  - Disabilities: [N/A]
  - Technical expertise: [N/A]

- Professors (Course Administrators)
  - Overview: Primary content administrators; upload files, links, and multimedia; grade assignments; create and manage collaborative spaces (wikis, forums, blogs); configure per-page options (e.g., multiple file upload, web feeds, notifications); maintain gradebooks; organize student voice-clip portfolios where applicable.
  - Educational level: University faculty.
  - Experience with courseware: [N/A]
  - Disabilities: [N/A]
  - Technical expertise: [N/A]

- System Administrators (Course Administrators)
  - Overview: Maintain and configure the courseware system, perform updates, manage backups and restores, and support system-wide settings; contribute minimally to course content; rely on comprehensive, searchable documentation for maintenance and troubleshooting.
  - Educational level: [N/A]
  - Experience with courseware: System maintenance and configuration responsibilities are expected.
  - Disabilities: [N/A]
  - Technical expertise: Advanced technical system administration responsibilities are expected.

### 1.3.4 Limitations
- a) Regulatory requirements and policies: [N/A]

- b) Hardware limitations (e.g., signal timing requirements): [N/A]

- c) Interfaces to other applications:
  - Enhancements must utilize existing Moodle APIs.
  - Integrated wiki and blog engines must share authentication and notification with Moodle.
  - Web feeds (e.g., RSS 2.0) must be supported for course components, with enablement controlled per page by course administrators.

- d) Parallel operation: [N/A]

- e) Audit functions:
  - Gradebook must maintain a history of grade changes with timestamps for each assignment.

- f) Control functions:
  - Course administrators must be able to enable or disable multiple file uploads on a per-page basis.
  - Course administrators must be able to toggle web feeds on or off per page.
  - Course administrators must be able to enable or disable notifications per page; students can subscribe/unsubscribe and choose SMS or email delivery.

- g) Higher-order language requirements: [N/A]

- h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK): [N/A]

- i) Quality requirements (e.g., reliability):
  - Availability target of 99% with an expectation of 24x7 access allowing maintenance windows.
  - Nightly backups (with options for weekly off-site backup) and ability to restore within six hours.
  - Support for at least 1,000 concurrent users.
  - System must be maintainable without substantial modification.
  - Usability goal of a simple, responsive interface with centralized administration to reduce page clutter.

- j) Criticality of the application:
  - Not required to be highly available beyond 99% uptime; downtime for maintenance is acceptable.

- k) Safety and security considerations:
  - Grade visibility is restricted to the graded student and course administrators of the relevant course.

- l) Physical/mental considerations: [N/A]

- m) Limitations sourced from other systems (including real-time requirements through interfaces):
  - Dependence on Moodle as the base platform; features are implemented as enhancements within Moodle.
  - Audio clips must be stored in a speech-optimized format, converted to MP3 only on download, with a cross-platform in-application audio player.
  - Real-time interface requirements: [N/A]

## 1.4 Definitions
- Actor: Synonymous with user; used to describe a user performing actions in use cases within the system.
- Role: The capacity 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.
- Student: An actor enrolled in a course who primarily consumes course content, uploads assignments, and participates in discussions.
- Professor: An actor who primarily administers course content, creates learning activities, and evaluates student work.
- System Administrator: An actor responsible for configuring, maintaining, and updating the courseware system, with minimal contribution to course content.
- Courseware System (Course Management System): Software that facilitates electronic classroom management, including grading, assignment submission, discussions, wikis, forums, and related learning tools.
- System: The currently deployed courseware system, a new courseware system, or any modifications to Moodle while it is being evaluated or adopted.
- Page: Any distinct content item or upload point within the system, such as an assignment, wiki page, forum post, announcement, or project page.
- Voice Clip (Audio Clip): A recorded audio submission (optimized for speech) used for instructional activities, especially in language coursework.
- Portfolio (Audio Portfolio, Archive): A persistent, actor-specific repository of recorded voice clips maintained over time for organization, assessment, preview, archival, and deletion.
- Web Feed (e.g., RSS): A machine-readable update stream for system pages or components (e.g., assignments, wikis, forums, announcements) that actors can subscribe to.
- Notifications: System-generated alerts about page updates delivered via email or SMS; configurable per page by course administrators and subscribable by students.
- Gradebook: The course-specific record of assignment grades, associated feedback, timestamps, and change history, visible to the owning student and course administrators.
- Relevance (Search): The ordering of search results based on the number of term matches with the search query.
- Priority Levels: Requirement importance categories used in this SRS:
  - Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.
  - Priority 2: Functionality not explicitly available today but critical for implementation at the University.
  - Priority 3: Important functionality that supplements critical features.
  - Priority 4: Valuable supplemental functionality that is not critical.

# 2 References
## Compliance
[N/A]

## Guidance
- Moodle Requirements Brainstorming.pdf
  - Title: Moodle Requirements Brainstorming.pdf
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: [N/A]
- RSS 2.0 Specification
  - Title: RSS 2.0 Specification
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: [N/A]
- MPEG Audio (MP3) Specification
  - Title: MPEG Audio (MP3) Specification
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
### 3.1.1 Multiple file transfer
- Inputs:
  - Files selected by an actor for upload to a specific page (assignment, wiki page, forum post, etc.).
  - Page-level configuration indicating whether multiple file upload is enabled.
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - A course administrator configures a page during creation or editing to enable or disable multiple file uploads.
  - An actor uploads one or more files to the configured page.
  - The system captures and associates the uploaded 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:
  - Enabling multiple file upload on a page permits more than one file to be attached at that upload point; disabling restricts upload to a single file.
- Relationship of outputs to inputs:
  - Output: Files stored and associated with the target page.
  - Input/output sequences: Upload request per file (or batch) results in stored file references on the page.
  - Formulas for input to output conversion: [N/A]

### 3.1.2 Audio recording and portfolio management
- Inputs:
  - Voice clips recorded and submitted by students.
  - Professor/system administrator options to preview-before-archive or auto-archive.
  - Actor actions to download or delete clips.
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - Students submit recorded clips.
  - Depending on configuration:
    - Preview-before-archive: professor/administrator previews a clip and chooses whether to archive it.
    - Auto-archive: clip is archived automatically upon submission.
  - Actors may attach archived clips to any page where uploads are permitted.
  - Downloading a clip triggers conversion to a widely supported format such as MPEG Audio (mp3).
  - Actors can view their portfolio and delete selected clips.
- Responses to abnormal situations:
  - Overflow: Equal and finite drive space is allotted, but behavior on quota exceedance is not specified. [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - Portfolio storage quotas can be partitioned by professors/administrators for students.
  - Archive mode selection (preview-before-archive vs auto-archive) controls whether clips are manually curated or automatically retained.
  - Storage format is optimized for speech; conversion to mp3 occurs on download.
- Relationship of outputs to inputs:
  - Output: Archived voice clips organized per actor portfolio; downloadable mp3 renditions; optional attachments of archived items to other pages.
  - Input/output sequences: Submission → preview decision (if enabled) → archival (or discard) → optional attachment and/or download → optional deletion.
  - Formulas for input to output conversion: Conversion to mp3 for download; detailed codec parameters not specified. [N/A]

### 3.1.3 Web feeds
- Inputs:
  - Course content events (forum posts, assignment postings, announcements, wiki edits and similar additions).
  - Course administrator page-level feed toggle and audience selection.
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - During page creation or editing, the course administrator enables or disables a feed for that page.
  - When enabled, content additions to the page produce updates that are exposed via a 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 a feed is produced.
  - Administrator control determines to whom feeds pertain.
- Relationship of outputs to inputs:
  - Output: Web feed entries reflecting new or changed content.
  - Input/output sequences: Content addition → feed update generation → feed consumption by subscribers.
  - Formulas for input to output conversion: [N/A]

### 3.1.4 Search
- Inputs:
  - Search query terms entered via a search box present after login on every page.
  - Optional filters (e.g., include/exclude forum posts, grades, etc.) on the dedicated search page.
  - Scope determined by navigation context (inside a course vs outside all courses).
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - Actor submits a query from any page or the dedicated search page.
  - If outside any course, the system searches all of the actor’s courses and groups results by course.
  - If inside a course, the system searches that course with an option to search all courses.
  - On the dedicated search page, optional filters narrow components searched.
  - Results are displayed in categories (Assignments, Wiki Pages, Forum Posts, etc.) ordered by relevance.
  - Actor selects a result to navigate 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:
  - Selected filters limit which components are included in results.
  - Scope (this course vs all courses) changes the search domain and grouping.
- Relationship of outputs to inputs:
  - Output: Categorized search results grouped by course when applicable.
  - Input/output sequences: Query submission → scoped search with filters → relevance-ranked result list → navigation on selection.
  - Formulas for input to output conversion: Relevance is determined by the number of terms matching the search terms.

### 3.1.5 Gradebook
- Inputs:
  - Course administrator grade entries for assignments, including points earned and points possible.
  - Optional feedback as text or attachment.
  - Grade modifications over time.
- Validity checks on inputs:
  - Access control: Only the course administrator for a course can post or modify grades; students can view only their own grades. (Display restrictions are specified; specific validation mechanics are not.) [N/A]
- Sequence of operations:
  - Course administrator posts a grade for an assignment, with optional feedback.
  - The system records the grade and a timestamp for the last modification.
  - On any change, the system maintains a grade history with timestamps.
  - The system displays per-assignment grades, averages, and overall grade to the appropriate student.
- 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:
  - Points possible and points earned affect the computed grade for an assignment.
- Relationship of outputs to inputs:
  - Output: Stored grades with timestamps, feedback, and history; student-facing grade views including assignment grades, averages, and overall grade.
  - Input/output sequences: Grade entry → computation and storage → timestamping and history update → student view update.
  - Formulas for input to output conversion:
    - Assignment grade is based on the ratio of points earned to points possible.
    - Formulas for averages and overall grade are not specified. [N/A]

### 3.1.6 Social networking applications (wiki and blog)
- Inputs:
  - Wiki page edits using a simple markup language; links to other wiki pages.
  - Blog posts with tagging, drafting, and comments.
  - Shared authentication and notification with the courseware system.
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - Actors create and edit wiki pages collaboratively; pages can link to other wiki pages.
  - Actors create blog posts, optionally as drafts, apply tags, and receive comments.
  - Authentication and notifications are shared with the courseware system.
- 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:
  - Output: Updated wiki content; published or drafted blog entries with tags and comments.
  - Input/output sequences: Content submission → content storage → availability with shared authentication and notifications.
  - Formulas for input to output conversion: [N/A]

### 3.1.7 Notifications (email and SMS)
- Inputs:
  - Page creation and subsequent content changes on pages (assignments, wiki pages, forum posts, etc.).
  - Course administrator per-page notification toggle (default on for announcements).
  - Student subscription preferences and channel selection (email or SMS); subscription management (e.g., unsubscribe).
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - On page creation, the course administrator configures whether notifications are enabled.
  - If notifications are off, students may subscribe to notifications for that page.
  - Students set preferences for notification channel (email or SMS) and manage subscriptions.
  - When a change occurs on a page with notifications enabled or with active subscriptions, the system sends notifications per each subscriber’s preferences.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: Behavior on email/SMS delivery failures is not specified. [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - Per-page notification toggle determines whether notifications are sent by default.
  - Student preferences determine the delivery channel (email or SMS).
- Relationship of outputs to inputs:
  - Output: Notification messages delivered via the selected channel to subscribed actors.
  - Input/output sequences: Content change → evaluate notification settings/subscriptions → dispatch notifications per preferences.
  - Formulas for input to output conversion: [N/A]

### 3.1.8 Backup and restore
- Inputs:
  - Configurable backup schedule.
  - Invocation of restore when needed.
- Validity checks on inputs:
  - [N/A]
- Sequence of operations:
  - The system performs backups on a schedule sufficient to protect system and course data; nightly backups are indicated, with options for weekly off-site backup.
  - On request, the system restores backup data within six hours.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: Restore capability within the stated time supports recovery from failures; further behavior is not specified. [N/A]
  - Error handling and recovery: Restore from backups within six hours.
- Effect of parameters:
  - Backup frequency and off-site options affect recovery point objectives; specific effects beyond schedule are not specified. [N/A]
- Relationship of outputs to inputs:
  - Output: Restored system and course data consistent with the selected backup set.
  - Input/output sequences: Scheduled backup → backup stored (possibly off-site) → restore operation when required.
  - Formulas for input to output conversion: [N/A]

## 3.2 Performance requirements
### Static capacity requirements
- Concurrent users: The system should support at least 1,000 concurrent users, including during peak periods such as midterm and finals weeks.
- Number of terminals to be supported: [N/A]
- Amount and type of information to be handled (quantitative limits): [N/A]

### Dynamic performance requirements
- Backup frequency: The system should be backed up on a nightly basis, with options for weekly off-site backup when necessary.
- Backup restoration time: The system must have the ability and capacity to restore backup data within six hours.
- Transaction/response time under normal load: [N/A]
- Transaction/response time under peak load: [N/A]
- Data processing/throughput limits within defined time windows: [N/A]
- Maximum allowable delays for user-facing operations (e.g., search, uploads, notifications): [N/A]

## 3.3 Usability requirements
This section consolidates usability and quality-in-use requirements and objectives extracted from the original SRS, focusing on effectiveness, efficiency, satisfaction, and avoidance of harm in the intended contexts of use.

### Effectiveness
- The system must allow actors to search for pages at the course level, providing a dedicated search page that:
  - Allows filtering of results by component (e.g., forum posts, grades).
  - Displays results in categories (e.g., Assignments, Wiki Pages, Forum Posts) based on relevance.
  - Navigates to the corresponding page when a result is selected.
- The system must display a search box on every page after an actor has logged in:
  - Outside a course: searches all of the actor’s courses with results grouped by course.
  - Inside a course: searches within that course with an option to search all courses.
- The system must allow web feeds (e.g., for forum posts, assignment postings, announcements, wiki alterations) to be enabled or disabled on a per-page basis by course administrators to keep actors informed of new content.
- The system must provide an integrated wiki with simple markup and page linking, and an integrated blog engine (tagging, drafting, comments), sharing authentication and notifications with Moodle, to reduce confusion and support collaborative work.

### Efficiency
- The system should provide a simple, responsive interface, configurable from a single, central administrative position to reduce page clutter.
- A single administrative interface must be provided rather than individual links for editing each page, and it must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.
- The system must provide both e-mail and SMS notifications for pages, with announcements enabled by default; students must be able to select SMS or e-mail and manage their subscriptions, reducing the need for repeated navigation to check updates.
- Multiple file upload must be configurable on a per-page basis to streamline submission workflows for assignments and collaborative projects involving multiple parts.

### Satisfaction
- Relevant, online documentation for users should be available on each page; modifications should be reported via the main page; phone and on-site support will be provided by the Office of Information Services.
- System administrators must have access to comprehensive, searchable documentation covering maintenance procedures, common errors, and advanced troubleshooting, with search results displayed based on relevance.
- The user interface will be redesigned to reflect a more natural flow of data and to be consistent with university practices.

### Avoidance of harm (quality in use)
- The system should display grade information only to the actor to whom the grades belong; no other actor should be able to view another’s grades except a course administrator for the corresponding course.
- The system must be backed up on a configurable schedule (nightly, with options for weekly off-site backup) and must be capable of restoring back-up data within six hours to prevent loss of submitted assignments and course data.
- The system should be available 24 hours a day, 7 days a week (99% up-time), allowing for maintenance windows, to ensure access during off-hours as well as business hours.

## 3.5 Logical database requirements
- a) Types of information used by various functions
  - Users/Actors and Roles: user identity; role assignments (student, professor, system administrator).
  - Courses: course identity and membership (which users are associated with which courses).
  - Pages (distinct upload or content points): assignment, wiki page, forum post/thread, announcement, and other course components where content is added.
  - File uploads: files associated to pages (including assignment submissions and other attachments).
  - Audio recordings: voice clips recorded by students; portfolios (archives) of clips; optional attachments of archived clips to any page where uploads are permitted.
  - Web feeds: per-page feed enablement flags and scoping (which components have feeds and to whom they pertain).
  - Search: searchable course/page content and metadata sufficient to locate and return results grouped by category and/or course.
  - Gradebook: grades associated with a student and an assignment; timestamps for last modification; grade history for changes.
  - Notifications: per-page notification enablement; user subscriptions; user delivery preferences (SMS or email).

- b) Frequency of use
  - Backups: nightly, with options for weekly off-site backup when necessary.
  - Other data access and update frequencies: [N/A].

- c) Accessing capabilities
  - Users/Actors and Roles: role-based access to features throughout the system.
  - Pages and file uploads: course administrators/professors can enable/disable multiple file uploads per page; users upload files to permitted pages.
  - Audio recordings and portfolios: students record/submit clips; professors/system administrators manage storage partitions for students; users can preview (where offered), archive automatically or after preview, attach archived clips to permitted pages, and delete their clips.
  - Web feeds: course administrators can enable/disable feeds per page and determine to whom feeds pertain.
  - Search: available from every page after login; searches within the current course or across courses as described.
  - Gradebook: course administrators post and modify grades and feedback; timestamps recorded; students can view only their own grades; administrators for the relevant course can view students’ grades.
  - Notifications: course administrators can toggle notifications per page (default on for announcements); students can subscribe/unsubscribe and set delivery preferences (SMS or email).

- d) Data entities and relationships
  - User/Actor has one or more Roles.
  - User enrolls in zero or more Courses; Course includes zero or more Users.
  - Course contains Pages (Assignments, Wiki Pages, Forum Posts/Threads, Announcements).
  - Page has zero or more File uploads.
  - Student has zero or more Audio Clips stored in a personal Portfolio; Audio Clip may be optionally attached to a Page where uploads are permitted.
  - Professor/System Administrator has an allotted finite audio storage space that can be partitioned among Students for their clips.
  - Assignment (a Page type) has Grades, each Grade associated with one Student in the Course.
  - Grade has zero or more Grade History entries capturing changes with timestamps.
  - Page may have an associated Web Feed; enablement is per Page.
  - User has Notification Preferences (SMS or email) and zero or more Notification Subscriptions that link the User to Pages for which notifications are enabled.

- e) Integrity constraints
  - Grade privacy: only the student to whom a grade belongs and the course administrator for the relevant course may view that grade.
  - Grade scope: each Grade references exactly one Student and one Assignment within a Course.
  - Grade auditability: changes to grades must create Grade History entries with timestamps; the latest grade value must reflect the most recent change time.
  - Per-page configuration: multiple file upload enablement, web feed availability, and notification enablement are stored and enforced per Page.
  - Audio storage quotas: equal and finite audio storage must be allotted to each professor/system administrator; partitions allocated to students must not exceed the professor/administrator’s allotted space.
  - Portfolio integrity: deletion of a recorded clip by its owner must remove it from that owner’s portfolio/archive.
  - Notification defaults: announcements must default to notifications enabled unless explicitly turned off.

- f) Security
  - Role-based access control must be enforced for all data access (e.g., grade viewing/editing limited as specified).
  - Authentication must be shared across integrated components (e.g., wiki and blog) to reduce confusion and ensure consistent authorization.
  - Web feed access must align with page-level configuration regarding to whom feeds pertain.
  - User notification preferences and subscriptions must be modifiable only by the owning user or authorized administrator.

- g) Data retention requirements
  - Audio recordings: clips are maintained in a user’s portfolio during the user’s existence in the system, subject to user-initiated deletion and storage quotas.
  - Grade history: the system must maintain a history of grade changes for assignments.
  - Backups: nightly backups with options for weekly off-site backup; capability to restore backup data within six hours.
  - Additional retention durations or archival periods: [N/A].

## 3.6 Design constraints
- External standards and formats
  - Web feeds must conform to RSS 2.0.
  - Voice clip downloads must be provided in MPEG Audio (MP3) format; clips are stored in a format optimized for speech, and an in-application, cross-platform audio player must be provided.

- Platform and integration limitations
  - Enhancements must utilize existing Moodle APIs; the solution is delivered as Moodle enhancements rather than a standalone system.
  - Changes should be consistent with existing university practices and delivered via a redesigned user interface within Moodle.
  - Wiki and blog functionality must be integrated within Moodle (not via external hosted services), be freely available, and share authentication and notifications with Moodle.
  - The system should provide a single, central administrative interface to configure UI, themes, and features across the courseware system.

- Maintainability constraints
  - The system must be maintainable without substantial modification, minimizing changes to core components.

- Operational constraints
  - Backups must be configurable and support nightly backup, with options for weekly off-site backup; the system must support restoration of backup data within six hours.
  - Target availability is 24x7 with 99% uptime, allowing for scheduled maintenance windows.

- Storage and allocation constraints
  - Equal and finite storage must be allotted for voice clip portfolios to professors/administrators, with the ability to partition space for students.

- Regulatory requirements
  - [N/A]

## 3.7 Software system attributes
- Reliability
  - The system must be backed up on a configurable schedule to ensure system and course data protection.
  - Nightly backups are required, with options for weekly, off-site backups when necessary.
  - The system must have the ability and capacity to restore backup data within six hours.

- Availability
  - The system should be available 24 hours a day, 7 days a week.
  - 99% up-time is sufficient and may include scheduled maintenance windows and downtime.

- Security
  - Access control: Grade information must be visible only to the actor to whom the grades belong and to course administrators for the corresponding course.
  - Authentication: Wiki and blog engines must share authentication and notification with the courseware system to provide integrated logins.
  - Auditability: The system should maintain a history of grades for a particular assignment, including timestamps of modifications.
  - Cryptographic techniques: [N/A]
  - Required logs/history beyond grade history: [N/A]
  - Functional separation into distinct security domains/modules: [N/A]
  - Restrictions on inter-module communications: [N/A]
  - Data integrity checks for critical variables: [N/A]
  - Additional data privacy requirements (beyond grade visibility): [N/A]

- Maintainability
  - The system must be maintainable without substantial modification and should be mostly self-sustaining to minimize IT staff effort.
  - System administrators must have access to comprehensive, searchable documentation covering regular maintenance procedures, common errors, and advanced troubleshooting.
  - A single, central administrative interface must allow configuration of the user interface and features across the entire system, including the ability to change themes and layout settings globally.

- Portability
  - Percentage of elements with host-dependent code: [N/A]
  - Percentage of code that is host dependent: [N/A]
  - Use of a proven portable language: [N/A]
  - Use of a particular compiler or language subset: [N/A]
  - Use of a particular operating system: [N/A]

## 3.8 Supporting information
This section consolidates background and contextual information that informed the requirements. Unless an item is explicitly captured as a requirement elsewhere in this SRS, the information herein is provided for context only and is not part of the requirements baseline.

a) Sample input/output formats, cost analysis, user surveys
- Stakeholder interview results: Captured in “Moodle Requirements Brainstorming.pdf,” which served as foundational input for this SRS and summarizes stakeholder feedback (see References and Stakeholder Needs). This document is not otherwise reproduced in the SRS.
- Sample input/output formats: [N/A]
- Cost analysis studies: [N/A]

b) Supporting/background information for readers
- Working document status: The SRS is a living document subject to refinement and change over time.
- Adoption assumptions: The University is evaluating Moodle as a candidate to replace Blackboard; enhancements should utilize Moodle’s existing APIs and align with university practices.
- Product context and intent: The target system is a courseware solution managing courses, assignments, wikis, forums, grading, and related learning tools. The goal is to refine Moodle to improve student learning and provide professors with better content and collaboration capabilities.
- Stakeholder input: Requirements are based on interviews with professors and students, with analysis of features in other available solutions, summarized in the referenced brainstorming document.

c) Problems to be solved by the software
- Improve content submission flexibility: Support multiple file uploads where appropriate, configurable per page/upload point.
- Enable language-learning support: Provide audio recording capture, organization into per-user portfolios, download in common formats, storage optimized for speech, and deletion/management of clips.
- Enhance awareness of changes: Offer web feeds (e.g., RSS) configurable per component/page by course administrators.
- Reduce navigation friction: Provide course-level and system-level search, including a persistent search box and an advanced search page with filtering and relevance-based results.
- Strengthen grading workflows: Allow assignment grading with points, feedback attachments, timestamps, controlled visibility to authorized users only, and grade history with change tracking.
- Improve social/collaborative tools: Integrate robust wiki and blog capabilities with simple markup, tagging, drafting, comments, shared authentication, and notifications.
- Provide proactive notifications: Support configurable email and SMS notifications, including default behavior for announcements and user-managed subscription preferences.
- Usability and administration: Deliver a simple, responsive interface with a central administrative interface for configuration, theming, and layout control to reduce page clutter.
- Reliability and availability: Support scheduled backups (e.g., nightly, with options for off-site weekly) and restoration within six hours; target general availability (e.g., 99% uptime, excluding maintenance windows).
- Performance under load: Support at least 1,000 concurrent users during peak academic periods.
- Maintainability: Be maintainable with limited IT staff involvement.
- User assistance: Provide relevant online help on each page and comprehensive, searchable documentation for system administrators.

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

Status of inclusion as requirements
- The items listed above are supporting information and are not requirements unless they are explicitly stated as functional or nonfunctional requirements in the Requirements sections of this SRS.

# 4 Verification
[NULL]

## 4.1 Functions
The original SRS does not specify verification approaches or methods for functional requirements. The following presents the required verification information items in parallel with the functional requirement groups; where the SRS provides no verification detail, items are marked [N/A].

- Multiple File Transfer (original SRS §3.1)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

- Audio Recording (original SRS §3.2, including §§3.2.1–3.2.4)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

- Web Feeds (original SRS §3.3, including §3.3.1)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

- Search (original SRS §3.4, including §§3.4.1–3.4.2)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

- Gradebook (original SRS §3.5, including §§3.5.1–3.5.3)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

- Social Networking Applications (original SRS §3.6, including §§3.6.1–3.6.2)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

- Notifications (original SRS §3.7, including §3.7.1)
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations: [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: [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequences: [N/A]
    - Formulas for input to output conversion: [N/A]

## 4.2 Performance requirements
The following verification approaches will be used to qualify the software against the performance requirements. They are organized in parallel with the performance information items (static and dynamic numerical requirements).

- Static numerical requirements verification
  - Number of terminals to be supported: [N/A]
  - Number of simultaneous users to be supported
    - Referenced requirement: The system should support at least 1000 concurrent users.
    - Verification method: Conduct controlled load testing in a production-like environment using a performance test harness to simulate at least 1,000 authenticated users distributed across representative courses. The user mix will exercise typical operations described in the SRS (e.g., login, navigate courses, view/download materials, submit assignments including multiple file upload where enabled, read/post to forums and wikis, view gradebook, perform searches, retrieve web feeds).
    - Evidence collected: Successful completion of scripted transactions for all virtual users, HTTP/application success status, absence of unhandled errors, system resource utilization logs, and test run artifacts.
    - Acceptance: The system remains available and completes all scripted transactions successfully while sustaining at least 1,000 concurrent users during the test run.
  - Amount and type of information to be handled: [N/A]

- Dynamic numerical requirements verification
  - Transactions/tasks throughput and timing under normal and peak workloads: [N/A]
  - Backup/restore within specified time
    - Referenced requirement: The system must have the ability and capacity to restore back-up data within six hours.
    - Verification method: Execute a timed disaster-recovery drill restoring from the most recent backup to a clean environment. Measure from initiation of restore to point at which users can access the system and course data.
    - Evidence collected: Start/stop timestamps, recovery logs, integrity checks confirming course and assignment data availability.
    - Acceptance: End-to-end restoration completes within six hours.

## 4.3 Usability requirements
This section defines the verification approaches and methods that will be used to qualify the software against the usability requirements identified in section 3.3.

- Verification of Requirement 3.3.1: Simple, responsive interface with a single, central administrative interface; ability to configure UI features and change themes/layout across the entire system
  - Method: Expert heuristic evaluation of UI simplicity and page clutter using an established checklist; cognitive walkthroughs on key tasks (e.g., configuring features, editing pages).
  - Method: Demonstration and task-based tests showing that administrators can access a single administrative interface to configure the system, with no need to navigate per-page edit links.
  - Method: System-wide theme/layout change test: apply a theme/layout change once and confirm propagation across representative course pages, dashboards, and activity types.
  - Method: Cross-browser interactive checks for basic UI responsiveness during typical administrative and student tasks.
  - Evidence: Test cases, walkthrough notes, screenshots/video captures, configuration change audit logs.
  - Acceptance thresholds and quantitative usability metrics: [N/A]

- Verification of Requirement 3.3.2: Relevant online user documentation is available on each page; modifications are reported via the main page; supplemental phone/on-site support information is available
  - Method: Page-type inventory and sampling plan covering representative pages (e.g., course home, assignments, forums, wikis, gradebook). Verify presence and functioning of context-relevant help links or embedded help on each sampled page.
  - Method: Content spot-checks to confirm that help topics correspond to the page context and are up to date.
  - Method: Change communication test: perform a representative system modification and verify that an announcement or notice appears on the main page informing users of the change.
  - Method: Verification that supplemental support contact information (phone/on-site) is accessible from the help/documentation entry points.
  - Evidence: Inspection checklists, sampled page list with pass/fail results, change announcement records, links validation report.
  - Acceptance thresholds and quantitative usability metrics: [N/A]

- Verification of Requirement 3.3.3: System administrators have access to comprehensive, searchable documentation with relevance-ordered results; coverage of all regular maintenance procedures, common errors, and advanced troubleshooting, with links to additional information
  - Method: Documentation coverage review against a checklist of required topics (regular maintenance procedures, common errors, advanced troubleshooting), including validation of outbound links and cross-references.
  - Method: Search usability test using a predefined set of administrator tasks and error scenarios; confirm that relevant documents are returned and ordered by relevance as stated.
  - Method: Task-based validation: administrators complete representative maintenance and troubleshooting tasks using only the documentation; record success/fail and issues encountered.
  - Evidence: Coverage checklist with findings, search query/result logs, link integrity report, task completion records.
  - Quantitative relevance/precision-recall thresholds: [N/A]

- Usability safety and avoidance of harm criteria (e.g., preventing user error leading to data loss or misinformation)
  - Applicable requirements content: [N/A]
  - Verification methods and thresholds: [N/A]

## 4.5 Logical database requirements
The following verification approaches qualify the logical database requirements in parallel with items (a)–(g) of Section 3.5.

- a) Types of information used by various functions
  - Requirements-to-schema review: Trace each specified function to corresponding logical data types and attributes, and verify presence in the schema:
    - Pages (assignments, wiki pages, forum posts, announcements) and their per-page settings (multiple file upload, web feed toggle, notifications toggle) per 3.1.1, 3.3.1, 3.7.1.
    - Files/attachments associated to pages and grade feedback per 3.1 and 3.5.1.
    - Voice clips and portfolios with archive/preview options, download format, storage format, and deletion per 3.2.1–3.2.4.
    - Grades with points earned/possible, feedback attachment, and modification timestamps per 3.5.1–3.5.3.
    - Notification subscriptions and delivery preferences (email/SMS) per 3.7.1.
    - Course, user, and role data supporting actors (students, professors, system administrators) per 2.3.
    - Web feed configuration per page per 3.3 and 3.3.1.
    - Search artifacts necessary to return course-scoped and cross-course results grouped by category per 3.4.1–3.4.2.
  - CRUD tests on each data type to demonstrate create, read, update, delete behaviors exercised by the above functions.

- b) Frequency of use
  - Load and concurrency testing aligned to 4.3.1: Simulate at least 1,000 concurrent users executing representative database operations during peak periods (e.g., midterms/finals), including assignment/file submissions, grading updates (with history writes), search queries, notification subscribe/unsubscribe, web feed toggles, voice clip record/download, and portfolio maintenance.
  - Measure DB throughput, latency, and contention; verify no functional degradation that violates specified behaviors.

- c) Accessing capabilities
  - Role-based access tests:
    - Verify grade visibility only to the owning student and course administrators per 3.5.2.
    - Verify course administrators can enable/disable per-page settings for multiple file upload, web feeds, and notifications per 3.1.1, 3.3.1, 3.7.1.
    - Verify students can manage notification subscriptions and delivery preferences per 3.7.1.
    - Verify authorized users can download their own voice clips per 3.2.2.
    - Verify the search box is available on every page after login and scopes results appropriately (in-course vs all courses) per 3.4.2.

- d) Data entities and their relationships
  - Data model review and traceability: Confirm entities and relationships necessary to satisfy requirements:
    - Courses contain pages; pages can have many files/attachments per 3.1.
    - Users (with roles) participate in courses and own portfolios/voice clips per 2.3, 3.2.1.
    - Grades link a student to an assignment/page; each grade has zero or more history records with timestamps per 3.5.1–3.5.3.
    - Notification subscriptions relate users to pages with delivery preferences per 3.7.1.
    - Web feed settings relate to pages per 3.3.1.
  - Referential integrity tests: Create and retrieve across relationships; verify no orphaned records can be created through normal operations.

- e) Integrity constraints
  - Grade constraints: Verify storage of points earned and points possible supports ratio calculation; confirm modification timestamps are captured on every change and histories persist per 3.5.1–3.5.3.
  - Voice clip constraints: Verify ability to delete clips; verify archive/preview vs auto-archive behavior is persisted and enforced; confirm per-user portfolio organization per 3.2.1, 3.2.4.
  - Storage quota constraints: Verify equal and finite storage is allotted to professors/administrators and that they can partition space for students per 3.2.1.
  - Format constraints: Verify voice clips are stored in a speech-optimized format and converted to MP3 only on download per 3.2.3.

- f) Security
  - Authorization tests: Attempt unauthorized access to another user’s grades and verify denial per 3.5.2.
  - Preference/privacy tests: Verify only the owning user (and authorized administrators) can view/modify notification subscriptions and delivery targets per 3.7.1.
  - Auditability checks: Verify that grade change histories with timestamps are recorded for each modification per 3.5.3.

- g) Data retention requirements
  - Backup/restore verification per 4.2.1: Demonstrate nightly backups, optional weekly off-site backups, and successful restoration within six hours.
  - Grade history retention: Verify historical entries persist across changes and are retrievable for dispute review per 3.5.3.
  - Portfolio retention: Verify a user’s voice clip portfolio persists for the duration of the user’s existence in the system and supports deletion by the owner per 3.2.1, 3.2.4.

## 4.6 Design constraints
This section defines the verification approaches to qualify compliance with the identified design constraints.

- Use of Moodle APIs and platform integration (assumption in scope: enhancements will utilize existing Moodle APIs)
  - Methods: architecture/design review to confirm use of published Moodle extension points; code inspection to verify no direct modification of Moodle core; integration testing against a baseline Moodle instance and after a Moodle update; installation test as a standard Moodle plugin.
  - Evidence: review records; code scan results; integration test reports.

- Cross-platform audio playback technology (separate viewer in a cross-platform language) and storage/download format (store optimized for speech; download as MP3)
  - Methods: compatibility testing of the in-system audio player across multiple browsers and operating systems; inspection of stored audio codec/bitrate settings; functional test that downloads are provided in MP3 and are playable; negative tests for non-supported environments.
  - Evidence: test matrix with pass/fail results; storage format inspection logs; sample download artifacts.

- Web feeds format (e.g., RSS 2.0)
  - Methods: schema/validator checks using an RSS 2.0 validator; subscription tests with common feed readers; inspection that feeds are exposed only for pages where enabled.
  - Evidence: validator outputs; subscription test screenshots/logs.

- Integrated wiki and blog engines within Moodle (shared authentication and notification; avoid reliance on external third-party services)
  - Methods: single sign-on tests verifying shared authentication; notification integration tests within Moodle; dependency audit to confirm components are locally hosted and no external service calls are required for core operation.
  - Evidence: SSO test results; notification delivery logs; dependency audit report.

- External regulatory or standards constraints not otherwise stated
  - [N/A]

- Licensing constraints
  - [N/A]

## 4.7 Software system attributes
- Reliability (trace: original SRS 4.2.1)
  - Verification method:
    - Configuration inspection of backup schedule to confirm nightly backups and any weekly/off-site backups are enabled as specified.
    - Restoration drill: perform a full-system restore from a representative backup to a clean environment.
  - Acceptance criteria:
    - Backup jobs are scheduled and enabled to run nightly; any configured weekly/off-site backups are present.
    - End-to-end restoration completes within 6 hours.
  - Evidence:
    - Backup job definitions and schedules.
    - Backup and restore logs with timestamps demonstrating successful nightly runs and a restoration completing in ≤ 6 hours.

- Availability (trace: original SRS 4.2.2)
  - Verification method:
    - Continuous availability monitoring with periodic synthetic checks against key user-facing endpoints during a defined observation window that includes off-hours and business hours.
    - Maintenance window annotation to exclude scheduled downtime from availability calculations.
  - Acceptance criteria:
    - Observed service availability ≥ 99% over a 30-day period, excluding documented maintenance windows.
  - Evidence:
    - Monitoring reports summarizing uptime percentage and incident timelines.
    - Change/maintenance records matching any excluded windows.

- Security
  - Confidentiality of grades (trace: original SRS 3.5.2)
    - Verification method:
      - Role-based access control tests (positive and negative): verify students can view only their own grades; verify course administrators can view grades for their course; verify unauthorized users cannot access others’ grades.
    - Acceptance criteria:
      - All access control test cases pass; no unauthorized disclosure occurs.
    - Evidence:
      - Test case results with screenshots/logs showing permitted/denied access as expected.
  - Grade history retention and auditability (trace: original SRS 3.5.3)
    - Verification method:
      - Functional test: change a grade multiple times and verify a chronological history is retained with timestamps for each modification.
      - Data persistence check across backup/restore: ensure grade history remains intact after restoration (executed in conjunction with reliability tests).
    - Acceptance criteria:
      - Complete grade change history, including timestamps, is visible and accurate after multiple edits and after a restore.
    - Evidence:
      - Grade history views and database/audit extracts as applicable.
  - Cryptographic techniques
    - [N/A]
  - Communications restrictions
    - [N/A]
  - Integrity checks for critical variables
    - [N/A]
  - Data privacy beyond grades
    - [N/A]
  - Security logging beyond grade history
    - [N/A]

- Maintainability (trace: original SRS 4.4.1, 4.6.2, 4.1.1)
  - Maintainable without substantial modification (trace: 4.4.1)
    - Verification method:
      - Maintenance task demonstrations with IT staff: perform representative configuration and routine tasks (e.g., creating courses, enabling features) without code changes.
      - Change effort review: confirm tasks are completed through configuration or administrative interfaces only.
    - Acceptance criteria:
      - All agreed routine maintenance tasks are completed without code modification.
    - Evidence:
      - Signed-off task execution records and screenshots from admin interfaces.
  - Central administrative interface for global configuration (trace: 4.1.1)
    - Verification method:
      - Demonstration that system-wide settings (e.g., themes, layout-affecting settings) can be applied centrally and observed across representative pages.
    - Acceptance criteria:
      - Changes made centrally propagate across the courseware system as intended.
    - Evidence:
      - Before/after captures showing global changes applied from a single administrative interface.
  - Administrator documentation (trace: 4.6.2)
    - Verification method:
      - Documentation review: confirm presence of comprehensive, searchable admin documentation covering regular maintenance, common errors, and advanced troubleshooting references.
      - Search relevance spot-checks for key topics.
    - Acceptance criteria:
      - Required topics are present and discoverable; search returns relevant results for sampled queries.
    - Evidence:
      - Documentation index and search result captures.

- Portability
  - [N/A]

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
- Adoption of Moodle as the base courseware system at the University of Puget Sound; if Moodle is not adopted, requirements mapping to another platform may change.
- Enhancements will utilize existing Moodle APIs; adequacy and stability of those APIs in the selected Moodle version affect feasibility.
- The specific target version of Moodle is to be determined; version differences may impact required functionality and integration effort.
- Stakeholder needs summarized in “Moodle Requirements Brainstorming.pdf” are accurate and sufficiently complete to drive requirements.
- Project timeframe and budget constraints determine which priority levels (Priority 1 and 2, and some 3) are delivered in the initial release.
- Availability of equal and finite storage capacity to support per-user audio clip portfolios and quota partitioning by professors/administrators.
- Cross-platform support for audio: storage in a speech-optimized format, in-browser playback via a cross-platform viewer, and MP3 downloads being widely supported across browsers and operating systems.
- Availability of institutional email services and SMS delivery to support notifications, and users providing/maintaining valid email addresses and mobile numbers.
- Existence and integrability of freely available wiki and blog engines that can share authentication and notifications with Moodle.
- Use of web feeds (e.g., RSS 2.0) is acceptable for course components where updates are published; client consumption of these feeds is assumed.
- Optional use of an external web search engine (e.g., Google) for web-wide searches from within the system, subject to that service’s availability.
- Infrastructure and policies to perform scheduled backups (e.g., nightly) with optional off-site backups, and to restore within six hours as required.
- Hosting capacity (hardware, network, and configuration) sufficient to support at least 1,000 concurrent users during peak periods.
- Availability of Office of Information Services staff and processes to provide maintenance, online documentation, and phone/on-site user support.
- The system may undergo changes based on ongoing stakeholder discussions; evolving requirements are assumed as this is a working document.

## 5.2 Acronyms and abbreviations
- API: Application Programming Interface
- FTE: Full-Time Equivalent
- IT: Information Technology
- MP3: MPEG Audio Layer III
- MPEG: Moving Picture Experts Group
- PDF: Portable Document Format
- RSS: Really Simple Syndication (RSS 2.0)
- SMS: Short Message Service
- e.g.: exempli gratia (for example)
- etc.: et cetera (and so on)
