lOMoARcPSD|17679483

Ums - software requirement specification srs

Software Engineering (Lovely Professional University)

StuDocu is not sponsored or endorsed by any college or university

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)
 lOMoARcPSD|17679483

SOFTWAREREQUI
REMENTSSPECI
FICATI
ON

Software Requirements
Specification

For

LPU UMS

Submitted by: - Prabhleen Kour

Roll No: - A-04 (11509802)

Sec:-K1512

Submitted to:-Mrs. Preeti Gupta

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

Lovely Professional University

i
i
Cop
yri
ght©2002b
yKa
rlE.Wi
ege
rs.Pe
rmi
ssi
oni
sgr
ant
edt
ous
e,modi
fy,a
nddi
st
ri
but
ethi
sdoc
ume
nt.

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

Table of Contents

1. Introduction................................................................................................................................

1.1 Purpose.................................................................................................................................1

1.2 Intended Audience and Reading Suggestions......................................................................1

1.2 Document Conventions, Definitions:...................................................................................1

1.3 Scope…………………………………………………………………………………… 2

2. Overall Description..................................................................................................................2

2.1 Product Perspective..............................................................................................................2

2.2 Product Features...................................................................................................................2

2.3 User Classes and Characteristics.........................................................................................3

2.4 Operating Environment........................................................................................................4

2.5 Design and Implementation Constraints..............................................................................4

2.6 User Documenttion..............................................................................................................4

2.7 Assumptions and Dependencies..........................................................................................4

3. Specific Requirements.............................................................................................................5

3.
1 Da
taba
seSt
ora
ge.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.5

3.
2 Func
it
iona
l…………………………………….
..
…………………………………….
.
..
.….
.5

4. External Interface Requirements...........................................................................................7

4.2 Hardware Interfaces.............................................................................................................7

4.3 Software Interfaces..............................................................................................................7

5. Other Nonfunctional Requirements.....................................................................................14

5.1 Performance Requirements................................................................................................14

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

5.2 Safety Requirements..........................................................................................................14

5.3 Security Requirements.......................................................................................................15

5.3 Software Requirements......................................................................................................15

5.3 Hardware Requirements.....................................................................................................15

6. Other Requirements..............................................................................................................15

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

CERTIFICATE: -
This is to certify that the thesis entitled “LPU UMS” submitted by Prabhleen kour, in
partial fulfillment of the requirements for the award of Degree of Bachelor of
Technology in Computer Science and Engineering at Lovely Professional University,
Punjab is an authentic work carried out by them under my supervision and guidance.
To the best of my knowledge, the matter embodied in the thesis
Has not been submitted to any other university institute for the award of any Degree.

Date:
1/03/2017

ACKNOWLEDGEMENT:-

I own a great many thanks to a great many people who helped and supported me
during my project work. I express my sincere gratitude Mr.Vijaya Raju
Sir for guiding and correcting various documents of mine with attention and care. He
has taken pain to go through the project and make necessary correction as
And when needed. Finally I would like to thank and friends for their help and
assistance all through this project.

ABSTRACT:-

Lovely Professional University, Punjab is one of the reputed institutions for technical
education in India. The main purpose of the project is intended to develop
A portal for management of Times of India a web based news. The portal provides a
suitable and easy display for which large population around the world can learn or
will have the knowledge about the world. Basically this is a crowd sourcing
newspaper. The idea is anyone can send a news item using their web based gadget
which is managed by administrator to whom the editor’s panel kept in charge for this
to make it visible for the masses. This portal is developed using HTML, PHP & CSS
technologies and SQL Server.

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

Entity Relationship Diagram For UMS: -

ADMI
N

`
Lo
ginID

St
aff St
ude
nt/
Use
r

Announc
e
H Re
sul
t ment
Hal
lti
cke
t Sa
lar
y
ge
nera
ti
on
Dail
y
Act
ivi
ty
Pre
viou
spaper
s Reg
.
f
orm

Ac
ti
vit
y Pr
ofil
e
Updat
e
resul
t Annou
nc
emen Admi
tca
rd
t
Na
me Addr
ess
Re
crui
tme
nt
for
m

I
dent
it
y

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

I. INTRODUCTION  Dat
aStor
ageLaye
r:-Thi
ste
rmr
efe
rtowhe
rea
llt
he
da
taisbe
ings
tor
ed.
Purpose:-
 Dat
a flo
w Di agram: - I
ts ho
w t he
The main objective of this document is to illustrate r
ela
ti
ons
hiporda
taflo
wbet
weent
heent
it
ie
s.
the requirements of the project University
Management System .This document describes the  Bool
ean:-At
rue/
fal
ses
tat
eme
nt.
design decision, architectural design and the
detailed design needed to implement the system. It  I
nter
face
:-Some t
hin
gusedt
ocommuni
cat
e
provides the visibility in the design and provide the a
crossdi
ffe
rentmedi
ums
.
information needed for software support .The
document gives the detailed description of both  Uni
quekey
s;-Us
edt
odi
ffe
rent
ia
tee
nti
ti
es
functional and non-functional requirements i
ndata
bas
e.
proposed by the client.
 Lay
ers:- Re
pre
sent
sthe s
ect
ion of t
he
A. Intended Audience and Reading pr
ojec
t.
Suggestions
 SQLSe
rver
:-As er
verus
edt
ost
oret
heda
ta
The document is intended for all the stakeholders’ customer i
nawel
l-
organi
zedfor
mat
and the developer (designers, testers, maintainers). The reader
is assumed to have basic knowledge of all the algorithms used
to reduce the complexity and also have knowledge of all the
basics which are used in the development and maintenance of
C. Project Scope: -
the project or an online system and also some basic knowledge
The online university management system is developing for
of Entity Relationship diagrams
the schools of the university and used to replace the old paper
B. Document Conventions, Definitions:- work system. The software supports a computerized university
management system network. The network enables Teachers,
The f oll
owinga ret he li
stof c onventions a nd students to complete simple tasks via U.M.S that may be
easily accessed to the authorized members at any time. The
acronymsus edinthisdocume ntati
on. UMS identifies a USER by a login id which provided by the
administrator and password. It collects information through
 Admi ni
st
rat
or:-A lo
ginidrepr
e s
enti
ngaus e rwit
h the database by following the login id (e.g., profile,
us
eradmini
st
rat
ionpr
ivi
le
gestothesoft
ware. attendance, examination, fees payment). The software must
 Us er
:-Ag e
nerall
ogi
nidass
ignedtousers
. handle concurrent accesses to the same account correctly.

 Cl
ie
nt:-I
nte
nde
dus
ersf
ort
hes
oft
war
e.

 SQL:-
Str
uct
uredQuer
yLa nguag
eusedt
ore
tri
eveor
st
oret
heinf
ormat
ioni
nthedata
base
. II. OVERALL DESCRIPTION

 ASP”
-Acti
veSe
rve
rPag
es:AWebpag
efor
mat
tedon
t
hese
rve
randde
li
ver
edt
otheb
rows
er.
A. Product Perspective
 Use
rInte
rfa
ceLayer
:-Thesec
tionoft
heass
ignme
nt
r
efe
rri
ngtowhatt
heuse
rint
era
ctswit
hdir
ect
ly.

 Appli
cat
ionla
ye r
:-Thissec
ti
onref
err
ingt
hetheWe
b
The proposed University Management System is an
Ser
verwhereallcomputa
ti
onsar
ecomplet
ed.
online University management system .This system
will provide a view submit online payment

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

uploading various documents and other resources.  Insert/delete/edit the information of

This view will be based on the categories like available on the UMS.
attendance view and daily activities. Further the
university management staff (faculty) can  Can access all the accounts of faculty
add/remove/update the resource or an automatic and the students.
removal of accessing features when the time limit
completes. The features that are available to the faculty
are:
The system have also an ADMIN who have full-fledged
rights with the regards to managing resources across branches.  Can mark the attendance of the
The user can view can submit, online payment, uploading
students online.
various documents and information about their account etc.
there are basically two types of users one is students and other  Can create the continuous
are faculty members. Each user facilitates with a different assessments for the students.
account number having a profile along with a password for
private use. The two type of user differ from each other due to  Can view the online attendance off
the accessing limits to online University Management System the students.

 Can submit the questions papers

online.
B. Product Feature:-
 Can upload marks, assignments,
There are three types of different user who will be reading material for the students.
using this product
The features that are available to the Students
So, every one ha the different interfaces to use the are:
interface..
 Can view the different types of the
reading material and assignments are
available in their account.
 Can pay their fees by online mode.

 University chancellor. whowi

llbeacti
ng  Can view their marks as well as
asthea dminist
rat
or attendance.
 Faculty Members who a r
esecond l
eve
l
usersaccessi
ngUMS.  Can view and modify it profile but
cam modify it to some limits range.
 Students of the university who wi
llbe
acces
singtheUMSonl ine

The features that are available to the

administrator are:
C. User classes and characteristics:-
 Can create or delete the account.
 Can view the accounts. Therear
ev ar
iousbyv ari
oususer
sforkindofus er
f
ortheproduct.
Usua l
lywebproduct
sarevis
itedb y
 Can change the password. var
ioususerfordiffe
rentrea
sonsvisi
te
ddi ffe
rent
re
asons.
 Can hide any kind of feature from
both users. Theu
seri
ncl
ude
s:-

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

 Chance llorwho wi llbeac ting ast he 1) Description and priority:-

cont rollera nd he wi l
l ha vea llthe
privil
eg esofadmi ni
st
rat
or. ProposedData
baseisint
endedt
ostor
e,re
tri
eve
,
 Faculty members who will be using update,andmani
pul
a t
einfor
mat
ionrel
at
edto
the above features by accessing the UMS univer
sit
ywhichinc
lude
online.
 Student swhowi llbeusin
gt hea bov e  Profil
eofbothusers
featuresb yac
c e
ssingtheUMSonl i
ne  Staffi
nformati
on
 Studentdeta
ils
 Mya cc
ount
 Onlinep a
yme nt
Operating Environment:-  Viewa tt
endance/
marks
/upl
oadi
ngofma
rks
anda ss
ignments.
The pr oduc t will be ope r
ating in wi ndows
envir
onme nt.Al s
oitwillbecompa ti
blewit
ht heIE
6.0.Mostoft hefeat
ureswil
lbec ompa t
ibl
ewi t
hthe
Mo zi
ll
aFi ref
o x& Ope ra7.
0orhi gherver
sion.The
onlyrequireme nttousethisonlineproductwould
betheinternetconnect
ion Stimulus / Response Sequences:-

Design and Implementation Constraints: - Responses for Administrator:

The Product is developed using ASP. The backend database
Thea dmi nis
tratorc a
nLo gina ndLo gout .Whe nthe
for this SQL Server. The product is accomplished with login
Admi nis t
ratorLo g sint otheUni versit
yma nageme nt
facility so that specific function is available to specific
student. system.Thes y ste
m wi l
lchec kforv al
idityofl ogin
.IftheLo gina ndpa sswor da revalid,ther esponset o
User Documentation:-
thisa ctioni sthea dmi ni s
tratorwillbea bleto
modi fy,vi e
w,a dd,de le ti
nga nda llothe rfunctions
Thepr oductwi l
li nc l
udeu serma nua l
.Theus er
thatc anbepe rfor
me dont heda ta
ba se
ma nualwi lli nclude pr oduc to verview,c ompl et
e
configurat
ionoft heus eds oftwa r
e( sucha sSQL
ser
v er)
,t echni c
alde tai
ls,ba ckup pr ocedur ea nd
contacti nfor mati
on whi ch wi lli nc l
ude e ma i
l
Functional requirement:-
address.Thepr oduc twi llbec ompa tiblewi t
ht he
Int
e r
netExpl orer6.0orhi ghe r
.Theda t
a bas
e swi l
l
Thi ss ectiongi vesthel is
tofFunc tiona land
bec r
e a
tedi ntheMi crosoftSQLs erver2000.
nonf unc tionalr equir
e me ntswhi cha rea pplicableto
theUni v ers
ityMa nag e mentSy ste
m
Assumptions and Dependencies:-
The product needs following third party product.
 Microsoft SQL server to store the database.
 ASP to develop the Product Interface Requirements:-
.
Thi
ssect
iondesc
ribe
sho wt hes
oft
war
ei nt
erfa
ces
wit
hothe
rs of
twar
epr oduc
tsoruse
rsforinputor
out
put
.
III. SPECIFIC REQUIREMENTS:-
A. Database Storage:- User Interfaces

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

10

Thi
ss e
cti
onDes
cri
besho
wthi
spr
odu
cti
nte
rfa
ces I
nputRe
qui
reme
nts
:-
wit
htheuser

GUI
:-

Describes the graphical user interface if present. Us erac ce ss:

This section should Ea chf ac ultyme mbe ra nds tudentisa ssi
gne da
Includeas etofs creendumpsormoc kup sto uniq uei de nti
fie rupona dmi ss
iont otheuni versi
ty.
il
lustrat
eus erint
e r
f a
cef eature s. Bo thoft he m mus tkno wt his.Thisi dentifyingk e
y
1.De scription ma pst oa llhis/he rregistr
ationr e
c ordinfor mationin
Theu seri nterf
acemus tbec ustomi zabl eb yt he thema i
nr egistrati
ons ystem.Admi tt
eda ndc ur r
ent
admi nist
r at
or stude ntsha vet heironliner egist
rationa ccountsa l
so
enabl ed .Suc ha ccountma ybedi sableddur ing
2.Cr iti
cality his/he rs t
a ya sama triculateds t
ude ntand/ora fter
Thisi s
suei se s sentialtotheo veralls ystem.Al lthe gradua ti
onors epa r
ationFr omt heUn iversity
.
modul e
spr o vide dwi t
ht hesof t
wa remus tfitinto Upl oa din gofda ta
thi
sgr a
phic a lus erinte r
facea nda cc ompl is
ht ot he Ea chf ac ultyme mbe rs houldf aci
litat
eswi t h
standa r
dde fined . uploa di ngofda tasucha ssignme nts,theirma rksa nd
otherki ndofr e adingma t
erial.Simi l
arl
ys uc hof
3.Te chnic ali ssue s op t
ionmus tbepr es
entt heirforstude ntstoupl oad
Inor dertos ati
s fythi srequir
e me ntt hede sign theira ssignme nt s.
shoul dbes impl ea nda l
lthedi ffer
e nti nte r
faces Onl inep ayme nt
shoul dfoll
o was tanda rdtempl ate.The rewi l
lbet h
e Thes tude ntss houldha vethef aci
litytop a ytheir
pos s
ibili
tyofc han gingc olor
sa ndi ma g es,plus payme ntonl i
nea nyki ndofun i
versit
yf eec hargesso
swi t
chingbe twe eni nt er
faceswi t
ht hemi nimum asthe res houldbef ac i
lit
yt oc heckwhe therthe
impa ctfort heus ers. entere dc odef orpa yme nti sav al
idc odeorno torin
simpl ewor dapr operv ali
da ti
oni srequired .
4.Ri sks
Tor educet hec ircums tancesunde rwhi cht his
requireme ntmi ghtno tabletobes atisfied,a l
lthe
designersmus th avebe endeve l
ope dwe bs ite
s
previouslya ndt heymus tbea wa reofht ml
restr
icti
ona ndc ros sbr o
ws ersimpl e me nt at
ions
befores t
artin gt hede si
gning.I nor de rtor educ et he
proba bil
it
yoft hisoc curre
ncet hee ntirede s i
gnt eam
willbet raine di nba si
cht mlde v el
opme nta nd
ma crome diafir ewor ks,thi
stoolwi llbeu sedins tea
d
ofPho t
oshop.

5.
Depe
nde
nci
eswi
tho
the
rre
qui
reme
nts

Al
luserint
erf
acesshouldbeabl
etoi
nter
actwit
h
t
heusermanageme ntmodul
eandapartofthe
i
nte
rfa
cemus tbede di
cat
edtot
helo
gin/l
ogout
module

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

11

IV. EXTERNAL INTERFACE REQUIREMENTS

I
tinc
ludet
henon–f
unc
ti
ona
lre
qui
reme
nts
.

A. User Interfaces

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

12

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

13

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483
Data Flow Diagram : -
Data flow diagram is a graphical representation of data flow
in an information system. It is capable of depicting incoming
data flow, outgoing data flow and stored data. The DFD does
not mention anything about how data flows through the
system.
There is a prominent difference between DFD and
Flowchart. The flowchart depicts flow of control in program
modules. DFDs depict flow of data in the system at various
levels. DFD does not contain any control or branch elements.
Types of DFD Data Flow Diagrams are either Logical or
Physical.
 Logical DFD - This type of DFD concentrates on the
system process and flow of data in the system. For example in
a Banking software system, how data is moved between
different entities.  Physical DFD - This type of DFD shows
how the data flow is actually implemented in the system. It is
more specific and close to the implementation.
Symbols used in DFD
Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)
14
Importance of DFDs in a good software design
The main reason why the DFD technique is so popular is
probably because of the fact that DFD is a very simple
formalism – it is simple to understand and use. Starting with a
set of high-level functions that a system performs, a DFD
model hierarchically represents various sub-functions. In fact,
any hierarchical model is simple to understand. Human mind
is such that it can easily understand any hierarchical model of
a system – because in a hierarchical model, starting with a
very simple and abstract model of a system, different details of
the system are slowly introduced through different hierarchies.
The data flow diagramming technique also follows a very
simple set of intuitive concepts and rules. DFD is an elegant
modeling technique that turns out to be useful not only to
represent the results of structured analysis of a software
problem, but also for several other applications such as
showing the flow of documents or items in an organization.
 lOMoARcPSD|17679483

15

Unified Modeling Language (UML):-

UML, as the name implies, is a modeling language. It may be

used to visualize, specify, construct, and document the
artifacts of a software system. It provides a set of notations
(e.g. rectangles, lines, ellipses, etc.) to create a visual model of
the system. Like any other language, UML has its own syntax
(symbols and sentence formation rules) and semantics
(meanings of symbols and sentences). Also, we should clearly
understand that UML is not a system design or development
methodology, but can be used to document object-oriented and
analysis results obtained using some methodology.

Coding:-
The objective of the coding phase is to transform
the design of a system into code in a high level
language and then to unit test this code. The
programmers adhere to standard and well defined
style of coding which they call their coding
standard. The main advantages of adhering to a
standard style of coding are as follows:
 A coding standard gives uniform appearances
to the code
Written by different engineers
 it facilitates code of understanding.
 promotes good programming practices.

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

16

For implementing our design into a code, we  Application: ASP (Active Server Pages)
require a good high level language. A programming
language should have the following features: .
Characteristics of a Programming Language
 Readability: A good high-level language will V. OTHER NONFUNCTIONAL REQUIREMENTS
allow programs to be written in some ways that A. Performance Requirements
resemble a quite-English description of the
underlying algorithms. If care is taken, the coding Thepropo sedsystemt hatwea r
eg oin
gt odev
elop
may be done in a way that is essentially self- wil
lbeu se dastheChi efpe r
forma ncesyst
em wit
hin
documenting. t
hediffe
re ntcampus esoft heuni ve
rsi
ty
 Portability: High-level languages, being Whichinte ra
ctwi t
htheuni v
ersitysta
ffand
essentially machine independent, should be able to st
udents
.The r
efore,i
ti sexpectedthatthedat
abase
develop portable software. woul
dpe rformf unc t
ionall
ya lltherequir
ementst
hat
 Generality: Most high-level languages allow ar
especifiedbyt heun i
v e
rsit
y
the writing of a wide variety of programs, thus
relieving the programmer of the need to become
5.2 Safety Requirements:-
expert in many diverse languages.
 Brevity: Language should have the ability to Thedata
basemayge tcra
shedatanycert
aintime
implement the algorithm with less amount of code. duetovi
rusoroper
atin
gs ys
temfai
lur
e.There
fore
,
Programs expressed in high-level languages are iti
sre
quir
edtot
akethedata
baseba
ckup.
often considerably shorter than their low-level
equivalents. 5.3 Security Requirements
 Error checking: Being human, a programmer
Wea regoin gtode velopas ecure dda t
abaseforthe
is likely to make many mistakes in the development
universi
ty.The r
ea rediffer
entc a t
egoriesofusers
of a computer program. Many high-level languages
na melyteac hi
n g
enforce a great deal of error checking both at
Admi ni
strator
,St affme mbe r
sa nds tudentsetc
.
compile-time and at run-time.
De pendingupont hec ategoryofus ertheaccess
 Cost: The ultimate cost of a programming
rightsarede cided.Itme ansift heus erisan
language is a function of many of its characteristics.
admi nis
tratorthe nhec anbea bl etomodi f
ythe
B. Hardware Interfaces da t
a,d e
lete,appe nde tc
.Al lothe rusersotherthan
Uni vers
it
ySt affonlyha vether ightstoretri
evethe
Hardware Interfaces Server Side: informationa boutda tabase.

 Operating System: Windows 9x/ xp, A. Software Quality Attributes

Windows ME
 Processor: Pentium 3.0 GHz or higher TheQualit
yoft heda t
aba
seismaint
ainedin
 RAM: 256 Mb or more s
uchawa ys othatitca
nbeve
ryus
erfri
endl
yto
 Hard Drive: 10 GB or more a
llt
heus
ersofthedat
aba
se

Hardware Interface Client side:

 Operating System: Windows 9x or above, 5.5 Hardware Constraints:-

MAC or UNIX.
 Processor: Pentium III or 2.0 GHz or higher. Thesyst
emrequir
esadat
abasei
norde
rtost
ore
 RAM: 256 Mb or more pers
ist
entda
ta.Thedat
abas
eshoul
dhaveba
ckup
capa
bil
it
ies
Software Interfaces
 Database: SQL Server.

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)

 lOMoARcPSD|17679483

17

5.6 Software Constraints: - userpar

tisful
lypor
tabl
eandan
ysys
temusi
ngany
Thedeve
lopme ntofthesyst
e m willbec onstr
aine
d webbr o
wsershoul
dbea bl
etouset
hefe
atur
esof
b
ytheavail
abilityofrequir
eds oft
wa res ucha sweb theappl
ica
ti
on.
s
erve
rs,databa s
eandde velopme ntt ool s.The
avai
la
bil
ityoft hesetoolswillbeg ove rne db ythe 6.4 ACID Properties:-
Lov el
yPr of
e s
sionalUnive r
sity .
The Online fees payment software must be able to
use several data formats according to the data
formats that are provided by the data bases of
different banks. A transaction should have all the
properties of a data base transaction (Atomicity,
5.7 Design Constraints:- Consistency, Isolation, and Durability).

Thesyste
m mustbedes
igne
dtoall
owwe bus
abil
it
y.
Thati
s,thes
yste
m mustbedesi
gnedi
nsuchaway
tha
twillbeea
sytouseandvis
ibl
eonmostofthe
brows
ers
CONCLUSION:
After processing through all phases of the system
VI. OTHER REQUIREMENTS De ve lopme ntlife cycle, the portal is developed. In Fut ure
it will be hosted on the internet server which Wi ll be accessed
6.1 Availability:-
by all people in the world and can Vi ewthe site and learn as
much as news and I n fo rm atio n about the unive rsity. The
Thes ystems houl dbeava
il
ablea
tal
lti
mes,meani
ng
theus erc ana cc e
ssi
tusin
gawe bbr o
wser
,only Administrator or Edi torwho will be assigned for editing or
managing Orcontrolling will be given the secure login
restri
ct
edb yt hed ownti
meoftheser
veronwhich
thes ys
tem Inf or ma ti
onand will change or modify the website.Asper
the requirements.
Runs.Incaseofaofaha r
dwa r
ef a
ilur
eorda t
abase
cor
rupti
on,ar e
plac
ementpagewi l
lbes hown.Also
incaseofaha r
dwaref
ail
ureorda t
abasecorr
upti
on,
bac
kupsoft hedat
abas
eshouldber e
tri
evedwiththe
MySQLs e
rverandsav
edbythea dmini
stra
tor
.

6.2 Maintainability:-

MySQLisusedformaint
a i
nin
gthedata
bas
ea ndt
he
Apaches
erv
erta k
esca r
eoft hesit
e.Incas
eofa
f
ail
ure,a re-i
nit
ial
iz
a t
ion of the pro
gram is
r
ecommende
d.

6.3 Portability:-

The appl
icat
ion i
s Linux-
baseda nd s houl
d be
compat
ibl
ewi thothersys
tems.Apac he,PHP a nd
MySQLpr ogramsarepr
act
ical
lyindependentofthe
OS-sy
stem whicht
heycommuni c
atewi t
h.Thee nd-

Downloaded by Adarsh Shivam (adarshshivam80@gmail.com)