Srs

SOFTWARE REQUIREMENTSSPECIFICATIONFEBRUARY 2006

COVCELL Software Requirements Specification Version 1.0

SOFTWARE REQUIREMENTSSPECIFICATION

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

Version Date Author(s) Comment0.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.


Table of Contents1 Introduction.....................................................................................................................31.1 Purpose.....................................................................................................................31.2 Scope........................................................................................................................31.3 Definitions, Acronyms and Abbreviations.............................................................31.4 References................................................................................................................41.5 Overview...................................................................................................................5

2 Overall Description.........................................................................................................52.1 Product Perspective................................................................................................52.2 Product Functions...................................................................................................62.3. User Characteristics...............................................................................................72.4 Constraints...............................................................................................................72.5 Assumptions and Dependencies............................................................................72.6 Apportioning of Requirements...............................................................................8

3 Specific Requirements....................................................................................................83.1 External Interface Requirements............................................................................83.1.1 User Interfaces..................................................................................................83.1.2 Hardware Interfaces.........................................................................................83.1.3 Software Interfaces...........................................................................................83.1.4 Communication Interfaces...............................................................................8

3.2 System Features......................................................................................................83.2.1 System Features of Phase I.............................................................................83.2.1.1 Dynamic Location-Specific Contact List and Chat.................................83.2.1.2 Whiteboard.................................................................................................93.2.1.3 One-on-One Audio and Video Chat........................................................103.2.1.4 “Goto-URL” Bar within Moodle Frame..................................................103.2.1.5 Activity View.............................................................................................11

3.2.2 System Features of Phase II..........................................................................113.2.2.1 Core Profile..............................................................................................113.2.2.2 Personal Glossary and Quizzer..............................................................113.2.2.3 Deadline Countdown...............................................................................113.2.2.4 Course Standing......................................................................................123.2.2.5 File Transfer.............................................................................................123.2.2.6 Upload of Corrected Documents............................................................12

3.2.3 System Features of Phase III.........................................................................133.2.3.1 Audio/Video Conferencing......................................................................133.2.3.2 One-on-One Video and Audio Chat........................................................133.2.3.3 Recording of Audio Feed for Evaluation...............................................13

4 Software Development Roadmap................................................................................13

2/14


1 Introduction

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

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

1.3 Definitions, Acronyms and AbbreviationsTerm Definition

administrator Administrator of the Moodle CMS, does not necessarily execute apedagogical rôle (cf. teacher)

AJAX Asynchronous JavaScript Technology and XMLA technology for adding functionality to Web pages.

block An element of a Moodle page. Can be an activity, a resource, acalendar, 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 computerprogram that facilitates computerised learning or e-learning, especiallyby helping teachers and learners with course administration.

COVCELL Cohort-Oriented Virtual Campus for Effective Language LearningSee http://covcell.org/

DBMS Database Management SystemEU European Union

3/14


Term DefinitionIEEE Institute of Electrical and Electronics EngineersLMS Learning Management System

A synonym for CMS (as defined above).Moodle Modular Object-Oriented Dynamic Learning Environmentopen source A method and philosophy for software licensing and distribution

designed to encourage use and improvement of software written byvolunteers by ensuring that anyone can copy the source code andmodify it freely.

participant A neutral term that refers either to a teacher or student participating ina Moodle course.

PHP PHP Hypertext PreprocessorA 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 ofseveral (software) servers running on a (hardware) server. Thedistinction is in many cases irrelevant, however, as the term serverimplies an entity that provides a service to a client. This client-serverrelationship is of importance, not whether we are speaking of hardwareor software.

SMTP Simple Mail Transfer ProtocolProtocol used for the sending of electronic mail.

SRS Software Requirements SpecificationThis document.

student Member of a courseTBD 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-purposemarkup languages, capable of describing many different kinds of data.

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

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

4/14


Software Requirements Specifications. This document is available fromhttp://standards.ieee.org/.Furthermore, these specifications should be read in conjunction with the originalCOVCELL application to the EU. This application is available upon request [email protected]

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

2 Overall Description

2.1 Product PerspectiveThe Moodle engine operates as the cornerstone of the CMS. Moodle is an acronym ofModular Object-Oriented Dynamic Learning Environment1, and its modular nature isexpressed in the diagram below. Moodle acts as the conduit for the functionalityencapsulated in the various modules, maintaining data concerning teachers and students(courses on offer, course enrolment, personal details, etc.) and structuring the interactionwith third party applications that allow participants to receive course-related emails and tointeract with Moodle by means of a Web browser.The COVCELL Project will develop modules that support its goals as stated above, inaccordance with the guidelines as stated on the Moodle Web site (cf. § 2.4). At this stageit is intended that Quality Assurance be provided by the maintainers of the Moodle OpenSource project.

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

5/14


2.2 Product FunctionsA 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 structuredaccording to an iterative, agile approach, thus providing the flexibility necessary toincorporate 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

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


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

2.3. User CharacteristicsThe Moodle homepage describes the software package as

designed using sound pedagogical principles, to help educators create effectiveonline learning communities.2

Moodle is intended for use by educators – be they lecturers or teachers – and learners, bethey students or pupils. The software is designed to be as easy to use as possible forboth 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 aEuropean learning environment.

2.4 ConstraintsDue to its nature as a transnational EU project, the software developed by COVCELL hasto take differing national privacy legislation into account. The software will be designedsuch that administrators of Moodle will be able to control the granularity or indeed the verynature 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 DependenciesThe software development is divided into 3 phases, as detailed in § 3.2. It is assumedthat the Open Source Flash Server Red5 will be sufficiently mature for inclusion in theCOVCELL software development by phase III (cf. § 3.2.3).

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

7/14


2.6 Apportioning of RequirementsThe software requirements for phases II and III may be modified at a later stage, based onfeedback gleaned from ongoing teacher and student surveys.

3 Specific Requirements

3.1 External Interface Requirements

3.1.1 User InterfacesMoodle takes a modular approach to offering functionality within the platform. In otherwords, it is a requirement for all modules developed by COVCELL that they conform to theMoodle look-and-feel and integrate with the complete environment.

3.1.2 Hardware InterfacesThe Moodle engine structures all interaction between the software and the hardware (inconjunction with third party products such as a Web server and DBMS – cf. § 2.1). Assuch, the software modules under development do not need to account for hardwareinterfaces.

3.1.3 Software InterfacesThe 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 occurson the client-side by means of a Web browser.AJAX will be utilised where appropriate.

3.1.4 Communication InterfacesInterfaces with network protocols will be handled by the CMS and the Web server.

3.2 System FeaturesThe 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 ChatActor: course participant.A dynamic contact list shall be generated, based on all participants engaged in a particularactivity at a specific location. The idea behind this feature is to exploit spontaneousmeetings 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 coursewould be able to strike up an impromptu conversation with any other course participants

8/14


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

3.2.1.2 WhiteboardActor: course participant.A module shall be developed that integrates the whiteboard functionality provided byCoccinella3 into a Moodle module. This will permit users to create and modify diagrams ina collaborative environment.

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

9/14


3.2.1.3 One-on-One Audio and Video ChatActor: course participant.Based on the dynamic contact list functionality described in § 3.2.1.1, the participantsshall 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 theirrespective profiles, the icons identifying them in the dynamic contact list shall drawattention to the fact that an audio/video chat using Skype is possible. By clicking on theicon, Skype would be launched and a call initiated between the two parties. Whether thechat would be just audio or audiovisual would depend on the Skype preferences of theparties and whether Web cams were attached to both computers.

3.2.1.4 “Goto-URL” Bar within Moodle FrameActor: course participant.Within Moodle a resource might be a link to an external Web page. Clicking on thisresource 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 URLwhile staying within the Moodle frame. Participants will thus not have to open anotherWeb 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

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


frame.

3.2.1.5 Activity ViewActors: 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 directinterest and moving other elements/blocks to the background. Attention shall thus befocussed 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 awhiteboard activity, or to supply presentation templates for a group activity.

3.2.2 System Features of Phase II

3.2.2.1 Core ProfileActor: student.The Core Profile module shall give students the opportunity to supply personalisedinformation regarding their person, coupled with rights management, thereby permittingthem 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 apersonalised calendar) within their profile.This feature shall augment the functionality provided by the My Moodle page.

3.2.2.2 Personal Glossary and QuizzerActor: student.During a language course, each student acquires vocabulary at a different rate and fromdifferent fields, depending on the breadth of their reading and variety of situations in whichthey practice written and spoken language. The personal glossary shall allow students toassemble a vocabulary that relates only to their specific language acquisition, and thequizzer shall give them the opportunity to test themselves on this personal glossary.

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

11/14


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

3.2.2.5 File TransferActor: 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 transferfiles and modules (e.g. a quiz) from one course to another.TBD.

3.2.2.6 Upload of Corrected DocumentsActor: teacher.After downloading and correcting a document submitted by a student, the teacher shall be

12/14

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


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

3.2.3 System Features of Phase III

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

3.2.3.2 One-on-One Video and Audio ChatActor: course participant.The third-party applications relied on in § 3.2.1.3 shall be replaced by a Moodle moduleutilising Red5.TBD.

3.2.3.3 Recording of Audio Feed for EvaluationActor: 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 RoadmapDate 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

Semester courses.Test of Phase I modules withstudents and teachers.

15.11.2006 Commencement of -β testing of PhaseII.

14.02.2007 Completion of Phase II.

5 See http://osflash.org/red5

13/14


Date Milestone Comments15.02.2007 Commencement of Phase III.15.05.2007 Commencement of -β testing of Phase

III.14.08.2007 Completion of Phase III.

14/14

Srs

Documents

specific contact

dynamic contact

web browser

external web

contact list

web browser

virtual campus

chat window