FINAL SRS

Virtual Classroom Version 1

Software Requirement Specification 29/12/2010

Snakes

1

Snakes/Netaji Subhash Engineering College

SNAKES

Virtual Classroom Software Requirement Specification

Version 1

Team Guide : Sourav Mitra

Members: Shoubhik Bose

Shamik Ray

Sumon Sadhukhan

Sudipta Ghosh

College Name: Netaji Subhash Engineering College.

Department: Computer Science Engineering.

State: Westbengal



Snakes

2


Revision History

Date Version Description Author

29/12/2010 1 Basic Structure and

design of the project

Snakes



Snakes

3


Table of Contents

Description Page No.

1.0 Introduction

1.2 Scope

1.3 Definition, Acronyms, and Abbreviations

1.4 References

1.5 Technologies to be used

1.6 Overview

2.0 Overall Description

2.1 Product Perspective

2.2 Software Interface 2.3 Hardware Interface 2.4 Product Function

2.5 User Characteristics 2.6 Constraints

2.7 Architecture Design

2.8 Use Case Model Description

Class Diagram ........................................................................

Sequence Diagram s ...............................................................

2.10 Database Design ....................................................................



Snakes

4


2.11.1 ER Diagram ...............................................................

2.11.2 Schema ......................................................................

2.12 Assumptions and Dependencies

3.0 Specific Requirements

3.1 Use Case Reports

3.2 Supplementary Requirements



Snakes

5


Software Requirements Specification

1.0 Introduction: 1.1 Purpose:

Gaining motivation from ONLP ( One Laptop Per Child ) project and NPTel(National Programme on Technology Enhanced

Learning ) , we yearn to provide good quality education to the masses through the use of technology.

“Give a man a fish and you feed him for a day.

Teach him to fish, you feed him for a lifetime ! “

Making education accessible for all mankind, our project would help to spread literacy to places where it becomes

difficulty to maintain the quality of education, due to economic, social and polictical problems.

1.2 Scope: The Scope of the virtual classroom includes:

• The users need to be connected to the internet.

• The students act as “consumers “ for the information “produced” by the teachers.

They(the students) take exams , view lectures and participate in exams.

• The management appoints the teachers.

• The administrator assures a smooth running of the system.

1.3 Definitions, Acronyms, and Abbreviations:

HTML (Hyper Text Markup Language): It is used to create static web pages.

JSP (Java Server Pages): It is used to create dynamic web content.

J2EE (Java 2 Enterprise Edition): It is a programming platform, belonging to the Java platform, which is used for

developing and running distributed java applications.

WASCE (WebSphere Application Server Community Edition): It is an application server that runs and supports the J2EE

and the web service applications.



Snakes

6


WSAD (WebSphere Studio Application Developer ): It is a designer toolkit which is designed to develop more complex

projects by providing a complete dynamic web service.

DB2 (IBM Database 2): It is a database management system that provides a flexible and efficient database

platform to raise a strong "on demand" business applications.

HTTP (Hyper Text Transfer Protocol): It is a transaction oriented client/ server protocol between a web browser

and a web server.

XML (Extensible Markup Language): It is a markup language that was designed to transport and store data.

• Ajax (Asynchronous Java Script and XML): It is a technique used in java script to create dynamic web pages.

• Web 2.0: It is commonly associated with web applications which facilitate interactive information sharing, interoperability,

user-centered design and collaboration on the World Wide Web.

1.4 References:

• Database System Concepts - 6th edition by Avi Silberschatz · Henry F. Korth · S. Sudarshan

• http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/

• http://www.magicdraw.com/files/case_studies/magiclibrary/requirements/MagicLibrary%20System%20Requirements.pdf?NMSESSID=

• UML DISTILLED by Martin Fouler.

• www.csc.villanova.edu/~tway/courses/csc4181/srs_template-1.doc

1.5 Technologies to be used:

J2EE: (Servlet, JSP, JAXP, Java Beans) Application architecture.

JAVA: Application architecture.

WASCE: (WebSphere Application Server Community Edition) Web Server

DB2: IBM Database.

Ajax: Asynchronous Java Script and XML.

XML: Extension Markup Language. Web 2.0: RSS Feed 2.0.



Snakes

7


RAD 7.0: Development tool.

Localization: 3 Languages - Hindi, Kannada, and English

1.6 Overview

The SRS will include two sections, namely:

-I- Overall Description: This section will describe major components of the system,

interconnections, and external interfaces.

-I- Specific Requirements: This section will describe the

functions of actors, their roles in the system and the constraints faced by the system.



Snakes

8


2.0 Overall Description:

2.1 Product Perspective

2.2 Software Interface:

-I- Front End Client: Web browser ( IE, NN, Mozzila, and Firefox. )

-I- Web Server: WebSphere Application Server CE

-I- Data Base Server: IBM DB2 UDB

2.3 Hardware Interface:

Client Side:

MINIMUM SYSTEM REQUIREMENTS

PENTIUM 4 AT 1 GHz , 256 MB RAM , DISC SPACE : 100MB

Server Side:

MINIMUM SYSTEM REQUIREMENTS

SOFTWARES: IBM DB2 , WASCE

PENTIUM 4 AT 1 GHz , 512 MB RAM , DISC SPACE: 1GB

Education is our birthright.

With a motivation to provide education to people worldwide, the virtual classroom system provides a user-friendly

interface to celebrate the spirit of learning , collaborating and thereby taking mankind one step forward to a no-strings

attached mode of acquiring knowledge.

On the client side, the users see HTML content . Communication is via HTTP/HTTPS protocols.

The Server side web server is J2EE compliant.

The DATABASE server is IBM DB2 Universal Database Server.



Snakes

9


2.4 Product Functions

• Students can choose courses, attend lectures, take exams, view their attendance records, progress reports etc as

per their convenience.

• Registration for multiple courses.

• Attend lectures either at the scheduled time or on request view lecture at a later time.

• Faculties can take lectures, upload assignments, announcements, evaluate answer sheets and also can upload

lectures and other discussions in various formats as in videos, power point presentation etc.

• Upload and Download of various assignments, college notices, student's notices, journals, videos.

• Asynchronous communication in the form of Emails, discussion boards that enable communication to occur at

"convenient-times" that suit student schedules and are not accessed at simultaneous or prearranged times.

• There can be forums, blogs etc to discuss various queries and to put up suggestions posted both by students and

teachers.

• Administrator can generate reports, log files, backup/recovery of data at any time.

• Shared documents and media library that can help in active learning of a student.

• One-to-Many (B->A), Many-to-One(A->B) and Many-to-Many (B->B) information sharing.

• Provision of resources to arouse the interest of students in extracurricular activities like public speaking etc and

to grasp the chance to enhance their personalities.

• Users must have valid User ID and password to login thus creating their individual profiles.

( more functions will be implemented during the coding phase )

2.5 User Characteristics

• The user needs to be able to use the computer ,connect to the internet. The technologies used in this

• project need not be known to the user.

• The GUI will support upto language translation upto 25 languages ( using Google Translate).

• The user needs to have average sensory ability.



Snakes

10


2.6 Constraints:

• No provision for guest users. User must be registered as a STUDENT , FACULTY , MANAGEMENT , ADMINISTRATOR.

• Only HTTP/HTTPS protocols will be used.

• The database server needs to secure. ( physically as well).

• The Faculty can register only on permission from the Management.

• The Management user can register only on permission from the Administrator.

2.7 Architecture Design:

2.8 Use Case Diagram

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created

from aUse-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms

of actors, their goals (represented as use cases), and any dependencies between those use cases. Following is our

use case diagram.



Snakes

11




Snakes

12


2.9 CLASS DIAGRAM

A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that

describes the structure of a system by showing the system's classes, their attributes, and the

relationships between the classes. Following is out class diagram.



Snakes

13




Snakes

14


2.10 SEQUENCE DIAGRAM

CREATING A NEW LECTURE:

ACTOR: FACULTY



Snakes

15


TAKING AN EXAM

ACTOR: STUDENT



Snakes

16


USER AUTHENTICATION

ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR



Snakes

17


POST TO A FORUM:




Snakes

18


READ A MESSAGE ( ASYNCHRONOUS MESSAGING SERVICE)


2.10.1 DATABASE DESIGN



Snakes

19


2.10.2 E-R DIAGRAM



Snakes

20


TABLES USED IN THE DATABASE:

SYSTEM ACCESS

USER( uid , password,active, privilege ,doj )

PRIMARY KEY: uid

FOREIGN KEY: uid references uid of USER

STUDENT (sid,name)

PRIMARY KEY and FOREIGN KEY: sid references uid of USER

STUDENT_CONTENT(sid,name,content)

FOREIGN KEY: sid references sid of STUDENT

FACULTY(fid,fname)

PRIMARY KEY and FOREIGN KEY: fid references uid of USER

FACULTY_CONTENT(fid,content)

FOREIGN KEY: fid references uid of FACULTY

MANAGEMENT(mid,designation)

PRIMARY KEY and FOREIGN KEY: mid references uid of USER

MANAGEMENT_CONTENT(mid,content)

FOREIGN KEY: mid references uid of MID

ADMINISTRATOR(aid)

PRIMARY KEY and FOREIGN KEY: aid references uid of USER

ADMINISTRATOR_CONTENT(aid,content)

FOREIGN KEY: aid references aid of USER



Snakes

21


EXAM MANAGEMENT

EXAM( eid,cid,fid,arr_questions )

During implementation ,

EXAM is normalized to EXAM_DETAILS AND EXAM_QUESTIONS

EXAM( eid,cid,fid,arr_questions,arr_answers )

decomposed

EXAM_DETAIL( eid , cid , fid )

foreign key: cid references cid of COURSE_DETAIL

EXAM_QUESTION( eid , arr_questions )

EXAM_ANSWER(eid , arr_answers )

foreign key: eid references eid of EXAM_DETAIL

SOLUTION(soln_id , eid , sid , arr_solns , result ,checked)

decomposed

SOLUTION_DETAIL(soln_id , eid , sid , checked)

SOLUTION_CONTENT(soln_id, arr_solns)

SOLUTION_RESULT(soln_id,result)

PRIMARY KEY: soln_id

FOREIGN KEY:

soln_id references soln_id of SOLUTION_DETAIL

eid references eid of EXAM_DETAIL



Snakes

22


DEPARTMENT MANAGEMENT

DEPARTMENT( did, hod , dname , content )

PRIMARY KEY: did

decomposed

DEPARTMENT_DETAIL( did , hod , dname ) , DEPARTMENT_CONTENT ( did , content )

COURSE MANAGEMENT

COURSE ( cid , did , fid , info )

decomposed

COURSE_DETAIL(cid,did,fid) COURSE_INFO(cid,...)

PRIMARY KEY: cid

FOREIGN KEY: did references did of DEPARTMENT_DETAIL

LECTURE MANAGEMENT

LECTURE ( lid , cid , fid , lcontent , date)

PRIMARY KEY: lid

FOREIGN KEY:

cid references cid of COURSE

fid references fid of FACLUTY

can be decomposed as

LECTURE_DETAIL(lid,cid,fid) and LECTURE_CONTENT(lid,lcontent)



Snakes

23


FORUM MANAGEMENT

FORUM ( fo_id , cid )

PRIMARY KEY: fo_id

FOREIGN KEY: cid references cid of COURSE_DETAILS

TOPIC( tid , fo_id , user_id , date_created , date_modified,content )

PRIMARY KEY: tid

FOREIGN KEY:

fo_i references fo_id of FORUM.

user_id refernces uid of USER.

POST(po_id , tid , user_id , content, date )

PRIMARY KEY: po_id

FOREIGN KEY:

tid references tid od TOPIC

user_id references uid of USER

MESSAGING SERVICE

MESSAGE ( mid , sender , recipient , subject , content ,date)

PRIMARY KEY: mid

FOREIGN KEY: sender,recipent references uid of USER.

decomposed

MESSAGE_DETAIL( mid , sender , recipent , subject ,date)

MESSAGE_BODY(mid , content )



Snakes

24


BLOG MANAGEMENT

BLOG(bid,uid)

PRIMARY KEY: bid

FOREIGN KEY: uid references uid of USER

BLOG_POST(bid,bpid,content)

PRIMARY KEY: bpid

FOREIGN KEY: bid

BLOG_POST(bid,bpid,content)

decomposed

BLOG_POST_DETAIL(bpid,bid) BLOG_POST_CONTENT(bpid,content)

NOTE:Content stands for multiple attributes, LOB(large objects) .i.e, related attributes for a table.

(to be decided during coding)



Snakes

25


2.11 ASSUMPTIONS AND DEPENDENCIES

• Staying synchronised with the vision of the project, registration of a student does not require

prior permission of any other user with a higher access privilege/role.

• Faculty members are registered strictly by the Management.

• The Virtual Classroom system is affiliated to an organisation who can appoint teachers from

anywhere in the world , but only after processing their application.

• As far as contacts are concerned, every student has every other “course-mate” as her 'contact'

which shows up in her conact list.

• The USER_ID is unique. The Student_id, faculty_id , management_id and admin_id references

UER_ID.

• The virtual classroom does not create discriminate on grounds of Grade or Standard, the only

grounds of distinction,however, are the courses being taken. In the implementation phase of

this project , it is being thought that every student will be given a rating based on a specific

criteria.

• The Messaging service is used for INTRA-APPLICATION electronic mail transfer . An email

notification will be sent to the public email account of recipient.



Snakes

26


3.0 SPECIFIC REQUIREMENTS

3.1 USE CASE REPORT

USER AUTHENTICATION

OPERATION: REGISTRATION ( STUDENT ) :

DESCRIPTION:

Non-registered students need to first register before accessing the virtual classroom.

Precondition

User requests to login to the system and fails / and clicks Register as a Student

BASIC FLOW OF EVENTS:

• USER_ID forwarded to registerUser.jsp

• registerUser.jsp accesses database and checks privilege .

• If Student, fetch registerForm.jsp and display in web browser.

• After student fills up the form, the HTTP POST sends the attribute values to the

web container.

• The web container sends the HTTPRequest object to the insertForm.jsp ,

• A new entry is inserted into the USER table , the (generated)user_id is returned.

• The HTTPRequest object attributes and the user_id is collectively inserted into

the STUDENT_DETAILS table.

• The user_id is returned to the client and and a confirmation email is sent.

Actors

Student

Postcondition

After user registration, the appropriate HOME page is generated.



Snakes

27


OPERATION: REGISTRATION ( FACULTY ) :

DESCRIPTION:

Faculty registration , unlike student registration requires verification, hence, needs

human interception. The prospective-faculty sends his request to the management

user-in-charge , who reviews it before accepting the prospective-faculty into the

organisation.

Precondition

User requests to login to the system and fails / and clicks Register as a FACULTY


• The user is provided with the email address of the management user-in-charge for

recruitment.

• The faculty ( asynchronously) sends her CV by email.

• The user-in-charge after acknowledging the letter, creates a new USER object (

with active = false) and inserts the tuple in the USER database.

• The user-in-charge sends the user_id and the system generated password to the

faculty.

• The faculty logs in to the system using the newly acquired user_id and password,

consequently, the ACTIVE is changed to TRUE.

Actors

Faculty

PostCondition




Snakes

28


OPERATION: REGISTRATION ( MANAGEMENT) :

DESCRIPTION:

The prospective management user logs in only by verification from the director.

Precondition

The user registers her request by email to the 'Director'


• The 'Director' (also a management user , but highest in the hierarchy tree) creates

a new entry in the User table and sets it as ACTIVE= FALSE.

• He , then sends the user_id and (system generated) password to the prospective

management user.

• The management user, on a successful first time login, fills out his profile.

• Concurrently, the system also sets ACTIVE=TRUE.

Actors

Faculty

PostCondition




Snakes

29


OPERATION: LOGIN:

DESCRIPTION:

Only registered user can to Log in. Users use the USERID and PASSWORD pair to login to

the system.

The USER database is searched for the USERID , PASSWORD pair and SYSTEM access is

allowed if such a pair is found, else denied.

Actors

All Users.

• Student

• Faculty

• Management

• Administrator

Precondition

User requests to login to the system by POSTing the user_id and password.


• The table USER is checked whether the corresponding USER_ID and PASSWORD

pair is correct.

• If yes, then ACTIVE attribute is checked. If ACTIVE = TRUE, then the corresponding

HOMEPAGE is generated.

• Otherwise, ACTIVE is set to TRUE , and the “create profile” page is generated at

the client side

NOTE: ACTIVE = FALSE signifies First-time log-in



Snakes

30


Alternative Flow of Events

• USERID and PASSWORD is incorrect.

• System informs USER that incorrect password or user_id is entered.

Postcondition

After user login, the appropriate HOME page is generated.

OPERATION:LOGOUT:

Description

After the user ends working with the system, he logs out in order none can use his

profile to add new reading items or for any other reason to pretend someone else.

Actors

All Users

PreCondition

• The user requests to log out from the system.

Basic Flow of Events

• USER SETTINGS are saved.

• Session is invalidated.

POST CONDITION

• The user is logged out from the system.



Snakes

31


COURSE MANAGEMENT

OPERATION: TAKE A LECTURE.

Description:

The user( student) logins to the system, visits his home page. Opens the course and

then clicks on the Lecture URL to visit the corresponding Lecture Home Page.

Actor:

• Student

PreCondition

The user clicks on the Lecture name from the Lectures table(not database) in the user

interface . The lecture data is then requested from the Web Server.

Basic Flow of events

• Check whether the student is enrolled to the course to which the lecture belongs.

• If not, go to STEP 3 , else JUMP to step 4.

• (Enroll)Register for the Course

• Seek the data corresponding to the LECTURE_ID from the TABLE: LECTURE_DETAILS

• Display it as showLecture.jsp

Alternative flow of events

• The student is not enrolled to the corresponding course.

• Enroll.

Postcondition

Send the HTML response for the showLecture.jsp to the web browser(client side)



Snakes

32


OPERATION: CREATE COURSE

Description

The Management user logs in to the system and creates a new course to create the

new course.

Actors:

Institution management ONLY.

Precondition

The user requests the newCourse.jsp( to create a new course)

Basic flow of events

• The user fills out the details of the course.

• The details are sent to the web server as a HTTP Post ( directed to

insertCourse.jsp ).

• The web container created the HTTPRequest object and sends the request to

the insertCourse.jsp.

• The insertCourse.jsp interacts with the Database and enters the new entry into

the table COURSE.

PostCondition:

The User is shown the Course home page for the corresponding Course_id , which

was just created by her.



Snakes

33


OPERATION: REGISTER FOR A COURSE

Description:

The user visits/browses the ALL COURSES and opens the COURSE Home page and

requests to join.

Actors:

Student

PreCondition

• Request to enroll to a course. ( identified with Course_name and Course_id )


• The entry < Enrollement_id,Student-id,Course_id> is sent as HTTP Post to the insertEnroll.jsp in the web server from the web browser(client).

• The database connection is made and the the new entry is updated in the Enroll table.

• An email acknowledgement is sent to the User's inbox on success.

Alternate Flow of Events.

The user may have been removed from the course previously for inappropriate

behaviour, and hence wouldn't be allowed to register.

The user shall have to send the course enrollement request to the HOD by email.

PostCondtition

The User sees the course Home page.



Snakes

34


ASYNCHRONOUS MESSAGING SERVICE

OPERATION: Send a message.

Description:

The User of the system shall open the messaging service. Then on clicking the

COMPOSE button, Users will be shown his contacts, and The user is required to

selects the contact(s) she wishes to send a message.Or, he may skip the contacts

page.

Actors:

• Student.

• Faculty.

• Management.

• Administrator.

PreConditions

The logged in user opens the messaging service and clicks on 'compose a message'.


• The form to type in the message is generated with the FROM field set as the user's email address. The TO field is filled with the synchronously if the user has selected reicipents form the contacts list. Otherwise , she enters it manually.

• The form input fields are sent to the web server as HTTP POST ( directed to “sendEmail.jsp” )

• The web container creates the HTTPRequest object and calls the sendEmail.jsp

• sendEmail.jsp inserts the entry < message_id,sender_id,recipient email address,recipent_id,subject,time>into the message_details table.



Snakes

35


• SendEmail.jsp inserts the entry < message_id , body > into the message_body table.

• The INBOX page of the user's account is generated.

PostCondition

• The User is acknowledged by a message (in the inbox) whether the message was successfully sent.

Included use cases

• Reply to a message.

• Forward a message.



Snakes

36


OPERATION: Read incoming message.

Description:

The Users of the system is notified in the HOME page , the number of unread

messages.

The User opens the messaging service, browses to the INBOX, and clicks on the

message she wishes to read from the list of messages.

Actors:

• Student.

• Faculty.

• Management.

• Administrator.

PreConditions

The logged in user opens the messaging service and clicks on 'INBOX'.


• The user clicks on the “INBOX” from the MESSAGING SERVICE page .

• The Web container fetches the showMessageList.jsp and supplies the parameter <userid>

• showMessageList.jsp queries the database table message_details and returns the tuple(s) where <user_id> equals <recipent_id>

• The List of messages is ordered(descending order TIME) and generated dynamically corresponding to the attributes <sender, subject, time>

• The HTML reponse is generated and sent to the web browser.

• The User clicks on the message subject she wishes to view .



Snakes

37


• The request for showMessage.jsp ( along with <message_Id> using URL rewriting) is sent to the web Server.

• The Web container sends the HTTPRequest object( containing <message_id>) and queries the message_body for the corresponding message_id from the MESSAGE_BODY table.

• The dynamic web page is generated containing the message_body and sent to the client(Web browser).

PostCondition

• The User views the message in her web browser.

EXAM MANAGEMENT

OPERATION: TAKE AN EXAM

Description:

The user selects an exam and the system generates an interface for the user to

answer the examination.

Then on submission, the solution is passed as attributes to insertSolution.jsp , which

inserts the data into the database.

Actors:

Student.



Snakes

38


PreConditions:

The user requests an exam listed in the corresponding home page of the course.

Basic Flow of Events:

• The user visits the Course Home page .

• Clicks on the Exam from the list of available exams.

• The request is sent to the web server as HTTP POST.

• The web container creates a HTTPRequest object and sends it to insertExam.jsp , which in turn inserts the entry <solution_id,exam_id,user_id,solution> into the database table EXAM.

• The user is sent a notification as a message to the user. PostCondition

The web server generates the COURSE home page for the USER.

OPERATION: CREATE AN EXAM

Description:

The faculty who's administering the corresponding course visits the course home page

and fetches the new exam template .

PreCondition

The Following (minimal)information is provided to the system : Course_id and

faculty_id of the corresponding exam.

Actors

• Faculty

Basic flow of Events

• Course_id and Faculty_id is saved as session attributes.

• The user requests for the new exam template .

• The web server sends it to the web browser.



Snakes

39


• The user sets the questions and sends it to the web server as a HTTP Post .

• The web server creates a HTTPRequest object and forwards it to insertExam.jsp

• insertExam.jsp inserts the tuple <exam_id,course_id,faculty_id> into the EXAM_DETAILS table and <exam_id , questions> into the EXAM_QUESTIONS table.

Note: The questions are stored in CSV format.

PostConditions

New exam is created and shows up in the list of exams in the list of exams for the

corresponding course.



Snakes

40


FORUM MANAGEMENT

OPERATION: POST TO A FORUM

Description:

The User creates a post for a particular forum_id and topic_id (of database table

TOPIC) and inserts the post into the database table: POST

PreCondition

The Following (minimal)information is provided to the system : Course_id and

faculty_id of the corresponding exam.

Actors

1)Faculty

2)Student

3)Management

4)Administrator

Basic flow of Events

• user requests the createPost.jsp and send the <forum_id> and <topic_id> as request parameters.

• The create-a-new-post page contains the text field for the post, as well as topic_id and forum_id as HIDDEN FIELDS.

• On submitting the form , the parameters <post_data>,<topic_id> and <forum_id> is sent to the web server.

• The web container creates a HTTPRequest object and forwards it to insertPost.jsp

• insertPost.jsp inserts the request parameters to the database and returns an acknowledgement.



Snakes

41


PostConditions

The post is inserted into the database and it is up for viewing for any user reading that

particular forum topic.



Snakes

42


BLOG MANAGAMENT

OPERATION:POST TO A BLOG

Description:

The user view the blog and clicks on POST-TO-BLOG. The system checks if the blog

belongs to the User and then redirects her to the page where the user can create her

post. Then the post is added to the database. Finally, on re-opening the blog , the new

post shows up.

Actors:

• STUDENT

• FACULTY

• MANAGEMENT

• ADMINISTRATOR

PreCondition

The user requests the createBlogPost.jsp . The user_id and blog_id is known to the

system.

Basic flow of events:

• The client sends the user_id and blog_id to createBlogPost.jsp as a request parameter.

• The database table is checked whether there is a tuple containing the user_id and blog_id pair.

• If no such tuple is found then, an error message is sent to the client.

• Else, createBlogPost.jsp generates an interface to type in a new post at the client side.



Snakes

43


PostCondition:

The new post shows up in the blog.

ASSUMPTIONS AND DEPENDENCIES

• Staying synchronised with the vision of the project, registration of a student does not require

prior permission of any other user with a higher access privilege/role.

• Faculty members are registered strictly by the Management.

• The Virtual Classroom system is affiliated to an organisation who can appoint teachers from

anywhere in the world , but only after processing their application.

• As far as contacts are concerned, every student has every other “course-mate” as her 'contact'

which shows up in her conact list.

• The USER_ID is unique. The Student_id, faculty_id , management_id and admin_id references

UER_ID.The virtual classroom does not create discriminate on grounds of Grade or Standard,

the only grounds of distinction,however, are the courses being taken. In the implementation

phase of this project , it is being thought that every student will be given a rating based on a

specific criteria.

• The Messaging service is used for INTRA-APPLICATION electronic mail transfer . An email

notification will be sent to the public email account of recipient.

FINAL SRS

Documents

Transcript of FINAL SRS