SOFTWARE REQUIREMENTS

SPECIFICATION
FEBRUARY 2006
COVCELL Software Requirements Specification Version 1.0

SOFTWARE REQUIREMENTS
SPECIFICATION

Contract Number 225020-CP-1-2005-1-IS-MINERVA-MPP

Version Date Author(s) Comment

0.1 13.02.2006 H. Kuper Begin drafting SRS.
0.2 23.02.2006 H. Kuper Further development of SRS, incorporating initial
feedback from A. Vollmer and S. Sigurðarson.
Added Roadmap.
0.3 27.02.2006 H. Kuper Incorporated feedback from M. Whelpton.
1.0 06.03.2006 H. Kuper First version of SRS complete.
COVCELL Software Requirements Specification Version 1.0

Table of Contents
1 Introduction.....................................................................................................................3
1.1 Purpose.....................................................................................................................3
1.2 Scope........................................................................................................................3
1.3 Definitions, Acronyms and Abbreviations.............................................................3
1.4 References................................................................................................................4
1.5 Overview...................................................................................................................5
2 Overall Description.........................................................................................................5
2.1 Product Perspective................................................................................................5
2.2 Product Functions...................................................................................................6
2.3. User Characteristics...............................................................................................7
2.4 Constraints...............................................................................................................7
2.5 Assumptions and Dependencies............................................................................7
2.6 Apportioning of Requirements...............................................................................8
3 Specific Requirements....................................................................................................8
3.1 External Interface Requirements............................................................................8
3.1.1 User Interfaces..................................................................................................8
3.1.2 Hardware Interfaces.........................................................................................8
3.1.3 Software Interfaces...........................................................................................8
3.1.4 Communication Interfaces...............................................................................8
3.2 System Features......................................................................................................8
3.2.1 System Features of Phase I.............................................................................8
3.2.1.1 Dynamic Location-Specific Contact List and Chat.................................8
3.2.1.2 Whiteboard.................................................................................................9
3.2.1.3 One-on-One Audio and Video Chat........................................................10
3.2.1.4 “Goto-URL” Bar within Moodle Frame..................................................10
3.2.1.5 Activity View.............................................................................................11
3.2.2 System Features of Phase II..........................................................................11
3.2.2.1 Core Profile..............................................................................................11
3.2.2.2 Personal Glossary and Quizzer..............................................................11
3.2.2.3 Deadline Countdown...............................................................................11
3.2.2.4 Course Standing......................................................................................12
3.2.2.5 File Transfer.............................................................................................12
3.2.2.6 Upload of Corrected Documents............................................................12
3.2.3 System Features of Phase III.........................................................................13
3.2.3.1 Audio/Video Conferencing......................................................................13
3.2.3.2 One-on-One Video and Audio Chat........................................................13
3.2.3.3 Recording of Audio Feed for Evaluation...............................................13
4 Software Development Roadmap................................................................................13

2/14
COVCELL Software Requirements Specification Version 1.0

1 Introduction
1.1 Purpose
This document provides concrete details concerning the software goals as identified by
Work Packages 1, 2 and 3 of the COVCELL Project. For more information, see the
COVCELL Web site (http://covcell.org).
The intended audience of the SRS is primarily the partners of the COVCELL Project, but it
also addresses all other parties that might have an interest in the software under
development (e.g. the wider Moodle Open Source community).

1.2 Scope
The overall objective of the COVCELL Project is to address the need, established in
current work on online language learning, for a virtual environment in which language
learners can meet and interact in the process of language study – a 'virtual campus' for
language learning. This virtual campus will be achieved by developing software modules
for the Open Source CMS Moodle. These modules will focus on supporting the teaching
of languages, but will offer functionality that may be applicable to a broader group of
users, beyond the language teaching community.
For more details on the planned modules, see § 3.2.

1.3 Definitions, Acronyms and Abbreviations

Term Definition
administrator Administrator of the Moodle CMS, does not necessarily execute a
pedagogical rôle (cf. teacher)
AJAX Asynchronous JavaScript Technology and XML
A technology for adding functionality to Web pages.
block An element of a Moodle page. Can be an activity, a resource, a
calendar, etc.
client A software application that utilises the services provided by a server.
CMS Course Management System
A synonym for LMS. A course management system is a computer
program that facilitates computerised learning or e-learning, especially
by helping teachers and learners with course administration.
COVCELL Cohort-Oriented Virtual Campus for Effective Language Learning
See http://covcell.org/
DBMS Database Management System
EU European Union

3/14
COVCELL Software Requirements Specification Version 1.0

Term Definition
IEEE Institute of Electrical and Electronics Engineers
LMS Learning Management System
A synonym for CMS (as defined above).
Moodle Modular Object-Oriented Dynamic Learning Environment
open source A method and philosophy for software licensing and distribution
designed to encourage use and improvement of software written by
volunteers by ensuring that anyone can copy the source code and
modify it freely.
participant A neutral term that refers either to a teacher or student participating in
a Moodle course.
PHP PHP Hypertext Preprocessor
A scripting language for generating dynamic Web content.
server A server can either be a hardware device or a software application,
depending on the context. Confusion arises when one speaks of
several (software) servers running on a (hardware) server. The
distinction is in many cases irrelevant, however, as the term server
implies an entity that provides a service to a client. This client-server
relationship is of importance, not whether we are speaking of hardware
or software.
SMTP Simple Mail Transfer Protocol
Protocol used for the sending of electronic mail.
SRS Software Requirements Specification
This document.
student Member of a course
TBD To Be Determined
Refers to content that will be provided at a later date.
teacher Course administrator, executes the pedagogical rôle of instructor.
XML Extensible Markup Language
A general-purpose markup language for creating special-purpose
markup languages, capable of describing many different kinds of data.

For more definitions, see http://moodle.org/mod/glossary/view.php?id=851

1.4 References
These specifications are based on IEEE Std 830-1998: Recommended Practice for

4/14
COVCELL Software Requirements Specification Version 1.0

Software Requirements Specifications. This document is available from

http://standards.ieee.org/.
Furthermore, these specifications should be read in conjunction with the original
COVCELL application to the EU. This application is available upon request from
[email protected]

1.5 Overview
§ 2 summarises the software development planned under the auspices of COVCELL. § 3
treats the planned functionality in more detail, relating each step in the development
process to particular system features (i.e. Moodle modules). A roadmap for the software
development can be found in § 4.
The requirements are not ranked in terms of stability or necessity, as the software
modules cannot affect the stability of the overall system. All features included in this SRS
are deemed of importance to the stated goals of COVCELL.
The requirements specified in this document are subject to change, pending the ongoing
assessment of teachers' and students' feedback. The software development has been
divided into three phases to accommodate the required flexibility.

2 Overall Description
2.1 Product Perspective
The Moodle engine operates as the cornerstone of the CMS. Moodle is an acronym of
Modular Object-Oriented Dynamic Learning Environment1, and its modular nature is
expressed in the diagram below. Moodle acts as the conduit for the functionality
encapsulated in the various modules, maintaining data concerning teachers and students
(courses on offer, course enrolment, personal details, etc.) and structuring the interaction
with third party applications that allow participants to receive course-related emails and to
interact with Moodle by means of a Web browser.
The COVCELL Project will develop modules that support its goals as stated above, in
accordance with the guidelines as stated on the Moodle Web site (cf. § 2.4). At this stage
it is intended that Quality Assurance be provided by the maintainers of the Moodle Open
Source project.

1 See http://en.wikipedia.org/wiki/Moodle

5/14
COVCELL Software Requirements Specification Version 1.0

Illustration 1: Relationships between Moodle engine, modules and 3rd party

applications.

2.2 Product Functions

A summary of the envisaged functionality (as per the goals of COVCELL outlined in § 1.2)
is provided here. For more detail see § 3. The software development will be structured
according to an iterative, agile approach, thus providing the flexibility necessary to
incorporate as much feedback as possible from users.
The software development is divided into three phases:
Phase I: Collaborative Space (Basic Functionality)
• Dynamic Location-Specific Contact List and Chat
• Whiteboard
• One-on-One Audio and Video Chat
• “Goto-URL” Bar within Moodle Frame
• Activity View

6/14
COVCELL Software Requirements Specification Version 1.0

Phase II: Personal Presence and Personal Learning Support

• Core Profile
• Personal Glossary and Quizzer
• Deadline Countdown
• Course Standing
• File Transfer
• Upload of Corrected Documents
Phase III: Collaborative Space (Advanced Functionality)
• Audio/Video Conferencing
• One-on-One Video and Audio Chat
• Recording of Audio Feed for Evaluation

2.3. User Characteristics

The Moodle homepage describes the software package as
designed using sound pedagogical principles, to help educators create effective
online learning communities.2
Moodle is intended for use by educators – be they lecturers or teachers – and learners, be
they students or pupils. The software is designed to be as easy to use as possible for
both groups, and the software developed by COVCELL shall be no exception.
Users will need to be computer literate, but this is not an unrealistic assumption in a
European learning environment.

2.4 Constraints
Due to its nature as a transnational EU project, the software developed by COVCELL has
to take differing national privacy legislation into account. The software will be designed
such that administrators of Moodle will be able to control the granularity or indeed the very
nature of the personal data logged by Moodle.
All software developed by COVCELL will conform to the Moodle Coding Guidelines (cf.
http://docs.moodle.org/en/Coding) and to the Moodle Interface Guidelines (cf.
http://docs.moodle.org/en/Interface_guidelines).

2.5 Assumptions and Dependencies

The software development is divided into 3 phases, as detailed in § 3.2. It is assumed
that the Open Source Flash Server Red5 will be sufficiently mature for inclusion in the
COVCELL software development by phase III (cf. § 3.2.3).

2 Homepage of Moodle, http://moodle.org/, 16.02.2006 at 22:09.

7/14
COVCELL Software Requirements Specification Version 1.0

2.6 Apportioning of Requirements

The software requirements for phases II and III may be modified at a later stage, based on
feedback gleaned from ongoing teacher and student surveys.

3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
Moodle takes a modular approach to offering functionality within the platform. In other
words, it is a requirement for all modules developed by COVCELL that they conform to the
Moodle look-and-feel and integrate with the complete environment.

3.1.2 Hardware Interfaces

The Moodle engine structures all interaction between the software and the hardware (in
conjunction with third party products such as a Web server and DBMS – cf. § 2.1). As
such, the software modules under development do not need to account for hardware
interfaces.

3.1.3 Software Interfaces

The modules will utilise PHP 5 and rely on the standard elements of a Moodle installation,
namely a MySQL DBMS and an Apache Web server. All interaction with Moodle occurs
on the client-side by means of a Web browser.
AJAX will be utilised where appropriate.

3.1.4 Communication Interfaces

Interfaces with network protocols will be handled by the CMS and the Web server.

3.2 System Features

The software development is split into 3 phases. At the completion of each phase,
particular functionality will be available in Moodle as detailed below.

3.2.1 System Features of Phase I

3.2.1.1 Dynamic Location-Specific Contact List and Chat
Actor: course participant.
A dynamic contact list shall be generated, based on all participants engaged in a particular
activity at a specific location. The idea behind this feature is to exploit spontaneous
meetings between students as might be experienced on any physical university campus.
E.g. students viewing the Web page associated with a particular activity within a course
would be able to strike up an impromptu conversation with any other course participants

8/14
COVCELL Software Requirements Specification Version 1.0

who happen to be on the same page. This might allow them to leverage this chance
meeting and discuss the task as specified on that particular page.
Information gleaned from Moodle regarding participants and their location shall be passed
to the Open Source chat server jabberd which shall be used to generate the contact list
and enable conversation. The block with the list of location-specific contacts is thus a
Jabber client that shall use AJAX to update the contact list at regular intervals. The chat
window itself shall be a floating layer that the user can move around the page as
appropriate. The user shall also have the option to dock the chat window in a fixed
position in the frame.
Text communication between multiple participants at a particular location shall be
possible. In other words, on page X, participants A and B shall be able to text-chat with
each other, while participants L, M and N – also on page X – shall be able to have a
separate chat with each other.
Should a text message not be deliverable, because a participant who was in the chat has
gone offline or moved to another location, this message shall be stored and posted to this
particular participant the next time she is online and on the particular page which was the
catalyst for the original chat.
The participant shall have the option to be invisible, i.e. if desired their presence shall not
be displayed in the dynamic contact list.

3.2.1.2 Whiteboard
Actor: course participant.
A module shall be developed that integrates the whiteboard functionality provided by
Coccinella3 into a Moodle module. This will permit users to create and modify diagrams in
a collaborative environment.

3 See http://hem.fyristorg.com/matben/

9/14
COVCELL Software Requirements Specification Version 1.0

Illustration 2: Mock-up showing chat and whiteboard functionality.

3.2.1.3 One-on-One Audio and Video Chat

Actor: course participant.
Based on the dynamic contact list functionality described in § 3.2.1.1, the participants
shall be offered the option of launching a third-party audio and video chat application,
based on information provided within their profile.
In concrete terms, assuming two students have entered their Skype4 IDs in their
respective profiles, the icons identifying them in the dynamic contact list shall draw
attention to the fact that an audio/video chat using Skype is possible. By clicking on the
icon, Skype would be launched and a call initiated between the two parties. Whether the
chat would be just audio or audiovisual would depend on the Skype preferences of the
parties and whether Web cams were attached to both computers.

3.2.1.4 “Goto-URL” Bar within Moodle Frame

Actor: course participant.
Within Moodle a resource might be a link to an external Web page. Clicking on this
resource displays the external Web page within the Moodle frame.
A “goto-URL” bar shall be added to this frame, allowing users to navigate to another URL
while staying within the Moodle frame. Participants will thus not have to open another
Web browser window and be able to return to the original Moodle activity more quickly,
since they shall be able to remain in the Web browser window containing the Moodle
4 See http://skype.com/

10/14
COVCELL Software Requirements Specification Version 1.0

frame.

3.2.1.5 Activity View

Actors: activity view defined by teacher, used by student.
Depending on the kind of activity being undertaken, the interface shown to the student
(and teacher) shall change appropriately, focussing on those elements that are of direct
interest and moving other elements/blocks to the background. Attention shall thus be
focussed on a particular aspect of an activity and distractions minimised.
Further examples of the activity view could be to show/hide the dynamic contact list in a
whiteboard activity, or to supply presentation templates for a group activity.

3.2.2 System Features of Phase II

3.2.2.1 Core Profile
Actor: student.
The Core Profile module shall give students the opportunity to supply personalised
information regarding their person, coupled with rights management, thereby permitting
them to determine who has rights to access what information about them.
Students shall also be able to set events of importance to them (i.e. maintain a
personalised calendar) within their profile.
This feature shall augment the functionality provided by the My Moodle page.

3.2.2.2 Personal Glossary and Quizzer

Actor: student.
During a language course, each student acquires vocabulary at a different rate and from
different fields, depending on the breadth of their reading and variety of situations in which
they practice written and spoken language. The personal glossary shall allow students to
assemble a vocabulary that relates only to their specific language acquisition, and the
quizzer shall give them the opportunity to test themselves on this personal glossary.

3.2.2.3 Deadline Countdown

Actors: deadline set by teacher, viewed by student and teacher.
As the deadline for the submission of an assignment approaches, a colour indicator shall
change e.g. from green, to orange, to red, indicating the status of this deadline. This
functionality will be available to the student on his My Moodle page.
Teachers shall also be alerted to submission deadlines, so that they can prepare
themselves to mark the assignments.

11/14
COVCELL Software Requirements Specification Version 1.0

Illustration 3: My Moodle page with Course Standing and Deadline information.

3.2.2.4 Course Standing

Actors: set by teacher, viewed by student.
This module shall provide an overview of a student's standing in her currently enrolled
courses, i.e. what assignments have already been completed successfully, which have
been failed, and which are still outstanding. This allows the student to gauge their
progress, and will also contain two-way message functionality to allow the teacher to
address the student regarding a particular course (e.g. “You need to pay more attention to
your grammar.”). The student shall be able to reply to the teacher's message, or to initiate
a course-related dialogue with the teacher.

3.2.2.5 File Transfer

Actor: teacher.
At present, transferring files in Moodle from one course to another for reuse is complicated
(one cannot choose specific files to transfer). A module shall be implemented to transfer
files and modules (e.g. a quiz) from one course to another.
TBD.

3.2.2.6 Upload of Corrected Documents

Actor: teacher.
After downloading and correcting a document submitted by a student, the teacher shall be

12/14
COVCELL Software Requirements Specification Version 1.0

able to upload the corrected assignment for the student's perusal. The corrected
assignment shall not overwrite the original submission.

3.2.3 System Features of Phase III

3.2.3.1 Audio/Video Conferencing
Actor: course participant.
Groups of up to five students shall be able to conduct a video conference as it relates to a
particular course. This will be implemented using the Open Source Flash Server Red55. A
client shall also be developed for Moodle.
TBD.

3.2.3.2 One-on-One Video and Audio Chat

Actor: course participant.
The third-party applications relied on in § 3.2.1.3 shall be replaced by a Moodle module
utilising Red5.
TBD.

3.2.3.3 Recording of Audio Feed for Evaluation

Actor: teacher.
Audio exchanges over the Red5 server shall be saved for later evaluation by a teacher.
The audio will be saved as MPEG-2 Layer 3 (MP3) files.
TBD.

4 Software Development Roadmap

Date Milestone Comments
15.02.2006 Commencement of Phase I. See § 3.2.
15.05.2006 Commencement of β-testing of Phase
I.
14.08.2006 Completion of Phase I.
15.08.2006 Commencement of Phase II.
01.09.2006 Test Moodle(s) online for Winter Test of Phase I modules with
Semester courses. students and teachers.
15.11.2006 Commencement of β-testing of Phase
II.
14.02.2007 Completion of Phase II.

5 See http://osflash.org/red5

13/14
COVCELL Software Requirements Specification Version 1.0

Date Milestone Comments

15.02.2007 Commencement of Phase III.
15.05.2007 Commencement of β-testing of Phase
III.
14.08.2007 Completion of Phase III.

14/14