Software Requirement Specification | 4

SOFTWARE REQUIREMENT SPECIFICATIONS

2.1. Requirements Specificti!n "!cument
According to Roger Pressman in Software Engineering: A Practitioner's
Approach (McGraw!i"" Pu#"ications$ %SEPA&'(()*+ the requirement specification
document is produced at the end of Ana",sis of the s,stem- .his document is a /er,
comprehensi/e document 0 contains a"" the 1ser requirements 0 Ana",sis diagrams-
.he Requirements are #road", di/ided into two groups:
2unctiona" requirements
3onfunctiona" requirements
2.1.1. FUNCTIONA# REQUIREMENTS
.he main functiona" requirements of the 1ni/ersit, semester cata"ogue (14S$ are the
fo""owing:
'- .he 14S sha"" pro/ide a means for entering and storing:
a- co""ege information5
#- department information5
c- professor information5
d- c"ass information5
e- #ui"ding information5
f- c"assroom information-
4o""ege 6e# Porta"
Software Requirement Specification | 7
8- .he 14S sha"" schedu"e+ if possi#"e+ the c"asses into c"assrooms-
9- .he 14S sha"" ta:e into consideration for generating the schedu"e the
Parameters
c"assroom si;e+ c"assroom t,pe+ and distance from the department- .hese
parameters sha"" #e se"ected #, the user from a "ist of predefined /a"ues-
4- .he 14S sha"" sa/e the schedu"e in a format that can #e used to generate a
1ni/ersit, Semester 4ata"og that is reada#"e #, humans-
7- .he 14S sha"" notif, the user if no /a"id schedu"e can #e generated and sha""
indicated the causes that pre/ent the generation of a /a"id schedu"e-
<- .he 14S sha"" write the schedu"e containing c"ass and c"assroom information to a
fi"e that can #e read #, supp"ied we# pages so that these can #e posted onto the
uni/ersit,
2.1.2. NON$FUNCTIONA# REQUIREMENTS
.he nonfunctiona" requirements consist of
An%&sis n' "esi(n
.he Ana",sis of the s,stem is done in each and e/er, phase- =esigns are
de/e"oped #, using Android concept which inc"udes the user interface+ which consists
of #uttons+ te>t /iew+ "ist /iew and spinner+ etc-
Mintin)i%it&
4o""ege 6e# Porta"
Software Requirement Specification | <
A"" the modu"es must #e c"ear", separate to a""ow different user interfaces to #e
de/e"oped in future- .hrough thoughtfu" and effecti/e software engineering+ a"" steps of
the software de/e"opment process wi"" #e we"" documented to ensure maintaina#i"it, of
the product throughout its "ife time- A"" de/e"opment wi"" #e pro/ided with good
documentation-
Perf!rmnce
.he response time+ uti"i;ation and throughput #eha/ior of the s,stem- 4are is
ta:en so as to ensure a s,stem with comparati/e", high per formance-
Us)i%it&
.he ease of use and training the end users of the s,stem is usa#i"it,- S,stem
shou"d ha/e qua"ities "i:e "earning a#i"it,+ efficienc,+ affect+ contro"- .he main aim of the
pro?ect is to increase the scope of page designer to design a page and to reduce the
rewor: of the programmer-
M!'ifi)i%it&
.he ease with which a software s,stem can accommodate changes to its software
is modifia#i"it,- @ur pro?ect is easi", adapta#"e for changes that is usefu" for the
app"ication to withstand the needs of the users-
P!rt)i%it&
.he a#i"it, of the s,stem to run under different computing en/ironments- .he
en/ironment t,pes can #e either hardware or software+ #ut is usua"", a com#ination of
4o""ege 6e# Porta"
Software Requirement Specification | )
#oth-
Reus)i%it&
.he e>tent to which e>isting app"ication can #e reused in new app"ication- @ur
app"ication can #e reused a num#er of times without an, technica" difficu"ties-
Securit&
.he factors that protect the software from accidenta" or ma"icious access+ use+
modification+ destruction+ or disc"osure- Securit, can #e ensured as the pro?ect
in/o"/es authenticating the users-
2.2 *AR"WARE AN" SOFTWARE REQUIREMENTS
Ser+er si'e
Minimum: '8AGB !ard =is:
Pentium : PCD Processor
RAM : 8GB
@S : 6indows EP or higher /ersion
C%ient si'e
Minimum: 4AGB !ard =is:
Pentium: PCD Processor
4"ient side "anguage: ?a/ascript
=ata#ase: SFG ser/er 8AAH
4o""ege 6e# Porta"