2. 1.Introduction
SRS represents the overall purpose, interfaces, flow of the data and constraints for
the product. It also describes the functional and performance requirements as well as
the definition of the terminology.
SRS is the written agreement in between the customer & developer.
1.1Purpose
The purpose of this SRS is to present a detail description of the “E-
Learning” system.
It will explain the purpose and features of the system, the interface of the
system, what the system will do and how it will benefit the user.
This website will mainly be designed for computer students who want to take
help in their course. It will prove to be helpful to students in their studies as well
as some other mock activities
1.2 Scope
This website can be used in educational institutions as well as for personal
use.
It can be used anywhere anytime as it is a web based application.
Self learning of course and self-evaluated material which are relevant and
easily understandable and accurate.
Students can save the material.
3. 1.3 Definitions and Abbreviations
DEFINATIONS/TERMS/ABBREVIATIONS DESCRIPTION
ADMINSTRATOR (Database administrator)he is the controller
of the entire website and maintaining all
records of the functionalities and user.
STUDENT People who can study the tutorial and can
watch related videos.
IE Internet Explorer.
SERVER The main computer on the network.
SRS Software requirement specification.
HTML Hypertext markup language.
PHP
TCP/IP Transfer Control Protocol/Internet Protocol
OS Operating system
URL Uniform Resource Locator
HTTP Hypertext Transfer Protocol
2. General Description
2.1Product Functions
The application will allow user with specific roles (administrator & student). A
summary of major function that application will perform.
Functions available to the administrator:
Login to the function page
View information of login user
View feedback
Functions available to the student:
Login
Can register himself/herself
Can give feedback
Access study material
Logout
4. Functions available to the guest:
Can view the site
Can know about the website
2.1.1 Hardware Interface
Server Side:
RAM: 512 MB
HDD: 20 GB or more (Free space excluding data size)
Processor: 1-2 GHz (P4) or onwards
Client Side:
RAM: 128 MB
HDD: 10 GB or more (Free space excluding data size)
Processor: 450 GHz (P2)
2.1.2 Software Interface
Server Side:
OS: Windows Server 2000 or onwards
Web Server: wamp server
Client Side:
OS: Any OS
Browser: Any browser compatible with IE 5.0 or onwards
2.1.4 Communication Interface
Client on Internet will be using HTTP/HTTPS protocol.
Client on Intranet will be using TCP/IP protocol.
2.2 User characteristics:
User of this website must have knowledge of computer fundamentals.
5. Administrator:
Administrator of this website has the top most level in our
system and authorizes all work related to access of study
material.
Student:
Students have the access to study material; they can interact
through the interface design by reading the chapters and
watching related videos.
2.3 General Constraints
1. Criticality of the Application: The server application will be available
24 X 7.
2. Safety and Security Considerations: The password and a valid
username are the security issue.
3. External users and Alumni will not be able to gain full functionality of
the website.
4. Any substantial enhancement in website will require approval of the
administrator.
2.4 Technologies Used
Front End: JavaScript
Back End: PHP
Design Tool: HTML
Web Server: WAMP SERVER
Others: Microsoft Frontpage
3. Specific Requirements
3.1 Functional Requirements:
6. Functional requirements can be provided using various use cases:
Use case diagram for student
Student
Use case diagram for Admin
Admin
USE CASE:
Table 1: Use Case of Register Function
Use Case No 1
Use Case Name Register
Login
Register
Feedback
Access study
material
Logout
Login
View details of
registered user
Feedback
Access study
material
LOGOUT
7. Actors: Guest
Descriptions This module helps the users to create new accounts.
Input Name, user id, password, date of birth, e-mail, mobile
number, security question, security answer
Normal Course Events 1. Users enter their e-mail address.
2. Users enter their passwords.
3. Users enter the security question.
4. Users enter other required Information.
5. Users click register button.
6. System connects to database.
7. User is registered.
Alternative Courses 1. Same Login-id exists in database
2. Error message appears.
3. Continue with step 1 in the normal course
events.
1. An error may occur during the database
operation.
2. System shows error messages.
Output New user account will be created.
Table 2: Use Case of Sign in Function
Use Case No 2
Use Case Name Sign In
Actors: Students, Administrator and other
existing users.
Descriptions This module helps the administrator and students to
login.
Pre-conditions The user must be a member of the system.
Input Login id and password.
Normal Course Events 1. Users enter their login-id.
2. Users enter their password.
3. Users click login button.
8. 4. System connects to database.
5. Homepage displayed.
Alternative Courses 1. User enters incorrect user name and/or
password.
2. Error message appears.
3. Continue with step 1 in the normal course
events.
4. An error may occur during the database
operation.
5. System shows error messages.
Output User homepage will be displayed.
Table 3: Use Case of Sign Out Function
Use Case No. 3
Use Case Name Sign Out
Actors: Students and Administrator
Descriptions This module helps the administrator and students
to sign out.
Pre-conditions The user must be Signed in to the website.
Normal Course Events 1. The website users click to Sign Out button.
2. DB connection terminated.
3. The website users Sign out successfully.
4. The website will be directed to homepage.
Output Website homepage will be displayed.
Table 4: Use Case of Password Recovery Function
Use Case No 4
Use Case Name Password Recovery
Actors: Students and Administrator
9. Descriptions This module helps the students and administrator to
retrieve their forgotten password.
Pre-conditions The user must be a member of the system.
Input Security question and corresponding answer.
Normal Course Events 1. User click on Forgot Password button.
2. User selects the security question.
3. User inputs the corresponding answer.
4. Password is retrieved.
Alternative Courses 1. Wrong answer is entered.
2. Error message appears.
3. Continue with step 2 in the normal course
events.
Output User homepage will be displayed.
Table 5: Use Case of Change Password Function
Use Case No 5
Use Case Name Change password
Actors: Students, Administrator .
Descriptions This module helps the administrator and
students to change password.
Pre-conditions The user must be logged on to the system.
Input Text
Normal Course Events 1. User clicks on change password button.
2. User enters the current password.
3. User enters the new password.
4. User confirms the new password.
Alternative Courses 1. In case user enters a wrong confirmation
password.
2. An error message appears.
Output Password is changed.
10. 3.2 Non-Functional Requirement:
3.2.1 Availability:
The availability of the “E- LEARNING”are up to the internet connection of the client
Since this is client server related website,website shall be attainable all the time.
User should havean account to view all the contents of all subjects, if the user does not
have an account,he/she should sign up tothe systemclicking the sign up link from the
home page for the availability of the “ E- LEARNING”.
3.2.2Security:
The authorization mechanism of the system will system will block the unwanted attempts
to the server and also let the system decide on which privileges may the user have .
3.2.3 Reliability:
All the information regarding the tutorials over different components is
unambiguous..
3.2.4 Maintainability:
The requirement modules that are explained inthis document are enough to
Satisfy the customers’ needs and wants .The maintenance can be easily done by
integrating new modules and offering new software solutions for the system . The
product is maintained as all the access right distributed by the admin to its users.
SdS
(System Design Specification)
1. Introduction
1.1 Purpose
The SDS shows how the software system will be structured to satisfy the
requirements identified in the SRS.
It is a translation of requirements into a description of software structure,
software components, interfaces and data necessary for the implementation
phase.
11. Thus, SDS is the blue print for the implementation activity.
1.2 Scope
This website can be used in educational institutions as well as for personal
use.
It can be used anywhere anytime as it is a web based application.
Self learning of course and satisfied material which are relevant and easily
understandable and accurate.
Can save the study material and notes can be used at a later stage.
1.3 Definitions , Terms , Acronyms and Abbreviations:
DFD:- Data Flow Diagram
E-R Diagram:- Entity Relationship Diagram
2.2.1 ACTIVITY DIAGRAMS:
Fig: Activity Diagram for Forgot Password
User click on Forgot Password
button.
Display the security question.
Fill the corresponding answer.
12. [NO]
[YES]
Fig: Activity Diagram for Change Password
Verify
the
answer
?
Error message:
Answer do not match!!!!!
Password is displayedon
the screen
User click on Change
Password button.
Enter current password.
Enter new password.
Re-enter the password.
13. [NO]
[YES]
Fig: Activity Diagram for Subject
Confirm
new
password
?
Error message:
Password doesn’t match.
Password is changed.
User click on Subject
link.
Select your Chapter
Revise Watch videosStudy
14. Fig: Activity Diagram for Study Material
Redirect to
window
User click on Study
material
Select your
chapter/topic.
Re-direct to
Pages
15. Fig: Activity Diagram for Sign in
Is it
correct?
Re-direct to
Homepage.
Error message:
Please fill valid entries.
Enter the email id and
password
User click on Sign in
button.
16. Fig: Activity Diagram for Sign Out
3.Data design
3.1 Database Description Tables:
Table 1: Register Table
Name Varchar2(20) Not NULL Name of the student.
Id Varchar2(20) Primary key Name of the user by
User click on Sign
out button.
Re-direct to Website.
17. which he will be
contacted.
Dob date Not NULL Date of birth of user
Sex Varchar(10) Not NULL Gender of user
Password Varchar(15) Not NULL Password of user
account
Mobile no. Number(10) Not NULL Mobile no. of
student.
Email_id Varchar2(20) Not NULL Email id of student.
Security_ques Varchar2(20) Not NULL Security question of
the student
Security_ans Varchar2(20) Not NULL Security answer of
the student
Table 5: Feedback Table
Id Varchar2(20) Primary key Feedback id of
student
User_id Varchar(15) Not NULL User id of student
Feed Varchar2(60) Not NULL Feedback of user
18. 3.2 ER – DIAGRAM
1
M
M 1 1
1 1
M
FEEDBAC
K
STUDE
NT
STUDYMATER
IAL
Administrato
r
Giv
e
Vie
w
name
DOB
Userid
Password
email
A_id Passwor
d
Acces
s
Subject
subject
chapte
r
Useri
d
Passwor
d
Comment
materialtyp
e
Logini
d
Feedbac
k no.
read
19. conclusion and references
1. CONCLUSION
There is a proper interaction between the Admin and the Employees. All the
activities can be carried out effectively without losing its transparency. This
on-line system will be of great help in carrying out the registration process,
interaction between two different users(i.e Admin and students),managing
their work and their details.
This system will save time, and the biggest advantage of being it web based.This
web based system will provide better prospective for the enhancement of study
methods regarding to quality and transparency.
2.Limitations of the System
This system can’t provide on line video interviews conferencing.
This system not providing online chatting facility
This system developed only one language (en-us) English and not support
different language.
3.Future Scope for Modification
This software can be easily upgraded in the future. And also include many more
features for existing system.
20. In future this system will provide online video conferencing bringing
people together who are geographically separated.
E-Work Solution will provide greater level of customizations suitable to
user’s requirements
