srs group11

8/17/2019 Srs Group11

http://slidepdf.com/reader/full/srs-group11 1/13

Software RequirementsSpecification

For

Mobile Phone Based Security System

Department of Computer Science and Engineering

Uniersity of Moratuwa

26 th October 2006

Superised by!Mr. Shantha FernandoMr. Samantha Senaratne

Prepared by!Awantha S.A.TDarshana S.A.T.Kumara M.D.B.J.B.Sandakalum H.K.L.S.

8/17/2019 Srs Group11


Software Requirements Specification for “Mobile Phone Based Security System”

Table of Contents

Table of Contents...........................................................................................................................ii

1. Introduction..............................................................................................................................11.1 Purpose.......................................................................................................................................11.2 Document Conventions..............................................................................................................11.3 Intended Audience and Reading Suggestions.............................................................................11.4 Project Scope..............................................................................................................................1

2. Overall Description..................................................................................................................22.1 Product Perspective....................................................................................................................22.2 Product Features.........................................................................................................................22.3 User Classes and Characteristics................................................................................................32.4 Operating Environment..............................................................................................................32.5 Design and Implementation Constraints.....................................................................................42.6 User Documentation...................................................................................................................42.7 Assumptions and Dependencies.................................................................................................4

3. System Features.......................................................................................................................43.1 Authentication using users’ mobile phone..................................................................................4

3.1.1 Description and Priority.........................................................................................................43.1.2 Stimulus/Response Sequences............................................................................................ ...53.1.3 Functional Requirements........................................................................................................5

3.2 Alternative authentication mechanism for special conditions.....................................................53.2.1 Description and Priority.........................................................................................................53.2.2 Stimulus/Response Sequences............................................................................................ ...53.2.3 Functional Requirements..........................................................................................................5

3.3 Identifying the direction of the authenticated user......................................................................63.3.1 Description and Priority.........................................................................................................63.3.2 Stimulus/Response Sequences............................................................................................ ...63.3.3 Functional Requirements........................................................................................................ 6

3.4 Automatic authorization to the resources.................................................................................. .63.4.1 Description and Priority.........................................................................................................6

3.4.2 Stimulus/Response Sequences............................................................................................ ...63.4.3 Functional Requirements........................................................................................................ 7

3.5 Identifying the location of the user.............................................................................................73.5.1 Description and Priority.........................................................................................................73.5.2 Stimulus/Response Sequences............................................................................................ ...73.5.3 Functional Requirements........................................................................................................7

3.6 Tracking the users’ specific activities such as entering and leaving time...................................73.6.1 Description and Priority.........................................................................................................73.6.2 Stimulus/Response Sequences............................................................................................ ...73.6.3 Functional Requirements........................................................................................................7

4. External Interface Requirements...........................................................................................84.1 User Interfaces............................................................................................................................84.2 Hardware Interfaces................................................................................................................... 84.3 Software and communication Interfaces.....................................................................................8

5. Other Nonfunctional Requirements.......................................................................................95.1 Performance Requirements.........................................................................................................95.2 Safety Requirements...................................................................................................................95.3 Security Requirements..............................................................................................................105.4 Software Quality Attributes......................................................................................................10

Appendix A: Glossary..................................................................................................................11Abbreviations........................................................................................................................................11

Department of Computer Science & Engineering

University of Moratuwa.

8/17/2019 Srs Group11


8/17/2019 Srs Group11


AD

ADSub Entrance

Main EntranceMain Server

Department x

BlueTooth Adaptors

BlueTooth Adaptors

User with Bluetooth supported

Mobile Phone


3hase 65 Location identification and Su$ section authentication.

2. Overall Description

2.1 Product Perspective

7'en thou*h the !roduct which is *oin* to $e im!lemented is a new !roduct it can $e used asa enhancin* solution for a e-istin* s%stem. Most common securit% s%stems at !resent areswi!e cards, fin*er !rint identifications, face reco*nitions, +F/D and etc. Since M3BSS isconsist of automatic authentication and location identification, it is !ossi$le to re!lace or im!ro'e the a$o'e mentioned securit% s%stems usin* the mechanisms which are usin* in thiss%stem im!lementation.

The followin* dia*ram illustrates hi*h le'el !rotot%!e of the s%stem.

.



8/17/2019 Srs Group11



2.2 Product Features

The ke% features of this s%stem can $e a$stracted as follows.

Authentication throu*h users1 mo$ile !hone

Alternati'e authentication mechanism for s!ecial conditions

/dentif%in* the direction of the authenticated user0enterin* or lea'in* the !remise2

Automatic authoriation to the resources

/dentif%in* the location of the user

Trackin* the users1 s!ecific acti'ities such as enterin* and lea'in* time.

2.3 User Classes and Characteristics

8nder the features s!ecif%in* in the s%stem it is !ossi$le to di'ide the users into se'eral classesas follows.

ote5 Assume that all the users ha'e mo$ile !hone e-ce!t if not es!eciall% mentioned

AdministratorThe s%stem administrator which administrates the resources of the or*aniationhas all the !ri'ile*es mentioned under 6.6 !roduct features.

ormal usersThe !eo!le who uses the or*aniation resources such as com!uters, networksand other !eri!herals. This class of users has all the !ri'ile*es e-ce!t theadministrati'e !ri'ile*es.

ormal users without a mo$ile !hone7'en thou*h this kind of users has the same !ri'ile*es as the normal users heor she will $e authenticated throu*h another ste!. Location $ased identificationis not !ossi$le under this class of users.

Minor staff This class of users includes !eo!le like !eons, cleanin* staff, maintainin* staff,

securit% and so on. This class of users has the !ri'ile*es to authentication $utnot automatic authoriation !ri'ile*es.

9isitorsThese are the !eo!le e-ternal to the !articular or*aniation. The% ha'e

!ri'ile*es onl% to authenticate to the or*aniation.

2.4 Operating Environment

The s%stem consists of two o!eratin* en'ironments, client side and ser'er side. :lient side isrun on a mo$ile !hone en'ironment while the ser'er side is runnin* on a LDA3 ser'er. The

communication $etween the mo$ile client and the ser'er is handlin* 'ia $luetooth technolo*%.



8/17/2019 Srs Group11



2.5 Design and Implementation Constraints

Most of the nowada%s !hones contains the "a'a !latform and some of ha'e windows !latform.Therefore the s%stem ma% ha'e a constraint of !latform de!endenc%. Since the client side iso!eratin* on a mo$ile !hone there are constraints on memor% and the !rocessin* !ower of the

mo$ile !hone. A!art from those thin*s communication time is also a main constraint for thes%stem. Since the de'elo!ment is carried out under the #Bluetooth& and #LDA3& !rotocolsthis s%stem has those communication !rotocols constraints.

2.6 User Documentation

3ro"ect we$site will $e !u$lished with all the details re*ardin* the !ro"ect. /t allows users tolo*in to their !rofiles, *et online hel! and some e-tra features as well. An or*aniation whichis *oin* to use this s%stem will $e !ro'ided a user manual a!art from the online hel! !ro'idedthrou*h the !ro"ect we$ site.

2.7 Assumptions and Dependencies

The assum!tions and de!endencies rele'ant to the s%stem are as follows.

All the users who are su!!osed to use this s%stem should ha'e $luetooth ena$ledmo$ile !hone within or near the !remise.

8ser has installed the mo$ile a!!lication to his;her !ersonal mo$ile !hone which is !ro'ided $% the s%stem.

The !articular user who will access the s%stem is inside the effecti'e si*nal area to *et

outcomes from this M3BSS.

The or*aniation consist a !ro!er and relia$le network.

The users are not enterin* to the !remise as a crowed at a !articular moment.

3ro!er communication can $e de!ends u!on the en'ironmental conditions.

8ser is kee!in* his;her !hone with him;her at all the time.

3. System Features

"#$ %uthentication using users& mobile phone

"#$#$ Description and Priority

When a person tries to enter to a premise of an organization through an entrance,

he/she will be checked whether he/she is an authorized person by analyzing his

mobile phone details through Bluetooth technology. If he/she is an authorized person

he/she can access to the relevant premise by entering the correct password in the pop



8/17/2019 Srs Group11


8/17/2019 Srs Group11



+7=)45 3ro'ide an alternati'e mechanism to authenticate in s!ecial occasions.+7=)65 Limit the usa*e of alternati'e mechanism to com!el users to use ori*inal

authentication mechanism.

3.3 *dentifying the direction of the authenticated user

"#"#$ Description and Priority

S%stem needs to identif% whether a !articular user is within the !remise or not. So $% usin* two Bluetooth ada!ters located in either sides of the main entrance it is !ossi$le to identif% the users1 mo'in* direction, into the !remise or out of the !remise $% controllin* the si*nal stren*th of the Bluetooth si*nals. This also ha'in*a hi*her !riorit%.

3.3.2 Stimulus(Response Sequences

At the entrance $oth ada!ters detects the mo$ile !hone.

Throu*h the seuence of detectin* the de'ice $% Bluetooth ada!ters determine themo'in* direction of the user.

8!date the s%stem data$ase.

"#"#" )unctional Requirements

+7=)45 /dentif% whether a !articular user is within the !remise or not at a !articular time.

3.4 %utomatic authori+ation to the resources

"#,#$ Description and Priority

Authenticated user can automaticall% authorie to some s!ecial resources 0such asnetwork domain, !rinters, ser'ers and etc2 within the !remise $% *ettin* thereuired details from the s%stem data$ase.

3.4.2 Stimulus(Response Sequences

User tries to enter to the organization domain by entering username and password.

System check whether a particular user is legally inside the premise or not. If he/she is a legally authenticated user, system allows him/her to access to theresources. If not system automatically prevent him/her from accessing theresources.



8/17/2019 Srs Group11



"#,#" )unctional Requirements

+7=)45 3re'ent ille*al user authoriations.+7=)65 !ro'ide automatic authoriations for le*al users.

3.5 *dentifying the location of the user

"#-#$ Description and Priority

?ithin a !remise there can $e se'eral sections. /n each section there are Bluetoothada!ters. So when a user enters to a !articular section those ada!ters detect thatuser and u!date the s%stem data$ase. Thus the s%stem has the ca!a$ilit% of determinin* the location of a !articular user.

3.5.2 Stimulus/Response Sequences

8ser comes into a !articular section

Correspondent adapter automatically detects the user and update the systemdatabase.

3.5.3 Functional Requirements

+7=)45 /dentif% the location of a !articular user.+7=)65 3ro'idin* some user controllin*, $ase on the location.

3.6 Tracking the users’ specific activities such as entering and leaving

time

3.6.1 Description and Priority

/n an or*aniation, kee!in* staffs1 $eha'ioral information such as arri'in* andlea'in* time is 'er% useful to the mana*ement and hi*her le'el !eo!le. For e-am!lewhen some or*aniation !olic% 'iolation has occurred it can $e tracked throu*hthis kind of information.

3.6.2 Stimulus/Response Sequences

Kee! dail% lo*s of the data$ase. +efer the lo*s and current data$ase when this kind of information is needed.



8/17/2019 Srs Group11



3.6.3 Functional Requirements

+7=)45 3ro'ide su!!ort for mana*ement acti'ities.

4. External Interface Requirements

4.1 User Interfaces

The s%stem contains se'eral interfaces which the user can interact with. These interfaces arede!endin* on the role of the user. These interfaces can $e classified as follows.

User interface in a mobile phone#

This facilitates the user to interact with the s%stem throu*h a mo$ile !hone. For that the user must ha'e installed the mo$ile a!!lication which is a !art of thes%stem. /f not the user una$le to identif% e'en there is such kind of securit%s%stem in the or*aniation. The communication $etween the mo$ile !hone andthe $luetooth de'ices are throu*h this a!!lication 'ia $luetooth technolo*%.7'er% detail such as username, !asswords, error messa*es and other notifications are recei'ed or initialied throu*h this interface.

System admin interface#This is the core of the s%stem which is handled $% the s%stem administrator.This facilitates addin* and remo'in* users to the s%stem, u!datin* the user

!rofiles, communication with users1 mo$ile !hone, ma!!in* the users, u!datin*and retrie'in* data from the data$ases,

.eb interface#?e$ interface !ro'ides *eneral descri!tion a$out the s%stem with the user lo*infacilit% to the s%stem to do thin*s like !rofile u!datin*. This also !ro'ides hel!and *uidance to the users.

4.2 Hardware Interfaces

The s%stem consists of se'eral hardware interfaces such as Mo$ile !hone, $luetooth ada!ters,

ser'er, network !eri!herals and door with a automated lock. Mo$ile !hone and $luetoothada!ters communicate 'ia $luetooth technolo*% to transfer useful information amon* them. ot onl% $luetooth ada!ters communicate with the users1 mo$ile !hone, it also communicateswith the s%stem ser'er. This communication is the one who handles most of the securit% issues.All the users ha'e to *o throu*h the s%stem ser'er to access the or*aniation resources such asnetworks.

4.3 Software and communication Interfaces

?hen lookin* at the software interfaces, it can $e mentioned that there are so man%.

Linu- and ?indows o!eratin* s%stems



8/17/2019 Srs Group11



?indows o!eratin* s%stem is usin* in the s%stem ser'er while Linu- <S is usedwith LDA3.

Mo$ile a!!lication de'elo!in* tools.

LDA3

This is used to domain authentication !ur!oses.

:ommunication throu*h $luetooth !rotocol.:ommunication $etween the !hone and the ada!ter is done 'ia $luetoothtechnolo*%.

?ired communication?ired communication is used all o'er the !laces e-ce!t $etween the !hone andthe ada!ters.

?e$ interface

?e$ interface is $ased on Microsoft /nternet 7-!lorer.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

Mo$ile !hone a!!lication occu!ies less memor% with hi*h !erformance.Since mo$ile !hones are ha'in* limited memor% ca!acit% and not much hi*her

!rocessin* !ower, the a!!lication should ha'e a$o'e features.

Less $atter% !ower consum!tion for $luetooth communication.The user has to ena$le $luetooth within the !remise all the time. But itconsumes $atter% !ower of the !hone. So this can $e a !ro$lem for the users.To a'oid this !ro$lem, the communication should use o!timal !ower consum!tion.

Ser'ers ha'e hi*h !erformance with low latenc%./t is needed to *i'e res!onses to the reuests without a dela%.

+eal time and relia$le communication.

5.2 Safety Requirements

Bluetooth communication and de'ices should $e !ro!er and not 'astl% de!ends onen'ironmental factors.

/f the communication is 'astl% de!ends on factors like en'ironment condition,noise, the communication ma% $e not !ro!er and relia$le.

Hi*h a'aila$ilit%.S%stem should correctl% handle in hi*h load circumstances.

Adhere to the or*aniational !olicies. The s%stem should follow the common or*aniational !olicies.



8/17/2019 Srs Group11


Software Requirements Specification for “Mobile Phone Based Security System” Page

5.3 Security Requirements

Secure communication.All the communication information should $e encr%!ted to achie'econfidentialit%.

3re'ent ille*al access to data$ases.Since all the information is stored in data$ases, onl% administrator can see thosedata.

3re'ent alienate of hi*hl% secured information.+educe the a$ilit% of alienation of hi*hl% secured data such as lo*in details toremo'e 'ulnera$ilities.

S%stem access throu*h we$ is secure.The s%stem is accessi$le throu*h we$ for limited !ur!oses of users. But this

communication should $e secure as well.

5.4 Software Quality Attributes

Ada!ta$ilit% and fle-i$ilit%S%stem should $e easil% chan*ed accordin* to the or*aniation and itsen'ironments.

A'aila$ilit%Hi*h a'aila$ilit% should $e satisfied $% the s%stem to !re'ent ille*al access tothe !remise.

:orrectness:orrectness should $e there to !ro'ide facilities for le*al !ersons onl%.

/ntero!era$ilit%Se!arate o!erations should $e identified as se!arate. And there can $e !arallelo!erations like more than one users accessin* from the entrance.

Maintaina$ilit%The s%stem should de'elo! in a wa% that it can $e easil% chan*ed to satisf%

chan*e of reuirements.

relia$ilit%Since this is a securit% !roduct the relia$ilit% is a ma"or reuirement to achie'esecurit% *oals.



8/17/2019 Srs Group11


srs group11

Documents