Srs
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Srs as PDF for free.
More details
- Words: 3,029
- Pages: 15
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. calendar, etc.
Can be an activity, a resource, a
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
Software Requirements http://standards.ieee.org/.
Version 1.0
Specifications.
This
document
is
available
from
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. assignment shall not overwrite the original submission.
The corrected
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 Semester courses. 15.11.2006
for
Winter Test of Phase I modules students and teachers.
Commencement of β-testing of Phase II.
14.02.2007 Completion of Phase II. 5 See http://osflash.org/red5
13/14
with
COVCELL Software Requirements Specification
Date
Version 1.0
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
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. calendar, etc.
Can be an activity, a resource, a
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
Software Requirements http://standards.ieee.org/.
Version 1.0
Specifications.
This
document
is
available
from
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. assignment shall not overwrite the original submission.
The corrected
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 Semester courses. 15.11.2006
for
Winter Test of Phase I modules students and teachers.
Commencement of β-testing of Phase II.
14.02.2007 Completion of Phase II. 5 See http://osflash.org/red5
13/14
with
COVCELL Software Requirements Specification
Date
Version 1.0
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
