# 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 for a courseware system. The University’s enhancements to the system 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. The goal is to determine what any courseware system would need to qualify as a viable solution for the University.

## 1.3 Product overview
### 1.3.1 Product perspective
The University of Puget Sound is currently seeking a new courseware system and is investigating Moodle as an option to replace the existing Blackboard system. The requirements are based on the assumption that Moodle will be adopted and that any enhancements to the system will utilize the existing APIs made available by Moodle.

#### System interfaces
[N/A]

#### User interfaces
The system should provide a central, easy-to-use interface that will allow administrators to configure the user interface and features in a way that reduces page clutter.

#### Hardware interfaces
[N/A]

#### Software interfaces
Any enhancements to the system will utilize the existing APIs made available by Moodle.

#### Communications interfaces
[N/A]

#### Memory constraints
[N/A]

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

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

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

### 1.3.2 Product functions
The courseware system is meant to help facilitate electronic classroom management and provide for electronic grading, assignment submission, discussion, and other learning tools. Moodle is a courseware system that manages courses, assignments, wiki pages, forums, etc. The goal is to refine parts of Moodle to provide functionality that improves the overall learning experience.

A summary of major functions includes:
*   Multiple file transfers for assignments and other pages.
*   Audio recording, storage, and portfolio management for students.
*   Web feed (e.g., RSS 2.0) generation for course content updates.
*   A comprehensive search utility to navigate course content.
*   An online gradebook with history tracking.
*   Integration of social networking applications like wikis and blogs.
*   Email and SMS notifications for course events.

### 1.3.3 User characteristics
*   Students: The primary consumers of a courseware system. They are accessing information posted by professors, uploading assignments and project files, and discussing concepts.
*   Professors: The primary content administrators of a courseware system. They are uploading files, links, and multimedia, and grading assignments in addition to creating new places for students to discuss and collaborate.
*   System Administrators: Primarily responsible for maintaining the courseware system. They contribute minimally to the courses themselves, but spend more time modifying the system’s configuration and making appropriate updates.

### 1.3.4 Limitations
Any enhancements to the system must utilize the existing APIs made available by Moodle.

## 1.4 Definitions
*   Actor: Synonymous with user and is used to describe users who are performing actions in use cases.
*   Course Administrator: An actor who is acting as a professor or system administrator and who has 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
The priorities defined below reflect the requirements of the development team. Requirements have been categorized according to the following definitions:
*   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 the Priority 1 (Core) and Priority 2 set of requirements, along with such Priority 3 requirements as can be developed within the project timeframe and budget constraints.

## 3.1 Functions
### 3.1.1 Multiple File Transfer
The system must be able to capture and manage files where appropriate. One of the fundamental tasks of the system is to allow actors to upload and manage files on certain pages of the system. An actor in the role of course administrator should be able to optionally upload multiple files where he or she finds that such as feature would be useful. For this requirement, page refers to any distinct upload point (e.g., an assignment, a wiki page, a forum post, etc.). Priority: 2.

*   The system must allow for multiple file upload to be configured on a per-page basis. Actors in the capacity of course administrator or professor should be able to enable multiple file uploads on a page of his or her choosing. Such a construct should be offered to the actor during a page’s creation and editing stages.

### 3.1.2 Audio Recording
The system must be able to capture and organize voice clips that can be used where appropriate. One of the shortcomings of the current courseware system is that the foreign language department is unable to capture and track voice clips—recorded by students—for oral homework over the course of a student’s education. Priority: 2.

*   The system must allow actors to organize their voice clips into a portfolio. Equal and finite drive space needs to be allotted to each actor in the role of professor or administrator for storing voice clips. The actor should have the option to have the voice clip be archived after a preview has taken place. The actor should be able to optionally attach one of his or her archived items to any page where uploads are permitted.
*   The system must allow actors to download their voice clips in a flexible format. Voice clips should be optionally downloadable in a format such as MPEG Audio (mp3) format.
*   The system must store audio clips in a format conducive to speech. Voice clips should be stored in a format optimized for speech. Recordings should only be converted to MPEG Audio (mp3) format when they are being downloaded.
*   The system must allow actors to delete recorded clips. An actor should be able to examine his or her portfolio to select and delete clips if he or she chooses to.

### 3.1.3 Web Feeds
The system must be able to display web feeds, such as RSS 2.0 feeds, for all pages of the course management system where elements such as forum posts, assignment postings, announcements, and wiki alterations are added. Actors in the role of course administrators should have the ability to determine which of these components have feeds and to whom these feeds should pertain. For this requirement, page refers to any distinct block (e.g., assignments, wikis, forum threads, etc.). Priority: 1.

*   The system must allow web feeds to be turned on or off on a per-page basis. During the creation and editing of a page, the course administrator should be able to toggle web feed availability.

### 3.1.4 Search
The system must be able to use search functionality as a way to navigate Moodle pages instead of using hierarchical links. For this requirement, page refers to any distinct page, such as an assignment, a wiki page, or a forum post. Priority: 2.

*   An actor must be able to search through pages in a course. A single page should be dedicated specifically to the task of searching the course management system. This page should allow an actor to filter out certain results and search specific sections of the course management system. Results should appear in categories based on relevance.
*   The system must display a search box on every page after an actor has logged in. If the actor is hierarchically outside of a particular course, each of his or her courses should be searched and results should be grouped by course. If the actor is hierarchically inside of a course, that course should be searched with an option to search all courses.

### 3.1.5 Gradebook
The system must allow actors in the capacity of course administrator to post grades associated with assignments for a particular actor in the capacity of student. Priority: 1.

*   A course administrator must be able to grade an assignment. Course administrators should be able to post grades for an assignment based on the ratio of points earned to points possible. The course administrator should also be able to attach feedback in the form of text or an attachment. Time stamps should be attached to the last time the grade was modified.
*   The system should display grade information to the appropriate actor. The system should display grade information such as the grade for each assignment, averages, and overall grade to the actor to whom the grades belong.
*   The system should maintain a grade history. The system should maintain a history of grades for a particular assignment if the course administrator changes them.

### 3.1.6 Social Networking Applications
The social, collaborative components of Moodle should be integrated to provide the best functionality possible for all actors without having to use 3rd party services. Priority: 3.

*   The system must provide a wiki where actors can collaboratively create networks of documents. A freely available wiki should provide a simple markup language that actors can use to style their input, as well as link to other pages in the wiki.
*   The system must provide a blog engine. A freely available blog engine should provide all modern blog functionality, such as tagging, drafting, and comments. These blogs should share authentication and notification with Moodle.

### 3.1.7 Notifications
The system should allow actors to receive SMS or email notifications of changes to Moodle pages (such as assignments or announcements). Priority: 3.

*   The system must provide both e-mail and SMS notifications for pages. For this requirement, page refers to any distinct page (e.g., an assignment, a wiki page, a forum post, etc.). When a page is created, the actor in the role of course administrator should be able to toggle whether notifications are turned on. If notifications are turned off, actors in the capacity of student should be able to subscribe to notifications. Students should be able to select in their preferences whether notifications are sent to their mobile telephone (via SMS) or e-mail account. They should also be able to manage their notification subscriptions.

## 3.2 Performance requirements
The system should support at least 1000 concurrent users. It is important that a substantial number of actors be able to access the system at the same time, since a courseware system is important to the courses that employ it. The times when the system will be under the most stress are likely during midterm and finals weeks. Priority: 1.

## 3.3 Usability requirements
As far as possible, the system should provide a simple, responsive interface. Although any courseware solution may be composed of diverse systems, applications, and processes, the underlying architecture should be transparent to the administrators. The system should be configurable from a single source at a central administrative position, and should provide a central, easy-to-use interface that will allow administrators to configure the user interface and features in a way that reduces page clutter. A system will be considered to meet this requirement if it has a single administrative interface rather than individual links for editing each page. Priority: 3.

## 3.5 Logical database requirements
*   The system must store and organize voice clips for each user in a portfolio.
*   The system must maintain a history of grades for a particular assignment if the course administrator changes them, including timestamps.
*   The system must be able to store course and user data for backup and restoration purposes.

## 3.6 Design constraints
Any enhancements to the system must utilize the existing APIs made available by Moodle.

## 3.7 Software system attributes
### 3.7.1 Reliability
The system must be backed up on a configurable schedule. The system should be backed up with a frequency that ensures system and course data is protected. Since assignments will be submitted via the system, it should be backed up on a nightly basis, with options for weekly, off-site backup when necessary. The system must have the ability and capacity to restore back-up data within six hours so that the system is never offline for an inordinate period of time. Priority: 2.

### 3.7.2 Availability
The system should be available 24 hours a day, 7 days a week. This statement provides a general sense of system availability. It should not exclude maintenance windows, or scheduled downtime. 99% up-time should be considered sufficient to meet this requirement. Priority: 1.

### 3.7.3 Security
No other actor should be able to view another’s grades except an actor in the role of course administrator for the course to which the grades belong.

### 3.7.4 Maintainability
The system must be maintainable without substantial modification. Due to limited staff in the Office of Information Services, it is important that the system be mostly self-sustaining. This will reduce the number of FTE hours spent maintaining the system and simplify maintenance tasks. Priority: 3.

### 3.7.5 Portability
[N/A]

## 3.8 Supporting information
### 3.8.1 On-line User Documentation and Help System Requirements
*   Relevant, online documentation for users should be available on each page. Users must have easy access to help while interacting 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. Priority: 3.
*   System administrators must have access to comprehensive, searchable documentation. A comprehensive database of maintenance tasks and help files should be compiled to make the courseware system easier to maintain from an IT staff point-of-view. 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. Priority: 3.

# 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
The University of Puget Sound is currently seeking a new courseware system and is investigating Moodle as an option. We are making an assumption that Moodle is of interest to the University as a viable choice to replace Blackboard. The goal of this document, and our work, however, is to determine what any courseware system would need to qualify as a viable solution for the University. We also intend to apply this document to Moodle to determine whether we can implement some of the features that Moodle lacks and our stakeholders find to be important. By no means is the University necessarily going to choose Moodle as a courseware system, but we want to use the platform to have a new learning experience and contribute back to a real product nonetheless.

## 5.2 Acronyms and abbreviations
*   API: Application Programming Interface
*   FTE: Full-Time Equivalent
*   RSS: Really Simple Syndication
*   SMS: Short Message Service