SRS Of Student Portal

8/19/2019 SRS Of Student Portal

1/25

STUDENT PORTAL Software Requirements Specification

(Approved by AICTE, Ministry of HRD, Govt of India &DTE, Govt of Haryana

and A liated to DCR University of S ien e andTe !nolo"y, M#rt!al, Sonepat$

Submitted by: Group 9


2/25

INTRODUCTION

The purpose of this report is to specify the softwarerequirements of the project on “Student Portal”.

The project “Student Portal” system is being developedfor the need of organization and student

This is one of the best efforts by us to prove that howonline system can be helpful in such organization

The objective is to create a website which can helpstudents to view academic record online and to reducepaper wor! as it is also easy to access online

"

#arch $%& "'$(


3/25

Product Perspective

Student )ortal is applicable to this fast growing worldwhere there is a need to communicate by sharinginformation

Today we need all relative information in less time buteasily

This project has different modules li!e new *ser login&+ownloading ,iles& -ttendance management& .ibrary&,ees / ,ine& -ptitude test& Syllabus etc

%

#arch $%& "'$(


4/25

Product eatures 0

#arch $%& "'$(

- summary of product features in the proposed systemfollows:

1.og in 2Student and teacher login31Retrieve password1Registration procedure1Time table14otes56oo!s1 -ttendance

178amination System1,orum


5/25

!"AT IS SRS#

#arch $%& "'$(

- so$t%are re&uire'ents speci$ication 2SRS3 is adescription of a software system to be developed& layingout functional and non functional requirements& and mayinclude a set of use cases that describe interactions theusers will have with the software

Software requirements specification establishes the basisfor an agreement on what the software product is to do aswell as what it is not e8pected to do


6/25

NEED OR SRS (

#arch $%& "'$(

Software requirements specification permits a rigorousassessment of requirements before design can begin andreduces later redesign ;t should also provide a realisticbasis for estimating product costs& ris!s& and schedules

The software requirements specification document enlistsenough and necessary requirements that are required forthe project development


7/25

User Classes and C(aracteristics

Student Lo)in,irst is Students& which have limited facilities in appro8imate all

modules Students will not have write permission in different fieldssuch as -ttendance ;nfo& library ;nfo& Result etc Student can onlyupdate some personal information

Teac(er Lo)inSecond is Teachers& who have to upload some set of information suchas Result& 4otes& 6oo!s and attendance for all students They canmanage the student user

Ad'in Lo)in.ast user is admin& who manages the student and teacher user -dminmay upload some data such as yearly fees& fine information and more

<

#arch $%& "'$(


8/25

=

#arch $%& "'$(

,unctional requirements may be calculations& technicaldetails& data manipulation and processing and other specificfunctionality that define what a system is supposed toaccomplish ,unctional requirements are supported by nonfunctional requirements& which impose constraints on the

design or implementation

,unctional requirements define %(at a system is supposedto do and non functional requirements define (o% a system

is supposed tobe

unctional * Non+ unctional re&uire'ents


9/25

S,ste' eatures

Lo)in

.ogin is one of the module in this project which is somehowmost integral to the system Three types of user can loginadministrator& teacher and student ;t chec!s for a validcandidate when the user enters his user id and password

Retrieve- or)et pass%ordGiven that a user has registered& then the user should be able

to retrieve his5her password by email

,unctional Requirements:>alidator .ogin ?hec!er

9

#arch $%& "'$(


10/25

S,ste' eatures

Re)istration Registration module mainly provides a form to the user to fill

the required necessary details and submit to complete theregistration process

,unctional Requirement:;t is divided into following functions:

*nique ;d ?hec!er #ailing System

$'

#arch $%& "'$(


11/25

S,ste' eatures

Ti'e Ta le This module allows the concerned authorities to upload thetime table

,unctional Requirement:

*pload

Notes-/oo0Teachers may upload some reference boo!s and notes that

may serve a great purpose to the students ,unctional Requirement:

*pload5+ownload facility

$$

#arch $%& "'$(


12/25

S,ste' eatures

AttendanceTeachers upload the attendance for each student in a batchwee!ly which is displayed on the student portal This modulemay help students as they get to !now their currentattendance

,unctional Requirement:*pload

$"

#arch $%& "'$(


13/25

S,ste' eatures

E1a'ination S,ste'This module provides the students the ability to assess theiraptitude and technical s!ills The results of the test will bedisplayed immediately after they finish the test


;d ?hec!er #ailing SystemResult ?hec!er

$%

#arch $%& "'$(


14/25

oru';n this module& user can upload any query& doubt or questionand other users can provide solution5answer for the specifiedquery


;d ?hec!er #ailing System

-nswer ?hec!er

+ownloader

$0

#arch $%& "'$(

S,ste' eatures


15/25

Constraints $

#arch $%& "'$(

The proposed system is basically being designed for aninstitution@ence& There may e8ist some constraints such as

G*; is only in 7nglish

.ogin and password is used for the identification of usersAnly registered teachers and students will be authorized to use

the services of this system


16/25

Non$unctional Re&uire'ents

Safety RequirementsThe system should be secure to threats li!e hac!ing and

viruses to the highest degree possible

Security Requirements+ S2L Server aut(entication3 ;n this case& SB. Serverrequires that a user specifies a name and password at thetime when connection is attempted

$(

#arch $%& "'$(


17/25

SO T!ARE RE2UIRE4ENT $<

#arch $%& "'$(

Operatin) S,ste' Cindows < or aboveScriptin) Lan)ua)e DavaScript

Inter$ace @T#.& ?SS

Server -pache Tomcat ( ' and -bove

/ac0+End Tool #ySB.

Tec(nolo), D"77 2DS) and Servlet3

/ro%ser ;7( or above

or Develop'ent+

User end+Operatin) S,ste' Cindows E) Service )ac! " or above

/ro%ser ;7( or above


18/25

"ARD!ARE RE2UIRE4ENT $=

#arch $%& "'$(

or Develop'ent+

Processor ?ore " +uo or aboveRA4 #inimum "G6 2for D+F& -pache Tomcat& #ySB.&

6rowser3

"DD #inimum $G6 of @ard dis! space

End user+Processor ?ore " +uo or above 2depending upon availability3

RA4 #inimum $"#6

"DD #inimum $"#6 of @ard dis! space


19/25

So$t%are 2ualit, Attri utes

Reusa ilit,Reusability defines the capability for components and

subsystems to be suitable for use in other applications andin other scenarios -s our product has different smallermodules2as 78amination System& ,orum etc 3& it will be

easy to reuse them anywhere else

Usa ilit,This product will have good user interface clear and easy to

use )ages will include buttons and radio buttons& and thescreen layout will also be suitable

$9

#arch $%& "'$(


20/25

So$t%are 2ualit, Attri utes

4odi$ia ilit,This product will have nice modifiability because different

functionalities will be divided into modules ma!ing themeasy to modify

4aintaina ilit,#aintainability is the ability of the system to undergo changes

with a degree of ease These changes could impactcomponents& services& features& and interfaces when

adding or changing the functionality& fi8ing errors& andmeeting new business requirements Aur product will havegood maintainability as it is divided into modules& thereforewe can easily ma!e any changes to this smaller parts

"'

#arch $%& "'$(


21/25

Develop'ent 4et(ods

The Student )ortal Cebsite will be written inDS) and @T#. languageThe development environment will be4otepad or 4otepadThe Student )ortal Cebsite will be tested onCindows < platform

"$

#arch $%& "'$(Hslide TitleI J ?A4,;+74T;-. "'$"


22/25

,orum ""



23/25

?ontK "%



24/25

?ont "0



25/25

CORE JAVAT@-4F LA*

SRS Of Student Portal

Documents

Transcript of SRS Of Student Portal