# 1 Introduction

## 1.1 Purpose
The purpose of this document is to capture, in natural language and at a functional level, the description and requirements of a new courseware system for the University of Puget Sound’s educational needs. This is a functional description of those features required to address current instructional and educational requirements. Each requirement is accompanied by a short discussion, designed to add the background and framework necessary to explain the functionality. It also describes nonfunctional requirements and other factors necessary to provide a complete and comprehensive description of the requirements for the software.

## 1.2 Scope
This document deals with the immediate requirements for the development of core functionality currently unavailable in Moodle, the existing courseware system candidate (version TODO: Version of Moodle). The University’s enhancements to Moodle will embody several small redesigns for consistency with other university practices. Additionally, the enhancements will take the opportunity to redesign the user interface to reflect a more natural flow of data. These requirements are based on the assumptions that Moodle will be adopted at the University of Puget Sound and that any enhancements to the system will utilize the existing APIs made available by Moodle.

## 1.3 Product overview

### 1.3.1 Product perspective
The software product is an enhancement to Moodle, an existing courseware system. It is intended to replace or augment the functionality currently provided by Blackboard at the University of Puget Sound. The enhancements will integrate with Moodle's existing APIs.

#### System interfaces
[N/A]

#### User interfaces
The system will feature a redesigned user interface to reflect a more natural flow of data. It should provide a simple, responsive interface, configurable from a single central administrative position. This interface must allow administrators to easily change themes and other settings affecting page layout. A search box will be displayed on every page after an actor has logged in.

#### Hardware interfaces
[N/A]

#### Software interfaces
The system will interface with Moodle, utilizing its existing APIs.
It will support:
*   MPEG Audio (mp3) format for voice clips.
*   RSS 2.0 feeds for web feed functionality.
*   Integration with freely available wiki software.
*   Integration with a freely available blog engine.
*   Potential integration with a standard search engine such as Google for world wide web searches.

#### Communications interfaces
The system will provide e-mail and SMS notifications.

#### Memory constraints
[N/A]

#### Operations
The system should be backed up on a configurable schedule, with nightly backups for assignment data and options for weekly, off-site backup. The system must have the ability and capacity to restore backup data within six hours.

#### Site adaptation requirements
[N/A]

#### Interfaces with services
[N/A]

### 1.3.2 Product functions
The courseware system is a piece of software meant to help facilitate electronic classroom management and provide for electronic grading, assignment submission, discussion, and other learning tools. The goal is to refine parts of Moodle to provide functionality that improves the overall learning experience of students at the University and helps professors to make students aware of new ways of presenting material. The system will manage courses, assignments, wiki pages, forums, etc.

### 1.3.3 User characteristics
*   **Students:** Primary consumers of the courseware system, accessing information posted by professors, uploading assignments and project files, and discussing concepts.
*   **Professors (Course Administrators):** Primary content administrators, uploading files, links, multimedia, grading assignments, and creating new places for discussion and collaboration. They also manage courses and course pages.
*   **System Administrators:** Primarily responsible for maintaining the courseware system, modifying system configuration, and making updates. They contribute minimally to courses.

### 1.3.4 Limitations
[N/A]

## 1.4 Definitions
*   **Actor:** Synonymous with user, describes users performing actions in use cases.
*   **Course Administrator:** An actor acting as a professor or system administrator with the ability to manage courses and course pages.
*   **Courseware System:** A piece of software meant to help facilitate electronic classroom management and provide for electronic grading, assignment submission, discussion, and other learning tools.
*   **System:** Refers to 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.

# 2 References
*   **Moodle Requirements Brainstorming.pdf:** This document was generated as a foundation for this document and contains the results of stakeholder interviews.

# 3 Requirements

## 3.1 Functions
The system must provide the following functional capabilities:

*   **Multiple File Transfer:**
    *   The system must be able to capture and manage files, allowing actors to upload and manage files on assignment submission pages, forum pages, wiki pages, and announcement pages.
    *   Course administrators should be able to optionally upload multiple files, such as on a devoted project page.
    *   The system must allow for multiple file upload to be configured on a per-page basis by course administrators or professors during a page’s creation and editing stages.

*   **Audio Recording:**
    *   The system must be able to capture and organize voice clips.
    *   The system must allow actors to organize their voice clips into a portfolio.
    *   Equal and finite drive space must be allotted to each professor or administrator for storing student voice clips, with the ability for professors/administrators to partition this space for students.
    *   Actors should have the option to preview voice clips before archiving or have them automatically archived upon submission.
    *   The system must allow actors to download their voice clips in a flexible format, such as MPEG Audio (mp3).
    *   The system must store audio clips in a format optimized for speech, converting to MP3 only upon download. A separate cross-platform viewer for listening to clips in Moodle should be provided.
    *   The system must allow actors to delete recorded clips from their portfolio.

*   **Web Feeds:**
    *   The system must be able to display web feeds (e.g., RSS 2.0) for all pages where elements like forum posts, assignment postings, announcements, and wiki alterations are added.
    *   Course administrators should be able to determine which components have feeds and to whom they pertain.
    *   The system must allow web feeds to be turned on or off on a per-page basis by course administrators during page creation and editing.

*   **Search:**
    *   The system must provide search functionality to navigate Moodle pages.
    *   An actor must be able to search through pages in a course.
    *   The search feature should be present as a search box and button on the top or bottom of every page.
    *   A dedicated search page should allow actors to filter results (e.g., forum posts, grades) and search specific sections.
    *   Search results should appear in categories (e.g., Assignments, Wiki Pages, Forum Posts) based on relevance.
    *   The search page might allow searching the world wide web using a standard search engine.
    *   The system must display a search box on every page after an actor has logged in.
    *   If outside a course, all courses should be searched with results grouped by course. If inside a course, that course should be searched with an option to search all courses.

*   **Gradebook:**
    *   The system must allow course administrators to post grades associated with assignments for students.
    *   A course administrator must be able to grade an assignment based on points earned to points possible.
    *   Course administrators should be able to attach feedback (text or attachment) to grades.
    *   Time stamps should be attached to the last grade modification.
    *   The system should display grade information (individual assignment grades, averages, overall grade) only to the student and the course administrator for that course.
    *   The system should maintain a history of grades for a particular assignment if changed by the course administrator, including timestamps for each change.

*   **Social Networking Applications:**
    *   The system must provide a wiki where actors can collaboratively create networks of documents, offering a simple markup language for styling input and linking to other pages.
    *   The system must provide a blog engine with modern blog functionality (tagging, drafting, comments), sharing authentication and notification with Moodle.

*   **Notifications:**
    *   The system must provide both e-mail and SMS notifications for changes to pages (e.g., assignments, wiki pages, forum posts, announcements).
    *   When a page is created, the course administrator should be able to toggle notifications (defaulting to on for announcements).
    *   Students should be able to subscribe to notifications if they are turned off by the administrator.
    *   Students should be able to select notification delivery preferences (SMS or e-mail) and manage their subscriptions.

## 3.2 Performance requirements
The system should support at least 1000 concurrent users, especially during peak times such as midterm and finals weeks.

## 3.3 Usability requirements
*   As far as possible, the system should provide a simple, responsive interface.
*   The system should be configurable from a single source at a central administrative position, providing a central, easy-to-use interface that reduces page clutter.
*   The administrative interface must allow administrators to easily change themes and other settings affecting page layout across the entire courseware system.
*   Relevant, online documentation for users should be available on each page to minimize Help Desk calls.
*   Modifications should be reported via the main page to inform actors of unexpected changes.

## 3.5 Logical database requirements
*   The system should maintain a history of grades for a particular assignment if the course administrator changes them.
*   Voice clips should be stored in a portfolio for each actor.

## 3.6 Design constraints
*   The system enhancements must utilize the existing APIs made available by Moodle.
*   Voice clips should be stored in a format optimized for speech.
*   Voice clips should be optionally downloadable in MPEG Audio (mp3) format.
*   Web feeds should support RSS 2.0.
*   Social networking applications (wiki, blog engine) should be freely available solutions integrated into Moodle.

## 3.7 Software system attributes
*   **Reliability:** The system must be backed up on a configurable schedule, with nightly backups for assignment data and options for weekly, off-site backup.
*   **Availability:** The system should be available 24 hours a day, 7 days a week, with 99% uptime considered sufficient, allowing for maintenance windows or scheduled downtime. The system must have the ability and capacity to restore backup data within six hours.
*   **Security:** The system should display grade information only to the appropriate actor (student or course administrator for that course).
*   **Maintainability:** The system must be maintainable without substantial modification, aiming to be mostly self-sustaining due to limited staff. System administrators must have access to comprehensive, searchable documentation covering maintenance tasks, common errors, and advanced troubleshooting.
*   **Portability:** [N/A]

## 3.8 Supporting information
*   The priorities for requirements are categorized as:
    *   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: Just barely outside the parameters of Priority 2; considered very important to supplement critical functionality.
    *   Priority 4: Outside the parameters of Priority 2; considered valuable as a supplement to other functionality, but not critical.
*   The initial production release will deliver Priority 1 (Core) and Priority 2 requirements, along with Priority 3 requirements as can be developed within project timeframe and budget constraints.
*   Stakeholder feedback (summarized in Moodle Requirements Brainstorming.pdf) was gathered to determine requirements for a replacement courseware system and analyze features in other available solutions.

# 4 Verification

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

# 5 Appendices

## 5.1 Assumptions and dependencies
*   Moodle will be adopted at the University of Puget Sound.
*   Any enhancements to the system will utilize the existing APIs made available by Moodle.
*   Moodle is of interest to the University as a viable choice to replace Blackboard.

## 5.2 Acronyms and abbreviations
*   **API:** Application Programming Interface
*   **FTE:** Full-Time Equivalent
*   **MP3:** MPEG Audio Layer III
*   **RSS:** Really Simple Syndication (or Rich Site Summary)
*   **SMS:** Short Message Service
*   **SRS:** Software Requirements Specification