# 1 Introduction
[NULL]

## 1.1 Purpose
The software’s purpose is to provide an integrated courseware system for the University of Puget Sound that facilitates electronic classroom management and supports teaching and learning. It will enable electronic grading, assignment submission, discussions, and related learning tools, improving the overall learning experience for students and supporting professors in presenting material and managing courses.

The system will refine and extend Moodle to address core functionality currently unavailable, align with university practices, and offer a user interface with a more natural flow of data, leveraging Moodle’s existing APIs.

## 1.2 Scope
This SRS defines the scope of a Moodle-based courseware system enhanced for the University of Puget Sound (the System). The document focuses on immediate requirements for core functionality not available in standard Moodle and small redesigns for consistency with university practices and a more natural user interface flow. The enhancements are intended to be implemented using Moodle’s existing APIs and, while centered on Moodle as the current candidate, also articulate functionality expected of any courseware system considered by the University.

The software product to be produced
- University of Puget Sound’s enhancements to Moodle (Moodle-based courseware system), comprising:
  - Multiple File Transfer
  - Audio Recording and Portfolio for voice clips
  - Web Feed publishing (e.g., RSS) per page/component
  - Course and cross-course Search
  - Gradebook enhancements (grading, feedback, visibility, history)
  - Integrated Wiki
  - Integrated Blog Engine
  - Notifications via e-mail and SMS with subscriptions
  - Central administrative interface for UI/theme and feature configuration
  - Backup and restore capabilities
  - Online user help and searchable administrator documentation

What the software will do
- Enable instructors and students to upload and manage multiple files where appropriate.
- Record, store, organize, preview, download, and delete speech-optimized voice clips in per-user portfolios, with optional attachment to pages.
- Publish configurable web feeds for course components (assignments, forums, wikis, announcements).
- Provide searchable navigation at course and cross-course levels, with an omnipresent search box and a dedicated search page with filtering and relevance-ranked results.
- Support grading workflows with points, feedback (text/attachments), timestamps, visibility controls, and grade history.
- Offer collaborative wiki and blogging tools integrated with Moodle authentication and notifications.
- Notify users of changes via e-mail/SMS and allow user-managed subscriptions.
- Provide a single, central administrative UI to configure themes and system-wide settings, reduce page clutter, and streamline administration.
- Perform scheduled backups and support timely restoration to protect instructional data.
- Supply relevant, in-context user help and comprehensive, searchable admin documentation.

Application, benefits, objectives, and goals
- Application context: An institutional courseware solution for students, professors, and system administrators supporting electronic classroom management, assignment submission, grading, discussion, and collaborative learning.
- Benefits: Improved learning experience; reduced navigation friction and “too many clicks”; timely awareness of course changes; support for foreign-language oral homework portfolios; consistency with university practices; reduced reliance on disparate third-party services through integrated social tools.
- Objectives and goals:
  - Deliver Priority 1 (Core) and Priority 2 requirements in the initial production release, plus feasible Priority 3 items within project constraints.
  - Redesign UI flows to be more intuitive while centralizing configuration.
  - Integrate using Moodle APIs to minimize disruption and leverage existing capabilities.
  - Ensure service availability, data protection, and maintainability appropriate to university operations.

Assumptions and alignment
- The scope is based on the assumption that Moodle is adopted and enhanced via its APIs; however, the requirements also inform evaluation of alternative courseware systems.
- [N/A]

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The product comprises University of Puget Sound enhancements and configurations to a Moodle-based courseware system. It operates as part of a larger learning environment that includes Moodle core, course modules (assignments, forums, wikis, gradebook), optional integrated wiki/blog components, notification mechanisms (email/SMS), web feeds, and backup/restore services. The enhancements are assumed to be implemented using existing Moodle APIs and to share Moodle authentication and notifications. Blackboard is referenced only as an incumbent system; no direct interface to Blackboard is required.

#### System interfaces

- Moodle core APIs
  - Purpose: Host platform for all functionality; enhancements integrate as modules/plugins and configurations (e.g., multiple-file upload per page, search, audio portfolios, feeds, notifications, gradebook improvements).
  - Interface description: Use Moodle’s existing APIs for page creation/editing, authentication, notifications, content storage, and module integration. [N/A] for specific API references.
- Course modules (Assignments, Forums, Wikis, Gradebook)
  - Purpose: Target surfaces for enhanced capabilities (e.g., multiple attachments, feed exposure, inline grading feedback).
  - Interface description: Module-level hooks to enable/disable features per page during create/edit flows. [N/A] for specific hook definitions.
- Notification subsystem (email/SMS)
  - Purpose: Deliver page-level change notifications, with user-managed subscriptions and preferences.
  - Interface description: Outbound email and SMS via institution services or gateways. Message content includes page identity, change summary, and timestamps. [N/A] for message format specification and gateway details.
- Web feeds (e.g., RSS 2.0)
  - Purpose: Syndicate changes for assignments, forums, wikis, announcements, and similar components, configurable per page.
  - Interface description: Expose read-only feeds per enabled page/component. [N/A] for formal feed schema/document reference beyond “RSS 2.0”.
- Backup/restore services
  - Purpose: Protect system and course data; support nightly backups, optional weekly off-site backups, and restoration within six hours.
  - Interface description: Invocation of scheduled backup and restore operations. [N/A] for mechanism and formats.
- Audio portfolio storage
  - Purpose: Store, manage, preview, and optionally auto-archive student voice clips with quotas and deletion controls.
  - Interface description: File storage operations and metadata management; optional attachment of archived clips to upload-capable pages. [N/A] for storage API details.

#### User interfaces

- General UI
  - Simple, responsive, centrally configurable administrative interface to reduce page clutter and enable system-wide theme/layout changes.
- Search
  - Search box present after login on every page; a dedicated search page supports filtering by component and relevancy-grouped results; cross-course search when outside a course.
- Per-page configuration controls
  - During page create/edit, course administrators can toggle multiple-file uploads, feeds, and notifications.
- Gradebook views
  - Instructor entry of grades with timestamps and feedback (text/attachment); student views of own grades, averages, and overall grade; grade history visible to relevant roles.
- Audio portfolio UI
  - Cross-platform clip playback, preview-before-archive option, list/manage/delete archived items, optional download to MP3 on demand.
- Notifications management
  - User preferences for delivery channel (email or SMS) and subscription management; default-on for announcements.
- Style guide
  - [N/A]

#### Hardware interfaces

- [N/A]

#### Software interfaces

- Moodle (base platform)
  - Name: Moodle
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Provides core courseware services and APIs consumed by the enhancements.
  - Interface definition: Use of documented Moodle plugin/module APIs. [N/A] for specific API documents.
- Wiki engine (integrated)
  - Name: [N/A]
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Collaborative content creation within Moodle, sharing authentication and notifications.
  - Interface definition: Integrated authentication/notification; [N/A] for API details.
- Blog engine (integrated)
  - Name: [N/A]
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Tagging, drafting, comments; shares Moodle authentication and notifications.
  - Interface definition: Integrated authentication/notification; [N/A] for API details.
- Email service
  - Name: [N/A] (e.g., SMTP service)
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Outbound notification delivery.
  - Interface definition: [N/A] for protocol/settings.
- SMS gateway/service
  - Name: [N/A]
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: SMS notification delivery to mobile phones.
  - Interface definition: [N/A] for API/format.
- Web feeds
  - Name: RSS 2.0
  - Mnemonic: RSS
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Syndication of page updates.
  - Interface definition: XML-based feed endpoints; [N/A] for formal spec reference.
- Audio playback component
  - Name: [N/A] (cross-platform viewer)
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: In-browser playback of stored speech-optimized audio.
  - Interface definition: [N/A]
- External web search engine (optional)
  - Name: [N/A] (e.g., Google)
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Optional courseware-adjacent search from the dedicated search page.
  - Interface definition: [N/A]

#### Communications interfaces

- Outbound email delivery to users’ email accounts. [N/A] for protocol details.
- Outbound SMS delivery to users’ mobile phones via a gateway/service. [N/A] for protocol details.
- HTTP/HTTPS delivery of RSS feeds to subscribers. [N/A] for protocol/profile details.
- Local network requirements/protocols: [N/A]

#### Memory constraints

- Storage quotas: Equal, finite storage must be allotted for voice clip portfolios for professors/administrators and partitioned among students; exact limits are configurable. Specific sizes: [N/A].
- Additional storage considerations for file attachments, feeds, and backups: [N/A].

#### Operations

- User-initiated operations
  - Students: Upload multiple files where enabled, submit assignments, participate in forums/wikis/blogs, manage notification subscriptions, record/manage voice clips, search within/all courses.
  - Instructors/course administrators: Create/edit pages; toggle multiple uploads, feeds, notifications; grade assignments with feedback; manage course content; manage voice clip archiving and quotas.
- Unattended operations
  - Scheduled backups (nightly) with optional weekly off-site backups; restore capability within six hours.
  - Automatic feed generation/updates for enabled pages.
  - Notification dispatch based on page changes and user subscriptions.
- Availability
  - Target availability: 24x7 access; 99% uptime is sufficient; maintenance windows permitted.
- Data processing support and recovery
  - Backup and recovery as above; help desk and on-site support supplement online documentation.
- Periods/modes specifics: [N/A] beyond the above.

#### Site adaptation requirements

- Configuration of system-wide themes and layout via a central administrative interface.
- Per-page defaults and policies (e.g., notifications default-on for announcements; ability to toggle feeds and multiple uploads).
- Storage quota policies for voice clip portfolios and partitioning among students.
- Backup scheduling (nightly; optional weekly off-site) and restoration procedures.
- Enablement/integration choices for wiki/blog engines within Moodle and sharing authentication/notifications.
- Search scope defaults (course-only vs all courses) and optional external web search link.
- Environment-specific parameters and initialization data: [N/A] for additional site-specific data.

#### Interfaces with services

- Email delivery service for outbound notifications. [N/A] for provider and protocols.
- SMS gateway/service for mobile notifications. [N/A] for provider and APIs.
- Optional external web search service (e.g., Google) accessible from the search page. [N/A] for integration method.
- Off-site backup service if used for weekly backups. [N/A] for provider and data transfer method.

### 1.3.2 Product functions
The courseware system will provide functions that support teaching, learning, and course administration across students, professors, and system administrators. Major functional areas include:

- Course and page management
  - Create and edit course pages and components such as assignments, announcements, forums, wikis, and blogs.
  - Configure per-page options, including enabling/disabling multiple-file uploads, web feeds, and notifications.

- Assignment submission and grading (Gradebook)
  - Accept electronic assignment submissions from students.
  - Allow course administrators to record grades (points earned/possible), attach textual or file feedback, and timestamp grade changes.
  - Display grades, averages, and overall course grades to the appropriate student while protecting privacy.
  - Maintain a grade change history for auditing and dispute resolution.

- File and media management
  - Support multiple-file uploads where allowed, configurable per page (e.g., assignment, wiki, forum post).
  - Capture, store, and organize student voice clips in a portfolio optimized for speech.
  - Allow professors/administrators to manage storage, preview clips prior to archival or auto-archive on submission, and permit students to attach archived clips to permitted pages.
  - Enable download of clips in a broadly supported format (e.g., MP3) and deletion of archived clips by owners.

- Search and navigation
  - Provide a search box on every page after login.
  - Offer course-level and cross-course search with filtering by component (e.g., assignments, forums, wikis) and grouped results (by category and/or course) based on relevance.
  - Provide a dedicated search page with advanced filters.

- Communication, collaboration, and social learning
  - Provide an integrated wiki for collaborative content creation with simple markup and intra-wiki linking.
  - Provide an integrated blog engine with modern features (e.g., tagging, drafts, comments).
  - Share authentication and notifications across these components to reduce friction.

- Notifications and subscriptions
  - Provide per-page e-mail and SMS notifications for new or changed content (e.g., assignments, announcements, forum posts).
  - Default notifications on for announcements; allow course administrators to toggle notifications per page.
  - Allow students to subscribe/unsubscribe and select preferred delivery channel (SMS or e-mail).

- Feeds and syndication
  - Provide web feeds (e.g., RSS) for pages/components such as assignments, forums, announcements, and wikis.
  - Allow course administrators to enable/disable feeds per page/component.

- Data protection and recovery
  - Perform scheduled backups (e.g., nightly) with options for off-site weekly backups.
  - Restore from backups within defined timeframes to minimize downtime.

- Online help and documentation
  - Provide context-relevant user help on each page.
  - Provide comprehensive, searchable administrator documentation covering routine maintenance, common errors, and advanced troubleshooting.

Relationships among functions (textual overview):
- Per-page configuration (uploads, feeds, notifications) applies consistently across course components (assignments, forums, wikis, announcements).
- Search indexes and surfaces content from all enabled components and respects access permissions.
- Notifications and feeds are complementary delivery mechanisms for content change awareness.
- The gradebook functions consume assignment submission artifacts (including multiple files and feedback attachments).
- Audio portfolios integrate with submission and content attachment points where uploads are permitted.

Illustrative user scenarios:
- As a student, I upload multiple files to an assignment and later search within my course to find the assignment page again.
- As a professor, I enable notifications and an RSS feed for a new assignment, grade submissions with feedback, and rely on timestamps and history for any subsequent grade changes.
- As a language student, I record a voice clip that is auto-archived in my portfolio, attach it to an assignment, and download past clips as MP3 to review my progress.
- As a professor, I create a wiki for group collaboration and a course blog, both using the same login and sending notifications to subscribers.

### 1.3.3 User characteristics
The intended users are members of the University of Puget Sound community and fall into three primary groups whose roles and typical tasks influence usability needs.

- Students
  - Primary consumers of the courseware.
  - Typical tasks: access information posted by professors, upload assignments and project files, participate in discussions and collaborative activities (e.g., forums, wikis).
  - Usability implications: frequent need for quick, direct navigation and search within and across courses; streamlined submission workflows.

- Professors (course administrators)
  - Primary content administrators of courses.
  - Typical tasks: upload files, links, and multimedia; create and manage course components (e.g., assignments, discussions, collaboration spaces); grade assignments and provide feedback.
  - Usability implications: need straightforward controls to configure page-level options (e.g., feeds, multiple-file uploads), and efficient grading and feedback workflows.

- System administrators
  - Responsible for maintaining the courseware system.
  - Typical tasks: configure the system, apply updates, and perform maintenance.
  - Usability implications: benefit from a central, easy-to-use administrative interface and comprehensive, searchable documentation to reduce maintenance effort.

Cross-cutting characteristics affecting usability:
- Educational level: University students and university faculty; system administrators in the Office of Information Services.
- Experience with similar systems: [N/A]
- Disabilities and accessibility considerations: [N/A]
- Technical expertise: [N/A]

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

- b) Hardware limitations: [N/A]

- c) Interfaces to other applications:
  - Enhancements must utilize existing Moodle APIs made available by Moodle.
  - Integrated social applications (wiki and blog) must share authentication and notification with Moodle.
  - The system must support web feeds (e.g., RSS 2.0) for selected pages/components.
  - The system must provide both e-mail and SMS notifications for pages.
  - A separate, cross-platform audio clip viewer must be provided within Moodle.
  - Optional linking to a standard web search engine (e.g., Google) may be provided from the search page.

- d) Parallel operation: [N/A]

- e) Audit functions:
  - Grades must include timestamps for the last modification.
  - A history of grade changes for assignments must be maintained for review/dispute.

- f) Control functions:
  - Course administrators must be able to toggle features on a per-page basis, including:
    - Multiple file upload.
    - Web feed availability.
    - Notifications (on by default for announcements; students may subscribe if off).

- g) Higher-order language requirements:
  - The audio playback viewer must be implemented in a cross-platform language.

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

- i) Quality requirements:
  - Availability target: 24/7 access with 99% uptime (allows maintenance windows).
  - Backup/restore: Nightly backups with options for weekly off-site backup; ability to restore within six hours.
  - Performance: Support at least 1,000 concurrent users.
  - Maintainability: The system must be mostly self-sustaining and maintainable without substantial modification; provide a single, central administrative interface for configuration and theming.

- j) Criticality of the application:
  - The courseware system is important to course operations (e.g., assignment submission) and experiences peak load during midterms/finals; however, high availability is not mandated beyond the 99% uptime expectation.

- k) Safety and security considerations:
  - Grade privacy: Only the student to whom grades belong and the course administrator for the course may view grade information.
  - Data protection: Regular backups as above to protect assignment and course data.

- l) Physical/mental considerations:
  - Usability constraints require a simple, responsive interface that reduces page clutter and minimizes navigation steps; search must be available on every page after login.

- m) Limitations sourced from other systems (including real-time requirements through interfaces):
  - Assumes Moodle will be adopted and that enhancements are constrained by Moodle’s architecture and APIs.
  - Integrated components (e.g., wiki, blog, notifications, audio viewer) must operate within Moodle’s authentication/notification framework.
  - Real-time interface requirements: [N/A]

## 1.4 Definitions
- Actor: Synonymous with user; used to describe users who are performing actions in use cases.

- Course administrator: An actor acting as a professor or system administrator who has the ability to manage courses and course pages.

- Courseware system: Software that facilitates electronic classroom management and provides electronic grading, assignment submission, discussion, and other learning tools.

- System: The existing courseware system, a new courseware system, or any modifications being made to Moodle while it is being considered as a replacement for the existing courseware system.

- Page: Any distinct unit or upload point within the courseware system (e.g., an assignment submission, a wiki page, a forum post or thread, an announcement, or similar component) that may accept uploads, generate feeds, or be searched.

- Portfolio (Archive): A long-term, per-actor collection of recorded voice clips maintained within the courseware system to organize, review, and compare recordings over time.

- Voice clip: A recorded audio submission (e.g., for oral homework) stored in a speech-optimized format and optionally downloadable (e.g., as MP3) for archival or presentation purposes.

- Web feed: A syndication feed (e.g., RSS 2.0) for a page’s new or changed content (such as forum posts, assignment postings, announcements, or wiki alterations), configurable on a per-page basis.

- Priority 1 (Core): Core functionality currently existing in Moodle/Blackboard.

- Priority 2: Functionality not explicitly available today, but considered critical to implementing a courseware system at the University.

- Priority 3: Functionality just outside the parameters of Priority 2; very important to supplement critical functionality.

- Priority 4: Functionality outside the parameters of Priority 2; valuable as a supplement, but not critical.

# 2 References
## 2.1 Compliance
- [N/A]

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

# 3 Requirements
[NULL]

## 3.1 Functions
This section defines the fundamental actions of the courseware system, partitioned into sub-functions, and describes inputs, processing, outputs, validity checks, effects of parameters, and the relationship of outputs to inputs. Where the original SRS does not specify requested details, [N/A] is indicated.

### 3.1.1 Multiple file transfer (per page)
- Validity checks on inputs:
  - Actor must be in the role of course administrator/professor to enable multiple file upload. 
  - The page must have multiple-file upload enabled to accept more than one file.
  - [N/A] file type/size/quota checks.
- Exact sequence of operations:
  1) Course administrator creates or edits a page and enables multiple-file upload (optional).
  2) Actor uploads one or more files to the page (assignment, forum post, wiki page, etc.).
  3) System stores files and associates them with the 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:
  - Per-page toggle (multiple-file upload on/off) determines whether the upload form accepts one or many files.
- Relationship of outputs to inputs:
  - Input/output sequence: Files provided by the actor become stored artifacts attached to the specified page; successful store yields the page updated with file listings.
  - Formulas for conversion: [N/A]

### 3.1.2 Audio recording and portfolios
- Validity checks on inputs:
  - Actor in student role may submit/record voice clips; professors/administrators manage storage partitions.
  - [N/A] on maximum duration/bitrate/content checks.
- Exact sequence of operations:
  1) Student records/submits a voice clip.
  2) Professor/administrator chooses archival mode:
     - Preview-then-archive: clip is previewed; actor decides to archive or discard.
     - Auto-archive: clip is archived upon submission.
  3) Clip is stored in the student’s portfolio in a speech-optimized format.
  4) Actor may attach archived clips to any page that permits uploads.
  5) Actor may download a clip (mp3) or delete a clip from their portfolio.
- Responses to abnormal situations:
  - Overflow (drive space/quota): [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - Equal and finite drive space is allotted to professors/administrators; they may partition this space for students.
  - Archival mode (preview vs. auto-archive) changes when a clip is stored and whether pre-archive review occurs.
  - Download format selection determines whether on-the-fly conversion to mp3 occurs.
- Relationship of outputs to inputs:
  - Input/output sequence: Recorded clip → stored in portfolio → optionally attached to pages → optionally downloaded or deleted.
  - Formulas for conversion: Stored speech-optimized format is converted to MPEG Audio (mp3) on download; exact conversion formula/codec details: [N/A]

### 3.1.3 Web feeds (per component/page)
- Validity checks on inputs:
  - Course administrator must enable feeds for a page/component.
  - [N/A] on feed syntax validation and audience scoping rules.
- Exact sequence of operations:
  1) During page creation/edit, course administrator toggles web feed availability.
  2) When content is added/updated (assignments, announcements, forum posts, wiki edits), the system emits corresponding feed entries.
- 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 controls whether updates appear in feeds.
  - Administrator determines which components have feeds and to whom the feeds pertain.
- Relationship of outputs to inputs:
  - Input/output sequence: Page update events → feed item generation → feed consumption by clients.
  - Formulas for conversion: [N/A]

### 3.1.4 Search (course and cross-course)
- Validity checks on inputs:
  - Actor must be logged in to search.
  - [N/A] on search term length/character validation.
- Exact sequence of operations:
  1) Actor enters query in search box available on every page.
  2) Context handling:
     - Inside a course: search that course, with option to search all courses.
     - Outside any course: search all of the actor’s courses.
  3) Optional dedicated search page allows filtering by component (Assignments, Wiki Pages, Forum Posts, etc.) and scope selection.
  4) System computes relevance and groups results by category (and by course when applicable).
  5) Actor selects a result; system navigates to the corresponding page.
  6) Optional: page may allow searching the web via a standard engine. 
- Responses to abnormal situations:
  - Overflow (very large result sets): [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - Filters (component types) and scope (course vs. all courses) constrain the result set.
- Relationship of outputs to inputs:
  - Input/output sequence: Query + filters + context → ranked, grouped result list → navigation to selected page.
  - Formulas for conversion:
    - Relevance is determined by results having the highest number of terms matching the search terms; precise ranking formula: [N/A]

### 3.1.5 Gradebook (assignment grading and history)
- Validity checks on inputs:
  - Only course administrators can post/modify grades.
  - [N/A] on numeric range validation and attachment scanning.
- Exact sequence of operations:
  1) Course administrator enters points earned and points possible for an assignment; optionally adds textual feedback or an attachment.
  2) System records grade and timestamp.
  3) If a grade is changed, the system maintains a grade history with timestamps.
  4) The student to whom the grade belongs can view per-assignment grades, averages, and overall grade; other students cannot.
- Responses to abnormal situations:
  - Overflow (gradebook size/history growth): [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - Presence of feedback (text/attachment) augments the stored grade record.
- Relationship of outputs to inputs:
  - Input/output sequence: Points and feedback → stored grade record (+timestamp, history) → student-visible grade views.
  - Formulas for conversion:
    - Assignment grade computation is based on the ratio of points earned to points possible; exact scaling/weighting beyond this ratio: [N/A]

### 3.1.6 Social networking applications (wiki and blog)
- Wiki
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations:
    1) Actors collaboratively edit wiki pages using a simple markup language.
    2) Pages can link to other wiki pages.
    3) Authentication and notifications are integrated 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:
    - Input/output sequence: Markup edits → rendered wiki pages interconnected via links.
    - Formulas for conversion: [N/A]
- Blog
  - Validity checks on inputs: [N/A]
  - Exact sequence of operations:
    1) Actors create blog posts; may save drafts.
    2) Actors tag posts; others may comment.
    3) 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:
    - Input/output sequence: Drafts/tags/comments → published blog entries with metadata and discussion.
    - Formulas for conversion: [N/A]

### 3.1.7 Notifications (email and SMS)
- Validity checks on inputs:
  - Course administrator can toggle notifications on page creation.
  - Students can subscribe/unsubscribe and set delivery preference (SMS or email).
  - Default: notifications on for announcements.
- Exact sequence of operations:
  1) When a page is created, the course administrator sets notifications on/off.
  2) If notifications are off, students may individually subscribe.
  3) On relevant page events, the system sends notifications via the recipient’s chosen channel (email or SMS).
  4) Students may update preferences or remove subscriptions.
- Responses to abnormal situations:
  - Overflow (notification queue/backlog): [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:
  - Page-level notification toggle and per-user delivery preferences directly control whether and how notifications are sent.
- Relationship of outputs to inputs:
  - Input/output sequence: Page events + subscription state + delivery preference → dispatched email/SMS messages.
  - Formulas for conversion: [N/A]

## 3.2 Performance requirements
The following requirements specify static capacity limits and dynamic time-based expectations for the system. Items not specified in the original SRS are marked as [N/A].

- Static capacity requirements
  - Number of terminals to be supported: [N/A]
  - Simultaneous users to be supported: The system shall support at least 1,000 concurrent users.
  - Amount and type of information to be handled:
    - Types: assignments, forums, wikis, grades, notifications (email/SMS), audio voice clips, and web feeds.
    - Quantitative limits (e.g., maximum file sizes, per-user storage, per-course storage, total system storage): [N/A]

- Dynamic performance requirements
  - Backup and restore
    - The system must support a configurable backup schedule.
    - The system should be backed up on a nightly basis, with an option for weekly off-site backup.
    - The system must be able to restore backup data within 6 hours.
  - Transaction/response time under normal workload (e.g., page loads, assignment submission, search, grading): [N/A]
  - Transaction/response time under peak workload (e.g., midterm/finals periods): [N/A]
  - Throughput targets (e.g., transactions per second, background processing rates): [N/A]
  - Data processing volumes within defined time windows (e.g., indexing, notifications dispatch): [N/A]

## 3.3 Usability requirements
- The system should provide a simple, responsive interface that reduces page clutter and makes configuration easy for administrators. The underlying architecture should be transparent to administrators and configurable from a single, central administrative position. The system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page. The interface must allow administrators to easily change themes and other settings that affect page layout across the entire courseware system.

- The system should enable actors to use search functionality as a primary way to navigate pages, in addition to hierarchical links, to reduce the number of steps needed to complete basic actions.
  - A search box and a Search button should be displayed on every page after an actor has logged in.
  - If the actor is outside a particular course, searches should cover all of the actor’s courses and group results by course. If the actor is inside a course, that course should be searched with an option to search all courses.
  - A dedicated search page should be provided that allows filtering of results (e.g., forum posts, grades) and searching specific sections of the system. Results should appear in categories (e.g., Assignments, Wiki Pages, Forum Posts) based on relevance, where relevance is determined by the highest number of terms matching the search terms. Selecting a result should navigate directly to the corresponding page.

- Relevant, online user documentation should be available on each page to provide easy access to help during interaction with the system. Modifications should be reported via the main page to inform actors of unexpected changes. This electronic documentation should be supplemented with phone and on-site support provided by the Office of Information Services.

- System administrators must have access to comprehensive, searchable documentation. Search results should be displayed based on relevance. This documentation must cover all procedures necessary for regular maintenance (with links to additional information), all common errors, and links or documentation for advanced troubleshooting.

## 3.5 Logical database requirements
- a) Types of information used by various functions
  - Users and roles: actors (students, professors, system administrators) and their roles in courses.
  - Courses and enrollment: courses and the association of actors to courses.
  - Pages/components within a course: assignments, forums, wiki pages, announcements, and other distinct upload/interaction points (“pages” or “components”).
  - Files and attachments: uploaded files associated with pages (e.g., assignment submissions, forum posts, wiki pages, announcements); per-page setting for multiple-file upload.
  - Gradebook: per-assignment grades (points earned, points possible), timestamps of last modification, instructor feedback (text and/or attachment), and grade change history.
  - Audio portfolios: voice clips recorded/submitted by students, organized into a portfolio/archive; clip metadata (owner, course/context, timestamps, format optimized for speech), and professor/administrator-managed storage allocation that can be partitioned for students; deletion state.
  - Web feeds: per-page feed enablement; feed items reflecting additions/changes to forums, assignments, announcements, and wikis.
  - Search: searchable representation of pages/components and their content with categorization of results (Assignments, Wiki Pages, Forum Posts, etc.) and relevance indicators.
  - Notifications: per-page notification enablement; per-user subscription and delivery preferences (e-mail or SMS); default-on for announcements.
  - Social networking applications: wiki content (pages and links among them); blog content (posts, tags, drafts, comments).

- b) Frequency of use
  - The database shall support at least 1,000 concurrent users accessing and updating data, with peak usage likely during midterm and finals weeks.
  - Search shall be available from every page after login and is expected to be used frequently at course scope and, optionally, across all courses.
  - Grade viewing by students and grade posting/editing by course administrators occur throughout a term; grade changes must be recorded whenever they occur.
  - Web feeds and notifications are produced when content is created or changed; announcements default to notifications on.
  - Voice clip recording, organization, preview, archiving, download, and deletion occur as required by courses using oral homework.
  - More granular per-entity transaction rates and volumes: [N/A].

- c) Accessing capabilities
  - Query and filter by course, user, role, and component/page type (e.g., assignments, forums, wikis, announcements).
  - Provide course-scoped search with optional all-courses search; allow filtering by component type; return categorized results ordered by relevance.
  - Retrieve grade details and full grade change history with timestamps for a given student, assignment, and course.
  - Retrieve and manage per-page settings (multiple file upload, web feed enabled/disabled, notifications enabled/disabled).
  - Retrieve, preview, download (as MP3), and delete voice clips from an actor’s portfolio/archive.
  - Manage notification subscriptions and delivery preferences per user; allow opt-in when notifications are off at the page level.
  - Web feeds must be retrievable for pages where feeds are enabled and scoped “to whom these feeds should pertain” as determined by course administrators.

- d) Data entities and relationships
  - User —< Enrollment >— Course: users are enrolled in courses with roles (student, professor, system administrator).
  - Course —< Component/Page: a course contains many components/pages (assignments, forums, wikis, announcements).
  - Assignment —< Submission >— User (student): students submit to assignments; submissions can include multiple files when permitted.
  - Submission/Assignment + User —< Grade: each student has a grade per assignment; grades include feedback and timestamps; Grade —< GradeHistory (changes with timestamps).
  - Page/Component —< File: pages can have zero or more attached files subject to the per-page multi-file setting.
  - User —< VoiceClip (Portfolio/Archive): each actor maintains a portfolio/archive of voice clips; clips can be associated with courses/assignments; professors/administrators have storage allocations that can be partitioned for students.
  - Page/Component —< FeedConfig: per-page feed enablement and scope; page changes produce feed items.
  - User —< NotificationPreference: delivery channel (e-mail or SMS).
  - Page/Component —< NotificationSubscription >— User: users may subscribe to notifications per page when allowed.
  - SearchIndex — references — Page/Component: searchable terms/content mapped to pages/components and their categories.
  - Wiki (pages linking to pages) and Blog (posts —< Comments; posts —< Tags; posts may be Drafts).

- e) Integrity constraints
  - Grades
    - Exactly one current grade per student per assignment; changes must create GradeHistory entries with timestamps.
    - Grade feedback may include text and/or an attachment linked to the grade record.
    - Grade timestamps for last modification are mandatory.
  - Access/visibility
    - Only the grade owner (student) and the course’s administrators may view a student’s grades for that course.
  - Files and uploads
    - The number of files attached to a page must comply with that page’s multi-file upload setting.
  - Audio portfolios
    - Voice clips are stored in a format optimized for speech; downloads are provided as MP3 without altering the stored master.
    - Users may delete their own recorded clips from their portfolio/archive.
    - Storage for voice clips must observe finite, per-professor/administrator allocations and any partitions assigned to students.
  - Notifications and feeds
    - Announcement pages default to notifications enabled; other pages follow their configured default.
    - Web feeds must only include items for pages where feeds are enabled and only for the audience designated by the course administrator.
  - Search
    - Search relevance is determined by term matching as specified; results must be categorized (e.g., Assignments, Wiki Pages, Forum Posts).
  - Additional domain-specific validation rules (e.g., allowable value ranges beyond those stated): [N/A].

- f) Security
  - Role-based access control enforcing actor capabilities:
    - Course administrators/professors manage courses, pages, grades, per-page settings, and voice clip storage allocations.
    - Students access their own submissions, portfolios, and grades; they may subscribe to notifications when allowed.
  - Privacy
    - Grade information is visible only to the grade owner and course administrators for the relevant course.
    - Web feeds and notifications must respect configured audience/scope.
  - Search results must respect all access controls so that restricted data (e.g., grades) is not disclosed to unauthorized users.
  - Security controls for storage and delivery of e-mail/SMS contact details: [N/A].

- g) Data retention requirements
  - Audio portfolios: voice clips are maintained for each actor “during his or her existence in the course management system,” with user-initiated deletion permitted.
  - Gradebook: a history of grade changes must be maintained (no loss of prior values when grades are changed).
  - Backups: the system must be backed up on a configurable schedule; nightly backups with options for weekly, off-site backups; ability to restore within six hours.
  - Retention periods for courses, submissions, files, wiki/blog content, forums, feeds, notifications, and search index beyond the statements above: [N/A].

## 3.6 Design constraints
- External standards and formats
  - Web feeds must support RSS 2.0 for course components where feeds are provided.
  - Audio clips must be downloadable in MPEG Audio (MP3) format; stored in a format optimized for speech, with playback provided via a cross-platform viewer within Moodle.

- Regulatory and compliance constraints
  - [N/A]

- Platform and integration constraints
  - Enhancements must utilize existing Moodle APIs; the system is assumed to be implemented as extensions to or integrations with Moodle.
  - Wiki and blog functionality should be integrated inside Moodle (sharing authentication and notifications) rather than relying on separate third-party services.

- Maintainability and administration constraints
  - The system must provide a single, centralized administrative interface to configure UI themes and features across the entire courseware system.
  - The system must be maintainable without substantial modification and be mostly self-sustaining due to limited IT staff.

- Operational and infrastructure constraints
  - The system must support scheduled backups (nightly, with options for weekly off-site backups) and be able to restore from backup within six hours.
  - The system should be available 24x7 with approximately 99% uptime, allowing for scheduled maintenance windows.

- Licensing constraints
  - [N/A]

## 3.7 Software system attributes
### Reliability
- The system must be backed up on a configurable schedule.
- The system must support nightly backups, with options for weekly, off-site backup 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% uptime is sufficient to meet the availability expectation.
- This expectation does not exclude maintenance windows or scheduled downtime.

### Security
- Grade information must be displayed only to the actor to whom the grades belong and to the course administrators for the course to which the grades pertain.

### Maintainability
- The system must be maintainable without substantial modification and be mostly self-sustaining to minimize IT staff effort.
- The system should provide a single, central administrative interface to configure the user interface and features across the entire courseware system, including global theme and layout settings.
- System administrators must have access to comprehensive, searchable documentation covering regular maintenance procedures, common errors, and advanced troubleshooting.

### Portability
- [N/A]

## 3.8 Supporting information
This section consolidates supporting and background information to aid interpretation of the SRS. Unless an item below is explicitly restated as a requirement elsewhere in Sections 3 or 4, it is not to be considered a binding requirement.

- Sample input/output formats
  - [N/A]

- Cost analysis studies
  - [N/A]

- Results of user surveys or interviews
  - Stakeholder interviews (e.g., professors and students) informed these requirements; their feedback is summarized in “Moodle Requirements Brainstorming.pdf” (see Section 1.4.1). This SRS does not make any further reference to that document.

- Supporting/background information
  - Assumptions and scope:
    - The University of Puget Sound is investigating Moodle as a candidate to replace Blackboard; Moodle is not yet selected.
    - Enhancements are expected to use Moodle’s existing APIs and include small redesigns and a user-interface redesign to support a more natural flow of data.
    - This is a working document subject to change; it forms a basis for ongoing stakeholder discussions.
  - Actors and terminology:
    - Actors include students, professors, and system administrators; “course administrator” denotes a professor or system administrator who can manage courses and course pages.
    - “Page” refers to any distinct item such as an assignment, wiki page, or forum post (also an upload point).
  - Priority and release intent:
    - Priorities: 1 (Core), 2 (Critical additions), 3 (Important supplements), 4 (Valuable, non-critical).
    - Initial production release targets Priority 1 and 2 requirements, plus as many Priority 3 items as feasible within time and budget.

- Problems to be solved by the software (as identified in the SRS)
  - Content submission and organization:
    - Current systems make it difficult to upload and manage multiple files for a single page or assignment.
    - Foreign language courses cannot capture, organize, and track student voice clips across courses.
  - Awareness and navigation:
    - Lack of web feeds and notifications hampers timely awareness of new or changed content.
    - Navigation is cumbersome (too many clicks); users need search at course and cross-course levels.
  - Teaching and assessment:
    - Gradebook needs clear grading workflows, feedback attachments, timestamps, visibility controls, and history.
  - Collaboration tools:
    - Existing social/collaborative components are weak; integrated wiki and blog with shared authentication/notifications are needed.
  - Communications:
    - No email/SMS notifications with opt-in/opt-out and per-page (component) control.
  - Operations and quality attributes:
    - Data protection requires scheduled backups and timely restoration.
    - Availability expectations (24x7 with reasonable uptime) during both business and off-hours.
    - Performance must support substantial concurrent use (e.g., midterms/finals).
    - Limited IT staffing necessitates maintainability with minimal ongoing effort.
    - Users and administrators need accessible, relevant online help and comprehensive, searchable admin documentation.

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

Scope note on requirement status: The items above are provided for context and are not requirements unless they are explicitly restated as numbered requirements elsewhere in this SRS.

# 4 Verification
[NULL]

## 4.1 Functions
This subsection defines the planned verification approaches for each functional area in parallel with the functional requirements. For each area, the verification will address: validity checks on inputs; exact sequence of operations; responses to abnormal situations (overflow, communication facilities, hardware faults/failures, error handling and recovery); effect of parameters; and relationship of outputs to inputs (including input/output sequences and any formulas). Where the original SRS does not specify behavior, the item is marked [N/A].

- Multiple File Transfer (per-page configurable multiple uploads)
  - Validity checks on inputs:
    - Verify that when the multiple-file option is enabled for a page, the upload control accepts more than one file; when disabled, it accepts only one file.
    - [N/A] for file type, size limits, or virus checks (not specified).
  - Exact sequence of operations:
    - Enable/disable multiple uploads during page creation and edit; confirm the setting persists.
    - Upload files as an authorized actor (course administrator, professor, student as permitted by the page) and confirm successful completion and association to the target page (assignment, forum post, wiki page, announcement).
  - 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 toggle for multiple upload; actor role permissions (course administrator/professor enabling the feature).
  - Relationship of outputs to inputs:
    - After upload, all selected files appear on the page to which they were uploaded and are retrievable; the count of stored files equals the count selected for upload; no unintended files are attached.

- Audio Recording (portfolio of voice clips, download, storage format, deletion)
  - Validity checks on inputs:
    - Verify that only authenticated actors can record/submit clips and that clips are associated to the correct actor portfolio.
    - [N/A] for allowed audio formats on input (not specified).
  - Exact sequence of operations:
    - Portfolio space allocation: confirm each professor/administrator is allotted finite space and can partition space for students.
    - Preview-then-archive mode: record → preview → choose archive or discard; confirm only chosen clips are archived.
    - Auto-archive mode: record/submit → clip is archived automatically.
    - Attach archived clip to any page where uploads are permitted; confirm attachment references the archived item.
    - Download a clip; confirm delivery in MPEG Audio (mp3).
    - Listen in provided viewer without download; confirm cross-platform operation. 
    - Delete a clip from the portfolio; confirm removal and no longer available for attachment.
  - Responses to abnormal situations:
    - Overflow: [N/A] for behavior when portfolio space is exhausted.
    - Communication facilities: [N/A].
    - Hardware faults and failures: [N/A].
    - Error handling and recovery: [N/A].
  - Effect of parameters:
    - Choice between preview-then-archive and auto-archive modes; partitioning of storage space; actor role (professor/administrator/student).
  - Relationship of outputs to inputs:
    - Stored format optimized for speech; verify that storage format differs from mp3 if applicable and that on-demand conversion to mp3 occurs only at download.
    - Post-deletion, the clip is absent from portfolio listings and attachments referencing it indicate unavailability as appropriate. 
    - Input/output sequence: record → store (per selected mode) → optional attach → optional download (conversion to mp3 on download).

- Web Feeds (per-page RSS-like feeds)
  - Validity checks on inputs:
    - Verify that when feeds are enabled for selected components/pages, only the intended content appears in feeds and is associated with the correct course/context.
    - Verify configuration restricting “to whom feeds should pertain” produces feeds scoped to that audience. 
  - Exact sequence of operations:
    - Create/edit a page; toggle feed availability; confirm feed endpoint is created/removed accordingly.
    - Generate events (e.g., new forum post, assignment posting, announcement, wiki edit); confirm corresponding feed items appear with correct metadata and ordering.
  - Responses to abnormal situations:
    - Overflow: [N/A].
    - Communication facilities: [N/A] for behavior when external aggregators poll feeds.
    - Hardware faults and failures: [N/A].
    - Error handling and recovery: [N/A].
  - Effect of parameters:
    - Per-page feed toggle; administrator selection of components and target audience for feeds.
  - Relationship of outputs to inputs:
    - Each supported content change results in a corresponding feed item; disabling the feed stops new items and hides or removes the feed as configured.

- Search (course and global search with scoping, filters, relevance, and ubiquitous search box)
  - Validity checks on inputs:
    - Verify search accepts text queries; [N/A] for special character handling or query syntax beyond term matching.
  - Exact sequence of operations:
    - Presence of a search box on every page after login.
    - From outside any course: execute a query; confirm all of the actor’s courses are searched and results are grouped by course.
    - From within a course: execute a query; confirm default scope is the current course with an option to expand to all courses.
    - Use the dedicated search page: apply filters (e.g., exclude forum posts, grades, etc.) and select specific sections; confirm only selected categories are returned.
    - Select a result; confirm navigation to the correct target page.
    - Verify results are grouped by categories (Assignments, Wiki Pages, Forum Posts, etc.) and ordered by relevance as defined.
  - 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 by content type; course scope selection; actor’s login state (search box appears only after login).
  - Relationship of outputs to inputs:
    - Relevance is determined by number of term matches; verify ordering reflects decreasing match counts.
    - Input/output sequence: enter query → apply scope/filters → display grouped, relevant results → navigate to selected page.

- Gradebook (grading assignments, feedback, visibility, timestamps, history)
  - Validity checks on inputs:
    - Verify that only course administrators can enter/modify grades for their course.
    - Verify entered points earned and points possible are numeric; [N/A] for constraints such as non-negative ranges or division by zero handling.
    - Verify optional feedback text and attachment are accepted.
  - Exact sequence of operations:
    - Enter a grade for an assignment as points earned/points possible; save; confirm proper storage and visibility to the correct student.
    - Attach feedback (text and/or file); confirm association with the graded item.
    - Modify a grade; confirm timestamp updates and history entry is created.
    - View gradebook as the student; confirm visibility only to the student owner and course administrators.
  - Responses to abnormal situations:
    - Overflow: [N/A].
    - Communication facilities: [N/A].
    - Hardware faults and failures: [N/A].
    - Error handling and recovery:
      - Verify that grade history persists across edits and allows review of prior values with associated timestamps.
  - Effect of parameters:
    - [N/A] for weighting schemes or aggregation parameters (not specified).
  - Relationship of outputs to inputs:
    - Verify displayed assignment grade is based on the input ratio points earned/points possible.
    - Verify overall grade and averages are displayed to the student as specified; [N/A] for formulas for overall grade calculation (not specified).

- Social Networking Applications (wiki and blog integration)
  - Validity checks on inputs:
    - Wiki: verify acceptance of the simple markup language and creation of links to other wiki pages.
    - Blog: verify creation of posts with tagging, drafting, and comments.
  - Exact sequence of operations:
    - Wiki: create/edit pages; add links; confirm content persistence and navigable links.
    - Blog: create draft → publish; add tags and comments; confirm functions operate as specified.
    - Confirm authentication is shared with Moodle (single sign-on) and that notification integration is available where applicable.
  - 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] for configurable parameters beyond features listed.
  - Relationship of outputs to inputs:
    - Wiki/blog content displayed matches submitted content; links navigate to intended targets; comments associate with the correct posts.

- Notifications (email and SMS, defaults, subscriptions, preferences)
  - Validity checks on inputs:
    - Verify that on page creation, the notification toggle reflects the page type default (on by default for announcements).
    - Verify student preference selection of delivery method (SMS or email) is stored and used.
    - Verify subscription management accepts add/remove requests from students when notifications are off by the page owner.
  - Exact sequence of operations:
    - Create a page with notifications enabled; perform a change; confirm notifications are sent to subscribed actors via their chosen channel.
    - Create a page with notifications disabled; as a student, subscribe; perform a change; confirm delivery to the subscribing student only.
    - Change preferences from email to SMS (and vice versa); confirm subsequent notifications follow the new preference.
    - Unsubscribe; confirm no further notifications are delivered.
  - Responses to abnormal situations:
    - Overflow: [N/A] (e.g., high-volume throttling not specified).
    - Communication facilities: [N/A] for retry behavior on external email/SMS failures.
    - Hardware faults and failures: [N/A].
    - Error handling and recovery: [N/A].
  - Effect of parameters:
    - Page-level notification toggle; default behavior for announcements; per-user delivery preference; subscription status.
  - Relationship of outputs to inputs:
    - Each qualifying page event results in one notification per subscribed actor via the selected channel; disabling notifications or unsubscribing prevents further delivery.

- Web feed/search/notification integration with pages (cross-cutting)
  - Validity checks on inputs:
    - [N/A] beyond items listed above.
  - Exact sequence of operations:
    - Confirm that the term “page” is consistently applied across assignments, wikis, forum posts, announcements for the purposes of uploads, feeds, search, and notifications as specified.
  - Responses to abnormal situations:
    - [N/A].
  - Effect of parameters:
    - Per-page toggles (multiple file upload, feeds, notifications) correctly and independently affect behavior for that page.
  - Relationship of outputs to inputs:
    - Actions on a page (create/edit/post) result in the corresponding outputs (files attached, feed items emitted, search index updated, notifications sent) when the associated toggles are enabled, and do not when disabled.

## 4.2 Performance requirements
This section defines the verification approaches and methods to qualify the software against the performance requirements. The items are organized in parallel with the performance information items in Requirements section 3.2.

- Static numerical requirements
  - Number of terminals to be supported
    - Verification method: [N/A]
    - Acceptance criteria: [N/A]
  - Number of simultaneous users to be supported
    - Requirement: The system should support at least 1,000 concurrent users.
    - Verification method:
      - Conduct production-like load testing with 1,000 virtual users authenticated concurrently.
      - Execute a representative mix of core actions (e.g., logging in, navigating course pages, viewing assignments, posting to forums, performing searches, viewing gradebook) at steady state.
      - Test window to include sustained load representative of peak academic periods (e.g., midterms/finals).
      - Instrument and monitor application, database, and web tiers for resource utilization and errors.
    - Test environment:
      - Production-representative infrastructure (server tiers, database size seeded with typical course data).
      - Network conditions comparable to campus access patterns.
    - Measurements collected:
      - Successful request rate, application error rate, resource utilization (CPU, memory, I/O), and session stability.
      - Response-time distributions for executed actions.
    - Acceptance criteria:
      - System sustains 1,000 concurrent authenticated users performing core actions without service interruption or systemic failures.
      - Application-level error rate remains within acceptable bounds. Specific thresholds: [N/A]
      - Response-time thresholds: [N/A]
  - Amount and type of information to be handled
    - Verification method: [N/A]
    - Acceptance criteria: [N/A]

- Dynamic numerical requirements (throughput, latency, and processing under normal and peak workloads)
  - Normal workload transaction rates and response times
    - Verification method: [N/A]
    - Acceptance criteria: [N/A]
  - Peak workload transaction rates and response times
    - Verification method: [N/A]
    - Acceptance criteria: [N/A]
  - Data volumes processed within time periods (e.g., batch or background tasks)
    - Verification method: [N/A]
    - Acceptance criteria: [N/A]

## 4.3 Usability requirements
This section defines how the usability requirements will be verified. Verification activities are organized in parallel to the usability-related requirements (simple, responsive interface with a single administrative interface and global theming; on-page user help; comprehensive, searchable administrative documentation). Where quantitative targets for effectiveness, efficiency, satisfaction, accessibility, or avoidance of harm are required but not specified in the SRS, they are indicated as [N/A].

- Simple, responsive interface with a single, central administrative interface
  - Verification methods:
    - Expert heuristic evaluation focused on simplicity, consistency, minimalist design, and match between system and real world.
    - Role-based cognitive walkthroughs (student, professor, system administrator) for key tasks: access the single administrative interface; configure system-wide settings; edit a page without navigating multiple disparate admin entry points.
    - UI inspection to confirm there is one administrative entry point for configuration (as opposed to per-page editing links only).
  - Evidence/artifacts:
    - Heuristic evaluation report with issues and severities.
    - Walkthrough task scripts, observations, and pass/fail outcomes.
    - Interface inventory/screenshots showing the single administrative interface and its scope.
  - Acceptance checks:
    - A single administrative interface exists and provides access to system-wide configuration.
    - Editing and configuration tasks can be initiated from the central interface without requiring multiple, disjoint admin UIs.
    - Participants complete the defined walkthrough tasks without external assistance; quantitative thresholds for task time, error rate, or satisfaction: [N/A].
    - Perceived responsiveness will be assessed during testing; specific response-time thresholds are verified under performance verification, not usability: [N/A].

- Ability to easily change themes and layout settings across the entire courseware system
  - Verification methods:
    - Task-based usability test with administrative users to apply a theme/layout change and observe its propagation across representative pages and modules.
    - UI inspection to confirm theme/layout controls are centralized within the administrative interface.
  - Evidence/artifacts:
    - Test logs and before/after screenshots across a sample of courses, roles, and page types.
    - Configuration pathway documentation showing where theme/layout changes are performed.
  - Acceptance checks:
    - Theme and layout changes made in the central interface propagate across the entire system.
    - Steps/clicks required to locate and execute the change: [N/A] (no target specified).

- On-page user documentation and help availability and relevance
  - Verification methods:
    - UI inspection across representative pages (assignments, forums, wikis, gradebook, admin pages) and roles to confirm presence of contextual help on each page.
    - Content review to confirm help explains page-relevant tasks and includes notification of recent modifications on the main page.
  - Evidence/artifacts:
    - Page inventory noting help presence/absence and linkage.
    - Content checklist mapping pages to corresponding help topics.
  - Acceptance checks:
    - Contextual help is available on each page.
    - The main page presents notices of unexpected/recent modifications.
    - Supplemental phone and on-site support contact information appears in help content; service-level targets: [N/A].

- Comprehensive, searchable documentation for system administrators
  - Verification methods:
    - Documentation audit for coverage of regular maintenance procedures, common errors, and advanced troubleshooting links.
    - Documentation search tests to confirm relevance-ranked results for common admin queries.
  - Evidence/artifacts:
    - Coverage matrix mapping required maintenance procedures and error scenarios to documentation; definitive list of required procedures/errors: [N/A].
    - Search query set with observed result ordering and relevance notes.
  - Acceptance checks:
    - All required maintenance procedures, common errors, and troubleshooting links are documented; completeness target: [N/A].
    - Search returns relevant content for sampled admin tasks and error messages, with results ordered by relevance.

- Quantitative usability and quality-in-use objectives (effectiveness, efficiency, satisfaction, avoidance of harm, accessibility)
  - Verification methods:
    - Summative usability testing (think-aloud) with representative users; administer standardized questionnaires (e.g., SUS) and collect task metrics (completion, errors, time).
    - Accessibility review against applicable standards; specific standard and conformance level: [N/A].
  - Evidence/artifacts:
    - Test plan, participant profiles, task lists, raw data, and summary findings.
    - Accessibility review checklist and findings.
  - Acceptance checks:
    - Target thresholds for task completion rate, time-on-task, error rate, SUS score, and avoidance of harm criteria: [N/A] (not specified in the SRS).

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
This section defines the verification approaches for the design constraints identified in the requirements.

- Use of Moodle APIs and no unsupported core modifications
  - Methods: architecture and code reviews; plugin packaging inspection; use of Moodle plugin validator tools; upgrade regression tests against the target Moodle version(s).
  - Acceptance criteria: all changes delivered as Moodle-compliant plugins/extensions; no direct edits to Moodle core; clean install/upgrade paths succeed without manual core patching.

- Self-hosted, freely available collaboration tools (wiki/blog) integrated with shared authentication/notifications
  - Methods: license compliance scan of included components; deployment review confirming on-premise/self-hosted operation; SSO tests using Moodle authentication; notification flow tests; offline test (internet disabled) to confirm no reliance on external hosted services.
  - Acceptance criteria: OSS licenses identified and compatible; tools operate without external service dependencies; single sign-on and notifications function through Moodle.

- Cross-platform audio playback and speech-optimized storage with MP3 download
  - Methods: cross-platform compatibility testing across supported OS/browser matrix; file format inspection; conversion tests for MP3 downloads; usability demonstration within Moodle using the embedded player.
  - Acceptance criteria: record/playback works on all supported OS/browsers; stored format is validated as speech-optimized; downloaded files are MP3 and play in common players; no proprietary runtime requirements.

- Centralized administrative interface for system-wide configuration
  - Methods: UI inspection and task-based walkthroughs; administrator usability review; traceability from configuration items to a single admin area.
  - Acceptance criteria: all global UI/theme and feature settings are accessible from one administrative interface; no per-page-only configuration required for global settings.

- Maintainability without substantial modification (mostly self-sustaining)
  - Methods: maintainability review (plugin isolation, configuration over customization); static code analysis; change impact analysis on Moodle upgrades; operations runbook review.
  - Acceptance criteria: routine maintenance tasks require configuration rather than code changes; custom code is isolated to plugins; successful verification of upgrade to a newer Moodle minor release without refactoring.

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

## 4.7 Software system attributes
This section defines the verification approaches and methods to qualify the software against the software system attributes identified in the requirements. Methods include inspection, analysis, demonstration, and test, aligned to the corresponding requirements.

### Reliability
- Backup scheduling configurability (Req: 4.2.1)
  - Method: Inspection and configuration test.
  - Approach: Configure backup to run on a nightly schedule; verify the configuration is persisted and effective by reviewing scheduler settings and successful backup job logs for a representative period.
  - Evidence: Administrative configuration screenshots/records, scheduler configuration export, backup job logs with timestamps.

- Off-site weekly backup option (Req: 4.2.1)
  - Method: Demonstration.
  - Approach: Configure an off-site backup target; execute a weekly backup; verify the existence and integrity of the off-site backup artifact at the target.
  - Evidence: Off-site target configuration record, transfer logs, checksum/integrity report of the off-site artifact.

- Backup restore within six hours (Req: 4.2.1)
  - Method: Timed restoration test.
  - Approach: Restore the most recent full backup into a representative environment; measure elapsed time from initiation of restoration to system availability.
  - Acceptance: Restoration completes within six hours.
  - Evidence: Test plan and procedure, timing log, post-restore validation checklist confirming system operability.

### Availability
- 24x7 availability with 99% uptime (Req: 4.2.2)
  - Method: Operational monitoring and analysis.
  - Approach: Deploy availability monitoring (internal and/or external probes); measure uptime over an agreed monitoring period, including maintenance windows; calculate availability percentage.
  - Acceptance: Measured availability ≥ 99% over the monitoring period.
  - Evidence: Monitoring configuration, raw uptime/downtime records, availability calculation, incident reports for any outages.

### Security
- [N/A]

### Maintainability
- Maintainable without substantial modification (Req: 4.4.1)
  - Method: Design/implementation inspection and scenario-based demonstration.
  - Approach: Identify routine maintenance tasks (e.g., configuring features, managing courses and users, adjusting schedules). Demonstrate completion of these tasks via configuration and administrative interfaces without source code changes. Review deployment and configuration artifacts to confirm change isolation and absence of code modifications for routine operations.
  - Evidence: Maintenance task checklist with outcomes, admin interface operation records, configuration change logs, version control history showing no code changes required for demonstrated tasks.

### Portability
- [N/A]

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
- Adoption of Moodle as the baseline courseware platform, with enhancements implemented via Moodle’s existing APIs; target Moodle version to be determined. Any change in platform or API availability will affect the requirements.
- Moodle remains a viable option to replace Blackboard at the University of Puget Sound; a change in platform selection would necessitate reevaluating the requirements.
- Stakeholder needs captured in “Moodle Requirements Brainstorming.pdf” accurately reflect user expectations and remain stable; substantial changes in stakeholder input will drive requirement changes.
- Delivery scope depends on project timeframe and budget, with Priority 1 and 2 requirements targeted and only feasible Priority 3 items included; changes in resources will alter the delivery set.
- Institutional infrastructure can provide and support email and SMS delivery for notifications; lack of an SMS gateway or email service would change notification requirements.
- Sufficient storage capacity and quota management are available to support per-user voice-clip portfolios and partitioning of space by professors/administrators.
- Availability of audio encoding/decoding capabilities: storage in a speech-optimized format, on-demand conversion to MP3 for downloads, and a cross-platform in-browser audio player; absent or incompatible codecs/players would affect audio requirements.
- Server hardware and network capacity can meet performance and availability expectations (e.g., ~1,000 concurrent users and 24x7 access with 99% uptime target); insufficient capacity would require revising performance-related requirements.
- Backup and restore infrastructure and processes exist to meet stated needs (e.g., nightly backups, optional weekly off-site backups, and restoration within six hours); limitations here would affect reliability requirements.
- Limited Office of Information Services staffing persists, motivating maintainability and self-sustaining operation; staffing changes may relax or tighten maintainability requirements.
- Availability of freely available wiki and blog engines that can be integrated and share authentication and notifications with Moodle; if suitable components are unavailable or incompatible, integration requirements would change.
- Online user documentation can be hosted and supplemented by phone and on-site support from the Office of Information Services; changes in support model would affect documentation and help requirements.
- Optional dependency: if course search includes web search integration, availability and terms of use of an external search engine (e.g., Google) apply; lack or change of such services would impact search-related requirements.
- Use of RSS/Atom web feed standards for exposing updates is assumed to be acceptable to stakeholders and consuming tools; changes in preferred syndication standards could impact feed-related requirements.

## 5.2 Acronyms and abbreviations
- API: Application Programming Interface (plural: APIs)
- RSS: Really Simple Syndication (e.g., RSS 2.0 web feed format)
- SMS: Short Message Service (text messaging)
- MP3: MPEG-1 Audio Layer III audio format
- MPEG: Moving Picture Experts Group (family of multimedia standards; used here for audio)
- PDF: Portable Document Format
- IT: Information Technology
- FTE: Full-Time Equivalent
- 3rd party: Third-party (external) services
