SRS Group

Software Requirements Specification M Moodle System
Version 1.0
Supervisors: Mr.Shantha Fernando Mr.Samantha Senaratne Prepared by: Team 11 Shammi J. Mathuvathanan M. Luckshy S. Sujeetha L.
Computer Science & Engineering University of Moratuwa
Copyright 2007 by Team 11, Computer Science & Eng, University of Moratuwa, SriLanka.
Software Requirements Specification
M- Moodle System
Page 1
Table of Contents
Table of Contents ..........................................................................................................................................1 1. Introduction.............................................................................................................................................2 1.1 Purpose.........................................................................................................................................2 1.2 Document Conventions................................................................................................................2 1.3 Intended Audience and Reading Suggestions ..............................................................................2 1.4 Project Scope................................................................................................................................2 2. Overall Description .................................................................................................................................4 2.1 Product Perspective......................................................................................................................4 2.2 Product Features...........................................................................................................................4 2.3 User Classes and Characteristics..................................................................................................5 2.4 Operating Environment................................................................................................................5 2.5 Design and Implementation Constraints ......................................................................................6 2.6 User Documentation.....................................................................................................................7 2.7 Assumptions and Dependencies...................................................................................................7 3. System Features ......................................................................................................................................8 3.1 View the assignment results by sending a SMS...........................................................................8 3.1.1 Description and Priority...............................................................................................................8 3.1.2 Stimulus/Response Sequences .....................................................................................................8 3.1.3 Functional Requirements .............................................................................................................8 3.2 Get an alert message when there is any new announcement posted in moodle..................................9 3.2.1 Description and Priority...........................................................................................................9 3.2.3 Stimulus/Response Sequences ..................................................................................................9 3.2.2 Functional Requirements .........................................................................................................9 3.3 Send SMS about any announcement to update moodle (by a lecturer)......................................10 3.3.1 Description and Priority.........................................................................................................10 3.3.2 Stimulus/Response Sequences ...............................................................................................10 3.3.3 Functional Requirements .......................................................................................................10 3.4 Adding a discussion topic through the mobile ...........................................................................11 3.4.1 Description and Priority.........................................................................................................11 3.4.2 Stimulus/Response Sequences ...............................................................................................11 3.4.3 Functional Requirements .......................................................................................................11 4. External Interface Requirements...........................................................................................................12 4.1 User Interfaces ...........................................................................................................................12 4.2 Hardware Interfaces ...................................................................................................................12 4.3 Software Interfaces.....................................................................................................................13 5. Other Nonfunctional Requirements ......................................................................................................14 5.1 Performance Requirements ........................................................................................................14 5.2 Safety Requirements ..................................................................................................................14 5.3 Security Requirements ...............................................................................................................14 5.4 Software Quality Attributes .......................................................................................................15 6. Appendix A: References .......................................................................................................................16
Revision History
Name Date Reason For Changes Version
M- Moodle System
Page 2
1. Introduction
1.1 Purpose
This document is the System Requirement Specification of M- Moodle System. This system is developing for the University of Moratuwa, to extend the E - Learning facilities to mobile. The ultimate goal of this to, develop a sms service through which the students and staffs can get the 90% benefits of the current E Learning system from wherever they are. This SRS will cover the whole proposed system. This is the SRS document of version 1.0 of M- Moodle System.
1.2 Document Conventions

The following document conventions have been used to ensure ease of readability. Font Times New Roman, size 12, spacing 1.5 Main Headings Font size 18, Bold Sub Headings Font size 14, Bold Sub-sub headings Font Size 12, Bold Important terms have been italicized, and are bold.
1.3 Intended Audience and Reading Suggestions

This document is intended for the benefit of the project coordinator, final evaluator of this system. It will also be a guideline for the developers. All the details are structured smartly.
1.4 Project Scope

The scope of the system is to develop a sms service through which the students and staffs can get the 90% benefits of the current E Learning system from wherever they are. Nowadays the use of mobiles phones are increased beyond the web. Therefore this system will be very useful in places where they dont have internet connections. Using this system student can carry out their learning where ever they are. This system is developing for University of Moratuwa. Therefore this system
M- Moodle System
Page 3
mainly targeted the students and staffs of University of Moratuwa. This system mainly supports three kinds of functionalities. Send a sms and get a reply sms. E.g.: Sending a sms in order to see the results Get a notification messages when there is a new updates in E- Learning. E.g.: Announcements. Uploading information in E Learning through sms. E.g.: Add a discussion topic in E Learning. Not only above things, But also we are planning to develop a mobile interface for the E Learning system called Moodle.
M- Moodle System
Page 4
2. Overall Description
2.1 Product Perspective
This is not a standalone system. This is the extension of E Learning through mobile. The current E Learning system in University of Moratuwa is Moodle. Moodle is an open source course management system. Therefore in our system, we are going to interact with the Moodle through mobile. That means most of the actives can be carrying out using mobile rather than a web browser. This system will available at all and will be function in secure manner with filtering. The main parts of the systems are the filtering section and the administrator part. (Authentication part)
2.2 Product Features

Main features of the system are listed as below. (To be discussed in depth in section 3)
Viewing the assignments results by just sending a sms Getting an alert message when there is a new announcement posted in Moodle. Adding a discussion topic to the forum and be able to send replies for a discussion topic by simply sending a sms when there is no internet connection. Lecturers should be able to make any announcement by just sending a sms when there is no net connection is available. That sms should be uploaded in the Moodle subject page as well as it should be forwarded to the batch representative. Developing a mobile interface to Moodle.
M- Moodle System
Page 5
2.3 User Classes and Characteristics

Normal Users Main targeted user groups are the staffs and students from University of Moratuwa. The user should not need previous training experience on system to obtain desired outcomes, but the user should know how to send a sms, in which format that they want to send, and to which number they want to send. In that, to get a reply sms from the system the mobile number should be authenticated in the system before in each users account. Advanced Users Advanced users mentioned the peoples who are going to maintain this system and the administrator part of our system. This is maintained by the LK Domain people in University of Moratuwa.
2.4 Operating Environment

This system should work together with the E Learning system Moodle. Therefore our system should operate in the environment of Moodle. Hardware requirements: Disk space: 160MB free (min) Memory: 256MB (min), 1GB (recommended). Software requirements: Web server software. Most people use Apache, but Moodle should work fine under any web server that supports PHP, such as IIS on Windows platforms. PHP does impose requirements on versions of web servers, however these are complex and the general advice is to use the newest version possible of your chosen web server. PHP scripting language.
M- Moodle System
Page 6
A working database server: MySQL or PostgreSQL is recommended.
Operating system: It can be work on Linux /Windows/Solaris 10 (Sparc and x64), Mac OS X and Netware 6
2.5 Design and Implementation Constraints

Database maintenance for the system: Our system is handling with the data from the Moodle. But Moodle is integrated with its own data base. Therefore we should find a way to populate the data from Moodle to our system. Filtering part: This is the important part of our system. It should work properly and want to handle the sms character limitation as well. Requirement for mobile: This system is useful if a mobile phone is available for the user. Requirement of registration: To make use of this system the mobile number that is using to send the request should be authenticated to a particular user that already registered in the system.
M- Moodle System
Page 7
2.6 User Documentation

The user documentation will be provided with the system.
2.7 Assumptions and Dependencies

To have a separate sever for M Moodle, we assume that we can populate the Moodle data in to our server. To be a real application, we have a get a gateway from any GSM provider. At this time we are using GSM modem for the testing purpose. We wish to develop the mobile interface for the M-Moodle system only there is time after completing all other previous tasks.
M- Moodle System
Page 8
3. System Features
3.1 View the assignment results by sending a SMS 3.1.1 Description and Priority This is one of the key features of the M-Moodle system. A student who has already registered in the M-Moodle system should be able to send a SMS in a given format to view their assignment results through their mobile (if any). If we can categorize the priorities of the features as high, medium and low, this feature will besides under high category. 3.1.2 Stimulus/Response Sequences Here the action will be started by the student. He/She will send a SMS from the mobile interface. The system should be able to receive those SMSs and should be able to filter according to the specified format whether it conforms to that. Then the system will retrieve the result from its database and again will send it to the mobile through the filter. (System should already have to pop up the results from the moodle database to itself if there any assignment results uploaded in moodle) 3.1.3 Functional Requirements REQ1: Should be able to receive the SMS details (receiver, time and the context) into the system database. REQ2: Should be able to filter the SMSs whether they conform to the specified format. If it is not, then should be able to discard the SMS. Also it should be check the mobile numbers whether they have authenticated in the system. REQ3: Should be able to connect to its own database and pop the results of the particular student. REQ4: Should be able to send the results back to the sender.
M- Moodle System
Page 9
3.2 Get an alert message when there is any new announcement posted in moodle
3.2.1 Description and Priority
This another key feature of our system. There can be many new announcements posted in moodle time to time. Not only announcements, but also there can be any messages from lecturers about their lecture time schedules (cancel/new arrangement). Then those messages should be notified to all students using the M-Moodle system. But by considering the cost incurred in this, we wish to select the receivers dynamically. Even though it seems to be a main feature, we considered this as a medium priority feature compared with others. 3.2.3 Stimulus/Response Sequences
Here the action will be started by the system itself. There should be a lifetime thread looking at the moodle database to check whether there are any new announcements posted. If so, those should be retrieved to the system database and should be sent to the students mobiles notifying the new event. There should be a format to the notifying SMS. If the number of characters are exceeded the allowed characters, then the format should be defined according to that. For example, if there any news about an assignment and if it exceeds the maximum character size, then the system should send the SMS just saying that a new news about the assignment for the particular subject is posted in moodle rather than sending the entire news about the particular assignment. 3.2.2 Functional Requirements
REQ1: There should be a life time thread running on moodle database to check whether there are any new updates. REQ2: System should retrieve the new updates from moodle and should save in its database. REQ3: System should check the number of characters of the message whether it exceeds the maximum character size for a SMS
M- Moodle System
Page 10
REQ4: There should be a format to send the messages for the announcements which character size is unlimited. REQ5: System should fetch all the students mobile number and should send the news to their mobiles.
3.3 Send SMS about any announcement to update moodle (by a lecturer)
This feature is added for the lecturers to give them more facilities when they are not able to connect to internet. This feature should facilitate the users to update the moodle through their mobile. So lecturers should be able to update the moodle when they are without internet connectivity. Here we considered the situations like lecture cancellation, request to bring any equipments/materials (calculator, past papers, reference text book etc.) to the upcoming lecture and so on. These situations might arise once in a while. So we can consider this as a low priority one. 3.3.2 Stimulus/Response Sequences
Here again the action should start by the user (Lecturer in this case). Users should send a SMS about the notification from their mobile interface. The system should capture this through the filter and should ensure that the SMS is coming from a lecturer. After the filtering, system should be able to connect to moodle server and update it in order to display the required task by the lecturer in the particular course forum. 3.3.3 Functional Requirements
REQ1: System should receive the SMS and should filter it according to the format. REQ2: System should connect to the moodle server. REQ3: It should write whatever the contents in the SMS to the course forum.
M- Moodle System
Page 11
3.4 Adding a discussion topic through the mobile

There are several forums in the moodle for each and every subject that the student undertakes. Students can add a discussion topic and continue to send comments about that. It can be a question about the subject or a new technology he/she got to know about that subject or anything else related with the subject. So in our system we thought of giving a way to the students that they can add these comments whenever they want (when they cannot use the internet). This feature can be considered as a medium priority one.
3.4.2
Stimulus/Response Sequences
Here the action should be started by the user (Lecturer/ Student). User should able to send a SMS about their discussion topic. The system should filter those SMSs, then should connect to the moodle server and should update it in order to display the discussion topic in the course forum. 3.4.3 Functional Requirements
REQ1: System should receive the SMS and should filter it according to the format. REQ2: System should connect to the moodle server. REQ3: System should update the moodle to display the discussion topic inside the course forum.
M- Moodle System
Page 12
4. External Interface Requirements

4.1 User Interfaces In our system there are two interfaces that users can interact. One is the M-Moodle page which should be added to the LearnOrg server. The user should first register into M- Moodle in order to gain its functionalities. The page should first prompt a login page which should ask the user to enter his/her user name and pass word. After logged in, it should display the links for all the subjects he/she undertakes. Each and every subject should display the inbox and sent items folders for the user. Here the inbox and sent items folders should have the users SMS messages which were received and sent by the system. The second interface is their mobile itself through which they communicate with our system. Any phones which have the message sending facility in text format are suitable for this interface. 4.2 Hardware Interfaces The main hardware component used in M- Moodle is the mobile phone. Almost all the mobile phones have the facility of sending message in text format. We thought of using a GSM modem for the early stage of our project for the testing purposes. In that case, The SIM card inserted into the GSM modem should retrieve the SMS messages that the users sent (of course the users should send their SMS messages to that SIM cards number). Then by using an API called JSMS Engine, the messages received by the Modem can be converted to our system. (API handles the AT commands sends by the GSM modem through the serial port of the computer and converts it in the form that can be understood by the computer). The above procedure should be reversible when the system responds to a user.
M- Moodle System
Page 13
4.3 Software Interfaces M- Moodle system should compatible with all the windows operating systems. The server running on our system should use the database MySQL to connect to the moodle server as well as LearnOrg server and its databases. And there is an API for interfacing with the GSM modem connected with the computer. We found it as jsmsengine which converts the AT commands to the text format.
M- Moodle System
Page 14
5. Other Nonfunctional Requirements

5.1 Performance Requirements Performance is a key requirement in our system. Soon after getting any SMS messages from the users, the system should be able to connect to its own database as well as LearnOrg server to get the required details. There should be a lifetime thread to check the new updates on the moodle server. So that the system can be able track the changes done on moodle. The system should be able to capture the concurrent SMS messages coming from several users. It should be able to connect to other servers within a shorter period of time. 5.2 Safety Requirements M- Moodle will be accessing the existing well structured LearnOrg server time to time to get the details from its database and also to update it in order to show the SMS messages received from the lecturers. This should not harm the existing system and its configuration in any manner. 5.3 Security Requirements Viewing the assignment results is a confidential issue. That should be allowed only to the authorized students. And also the lecture cancellation must be sent from an authorized lecturer in charge. Therefore the filtering part of our system should be made in order to affect those constraints. The SMS messages should start by their usernames in the front. By considering these issues we thought of giving a separate account for each and every user and that should be activated by the user at the first stage of using the system.
M- Moodle System
Page 15
5.4 Software Quality Attributes The system should reflect the changes done on moodle as soon as possible. It should keep all the incoming and outgoing messages of each and every student so that he/she can verify it later also. The system should be available to the user all the time to send and receive SMS messages whenever he/she wants. The system should be able to interoperate with the existing LearnOrg server. Since it is a lifetime system, it should be developed in such a way that it could be maintainable for long time. The system should correctly display the contents of the message on the moodle, and should correctly send the text message according to the change done on moodle. And the very important feature is that it should be reliable. The end user should rely on the system that it displays the correct information as expected.
M- Moodle System
Page 16
6. Appendix A: References
1. http://www.developershome.com/sms 2. http://moodle.org

SRS Group

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SRS Group

Enviado por

Direitos autorais:

Formatos disponíveis

Software Requirements Specification M Moodle System

Computer Science & Engineering University of Moratuwa

Software Requirements Specification

Software Requirements Specification

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Project Scope

Software Requirements Specification

Software Requirements Specification

2.2 Product Features

Software Requirements Specification

2.3 User Classes and Characteristics

2.4 Operating Environment

Software Requirements Specification

A working database server: MySQL or PostgreSQL is recommended.

2.5 Design and Implementation Constraints

Software Requirements Specification

2.6 User Documentation

2.7 Assumptions and Dependencies

Software Requirements Specification

Software Requirements Specification

Software Requirements Specification

Software Requirements Specification

3.4 Adding a discussion topic through the mobile

Software Requirements Specification

4. External Interface Requirements

Software Requirements Specification

Software Requirements Specification

5. Other Nonfunctional Requirements

Software Requirements Specification

Software Requirements Specification

Você também pode gostar