Académique Documents
Professionnel Documents
Culture Documents
Contents
Table of Contents
1. Introduction
2. Phases .
2.1 Module 1
2.2 Module 2
2.3 Module 3
3. Purpose
3.1 Scope
4. Application, Objective and ene!its ..
". #M$ ..
".1 Structural %ia&ra's
".2 %eplo('ent %ia&ra's
".3 ehavioral %ia&ra's
".4 Se)uence %ia&ra's
"." *ollaboration %ia&ra's
".+ State chart %ia&ra's
+. Architecture %ia&ra' .
,. %atabase .
-. #ser Inter!ace
.. So!t/are 0e)uire'ent Speci!ication 1S0S2
..1 Overvie/
..2 Product Perspective ...
..3 S(ste' Inter!aces ..
..3.1 #ser Inter!ace
..3.2 3ard/are inter!ace
..3.3 So!t/are Inter!aces
..3.4 Me'or( *onstraints ..
..4 Product 4unctions
.." #ser *haracteristics .
..+ *onstraints
.., $o&ical %atabase 0e)uire'ents
..- %esi&n *onstraints
... Standard *o'pliance
..15 0eliabilit( ...
..11 Availabilit( .
..12 Securit( .
..13 Maintainabilit( ...
..14 Portabilit( ..
..1" S(ste' Mode .
..1+ Supportin& In!or'ation
..1, %ocu'ent *ontrol
..1- Appendi6 A
..1. Speci!ic 0e)uire'ents ..
..25 Per!or'ance re)uire'ents .
..21 So!t/are S(ste' Attributes ..
..22 4eatures ..
..23 Objects ..
..24 Sti'ulus
..2" 0esponse
..2+ 4unctional 3ierarch( .
..2, Additional *o''ents
15. Pro&ra''in& *ode
11. 7echnolo&( 4eatures .
11.18299 .
11.282M9
11.38%*
11.4:9 S90;I*9S..
11."4$AS3 #I$%904."..
11.+A<%00OI%..
12. 7estin&
12.1 lac= o6 7estin&
12.2 :hite o6 7estin&
12.3 Securit( 7estin&
12.4 *o'patibilit( 7estin&
13. *onclusions
14. 4uture 9nhance'ents
1". 0e!erences ..
1. Introduction
Interactive lectures are an i'portant /a( to enhance student learnin&, particularl( in lar&e
classes. 7he( help to =eep students> attention !ocused on the class, &ive students repeated
opportunities to practice, and increase student retention o! lecture 'aterial. 7he( also provide an
eas( /a( to e6peri'ent /ith di!!erent teachin& techni)ues. In s'all classes 1less than 35
students2 'ost students are prepared to as= )uestions i! the( are stru&&lin& to understand /hat is
bein& covered b( the lecturer. 3o/ever the( 'a( be inti'idated in lar&er &roups. In s'all
classes students have a sense o! inclusion and involve'ent that enhances their learnin& and
'otivation. ut this is lost in lar&er classes leadin& to reduced satis!action and less e!!ective
learnin&.
! "#ase
Module1
*reate a /eb ad'inistration !ront end /here a lecturer can activate?deactivate users, upload
presentations, upload )ui@@es, vie/ statistics1results, !eedbac=s2.
Module!
*reate an android application !or students to send their )uestions and ans/ers to the pro!essor.
A!ter validatin& the( /ill receive the results /hich /ill be presented b( this android application.
Module$
*reate a lecturer 'odule that /ill receive a students> doubts?)uestions /hile the lecture is bein&
delivered and to 'ana&e the si'ilar and dissi'ilar doubts a'on& the'.
Module%
%atabase to store all the )ui@@es and ans/ers to the' as /ell as the !eedbac=s &iven b( the
students re&ardin& the lecture.
"ur&ose
7he purpose o! this project is to develop an Interactive $ecture %eliver( S(ste' in real ti'e to
address the students directl( in vast class roo's /here hundreds o! students &ather !or an(
session.
Sco&e
7he scope o! this project is to 'a=e the lectures ver( interactive a'on& students and lecturers in
order to clari!( the students doubts then and there durin& a session in lar&e lecture halls.
%. A&&lication' (b)ecti*e and +enefits
A&&lication
7he application /ill be utili@ed b( the #sers.
,-oal
7he :eb Site is intended to avoid server !ailure, virus attac= and decrease the
in!rastructure costs, 'aintenance costs occurred to 'aintain the application .
,(b)ecti*e
%esi&n is the !irst step in 'ovin& !ro' proble' do'ain to solution do'ain. %esi&n is essentiall( the
brid&e bet/een re)uire'ents speci!ication and the !inal solution.
7he &oal o! desi&n process is to produce a 'odel or representation o! a s(ste' can be used later to
build that s(ste'. 7he produced 'odel is called the A%esi&n o! the S(ste'>.
It is a plan !or a solution o! the s(ste'.
7he objective o! desi&n phase is toB
*reate #ser Inter!ace.
*reate Application.
.
.. UML
%esi&n Patterns brou&ht a paradi&' shi!t in the /a( object oriented s(ste's are desi&ned.
Instead o! rel(in& on the =no/led&e o! proble' do'ain alone, desi&n patterns allo/ past
e6perience to be utili@ed /hile solvin& ne/ proble's. 7raditional object oriented desi&n 1OO%2
approaches such as ooch, OM7, etc. advocated identi!ication and speci!ication o! individual
objects and classes. %esi&n Patterns on the other hand pro'ote identi!ication and speci!ication o!
collaborations o! objects and classes. 3o/ever, 'uch o! the !ocus o! recent research has been
to/ards identi!ication and catalo&in& o! ne/ desi&n patterns. 7he e!!ort has been to assi'ilate
=no/led&e &ained !ro' desi&nin& s(ste's o! the past, in various proble' do'ains. 7he proble'
anal(sis phase has &ained little bene!it !ro' this paradi&'. Most projects still use traditional
object oriented anal(sis 1OOA2 approaches to identi!( classes !ro' the proble' description.
0esponsibilities to those classes are assi&ned based upon the obvious description o! entities
&iven in the proble' de!inition.
Pattern Oriented 7echni)ue 1PO72 is a 'ethodolo&( !or identi!(in& interactions a'on& classes
and 'appin& the' to one or 'ore desi&n patterns. 3o/ever, this 'ethodolo&( also uses
traditional OOA !or assi&nin& class responsibilities. As a result, its interaction oriented desi&n
phase 1driven b( desi&n patterns2 receives its input in ter's o! class de!initions that 'i&ht not
lead to best possible desi&n.
7he 'issin& piece here is the lac= o! an anal(sis 'ethod that can help in identi!(in& class
de!initions and the collaborations bet/een the' /hich /ould be a'enable to application o!
interaction oriented desi&n. 7here are t/o =e( issues here. 4irst is to co'e up /ith &ood class
de!initions and the second is to identi!( &ood class collaborations.
It has been observed in that even arrivin& at &ood class de!initions !ro' the &iven proble'
de!inition is nonCtrivial. 7he =e( to various success!ul desi&ns is the presence o! abstract classes
1such as an event handler2 /hich are not 'odeled as entities in the ph(sical /orld and hence do
not appear in the proble' description. In anticipatin& chan&e has been proposed as the 'ethod
!or identi!(in& such abstract classes in a proble' do'ain. Another di!!icult tas= is related to
assi&n'ent o! responsibilities to entities identi!ied !ro' the proble' description. %i!!erent
responsibilit( assi&n'ents could lead to co'pletel( di!!erent desi&ns. *urrent approaches such
as *oad and Dourdon, PO7 etc. !ollo/ the si'ple approach o! usin& entit( descriptions in the
proble' state'ent to de!ine classes and !i6 responsibilities. :e propose to !ollo/ a !le6ible
approach to/ards assi&nin& responsibilities to classes so that the best responsibilit( assi&n'ent
can be chosen.
7he second issue is to identi!( class collaborations. 7echni)ues such as PO7 anal(@e interactions
a'on& di!!erent sets o! classes as speci!ied in the proble' description. Such interactin& classes
are then &rouped toðer to identi!( desi&n patterns that 'a( be applicable. 3o/ever, as
'entioned earlier, onl( the interactions a'on& obvious classes are deter'ined currentl(. Other
interactions involvin& abstract classes not present in the proble' or interactions that beco'e
!easible due to di!!erent responsibilit( assi&n'ents are not considered. :e present so'e
techni)ues that enable the desi&ner to capture such interactions as /ell.
Interaction +ased Anal/sis and Desi0n
To&1do2n a&&roac#
7his approach is applicable to situations /here the desi&ner =no/s the solution to the &iven
proble'. It is true !or proble' do'ains that have /ell established hi&hClevel solutions and
di!!erent i'ple'entations var( in lo/ level details 1!or e.&. 9nterprise 0esource Plannin& 190P2
s(ste's2. 3er 'ain concern is to reali@e that solution in a /a( such that the i'ple'ented s(ste'
has nice properties such as 'aintainabilit( and reusabilit( etc.
7o achieve this &oal, the s(ste' desi&ner selects appropriate desi&n patterns that !or' the
buildin& bloc=s o! her solution. 3avin& obtained this desi&n te'plate 1desi&n t(pe2, she 'aps the
classes and objects participatin& in those patterns to the entities o! the proble' do'ain. 7his
'appin& i'plicitl( de!ines the responsibilities o! various classes?objects that represent those
entities. 7o help clari!( the concept, consider a scenario /here an architect is assi&ned the tas= o!
buildin& a !l(over. 4l(over construction is an established science and the architect =no/s the
solution to the proble'. She starts b( identi!(in& co'ponent patterns such as road strip, support
pillars, side railin&s and so on. 3avin& done that, she 'aps the participatin& objects to actual
entities in the proble' do'ain. 7his /ould involve de!inin& the len&th and /idth o! the road
strip based upon the space constraints speci!ied in the proble'. 7he hei&ht and /ei&ht o! the
pillars &et decided based upon the load re)uire'ents speci!ied. 7he entr( and e6it points &et
decided based upon the &eo&raph( o! the location and so on. 7his results in a concrete desi&n
instance. So'e ne/ classes or objects, not e6istin& in the do'ain 'odel, 'a( also have to be
introduced !or a success!ul instantiation o! the desi&n te'plate. 4or instance, the proble'
do'ain 'a( not 'odel an abstract entit( such as an event handler /hich 'a( be a participant in
so'e portion o! the desi&n te'plate. Such &eneric classes?objects 'a( be dra/n !ro' a co''on
repositor( o! utilit( classes. Interaction driven anal(sis phase here is si'ple since the interactions
1in the !or' o! desi&n patterns2 are alread( /ell established and directl( obtained !ro' the
=no/led&e base.
+otto31u& a&&roac#
7his approach is applicable in scenarios /here interactions in the proble' do'ain are not /ell
understood and need to be discovered and e6plored. 7his situation is a !unda'ental proble'
!aced b( the desi&ners o! object oriented s(ste's. It relates to the !act that objects oriented
anal(sis 1OOA2 does not help 'uch in creatin& a solution to the proble' at hand. 7he anal(sis
phase is 'ainl( concerned /ith enhancin& the understandin& o! the proble' do'ain. 7his
=no/led&e is then later used b( a proble' solvin& approach to co'e up /ith a solution
possessin& &ood desi&n properties. As a result, at the end o! the anal(sis phase the desi&ner has a
set o! /ell de!ined co'ponents that need to be asse'bled toðer !or reali@in& a solution. 4or
instance, to build a route !inder application the OOA phase helps in 'odelin& the do'ain objects
such as roads, vehicles, cities, addresses etc. but does not actuall( provide a solution !or !indin&
routes bet/een t/o &iven addresses. 7his is si'ilar to havin& various pieces o! a ji&sa/ pu@@le
but the pu@@le still needs to be solved. 7he proble' in so!t/are s(ste's is !urther co'plicated b(
the !act that there is &enerall( no uni)ue solution to a proble'. 7here are al/a(s tradeCo!!s at
various sta&es and the resultin& desi&ns are a re!lection o! the choices 'ade at those sta&es. In
the ji&sa/ pu@@le e6a'ple this is si'ilar to the situation /here di!!erent sets o! the sa'e pu@@le
are available each di!!erin& !ro' another in ter's o! the desi&n o! its co'ponent pieces. So'e
co'ponent desi&ns 'a( help in solvin& the pu@@le !aster and 'ore e!!icientl( than others.
7he botto'Cup approach helps in such situations /here the entities in the proble' do'ain have
been identi!ied b( traditional OOA techni)ues but 'ultiple choices e6ist in ter's o! assi&nin&
responsibilities to those entities. #nli=e topCdo/n approach, the 'appin& o! responsibilities to
entities is not dictated b( the desi&n solution speci!ied b( the desi&ner. Instead, the tas= o! the
desi&ner here is to tr( various responsibilit( assi&n'ents and create an interaction speci!ication
involvin& those objects. 7he objective o! this interaction driven anal(sis is to obtain an
interaction speci!ication that helps in arrivin& at a solution /ith best desi&n characteristics
possible. 3avin& identi!ied the entities in the do'ain, the startin& point !or the desi&ner is to
identi!( various alternatives available !or assi&nin& responsibilities to individual objects. 3er
do'ain =no/led&e helps her in this tas=. Eiven these alternatives !or potential object de!initions
and standard utilit( objects 1such as schedulers, event handlers etc.2, the ne6t step is to !ind
co'positions o! these buildin& bloc=s 1i.e. interactions o! these objects2 that provide alternative
solutions to the proble'. 7his tas= is a nonCtrivial one especiall( /hen done 'anuall(. 7here are
just too 'an( co'binations to be considered, !or an( hu'an desi&ner to obtain alternative
solutions in a reasonable a'ount o! ti'e. :e need to appl( 1se'iC2auto'ated so!t/are
co'position techni)ues based on so'e !or'al speci!ication. Several such approaches have been
recentl( investi&ated in the conte6t o! eCservices. 7hese include /or=!lo/ based approaches and
AI Plannin& based techni)ues. Other !or'al techni)ues !or speci!(in& co'position include PetriC
net based 'odels, auto'ataCbased 'odelsF te'poral lo&ics etc. !ro' veri!ication co''unit( and
GHuer(, GM$ constraint tools based techni)ues !ro' data 'ana&e'ent co''unit( .
7he resultin& candidate co'positions 1i.e. interaction speci!ications2 then need to be co'pared
/ith e6istin& desi&n patterns either 'anuall( or auto'aticall(. It is not be(ond i'a&ination to
visuali@e that /ith advance'ent in auto'ated co'position techni)ues, ne/ desi&n patterns 'a(
&et identi!ied durin& this process. 4or instance, techni)ues such as 0ein!orce'ent $earnin& have
resulted in ne/ novel solutions in various do'ains such as pla(in& ac=&a''on. In such a case,
the resultin& desi&ns 'a( need to be evaluated 'anuall(. 7he best desi&n a'on& the alternatives
is then chosen !or i'ple'entin& the s(ste'.
(&en Issues
Identif/in0 interactions
7his is a crucial step in the anal(sis phase and the success o! re'ainin& phases depends on it.
7he issue here is to identi!( interactions /hich are not evident !ro' the proble' description but
'a( hold the =e( to an e!!icient desi&n solution. 7he botto'Cup approach proposed in this paper
ta=es a step in this direction but a lot 'ore /or= is needed. 7he anal(sis 'ethod should be such
that it is able to incorporate abstract classes such as event handlers, pro6ies etc. Moreover,
current anal(sis 'ethods 'ap entities to responsibilities o! individual classes in ter's o! services
the( provide and 'ethods the( invo=e on other classes. 3o/ever, an entit( 'a( be reali@ed b( a
set o! classes. 4or instance, an adapter class hides the inter!ace o! an adoptee class and the(
collectivel( provide the desired !unctionalit(. Si'ilarl(, an abstraction and its i'ple'entation
provide a sin&le !unctionalit( throu&h separate classes resultin& in increased 'aintainabilit(. 7he
anal(sis 'ethod needs to be able to deter'ine /hen is it appropriate to reali@e an entit(
responsibilit( b( 'eans o! 'ultiple interactin& classes.
Re&resentation of Class Res&onsibilities
Since /e need to speci!( di!!erent alternative class responsibilities, as in botto'Cup approach, a
'echanis' is re)uired to docu'ent the' in a 'achine interpretable !or'at. So'e o! these
responsibilities /ould &et captured in the !or' o! 'ethods a class e6ports or 'ethods it invo=es
on other classes. 3o/ever, other responsibilities /ith respect to its interaction /ith other classes
need to be e6plicitl( speci!ied. 7hese 'a( include preC and postCconditions !or di!!erent 'ethod
invocations, other properties such as >hasSa'eInter!aceAs Ianother classJ>, >hidesInter!aceO!
Ianother classJ> etc. $an&ua&es such as could be used as it is or e6tended !or this purpose.
Lan0ua0e for S&ecif/in0 Desi0n "atterns
7he approaches !or OO %esi&n proposed in this paper !avor auto'atic techni)ues over 'anual
ones !or reasons described earlier. 7his 'eans that /e need a 'echanis' to be able to e6press
desi&n patterns in a !or'at a'enable to be read and interpreted b( pro&ra's. So'e atte'pts
have been 'ade at de!inin& such pattern description lan&ua&es K14, 13L. One o! these or so'e
variation o! these could be used to e6press desi&n patterns in a !or'al lan&ua&e.
Co3&arison of Soft2are Desi0ns
Once /e have alternative desi&ns available, the( need to be co'pared to arrive at the best one.
9ach desi&n 'a( consist o! 'ultiple desi&n patterns. 7he criteria here /ould not be to si'pl(
count the nu'ber o! desi&n patterns used but to evaluate the interaction bet/een patterns and
also bet/een other desi&n ele'ents used. 7his /ould involve an understandin& o! &ood and bad
desi&n interactions and an abilit( to identi!( the' in a &iven desi&n. 7he !inal challen&e /ould
be to do it auto'aticall(.
..1 Structural Dia0ra3
Class Dia0ra3
*lass dia&ra's identi!( the class structure o! a s(ste', includin& the properties and 'ethods o!
each class. Also depicted are the various relationships that can e6ist bet/een classes, such as an
inheritance relationship. 7he *lass dia&ra' is one o! the 'ost /idel( used dia&ra's !ro' the
#M$ speci!ication
Class Dia0ra3s are 0i*en to de&ict interactions
Student
username
password
login()
sendQueries()
attemptQuiz()
sendFeedback()
Professor
username
password
register()
login()
receiveQueries()
viewResults()
viewFeedback()
Admin
username
passowrd
login()
registerStudents()
managePresentations()
manageQuiz()
manageUserdetails()
Database
presentationTable
QuizTable
usersTable
sendsResponse()
(b)ect Dia0ra3
Object dia&ra's 'odel instances o! classes. 7his t(pe o! dia&ra' is used to describe the s(ste'
at a particular point in ti'e. #sin& this techni)ue, (ou can validatin& the class dia&ra' and itMs
'ultiplicit( rules /ith realC/orld data, and record test scenarios. 4ro' a notation standpoint,
Object dia&ra's borro/ ele'ents !ro' *lass dia&ra's.
Co3&onent Dia0ra3
*o'ponent dia&ra's !all under the cate&or( o! an i'ple'entation dia&ra', a =ind o! dia&ra'
that 'odels the i'ple'entation and deplo('ent o! the s(ste'. A *o'ponent %ia&ra', in
particular, is used to describe the dependencies bet/een various so!t/are co'ponents such as the
dependenc( bet/een e6ecutable !iles and source !iles. 7his in!or'ation is si'ilar to that /ithin
'a=e !iles, /hich describe source code dependencies and can be used to properl( co'pile an
application.
..! De&lo/3ent Dia0ra3
%eplo('ent dia&ra's are another 'odel in the i'ple'entation dia&ra' cate&or(. 7he
%eplo('ent dia&ra' 'odels the hard/are used in i'ple'entin& a s(ste' and the association
bet/een those hard/are co'ponents. *o'ponents can also be sho/n on a %eplo('ent dia&ra'
to sho/ the location o! their deplo('ent. %eplo('ent dia&ra's can also be used earl( on in the
desi&n phase to docu'ent the ph(sical architecture o! a s(ste'.
..$ +e#a*ioral Dia0ra3s
Use Case Dia0ra3
#se *ase dia&ra's identi!( the !unctionalit( provided b( the s(ste' 1use cases2, the users /ho
interact /ith the s(ste' 1actors2, and the association bet/een the users and the !unctionalit(. #se
*ases are used in the Anal(sis phase o! so!t/are develop'ent to articulate the hi&hClevel
re)uire'ents o! the s(ste'. 7he pri'ar( &oals o! #se *ase dia&ra's includeB
Providin& a hi&hClevel vie/ o! /hat the s(ste' does
Identi!(in& the users 1NactorsN2 o! the s(ste'
%eter'inin& areas needin& hu'anCco'puter inter!aces
#se *ases e6tend be(ond pictorial dia&ra's. In !act, te6tCbased use case descriptions are o!ten
used to supple'ent dia&ra's, and e6plore use case !unctionalit( in 'ore detail.
Register
login
receiveQueries
viewResults
Professor1
viewFeedback
adminLogin
registerStudents
managePresentations
manageQuiz
Admin1
maintainUserDetails
login
sendQueries
attemptQuiz
Student1
sendFeedback
..% Se4uence Dia0ra3
Se)uence dia&ra's docu'ent the interactions bet/een classes to achieve a result, such as a use
case. 7he Se)uence dia&ra' lists objects hori@ontall(, and ti'e verticall(, and 'odels these
'essa&es over ti'e.
A : admin P : professor S : student Android : application DB : database Web : application
login
upload presentations, quiz, userdetails
store all fles and details
login
get presentation
login
send doubts
presents a pop up message on screen
update student status
presents list of presentations
display quiz
send answers for the quiz
sends answers for validation
register students
get results
... Collaboration Dia0ra3
*ollaboration dia&ra's 'odel the interactions bet/een objects. 7his t(pe o! dia&ra' is a cross
bet/een an object dia&ra' and a se)uence dia&ra'. It uses !reeC!or' arran&e'ent o! objects
/hich 'a=es it easier to see all iterations involvin& a particular object.
A : admin
P :
professor
S :
student
Android :
application
DB :
database
Web :
application
1: login
2: register students
3: upload presentations, quiz, userdetails
5: login
7: get presentation
11: update student status
12: display quiz
8: login
9: send doubts
13: send answers for the quiz
10: presents a pop up message on screen
14: sends answers for validation
15: get results
4: store all fles and details
6: presents list of presentations
..5 State c#art Dia0ra3
State dia&ra's, are used to docu'ent the various 'odes 1NstateN2 that a class can &o throu&h, and
the events that cause a state transition.
..6 Acti*it/ Dia0ra3
Activit( dia&ra's are used to docu'ent /or=!lo/s in a s(ste', !ro' the business level do/n to
the operational level. 7he &eneral purpose o! Activit( dia&ra's is to !ocus on !lo/s driven b(
internal processin& vs. e6ternal events.
5. Arc#itecture Dia0ra3
Project architecture represents no o! co'ponents /e are usin& as part o! our project and the
!lo/ o! re)uest processin&.
6. Database
RealTi3e1Interacti*e Lecture Deli*er/ S/ste3
Data+aseTables
UserDetails Table:
DoubtsTable:
FeedBack Table:
ManagementDetails Table:
PresentationTable:
QuizTable:
ResultsTable:
7. User InterfaceB
8Version 1.9.9:
Approvals ignature Block
(r0ani;ation Res&onsibilit/ Si0nature Date
*usto'er ?custo'er representative
Project Mana&er
So!t/are Hualit( Assurance $eader
So!t/are *on!i&uration Mana&e'ent
$eader
#ser %ocu'entation $eader
#ser <a'e
#ser 7rainin& $eader
Definitions' Acron/3 and Abbre*iation
Ter3 or Acron/3 Definition
Stora&e Eenerall(, Stora&e can be de!ined as the act o! storin&
so'ethin&
Store Mana&e'ent Store Mana&e'ent can be si'pl( de!ined as 'ana&in& or
'aintain the stored data properl(.
82M9 Application An Application /hich is deplo(ed and run on 'obile.
<.1 (*erall Descri&tion
7he 0eal 7i'e Interactive $ecture %eliver( S(ste' is 'otivated b( the need to increase
students> interaction /ith the lecturer in real ti'e durin& a lecture. :ith the &ro/th o! the
nu'ber o! students in a class, interaction /ith students has beco'e increasin&l( di!!icult. 7his
s(ste' co'prises o! a /ebsite that 'aintains pro!iles o! lecturers and lecture 'aterial
1presentations, )ui@@es, student !eedbac=, etc.2. 7he ai' o! this project is to build a s(ste' that
!acilitates !eedbac= !ro' students and also to !acilitate interactive )uestionCans/er sessions /ith
the teacher via our 'obile client that runs on an( 8ava enabled 'obile phone /ith an internet
connectivit(. $ecturers /ould be 'ana&in& the presentations o! their respective subjects and also
conduct )ui@@es.
<.! "roduct "ers&ecti*e
7he project is a part o! a lar&e s(ste'.
+loc= dia0ra3B 7he 'ajor co'ponents o! the lar&er s(ste' are sho/n as belo/.
<.$ S/ste3 Interfaces
%escription o! various inter!aces used in the s(ste' is described in the subse)uent para&raph.
<.$.1 User Interfaces
Interface bet2een t#e soft2are &roduct and its usersB
#ser !riendl( inter!aces as depicted belo/ /ill be used.
1. Screen for3ats are re)uired to be created /ith !ollo/in& !eaturesBC
a2 #ser !riendl(.
b2 Indicate the Mandator( !ields b( asteris= 1O2.
c2 4ill up de!ault values /here ever possible
d2 Eive co'bo bo6es in all input screens.
e2 #ser and %ata entr( personnel details should be stored in the database throu&h
PSaveQ button.
!2 Authentication o! users should be carried out /here ever re)uired.
!. >eb "a0e or 2indo2 la/outs
9ach screen should have
Menu driven !acilit(
#ni!or'it(
*onsistenc(
3. (ut&uts
Anal(tical outputs should be supported b( &raphs.
a2 4or each output there should be provision o! printin&
c2 9'ails should be /ell structured
d2 9ach paper output should be !or'atted to A4 si@e paper.
%. D(s ?In&ut@
a2 9ach input bo6 to be supported b( label
b2 Eive tool tips /here re)uired
c2 Eive !or'ats 1''? dd ?((2
d2 Provide 7ab Inde6
e2 Input ele'ents /ithout visible labels s#ould continue to contain te6t 1search,
lo&in2
Enter search t
Search site
!2
Enter login nam
Pass/ord
Login
&2 radio inputs s#ould have one option chec=ed as de!ault
.. D(NTs ?In&uts@
a2 %on>t distract users !ro' their &oals
b2 %on>t use dar= bac=&round /ith dar= !ont colors
c2 %on>t use too 'an( colors
5. Error 3essa0es Eive s'all error 'essa&es li=e PIncorrect %ataQ or PIncorrect %ate 4or'atQ
or P4ield is re)uiredQ and supple'ent it /ith PO=Q utton.
<.$.! Aard2are Interfaces
4ollo/in& 3ard/are Inter!aces are re)uiredB
1. 1E 0AM
2. -5E 3ard%is=
3. Pentiu' 4 Processor
4. Internet *onnectivit(
<.$.$ Soft2are Interfaces
4ollo/in& So!t/are is re)uiredBC
8ava
Adobe 4lash uilder 4.".1
M( 9clipse -.+
8oss ".1
M(s)l ".1
Android S%R
<.$.% Me3or/ Constraints
0AM /ith 'ini'u' 1 E and 45 E 3% space
1.1.1.1 Broad level software requirements :
Re4uire3ent Re3ar=s
1. Ma=e #ser !or 0e&istration. Provide a
0e&istration and
authentication user
inter!ace.
!. Allo/s #ser to #pload 4iles
$. Allo/s #ser to ;ie/ the 4iles
%. Allo/s #ser to %o/nload the 4iles
<.% "roduct Bunctions
Database Bunctions
1. %atabase should have the !acilit( to
a2 insert records,
b2 update,
c2 edit,
d2 delete 10estricted users onl(2,
e2 Search and
!2 Sort records.
&2 *reate and edit 'aster and transaction records.
h2 All the interaction to and !ro' the database should be throu&h :eb Pa&es.
i2 %atabase should have !ollo/in& tablesBC
I. Data Entr/ "ersonnel 4irst <a'e, $ast <a'e, Address, *ontact
%etails, Huali!ication, Place o! /or=, %esi&nation. etc
II. Data Entr/ "oints user credentials.
2. Aut#entication
#sers at all levels should be authenticated be!ore &ivin& the' access.
$. Anal/sis
Outputs o! all anal(sis should be in the !or' o!
a2 %ata in tabular !or'
b2 Eraphical representation o! Per!or'ance.
<.. User c#aracteristics
4ollo/in& are the characteristics o! the intended usersBC
9ducational $evelB $evel o! the users is bet/een 9ducated to hi&hl( educated.
96perienceB 96perienced in their do'ain but trainin& in the proposed application.
7echnical 96pertiseB 7rainin& re)uired in the proposed application.
<.5 Constraints
Site Ada&tion Re4uire3ents
Onl( s(ste' Ad'inistrator and %A are authori@ed to carr( out this tas= jointl(.
Assu3&tions and De&endencies
It is assu'ed that all the s(ste's /ill have the basic 3:, S: and *o''unication Inter!aces
available. 7he users are trained in usin& the application.
A&&ortionin0 of Re4uire3ents
Identi!( re)uire'ents that 'a( be dela(ed until !uture versions o! the s(ste'.
All re)uire'ents /ill be 'et.
<.6 Lo0ical Database Re4uire3ents
$o&ical re)uire'ents connected /ith the database includeB
a2 Most o! the values are strin& t(pes but the count is in nu'bers.
b2 *ountin& o! the patients connected /ith a speci!ic disease is 'onitored i''ediatel( a!ter
enterin& the record o! each patient.
c2 Accessin& ri&hts are li'ited to authenticated users onl(.
d2 Inte&rit( constraints are 'aintained b( settin& the relationships.
Bunctions
;alidit( chec=s on the inputs
Data Entr/ (&erators
a2 0esponses to abnor'al situation, includin&
Over!lo/ S Periodic ac=ups
*o''unication !acilities B Internet, 7elephone
9rror handlin& and recover( B Periodic ac=up, 9rror alerts, Maintain 9rror $o&s
b2 9!!ect o! para'eters
<.7 Desi0n Constraints
Aard2are Constraints
Pentiu' 4 processor,
0AM Mini'u' 1 E 'e'or(,
45 E 3ard dis=.
155 Mbps Mode'
Desi0n constraints
*harts have to be created usin& 4le6
All user inter!aces have to be created usin& 4le6
Interaction bet/een #ser Inter!ace and the database should be throu&h :eb Services.
<.< Standards Co3&liance
4ollo/in& standards /ill be 'aintainedBC
0eport !or'at.
%ata na'in& 1As per the <a'in& *onventions S or&ani@ation polic(2
Accountin& procedures
Audit 7racin& 1All chan&es 'ade to student details /ill be traced in trace !iles /ith
be!ore and a!ter values2
<.19 Reliabilit/
So!t/are /ill be handed over to the client a!ter carr(out e6tensive
#nit 7estin&
Inte&ration 7estin&
S(ste' 7estin&
A!ter per!or'in& periodic de'onstrations to the end users on co'pletion o! each 'odule
and =eep a lo& o! the errors ? observations 'ade b( the user
<u'ber o! errors durin& #nit 7estin& 'a( be 'ore but the( should sho/ decreasin&
trend durin& Inte&ration and S(ste' 7estin& and should reduce to @ero at the ti'e o!
deliver(.
9nsure strict co'pliance to Project Plan
<.11 A*ailabilit/
Speci!( the !actors re)uired to &uarantee a de!ined availabilit( level !or the entire s(ste'
such as chec=point, recover(, and restart.
<.1! Securit/
Authentication 'odule /ill ensure that onl( authori@ed users are provided access control
on the /eb site.
0oles /ill be de!ined to i'pose restrictions on the authori@ed users.
9nsure that bu!!er over!lo/ and inte&er over!lo/ /ill be avoided.
:henever user is deleted his privile&es /ill also &et deleted.
*arr(out periodic bac=up o! the database and 'aintain a lo&.
3one( Pots Intentionall( include so'e P*s in the net/or= /hich are vulnerable !or
hac=ers. 7he( can be used to catch hac=ers or !i6 vulnerabilit(.
<.1$ Maintainabilit/
Reep a count o! the nu'ber o! lines o! code. 7hou&h there cannot be a bench'ar= !or the
'a6i'u' lines o! code in a sub routine but hi&her the lines o! code indicates
3i&her is the 'aintenance.
<eed to split up in to child levels.
Place ever( 'odule in 7r( *atch 12 and !inall( 12 bloc= to prevent dis&race!ul e6it.
Avoid e6cessive co'ple6it(
Avoid e6cessive Inheritance
;ariable na'e should not 'atch the !ield na'es
0educe co'ple6it( o! conditional branchin&
<.1% "ortabilit/
Speci!( attributes o! so!t/are that relate to the ease o! portin& the so!t/are to other host
'achines and?or operatin& s(ste's. 7his 'a( include
a2 Percenta&e o! co'ponents /ith hostCdependent code
b2 Percenta&e o! code that is host dependent
c2 #se o! a proven portable lan&ua&e
d2 #se o! a particular co'piler or lan&ua&e subset
e2 #se o! a particular operatin& s(ste'.
Once the relevant characteristics are selected, a subsection should be /ritten !or each, e6plainin&
the rationale !or includin& this characteristic and ho/ it /ill be tested and 'easured. A chart li=e
this 'i&ht be used to identi!( the =e( characteristics 1ratin& the' 3i&h, Mediu', or $o/2, or
ran=in& the' in order o! i'portance 11, 2, 3, etc.2.
ID C#aracteristic Ran=
1 *orrectness
2 9!!icienc(
3 4le6ibilit(
etc.
(r0ani;in0 t#e S&ecific Re4uire3ents
4or an(thin& but trivial s(ste's the detailed re)uire'ents tend to be e6tensive. 4or this
reason, it is reco''ended that care!ul consideration be &iven to or&ani@in& these in a 'anner
opti'al !or understandin&. 7here is no one opti'al or&ani@ation !or all s(ste's. %i!!erent
classes o! s(ste's lend the'selves to di!!erent or&ani@ations o! re)uire'ents in section 3. So'e
o! these or&ani@ations are described in the !ollo/in& subsections.
<.1. S/ste3 Mode
So'e s(ste's behave )uite di!!erentl( dependin& on the 'ode o! operation. 4or e6a'ple, a
control s(ste' 'a( have di!!erent sets o! !unctions dependin& on its 'odeB trainin&, nor'al, or
e'er&enc(. :hen or&ani@in& b( 'ode there are t/o possible outlines. 7he choice depends on
/hether inter!aces and per!or'ance are dependent on 'ode.
:eb Site bein& developed in ASP.<97 2.5 it is co'patible to 'ost o! the OS and the :eb
ro/sers.
<.15 Su&&ortin0 Infor3ation
7he supportin& in!or'ation 'a=es the S0S easier to use. It includesB
a2 7able o! *ontents at the !ront o! the docu'ent
b2 Inde6
c2 AppendicesB %e!initions o! i'portant ter'inolo&ies are &iven in the Appendi6
7he Appendices are not al/a(s considered part o! the actual re)uire'ents speci!ication and are
not al/a(s necessar(. 7he( 'a( includeB
1a2 Sa'ple I?O !or'ats, descriptions o! cost anal(sis studies, results o! user surve(sF
1b2 Supportin& or bac=&round in!or'ation that can help the readers o! the S0SF
1c2 A description o! the proble's to be solved b( the so!t/areF
1d2 Special pac=a&in& instructions !or the code and the 'edia to 'eet securit(, e6port,
initial loadin&, or other re)uire'ents.
:hen Appendices are included, the S0S should e6plicitl( state /hether or not the Appendices
are to be considered part o! the re)uire'ents.
7ables on the !ollo/in& pa&es provide alternate /a(s to structure section 3 on the speci!ic
re)uire'ents.
<.16 Docu3ent Control
C#an0e Aistor/
Re*ision
Release
Date
Descri&tion Clist of c#an0ed &a0es and reason for
c#an0eD
Docu3ent Stora0e
7his docu'ent /as created usin& standard S0S 7e'plate !ollo/ed b( I999. 7he !ile is stored
b( the Project Mana&er, one si&ned cop( is handed over to the authori@ed representative o! the
custo'er and the second cop( is =ept /ith the Ad'inistrator. It establishes the basis !or
a&ree'ent /ith the client on /hat the so!t/are product is e6pected to do, as /ell as /hat it is not
e6pected to do.
Docu3ent (2ner
Project Mana&er is responsible !or developin& and 'aintainin& this docu'ent.
<.17 A&&endiE A
%e!initions o! the )ualit( characteristics !ollo/.
*orrectness C e6tent to /hich pro&ra' satis!ies speci!ications, !ul!ills user>s
'ission objectives
9!!icienc( C a'ount o! co'putin& resources and code re)uired to per!or' !unction
4le6ibilit( C e!!ort needed to 'odi!( operational pro&ra'
Inte&rit(?Securit( C !actors that protect the so!t/are !ro' accidental or 'alicious
access, use, 'odi!ication, destruction, or disclosure
Interoperabilit( C e!!ort needed to couple one s(ste' /ith another
Maintainabilit( C ease o! 'aintenance o! the so!t/are itsel!
Portabilit( C ease o! portin& the so!t/are to another host
0eliabilit( C !actors re)uired to establish the re)uired reliabilit( o! the s(ste'
0eusabilit( C e6tent to /hich it can be reused in another application
7estabilit( C e!!ort needed to test to ensure per!or's as intended
#sabilit( C e!!ort re)uired to learn, operate, prepare input, interpret output
Availabilit( C !actors re)uired to &uarantee a de!ined availabilit( level !or the
s(ste'