Table of Contents

1. Introduction ...................................................................................................................... 2
1.1. Purpose ..................................................................................................................... 2
1.2. Document Conventions ............................................................................................ 3
1.3. Scope ......................................................................................................................... 3
2. Overall Description ......................................................................................................... 4
2.1 Product Perspective ................................................................................................... 4
2.2 Product Features ........................................................................................................ 5
2.3 User Classes and Characteristics ...............................................................................
2.4 Operatin! "nvironment .............................................................................................
2.5 Desi!n and Implementation Constraints ....................................................................
2. User Documentation ..................................................................................................
2.# $ssumptions and Dependencies ................................................................................ #
3. S%stem Features ............................................................................................................... &
3.1. Data'ase ( Stora!e ................................................................................................... &
3.2 . Functional )e*uirements .......................................................................................... &
3.2.1 Inter+ace )e*uirements ........................................................................................... &
3.2.1.1 User Inter+aces ................................................................................................. ,
4. -on Functional )e*uirements ....................................................................................... 1.
4.1. User Inter+aces ........................................................................................................ 1.
4.2. /ard0are Inter+aces ................................................................................................ 1.
4.3. So+t0are Inter+aces ................................................................................................. 11
4.4. Communications Inter+aces .................................................................................... 11
5. Other -on+unctional )e*uirements ............................................................................... 11
5.1. Per+ormance )e*uirements ..................................................................................... 11
5.2. Sa+et% )e*uirements ............................................................................................... 11
5.3. Securit% )e*uirements ............................................................................................ 12
5.4. So+t0are 1ualit% $ttri'utes .................................................................................... 12
5.5 /ard0are Constraints .............................................................................................. 12
5. So+t0are Constraints ................................................................................................ 12
5.# Desi!n Constraints ................................................................................................... 12
Preface
2his document contains the So+t0are )e*uirements Speci+ication 3S)S4 o+ an Online Pro5ect
6ar7in! S%stem +or the School o+ Computin! at the Universit% o+ Portsmouth. 2he main aim o+
this pro5ect is to add +unctionalit% to the e8istin! SU6S s%stem in order to provide an online
+acilit% +or mana!in! and re!isterin! student accounts.
2his document has 'een prepared in accordance 0ith the I""" Std &3.91,,&: I"""
)ecommended Practice +or So+t0are )e*uirements Speci+ications ;I""" 1,,&<.
1. SRS
Introduction
1.1. Purpose
2he main o'5ective o+ this document is to illustrate the re*uirements o+ the pro5ect
Departmental Automation system. 2his document descri'es the desi!n decisions:
architectural desi!n and the detailed desi!n needed to implement the s%stem. It provides
the visi'ilit% in the desi!n and provides in+ormation needed +or so+t0are support. 2he
document !ives the detailed description o+ the 'oth +unctional and non +unctional
re*uirements proposed '% the client. 2he document is developed a+ter a num'er o+
consultations 0ith the client and considerin! the complete re*uirement speci+ications o+
the !iven Pro5ect. 2he +inal product o+ the team 0ill 'e meetin! the re*uirements o+ this
document.
1.2. Document Conventions
2he +ollo0in! are the list o+ conventions and acron%ms used in this document and the
pro5ect as 0ell=
Administrator= $ lo!in id representin! a user 0ith user administration privile!es to the
so+t0are
User $ !eneral lo!in id assi!ned to users
Client Intended users +or the so+t0are
S!" Structured 1uer% >an!ua!e? used to retrieve in+ormation +rom a
data'ase
S!" Server $ server used to store data in an or!ani@ed +ormat
ASP $ctive Server Pa!es= $ Ae' Pa!e +ormatted on the server and delivered to
the 'ro0ser.
"ayer )epresents a section o+ the pro5ect
User Interface "ayer 2he section o+ the assi!nment re+errin! to 0hat the user
interacts 0ith directl%.
Application "o#ic "ayer 2he section o+ the assi!nment re+errin! to the Ae'
Server. 2his is 0here all computations are completed.
Data Stora#e "ayer 2he section o+ the assi!nment re+errin! to 0here all data is
recorded
Data flo$ dia#ram It sho0s the data+lo0 'et0een the entities.
Use Case $ 'road level dia!ram o+ the pro5ect sho0in! a 'asic overvie0
%oolean $ trueB+alse notation
Interface Somethin! used to communicate across di++erent mediums
Uni&ue 'ey Used to di++erentiate entries in a data'ase
1.( Product Scope
Online Pro5ect 6ar7in! S%stem is developin! +or School o+ Computin!: Universit% o+
Portsmouth and used to replace old paper 0or7 s%stem and PU6S. OP6S is to 'uild
upon the e8istin! 0e'9'ased pro5ect mar7in! s%stem PU6S in order to implement the
pro5ect mar7in! process and allocatin! supervisorBideas to students. 2his increase in
e++icienc% o+ pro5ect mar7in!: audit trails o+ mar7in! process: !ive +eed'ac7 to student:
+inall%: pu'lication and email student result. It provides a mechanism to edit the online
mar7in! +orm 0hich ma7es the s%stem is +le8i'le.
2. )verall Description

2.1 Product Perspective
2he proposed Departmental Automation system is an on9line Universit% 6ana!ement
S%stem. 2his S%stem 0ill provide a vie0: su'mit: online pa%ment: uploadin! various
documents and other miscellaneous resources. 2his vie0 0ill 'e 'ased on the cate!ories
li7e attendance vie0 and dail% activities. Further the Universit% mana!ement sta++
personnel 3+acult%4 can addBupdateBremove the resources or an automatic removal o+
accessin! +eatures 0hen the time limit completes.
2he S%stem 0ill also have an $D6I- 0ho has +ull9+led!ed ri!hts 0ith re!ards to
mana!in! resources across 'ranches ( such as trans+errin! 'oo7s across these 'ranches.
2he users can vie0: su'mit: online pa%ment: uploadin! various documents and
in+ormation a'out their account etc. there are 'asic t0o t%pes o+ users one are the students
and other are +acult% mem'ers. "ach users +acilitates 0ith a di++erent account num'er
havin! a pro+ile alon! 0ith a pass0ord +or private use. 2he t0o t%pes o+ users di++er +rom
each other due to the accessin! limits to Departmental $utomation S%stem.
2.2 Product *unctions
2here are three di++erent users 0ho 0ill 'e usin! this product=
Universit% chancellor 0ho 0ill 'e actin! as the administrator.
Facult% mem'ers 0ho are second level users accessin! U6S.
Student o+ the Universit% 0ho 0ill 'e accessin! the U6S online.
2he +eatures that are availa'le to the $dministrator are=
2he administrator has the +ull +led!ed ri!hts over the U6S.
Can createBdelete an account.
Can vie0 the accounts.
Can chan!e the pass0ord.
Can hide an% 7ind o+ +eatures +rom the 'oth o+ users.
InsertBdeleteBedit the in+ormation o+ availa'le on U6S.
Can access all the accounts o+ the +acult% mem'ersBstudents.
2he +eatures availa'le to the Facult% mem'ers are=
Can mar7 the attendance o+ students online.
Can vie0 the attendance online.
Can upload mar7s: assi!nments: readin! materials +or students.
2he +eatures availa'le to the Students are=
Can vie0 2he di++erent cate!ories o+ assi!nments availa'le in their
account.
Can vie0 their mar7s.
Can vie0 the various readin! material.
Can vie0 attendance.
Can vie0 and modi+% its pro+ile 'ut can modi+% it to some limited ran!e.
Can pa% their +ee online.
2.( User Classes and C+aracteristics
2here are various 7inds o+ users +or the product. Usuall% 0e' products are visited
'% various users +or di++erent reasons.

2he users include =
Chancellor 0ho 0ill 'e actin! as the controller and he 0ill have all the
privile!es o+ administrator.
Facult% mem'ers 0ho 0ill 'e usin! the a'ove +eatures '% accessin! the
U6S online.
Students 0ho 0ill 'e usin! the a'ove +eatures '% accessin! the
U6S online.
2., )peratin# -nvironment
2he product 0ill 'e operatin! in 0indo0s environment. $lso it 0ill 'e compati'le 0ith
the I" ... 6ost o+ the +eatures 0ill 'e compati'le 0ith the 6o@illa Fire+o8 C Opera #..
or hi!her version. 2he onl% re*uirement to use this online product 0ould 'e the internet
connection.
2.. Desi#n and Implementation Constraints
2he Product is developed usin! $SP. 2he 'ac7end data'ase +or this S1> Server. 2he
product is accomplished 0ith lo!in +acilit% so that speci+ic +unction is availa'le to
speci+ic student.

2./ User Documentation
2he product 0ill include user manual. 2he user manual 0ill include product overvie0:
complete con+i!uration o+ the used so+t0are 3such as S1> server4: technical details:
'ac7up procedure and contact in+ormation 0hich 0ill include email address. 2he product
0ill 'e compati'le 0ith the Internet "8plorer .. or hi!her. 2he data'ases 0ill 'e created
in the 6icroso+t S1> server 2....
2.0 Assumptions and Dependencies
2he product needs +ollo0in! third part% product.
6icroso+t S1> server to store the data'ase.
$SP to develop the Product
(. System *eatures
(.1. Database 1 Stora#e
(.1.1. Description and Priority
Proposed Data'ase is intended to store: retrieve: update: and manipulate in+ormation
related to universit% 0hich include
Pro+ile o+ 'oth users
Sta++ in+ormation
Student details
6% account
Online pa%ment
Die0 attendanceBmar7sBuploadin! o+ mar7s and assi!nments
(.1.2. Stimulus 2 Response Se&uences
Responses for Administrator 2he administrator can >o!in and >o!out. Ahen the
$dministrator >o!s into the Universit% mana!ement s%stem. 2he s%stem 0ill chec7 +or
validit% o+ lo!in .I+ the >o!in and pass0ord are valid: the response to this action is the
administrator 0ill 'e a'le to modi+%: vie0: add: deletin! and all other +unctions that can
'e per+ormed on the data'ase.
(.2. *unctional Re&uirements
2his section !ives the list o+ Functional and non +unctional re*uirements 0hich are
applica'le to the Departmental $utomation S%stem.
(.2.1 Interface Re&uirements
2his section descri'es ho0 the so+t0are inter+aces 0ith other so+t0are products or users
+or input or output.
(.2.1.1UserInterfaces
Descri'es ho0 this product inter+aces 0ith the user.
3UI
Descri'es the !raphical user inter+ace i+ present. 2his section should include a set o+
screen dumps or moc7ups to illustrate user inter+ace +eatures.
1. Description
2he user inter+ace must 'e customi@a'le '% the administrator
2. Criticality
2his issue is essential to the overall s%stem. $ll the modules provided 0ith the
so+t0are must +it into this !raphical user inter+ace and accomplish to the standard
de+ined.
3. Tec+nicalIssues
In order to satis+% this re*uirement the desi!n should 'e simple and all the
di++erent inter+aces should +ollo0 a standard template. 2here 0ill 'e the
possi'ilit% o+ chan!in! colors and ima!es: plus s0itchin! 'et0een inter+aces 0ith
the minimum impact +or the users.
4. Ris4s
2o reduce the circumstances under 0hich this re*uirement mi!ht not a'le to 'e
satis+ied: all the desi!ners must have 'een developed 0e' sites previousl% and
the% must 'e a0are o+ html restriction and cross 'ro0sers implementations 'e+ore
startin! the desi!nin!. In order to reduce the pro'a'ilit% o+ this occurrence the
entire desi!n team 0ill 'e trained in 'asic html development and macromedia
+ire0or7s: this tool 0ill 'e used instead o+ Photoshop.
5. Dependencies $it+ ot+er re&uirements
$ll user inter+aces should 'e a'le to interact 0ith the user mana!ement module
and a part o+ the inter+ace must 'e dedicated to the lo!inBlo!out module
Input Re&uirements
User access
"ach +acult% mem'er and student is assi!ned a uni*ue identi+ier upon admission
to the universit%. Eoth o+ them must 7no0 this. 2his identi+%in! 7e% maps to all
hisBher re!istration record in+ormation in the main re!istration s%stem. $dmitted
and current students have their online re!istration accounts also ena'led. Such
account ma%'e disa'led durin! hisBher sta% as a matriculated student andBor a+ter
!raduation or separation +rom the universit%.
Uploadin# of data
"ach +acult% mem'er should +acilitates 0ith uploadin! o+ data such assi!nments:
their mar7s and other 7ind o+ readin! material. Similarl% such o+ option must 'e
present their +or students to upload their assi!nments.
)nline payment
2he students should have the +acilit% to pa% their pa%ment online an% 7ind o+
universit% +ee char!es so as there should 'e +acilit% to chec7 0hether the entered
code +or pa%ment is a valid code or not or in simple 0ord a proper validation is
re*uired.
,. 5on *unctional Re&uirements
,.1. User Interfaces

,.2. 6ard$are Interfaces
Server Side
Operatin! S%stem= Aindo0s ,8BFP :Aindo0s 6"
Processor= Pentium 3.. G/@ or hi!her
)$6= 25 6' or more
/ard Drive= 1. GE or more
Client side
Operatin! S%stem= Aindo0s ,8 or a'ove: 6$C or U-IF.
Processor= Pentium III or 2.. G/@ or hi!her.
)$6= 25 6' or more
,.(. Soft$are Interfaces
Database S1> Server.
Application $SP 3$ctive Server Pa!es4
7eb Server IIS 3Internet In+ormation Services 3IIS4 is a po0er+ul Ae' server that
provides a hi!hl% relia'le: mana!ea'le: and scala'le Ae' application in+rastructure4
,.,. Communications Interfaces
2he Customer must connect to the Internet to access the Ae'site=
Dialup 6odem o+ 52 7'ps
Eroad'and Internet
Dialup or Eroad'and Connection 0ith a Internet Provider.
/. )t+er 5onfunctional Re&uirements

..1. Performance Re&uirements
2he proposed s%stem that 0e are !oin! to develop 0ill 'e used as the Chie+
per+ormance s%stem 0ithin the di++erent campuses o+ the universit% 0hich interact 0ith
the universit% sta++ and students. 2here+ore: it is e8pected that the data'ase 0ould
per+orm +unctionall% all the re*uirements that are speci+ied '% the universit%.
..2. Safety Re&uirements
2he data'ase ma% !et crashed at an% certain time due to virus or operatin! s%stem
+ailure. 2here+ore: it is re*uired to ta7e the data'ase 'ac7up.
..(. Security Re&uirements
Ae are !oin! to develop a secured data'ase +or the universit% .2here are di++erent
cate!ories o+ users namel% teachin! $dministrator: Sta++ mem'ers and students etc.
Dependin! upon the cate!or% o+ user the access ri!hts are decided. It means i+ the user
is an administrator then he can 'e a'le to modi+% the data: delete: append etc. $ll other
users other than Universit% Sta++ onl% have the ri!hts to retrieve the in+ormation a'out
data'ase.
..,. Soft$are !uality Attributes
2he 1ualit% o+ the data'ase is maintained in such a 0a% so that it can 'e ver% user
+riendl% to all the users o+ the data'ase.
... 6ard$are Constraints
2he s%stem re*uires a data'ase in order to store persistent data. 2he data'ase should
have 'ac7up capa'ilities.
../ Soft$are Constraints
2he development o+ the s%stem 0ill 'e constrained '% the availa'ilit% o+ re*uired
so+t0are such as 0e' servers: data'ase and development tools.
2he availa'ilit% o+ these tools 0ill 'e !overned '% the Eharati Did%apeeth Universit%.
..0 Desi#n Constraints
2he s%stem must 'e desi!ned to allo0 0e' usa'ilit%. 2hat is: the s%stem must
'e desi!ned in such a 0a% that 0ill 'e eas% to use and visi'le on most o+ the 'ro0sers.