Software Requirements Specification

Table of Contents 1. Introduction ............................................................................................................................. 4 1.1 Purpose ................................................................................................................................. 4 1.2 Document Conventions .......................................................................................................... 5 1.3 Project Scope ......................................................................................................................... 5 1.4 Abbreviations ........................................................................................................................ 7 1.5 Benefits of System ................................................................................................................. 1.! "eferences ............................................................................................................................. # 1.7 $ec%no&o'ies ......................................................................................................................... # 1. (vervie)............................................................................................................................... # 2. Overall Description ............................................................................................................... 11 2.1 Pro*uct Perspective .............................................................................................................. 11 2.2 Pro*uct +eatures .................................................................................................................. 13 2.3 ,ser C&asses an* C%aracteristics ........................................................................................... 14 2.4 Desi'n an* -mp&ementation Constraints................................................................................. 15 2.5 ,ser Documentation............................................................................................................. 15 2.! Assumptions an* Depen*encies ............................................................................................ 15 2.7 Apportin' of "e.uirements ................................................................................................... 1! 3. System Requirments and nalysis ....................................................................................... 1! 3.1 ,ser -nterface ...................................................................................................................... 17 3.2 Stu*ent /ie) +unctiona&ity................................................................................................... 17 3.3 A*mission /ie) +unctiona&ity .............................................................................................. 1 3.4 $utor ................................................................................................................................... 1# 3.5 System ................................................................................................................................ 20 4. 5. Supplementary Requirements .............................................................................................. "1 Ot#er $onfunctional Requirements .................................................................................... "" 5.1 Performance "e.uirements ................................................................................................... 22 5.2 Security "e.uirements.......................................................................................................... 22 5.2 Portabi&ity "e.uirements ...................................................................................................... 23

5.2 1aintanabi&ity "e.uirements ................................................................................................ 23 5.2 "e&iabi&ity "e.uirements ...................................................................................................... 23 5.2 ,sabi&ity "e.uirements ........................................................................................................ 23 5.2 Avai&abi&ity "e.uirements .................................................................................................... 23 5.4 Soft)are System Attributes................................................................................................... 24

6. 7. 8.

C#an%e &ana%ement 'rocess............................................................................................... "4 Documentation pprovals .................................................................................................... "4 Supportin% Information ........................................................................................................ ""

ppendi( ) *lossary ................................................................................................................. "+ ppendi( ,) nalysis &odels..................................................................................................... "!

1.

Introduction

Stu*ent a*missions are a vita& part of any university2s runnin' because stu*ents are )%at 3eep a ,niversity a&ive. $%e stu*ent a*mission is one of t%e most important activities )it%in a university as one cannot survive )it%out stu*ents. A poor a*missions system can mean fe)er stu*ents bein' a*mitte* into a university because of mista3es or an over&y s&o) response time. $%e process be'ins )it% a potentia& stu*ent comp&etin' an app&ication form t%rou'% t%e ,niversities an* Co&&e'es A*missions Service4 t%e first step for stu*ents is to app&y *irect&y to t%e university t%rou'% a custom on&ine form. $%e ne5t step is for t%e A*missions service center %as to revie) t%e app&ication an* ensure t%at a&& of t%e re.uire* information %as been provi*e*4 from t%e form itse&f to t%e supp&ementary *ocumentation4 suc% as &an'ua'e an* *e'ree certificates. -f any of t%e re.uire* information is missin'4 it is t%e secretary for t%e *epartment to )%ic% t%e app&ication concerns t%at contacts t%e potentia& stu*ent an* arran'es for t%e *e&ivery of t%e outstan*in' *ata. $%e app&ication in its entirety is t%en for)ar*e*4 comp&ete )it% a recommen*ation4 to t%e respective *epartment2s A*missions $utor4 )%o %as t%e fina& say as to )%et%er eac% potentia& stu*ent is accepte* or rejecte*. Before ma3in' a *ecision4 t%e A*missions $utor revie)s t%e app&ication an* t%e a**itiona& *ocumentation4 comparin' t%e aca*emic cre*entia&s to a &ist of university ran3in's an* previous4 simi&ar app&ications. 1.1 'urpose $%e purpose of t%is S"S *ocument is to specify soft)are re.uirements of t%e (n&ine A*mission for t%e university. -t is inten*e* to be a comp&ete specification of )%at functiona&ity t%e a*mission provi*es. $%e main purpose of t%e system is to automate t%e tas3 carrie* out by *ifferent peop&es in t%e or'ani6ation to perform t%e stu*ent a*mission. Specific *esi'n an* imp&ementation *etai&s )i&& be specifie* in a future *ocument. 1." Document Conventions ? -tems t%at are inten*e* to stay in as part of your *ocument are in bold

? 75p&anatory comments are in italic te5t. ? P&ain te5t is use* )%ere you mi'%t insert )or*in' about your project

1.- 'ro.ect Scope $%is project2s aim is to automate t%e system4 pre8c%ec3in' t%e inc&usion of a&& re.uire* materia& an* automatica&&y ran3in' eac% stu*ent2s app&ication base* on a number of criteria. $%ese criteria inc&u*e

t%e ran3in' of t%eir university4 t%eir 'ra*e at sai* university an* t%eir &an'ua'e 'ra*e Certificate. $%e *ata use* by t%e system is store* in a *atabase t%at )i&& be t%e centre of a&& information %e&* about stu*ents an* t%e base for t%e remain*er of t%e process after t%e initia& app&ication %as been ma*e. $%is enab&es t%in's to be simp&ifie* an* consi*erab&y .uic3ene*4 ma3in' t%e jobs of t%e peop&e invo&ve* easier. -t supports t%e current process but centra&i6es it an* ma3es it possib&e for *ecisions to be ma*e ear&ier an* easier )ay.

1.-.1 *oals $%e main 'oa& of t%e system is to automate t%e process carrie* out in t%e or'ani6ation )it% improve* performance an* rea&i6e t%e vision of paper&ess a*mission. Some of t%e 'oa&s of t%e system are &iste* be&o)9 ? ? 1ana'e &ar'e number of stu*ent *etai&s. 1ana'e a&& *etai&s of stu*ent )%o re'istere* for t%e course an* sen* appropriate

*etai&s about t%e course to t%e stu*ents account. ? ? ? ? stu*ents. ? "e*uce t%e )or3 &oa* in intervie) t%e stu*ents for se&ection an* Counse&in' s%ou&* be Create stu*ent accounts an* maintain t%e *ata2s effective&y. /ie) a&& t%e *etai&s of t%e stu*ents. Create t%e statistica& reports to faci&itate t%e finance *epartment )or3. 1ana'e t%e *etai&s of %oste&&ers an* faci&itate t%e a&&otment of %oste&s rooms for t%e

very effective rat%er t%en *irect met%o*s. ? ? .-." Activities &i3e up*atin'4 mo*ification4 *e&etion of recor*s s%ou&* be easier. $%e System must support ,n*o t%e Previous activities if any Prob&em (ccurs. Ob.ectives of t#e 'roposed System)

$%e aim of t%e propose* system is to a**ress t%e &imitations of t%e current system. $%e re.uirements for t%e system %ave been 'at%ere* from t%e *efects recor*e* in t%e past an* a&so base* on t%e fee*bac3 from users of previous metrics too&s. +o&&o)in' are t%e objectives of t%e propose* system9 ? Reac# to %eo%rap#ically scattered students. (ne of t%e important objectives of t%e a*mission system is communicate )it% a&& t%e stu*ents scattere* 'eo'rap%ica&&y.

Reducin% time in activities.

"e*uce t%e time ta3en process t%e app&ications of stu*ents4 a*mittin' a stu*ent4 con*uctin' t%e on&ine e5amination4 verify stu*ent mar3s4 an* sen* ca&& &etters to se&ecte* stu*ents. ? Centrali/ed data #andlin% $ransfer t%e *ata smoot%&y to a&& t%e *epartments invo&ve* an* %an*&e t%e *ata centra&i6e* )ay. ? 'aperless admission wit# reduced manpower t%e paper )or3s nee*e*. ? Cost cuttin% "e*uce t%e cost invo&ve* in t%e a*mission process. . "e*uce t%e manpo)er nee*e* to perform a&& t%e a*mission an* a*ministration tas3 by re*ucin'

? Operational efficiency . -mprove t%e operationa& efficiency by improvin' t%e .ua&ity of t%e process. 1.4 bbreviations ? 0erification) Stu*ent verifies t%e mar3s t%ey score* in t%e on&ine entrance e5am con*ucte* by t%e university. ? Counselin%) ,niversity con*uct t%e on&ine Counse&in' to a*mit t%e stu*ents in t%e respective Courses. ? Course Catalo%) Course Cata&o' contains a&& t%e *etai&s about t%e course an* sc%e*u&e of t%e course. -t is 'enerate* by t%e Superior Persons &i3e "e'ister in t%e university. ? &aintenance) Stu*ent information2s are maintaine* in a separate :o' for maintenance. ? Re%istration) $o participate in t%e entrance e5am con*ucte* by t%e ,niversity4 t%e stu*ent must provi*e a&& t%e *etai&s about %im. $%is process is ca&&e* "e'istration. ? Deletion) -f t%e course not &i3e by most of t%e stu*ents an* &ess number of app&ications are 'etter from t%e stu*ents means t%e Course *etai&s is temporari&y stoppe* by t%e a*ministrator. ? Student 1o%) Stu*ent information2s are maintaine* in a separate &o' for future reference an* retrieve* for any contactin' Purpose. ? 2T&1) ;yper $e5t 1ar3up :an'ua'e is a mar3up &an'ua'e use* to *esi'n static )eb pa'es. ? 34,) 7nterprise <ava Beans. ? D,"9 DB2 Database is t%e *atabase mana'ement system t%at *e&ivers a f&e5ib&e an* cost effective *atabase p&atform to bui&* robust on *eman* business app&ications.

? 5 S) =eb sp%ere app&ication server is an app&ication server t%at runs business app&ications an* supports t%e <277 an* )eb services stan*ar*s. ? 2TT'9 ;yperte5t $ransfer Protoco& is a transaction oriente* c&ient>server protoco& bet)een )eb bro)ser ? a =eb Server. ? TC'6I') $ransmission Contro& Protoco&>-nternet Protoco&4 t%e suite of communication protoco&s use* to connect %osts on t%e -nternet. $CP>-P uses severa& protoco&s4 t%e t)o main ones bein' $CP an* -P.

1.+ ,enefits of t#e system As )it% most rea& )or&* activities4 t%ere are numerous benefits to usin' a soft)are system for university a*missions. $%e most apparent to t%is project is t%e unification of t%e entire process. Anot%er benefit of a soft)are system is t%e use of a centra& *atabase. $%is *atabase is t%e basis for a&& actions in t%e system an* can be trivia&&y up*ate* an* use* to ai* in a&& of t%e system2s processes4 meanin' a&& of t%e re.uire* information is store* in one centra& &ocation an* t%us is easi&y accessib&e. $%is is a far more reasonab&e stora'e met%o* t%an a paper8base* fi&e system4 )%ere t%e time of trave&in' to an* p%ysica&&y searc%in' t%e recor*s for t%e re.uire* information cou&* be a bur*en. ;uman error cou&* a&so be a factor in t%at mista3es cou&* be ma*e in t%e fi&in' process )%ic% )ou&* not occur in a )e&& )ritten *atabase system an* mista3es or c%an'es on p%ysica& recor*s can be messy to correct. Soft)are systems are a&so muc% faster at performin' certain tas3s t%an %umans4 meanin' t%at time can be save* performin' processes suc% as sen*in' communication e8mai&s4 creatin' recommen*ations an* t%e comparison of app&ications. $%is a&so means t%at t%ese tas3s can be *one so&e&y by t%e system4 freein' up t%ose invo&ve* to perform more important tas3s. -n t%e &on' term4 if met%o*s or minor *etai&s concernin' t%e a*missions process at universities c%an'es4 t%is can be ref&ecte* in potentia&&y minor c%an'es to t%e co*e of t%e system4 to retrain emp&oyees rat%er t%an %avin' re'ar*in' t%e ne) practices.

1.7 References

The document in this file is adopted from the IEEE "e.uirements Specifications ? (Std 830-1993).

@ui*e to

Soft)are

Basic "ecor* Structure for *esi'nin' an* *eve&opin' an (( System 'iven by (1@.

? Appendi A contains use cases for most of the functionalit! of the s!stem. 1.! Tec#nolo%ies ? <2779 App&ication Arc%itecture. ? DB29 Database. ? 7c&ipse9 Deve&opment $oo&. ? =AS9 =eb Server. ? "ationa&9 Desi'n $oo&.

1.8 Overview S"S )i&& inc&u*e t)o sections. Overall Description )i&& *escribe major components of t%e system4 interconnection an* e5terna& interfaces. Specific Requirements )i&& *escribe t%e functions of actors4 t%eir ro&e in t%e system an* constraints. 1.8.1 Overall Description) $%e rest of t%is *ocument )i&& 'ive furt%er *etai&s on t%e overa&& pro*uct *escription4 inc&u*in' t%e %ar*)are4 soft)are4 an* communications interfaces4 pro*uct functions4 user c%aracteristics4 an* any assumptions t%at )i&& be ma*e. 1.8." Specific Requirements) $%e *ocument )i&& a&so inc&u*e t%e specific re.uirements nee*e*. $%ese )i&& inc&u*e t%e functions4 performance4 *esi'n4 an* soft)are attributes. $%is *ocument is or'ani6e* in a &o'ica& manner an* is easy to fo&&o). "ea*ers s%ou&* refer to t%e tab&e of contents4 appen*ices4 or in*e5 if &oo3in' for

somet%in' in specific. (t%er)ise4 rea*in' t%is *ocument from start to finis% )i&& start )it% a va'ue *escription an* 'et more specific an* *etai&e* as c%an'in' sections an* rea*in' furt%er. 2. Overall Description 9i%ure 1) &odel of t#e System

".1 'roduct 'erspective

? ? ?

$%e )eb pa'es AB;$1:><SPC are present to provi*e t%e user interface on customer c&ient si*e. $%e C&ient Soft)are is to provi*e t%e user interface on system user c&ient si*e an* for t%is $CP>-P (n t%e server si*e )eb server is 7<B an* *atabase server is for storin' t%e information.

Communication bet)een customer an* server is provi*e* t%rou'% ;$$P>;$$PS protoco&s. protoco&s are use*.

Software Requirements Specification for Online University Admission System Page 11 ".1.1 System Interfaces

Client on Internet) =eb Bro)ser4 (peratin' System AanyC

Client on Intranet) C&ient Soft)are4 =eb Bro)ser4 (peratin' System AanyC

5eb Server)

=AS4 (peratin' System AanyC

Data ,ase Server) DB24 (peratin' System AanyC

Development 3nd) 7c&ipse A<2774 <ava4 Serv&ets4 <SPC4 DB24

(S A=in*o)sC4 =eb server.

".1." 2ardware Interfaces

".1.- Communication Interface

C&ient on -nternet )i&& be usin' ;$$P>;$$PS Protoco&.

C&ient on intranet )i&& be usin' $CP>-P protoco&.

Software

Requirements Specification for Online University Admission System Page 12

".1.4 &emory Constraints

2ardware memory)

$%e

'ro)t%

of

university

is

unpre*ictab&eD to reso&ve t%e future prob&ems occurs )%i&e en%ancin' t%e system is contro&&e* by &ar'er memory as possib&e. So t%e memory constraint in t%e server si*e is e5ten*e* up to 1$B.

".1.+ Site daptation requirements

Eo site a*aptation is necessary in t%is project. Because t%e ,niversity a*mission

system is portab&e. $%e entire system is transporte* to )%erever it is nee*e*. Eo e5terna& *epen*en*ancies are in p&ace an* operation of t%e system )i&& never c%an'e *ue to &ocation. "." 'roduct 9eatures

Some of t%e features are i*entifie* for t%e soft)are. $%ey are &iste* be&o)9

0iew Course Information:s)

$%e stu*ent must ab&e &o'

as stu*ent an* see a&& *etai&s about course )it%out any constraints.

pply for Course)

$%e stu*ent can ab&e *o)n&oa* t%e app&ication

form or re'ister for t%e course on&ine.

? t%rou'% on&ine.

0erification of &ar;s)

$%e system must a&&o) t%e stu*ent verify mar3s

? c&ear *oubts.

dvanced 3nquiry support)

7nab&e t%e stu*ents to as3 an*

Online Counselin%) $%e a*ministrator can ab&e to sen* t%e ca&& &etters

for t%e s%ort &iste* can*i*ates4 if t%e stu*ent not ab&e contact *irect&y respective aut%ori6e* persons4 t%an t%e system must faci&itate t%e on&ine Counse&in'.

? *ifferent criteria.

Report *eneration) $%e system supports 'eneration of reports base* on

Software

Requirements Specification for Online University Admission System Page 13

? reports of *ai&y

Record maintenance)

$%e system a&so must 3eep trac3 t%e statistica&

activities of t%e Stu*ent "e'istration Process.

? on&ine in effective )ay

Online 3(amination)

7nab&e t%e stu*ent to )rite t%e e5ams t%rou'%

compare )it% paper base* process.

".- <ser Classes and C#aracteristics

".-.1 <ser C#aracteristics

$%e Stu*ent s%ou&* %ave t%e basic i*ea to operate AuseC t%e system an* %e a&rea*y %as t%e e5perience to )or3 in t%e internet Abro)serC. Defau&t :an'ua'e is 7n'&is%. ".-." <ser Classes

Some of t%e users i*entifie* for t%is system t%rou'% use case ana&ysis are &iste* be&o)9

Stu*ents

Data entry operators

$utors

A*ministrators

A*mission Aut%orities

".4 Desi%n and Implementation Constraints

Some of t%e *esi'n an* imp&ementation constraints i*entifie* are &iste* be&o)9

Stu*ent is not a&&o)e* to re'ister for more t%an t%ree courses.

Stu*ent not %as any ri'%ts to e*it any *ata in t%e system.

Software

Requirements Specification for Online University Admission System Page 14

Stu*ent pays t%e app&ication fees in /PP or DD or 1( to re'ister for Course.

(n&ine Payment faci&ity may be restricte* if t%e university not )ant t%is faci&ity for some

reasons.

$%is system is not support *istribute* *atabase +aci&ity.

System is &imite* to ;$$P>;$$PS Protoco&s.

".+ <ser Documentation

(n&ine *ocumentation faci&ity is avai&ab&e for t%e stu*ents to assess t%em for t%e easy use.

A specific *ocument s%ou&* be prepare* for t%e maintenance of t%e system an* s%ou&* say t%e

system in easiest )ay. ".7 ssumptions and Dependencies

Courses are a&rea*y create* an* information2s avai&ab&e for use.

"o&es an* responsibi&ities are a&rea*y estab&is%e*.

? ".!

A*ministrator is a&rea*y create*. pportionin% of Requirements

-t is possib&e in t%e future t%at a fe) a**itiona& features be imp&emente* into t%is system.

&ana%ement System)

$%is )i&& a&&o) t%e system to mana'e

effective&y t%e ot%er resources in t%e easiest )ay.

Trainin% 9acility) $%is )i&& a&&o) effective&y train t%e staffs an* improve t%e .ua&ity of

e*ucation in t%e institution.

Software

Requirements Specification for Online University Admission System Page 1

3.

System Requirements and nalysis)

$%e fo&&o)in' sections )i&& intro*uce t%e numerous re.uirements of t%e system from t%e point of vie) of *ifferent users an* )i&& intro*uce a number of *ecisions t%at %ave been ma*e re'ar*in' imp&ementation. $%ese sections a&so attempt to some)%at *escribe t%e ro&e of eac% user 'roup in t%e system4 *iscussin' t%eir in*ivi*ua& ro&es t%rou'% t%e functions t%ey can perform. -.1 <ser Interface

$%e user interface for t%is system )i&& %ave to be simp&e an* c&ear. 1ost important&y4 t%e

a'es must be easy to rea*4 easy to un*erstan* an* accessib&e. $%e co&or sc%eme s%ou&* be appropriate to provi*e fami&iarity )it% t%e university an* t%ere s%ou&* be no contrast issues.

-." Student 0iew 9unctionality)

Re%istration and 1o%in System)

App&icants

)i&&

carry out t%eir o)n re'istration4 provi*in' t%e system )it% a )ay to associate a user to t%eir app&icationAsC. $%is )i&& enab&e t%e system to *isp&ay persona&i6e* information )%en t%e user &o's in an* certain information4 suc% as name an* a**ress4 to be a**e* to eac% app&ication automatica&&y. @ivin' eac% stu*ent a specific -D )i&& a&so a&&o) a user to app&y to a number of courses4 )%i&e 'ivin' t%e system a )ay to prevent unnecessary *up&ication of app&ications.

pplication System)

$%e app&ication process )i&& be as *ocumentation4 suc% as *e'ree

strai'%tfor)ar* as possib&e4 usin' an intuitive form &ayout4 )it% t%e necessary information bein' comp&ete* in sta'es. =%en re'ar*in' supp&ementary transcripts4 t%ese cou&* be up&oa*e* t%rou'% t%e form in *i'ita& format4 upon )%ic% it )i&& be save* to t%e *atabase an* associate* )it% t%e app&ication4 bein' accessib&e by bot% t%e a*missions office staff an* tutors.

? t%eir

<pdate Details)

App&icants4 a*missions staff an* tutors )i&& a&& %ave t%e

abi&ity to up*ate t%eir persona& *etai&s at any time. App&icants4 %o)ever4 )i&& a&so be ab&e to up*ate

Software

Requirements Specification for Online University Admission System Page 1!

app&ication *etai&s. After t%e user %as confirme* t%e up*ate4 an e8mai& is *ispatc%e* )it% t%e ori'ina& an* ne) *etai&s as confirmation. $%e on&y time an app&ication )i&& be &oc3e* for e*itin' )i&& be )%en it %as been submitte* to a tutor for revie)4 after )%ic% point t%e app&ication )i&& no &on'er be accessib&e by t%e user.

-.-

dmissions 0iew 9unctionality)

Create $ew pplication)

"e'isterin' is not somet%in'

a*missions office staff or tutors )i&& be re.uire* to comp&ete. $%ese accounts )i&& be create* by t%e a*missions office to prevent unaut%ori6e* users obtainin' '&oba& access4 )it% t%e &o'in information bein' 'iven to t%e appropriate user.

Create pplication) +or t%e sa3e of 3eepin' t%e system centra&i6e*

an* accessib&e4 s%ou&* an app&ication be receive* by post4 t%e a*missions office staff )ou&* enter t%e *etai&s into a specia&i6e* app&ication form. $%is form is very muc% &i3e t%e stu*ent vie) app&ication form4 %o)ever none of t%e information is automatica&&y fi&&e* in an* an account is automatica&&y create* for t%e user.

0iew Submitted

pplications)

/ie)in' a&& of t%e

recent&y submitte* app&ications is somet%in' t%e a*missions office )i&& *o on a re'u&ar basis. A &ist of a&& t%e submitte* app&ications4 o&*est to ne)est to prevent some app&ications remainin' unrea*4 )i&& be vie)ab&e4 eac% of )%ic% e5pan*ab&e to vie) t%e entire *etai&s. $%is &ist )i&& be a set si6e4 for e5amp&e t%e &ast t)o *ays4 but t%is va&ue )i&& be variab&e to enab&e more or fe)er app&ications to be *isp&aye*.

? *ocuments create*

*enerate 3mails)

+or most users4 )%o app&y t%rou'% t%e )ebsite4

communication can be %an*&e* most effective&y by e8mai&s. $%ese )i&& be &ess forma& t%an t%e

by t%e system4 but nonet%e&ess )i&& convey t%e same information. $%e a*missions office staff )i&& se&ect t%e type of communication re.uire*4 base* on temp&ates4 an* inc&u*e any a**itiona& re.uire* information an* t%e system )i&& automatica&&y sen* t%e e8mai& to t%e correct user.

Software

Requirements Specification for Online University Admission System Page 1"

*enerate Documents) +or t%ose users )%o app&y by post4 communication cannot be carrie*

out t%rou'% emai&s an* instea* forma& *ocuments must be create* inc&u*in' a&& of t%e re.uire* information to be poste* bac3 to t%e app&icant. $%is function of t%e system )i&& 'enerate a number of suc% *ocuments ran'in' from acceptance &etters to &etters re'ar*in' missin' information.

0iew 1o%s

9 =%enever an action %as been comp&ete*4 a time stampe* &o'

s%ou&* be create* by t%e system4 *etai&in' t%e action comp&ete* an* t%e user )%o performe* it for reference purposes. $%ese &o's s%ou&* be vie)ab&e by t%e a*missions office staff an* by *efau&t s%ou&* *isp&ay t%e &o's for t%e past t)o %ours.

3dit6 dd <niversities9 +rom time to time4 a university2s ran3 may c%an'e in t%e tab&es use*

by t%e a*missions office. Since t%is tab&e )i&& be %e&* by t%e system for automatic ran3in' of app&ications4 it )ou&* be )ise to inc&u*e t%e abi&ity to e*it t%is information. A member of t%e a*missions office staff )i&& be ab&e to vie) t%e &ist of universities inc&u*e* in t%e university ran3in' an* e*it its *etai&s4 inc&u*in' name4 ran3 an* &ocation.

-.4 Tutor)

0iew

pproved

pplication

1uc%

&i3e

t%e

vie)

submitte* app&ications pa'e for a*missions office staff4 vie) approve* app&ications )i&& &ist t%e app&ications4 o&*est to ne)est4 t%at )ere *eeme* of a suitab&e .ua&ity to for)ar* to an a*missions tutor. $%e main *ifference )it% t%e approve* app&ications is t%at eac% is on&y sent to

one tutor4 t%us t%ere is no nee* for a &oc3in' mec%anism.

Compare pplication

9 -n some cases4 *ecisions about an e5ceptiona&&y 'oo* or

app&ication )i&& be simp&e4 'iven t%at t%e app&ication mi'%t be

e5ceptiona&&y ba*. -f4 %o)ever4 an app&ication is simi&ar to ot%er4 previous app&ications4 t%e tutor may %ave a more *ifficu&t *ecision to ma3e an* inconsistencies may be intro*uce*. ,sin' t%e automatic ran3in' of app&ications a tutor )i&& be ab&e to see a &ist of app&ications )it% a simi&ar ran3in'. $%is &ist )i&& %ave a *efau&t &en't% of 54 for e5amp&e4 but t%is )i&& be e5ten*ib&e if more comparisons are nee*e*4 an* t%e &ist )i&& inc&u*e app&ications of t%e same ran3 as )e&& as s&i'%t&y %i'%er an* &o)er ran3s.

Software

Requirements Specification for Online University Admission System Page 1#

-.+ System

0alidation) (n t%e comp&etion of eac% form in t%e system4 t%e system )i&& use a set of

va&i*ation functions to ensure t%at information is of t%e ri'%t type in eac% fie&*.

&a;e Recommendations) $%e system s%ou&* be ab&e to ma3e recommen*ations to t%e tutor

)%ic% )i&& be *eci*e* once an app&ication %as been submitte* by t%e a*missions office. $%e system cou&* ma3e its recommen*ation base* on t%e ran3in' of t%e app&ication4 )%ere any ran3 above a certain t%res%o&* )ou&* be accepte* an* any be&o) )ou&* be rejecte*.

Statistics)

-f t%e a*missions office so )is%es4 t%ey s%ou&* be ab&e to

vie) statistics 'at%ere* by t%e system re'ar*in' app&ications. $%ese statistics s%ou&* be *isp&aye* on a pa'e )it% in*ivi*ua&&y e5pan*ab&e sections4 suc% as e5ten*in' t%e number of app&ications receive* from t%e past year to t%e past t)o years.

Report *eneration)

@enerate reports base* on t%e se&ecte* criteria.

Software

Requirements Specification for Online University Admission System Page 1$

4.

Supplementary Requirements

Immediate 9eedbac;)

$%e System must try to ans)er a&& t%e

.ueries of t%e stu*ents an* it s%ou&* provi*e imme*iate fee*bac3 after 'ettin' any re.uest from t%e stu*ents. $%e system must provi*e t%e i&&usion to t%e stu*ents t%at4 t%ey are contact t%e rea& peop&es for process t%e A*mission tas3.

Reduce t#e Cost of dmission 'rocess)

$%e

main aim of t%e System is to re*uce t%e cost nee*e* for A*mission Process4 so it automatica&&y re*uces t%e manua& po)er nee*e* to perform t%e entire tas3 an* improve t%e .ua&ity of t%e )or3.

Increase t#e =uality of t#e 'rocess)

$%e

System faci&itates t%e )or3 of t%e universities an* t%e same time it must re*uce t%e )or3 &oa* of t%e or'ani6ation )it% e5pecte* .ua&ity. Fua&ity in t%e sense4 t%e system try to avoi* t%e mista3es t%at are usua&&y %appen *urin' t%e A*mission Process because names of t%e stu*ents sometimes misse* in t%e se&ecte* &ist an* ca&& &etters for t%e stu*ents a&so not sen* proper&y to t%e .ua&ifie* stu*ents.

&a;e t#e Interface Simple as 'ossible) $%e System must provi*e t%e simp&e an* easy interface for be'inners an* a&so provi*e

faci&ities for tec%nica& peop&es )%o are usin' t%e system. $%e interface must be simp&e as possib&e.

? system is fai&s

Reduced Time) $o perform any tas3 time is one of t%e important factors

to consi*er. -f t%e system not uti&i6e proper&y time4 t%an t%e entire aim of system is fai&s an* t%e

to reac% its 'oa&. So time ta3e to process a&& t%ese activities s%ou&* be &ess but t%e output s%ou&* be effective.

? bet)een t%at ot%er e5istin' system

&a;e t#e System as *lobal <nit) $%e System must

provi*e faci&ities to tie up )it% any ot%er e5istin' system an* transformation of messa'es

s%ou&* be not *epen* upon any ot%er server arc%itecture an* any ot%er p&atform.

Software

Requirements Specification for Online University Admission System Page 2%

5.

Ot#er $onfunctional Requirements

+.1 'erformance Requirements

Some Performance re.uirements i*entifie* is &iste* be&o)9

$%e *atabase s%a&& be ab&e to accommo*ate a minimum of 104000 recor*s of stu*ents.

$%e soft)are s%a&& support use of mu&tip&e users at a time.

$%ere are no ot%er specific performance re.uirements t%at )i&& affect *eve&opment. +." Security Requirements

Some of t%e factors t%at are i*entifie* to protect t%e soft)are from acci*enta& or ma&icious access4 use4 mo*ification4 *estruction4 or *isc&osure are *escribe* be&o). Specific re.uirements in t%is area cou&* inc&u*e t%e nee* to9

? ?

,ti&i6e certain crypto'rap%ic tec%ni.ues Geep specific &o' or %istory *ata sets

? ? ? ?

Assi'n certain functions to *ifferent mo*u&es "estrict communications bet)een some areas of t%e pro'ram C%ec3 *ata inte'rity for critica& variab&es :ater version of t%e soft)are )i&& incorporate encryption tec%ni.ues in t%e user>&icense

aut%entication process. ? $%e soft)are )i&& inc&u*e an error trac3in' &o' t%at )i&& %e&p t%e user un*erstan* )%at error

occurre* )%en t%e app&ication cras%e* a&on' )it% su''estions on %o) to prevent t%e error from occurrin' a'ain. ? Communication nee*s to be restricte* )%en t%e app&ication is va&i*atin' t%e user or &icense.

Ai.e.4 usin' %ttpsC.

Software

Requirements Specification for Online University Admission System Page 21

+.- 'ortability Requirements

Some of t%e attributes of soft)are t%at re&ate to t%e ease of portin' t%e soft)are to ot%er %ost mac%ines an*>or operatin' systems. $%is may inc&u*e9

<ava is use* to *eve&op t%e pro*uct. So it is easiest to port t%e soft)are in any environment.

+.4 &aintainability

$%e user )i&& be ab&e to reset a&& options an* a&& store* user variab&es to *efau&t settin's. +.+ Reliability

Some of t%e attributes i*entifie* for t%e re&iabi&ity is &iste* be&o)9

A&& *ata stora'e for user variab&es )i&& be committe* to t%e *atabase at t%e time of entry.

Data corruption is prevente* by app&yin' t%e possib&e bac3up proce*ures an* tec%ni.ues.

+.7 <sability requirements

Some of t%e usabi&ity re.uirements i*entifie* for t%is system are &iste* be&o)9

A &o'ica& interface is essentia& to an easy to use system4 spee*in' up common tas3s.

7rror prevention is inte'ra& to t%e system an* is provi*e* in a number of formats from sanity

c%ec3s to &imitin' free8te5t input. +.! vailability

A&& cac%e* *ata )i&& be rebui&t *urin' every startup. $%ere is no recovery of user *ata if it is

&ost. Defau&t va&ues of system *ata )i&& be assi'ne* )%en necessary.

Software

Requirements Specification for Online University Admission System Page 22

+.8 Software System ttributes

$%ere are a number of attributes of soft)are t%at can serve as re.uirements. -t is important t%at re.uire* attributes by specifie* so t%at t%eir ac%ievement can be objective&y verifie*. $%e fo&&o)in' items provi*e a partia& &ist of e5amp&es.

$%e input system )i&& a&&o) for inputtin' numbers4 operan*s4 specia& symbo&s an* &etters of t%e a&p%abet.

6.

C#an%e mana%ement 'rocess

As a team4 )e )i&& up*ate an* eva&uate our S"S *ocument every )ee3 as )e ma3e c%an'es in our *esi'n an* re.uirements. =e )i&& a** ne) *etai&e* information )%ic% )i&& inc&u*e9 researc%4 references4 c%arts an* 'rap%s4 an* more specifications an* re.uirements t%at )e fin* a&on' t%e )ay in t%e *esi'nin' an* imp&ementation of t%e pro*uct.

7.

Document pprovals

=e %ave no *ocument approva&s as of t%is time.

Software

Requirements Specification for Online University Admission System Page 23

8.

Supportin% information

ppendi( ) *lossary

C D3&IC'RO*R &>

An aca*emic pro'ram is a broa*

cate'ory for t%e stu*ent2s area of aca*emic interest. An aca*emic pro'ram Ho)nsI stu*ents an* is t%at or'ani6ationa& entity to )%ic% a stu*ent app&ies4 is a*mitte*4 an* u&timate&y 'ra*uates from.

C D3&IC I$STIT<TIO$ > 7ac% campus of t%e ,niversity of 1issouri )i&& be an

aca*emic institution. Separate -nstitutions a&&o) us to maintain separate co*e an* ru&e tab&es for eac% campus )%i&e 3eepin' a&& four campuses in t%e same *atabase.

C D3&IC ?3 R > 7ac% term is associate* )it% an aca*emic year for purposes of

reportin' an* financia& ai* accumu&ation. A;o)ever4 a stu*ent may %ave any summer term )or3 c%an'e* to point at eit%er t%e prece*in' or subse.uent aca*emic year.C Accountin' is *one at a term &eve& an* t%en summari6e* into a fisca& year )%ic% usua&&y para&&e&s an aca*emic year.

'>

Accounts Payab&e mo*u&e )it%in t%e Peop&e Soft +inance System. =i&& be

use* for issuin' stu*ent refun* an* t%ir* party sponsor refun* c%ec3s.

? c&ass &eve&.

CO<RS3 >

A course offere* by a sc%oo&4 usua&&y *escribe* in t%e course

cata&o'. A course %as a stan*ar* sy&&abus an* cre*it &eve&4 a&t%ou'% t%ese may be mo*ifie* at t%e Courses can contain mu&tip&e components suc% as &ecture4 *iscussion4 an* &ab. Courses are not term or even aca*emic year specific4 but t%ey *o %ave an effective or startin' *ate. Courses may be entere* in pen*in' status.

CO<RS3 1IST >

A &istin' of courses t%at is use* to satisfy an Course &ists must be estab&is%e* before aca*emic

aca*emic or enro&&ment re.uirement. re.uirements are *eve&ope*.

T3R& 933S @@ $%e $erm +ee rate tab&e a&&o)s us to c%ar'e *ifferent rates base* on t%e

number of units a stu*ent is ta3in' in a particu&ar term. =e can *ifferentiate t%e course &oa* by aca*emic structure4 campus4 &ocation of t%e course an* %o) t%e course is tau'%t as )e&& as ot%er stu*ent attributes.

Software

Requirements Specification for Online University Admission System Page 24

T<ITIO$ *RO<' > A $uition @roup is a 'roup of stu*ents )%o are c%ar'e* t%e same set of

fees un*er t%e same 'enera& ru&es.

? anot%er.

5 S2 '3RIOD >

$%at perio* of time Ae5presse* in *aysC *urin'

)%ic% cre*its an* c%ar'es resu&tin' from re'istration a**>*rop activity H)as%I a'ainst one

Software

Requirements Specification for Online University Admission System Page 2

ppendi( ,) nalysis &odels Data 9low Dia%ram 1) @ive A*ministrator -nformationJs @ive Detai&s Stu*ent

@et App&icant Detai&s Se&ecte* "eport @et /acancy Detai&s Process A

@et A*mission Se&ection Process Status (n&ine C%at

9i%ure ") Data 9low Dia%ram level A

Software

Requirements Specification for Online University Admission System Page 2!

Data 9low Dia%ram ") Stu*en :o' (ut "e'ister +orm Eumber ? Pass)or* +orm Status C%at )it% Counci&or Data Store /a&i* form no. ? pass)or* 1ember2s Section

Se&ection process ,p*ate Detai&s Save

9i%ure -) Data 9low Dia%ram

Software

Requirements Specification for Online University Admission System Page 2"

Overall <se Case Dia%ram)

"e'ister for Course

/ie) Course Detai&s tu*ent

on*u ct pen

1o*ify Course -nformation2s

e'ister C&ose "e'istration

Provi*e Course -nformation2s KK,sesLL

reate Course Cata&o' KK75ten*sLL

Co&&ect Course -nformation2s $utor

9i%ure 4) <se Case Dia%ram