payselfy mobile app srs

8/17/2019 Payselfy mobile app SRS

1/20


2/20

PaySelfy Version 1.0.0

Software Requirements Specification 1st Feb, 2016

U!V"#PR

Document Control

1 !ppro"al

Mr. Vinay #abu Ro$it and %r !man Sin&$ will approve this document.

' Document C$an&e Control

Initial Release: Feb 1, 2016

urrent Release: !o "e #etermined $!"#%

#ate o& 'ast Review: !o "e #etermined $!"#%

#ate o& (e)t Review: !o "e #etermined $!"#%

!ar*et #ate &or (e)t +pdate: !o "e #etermined $!"#%

( Re"i)ion *i)tory

!he &ollowin* table concludes the chan*es made between versions o& this document:

Date Ver)ion De)cription !ut$or

1st Feb, 2016 1.0 reation +-#-V-'/-R


3/20



U!V"#PR

+able of Content)

De)cription Pa&e o

1- .ntroduction////////////////////////0

1.1 /urpose and Intended udience.....................................................................

1.2 cope o& /roduct3333333333333333333333....

1.4 #e&inition and bbreviations3333333333333333....6

1.4.1 Definitions………………………………………………………………………6

1.4.2 Abbreviations……………………………………….........................................7

1.5 verview o& stem33333333333333333333.......7

1. !echnolo*ies to be used33333333333333333333.8

1.6 Re&erences33333333333333333333333........10

2.0 eneral De)cription///////////////////11

2.1 /roduct /erspective3333333333333.333333.....11

2.2 /roduct Functions33333333333333333333.....11

.

2.4 /roduct &eatures333333333333333333333....12

2.3.1 Data Management…………………………………………………….……...12

2.3.2 Mapping of outcomes………………………………………………………...12

2.5 +ser characteristics3333333333333.............................12

2.4.1 Use case Diagrams and their description………..................................….13

2.4.2 ta!eho"ders…………………………………………......................................22


4/20



U!V"#PR

2. (on"ehavioral haracteristics...........................................................2

2.#.1 Dep"o$ment Diagrams...............................................................................26

2.6 %enera" &onstraints............................................................................26

2.7 Assumptions and Dependencies..........................................................27

(- Specific Requirement)'2

4.1 -)ternal Inter&ace Re9uirements......................................................27

3.1.1 User interface.............................................................................................2'

3.1.2 (ard)are interface.....................................................................................42

3.1.3 oft)are interface.......................................................................................32

3.1.4 &ommunication interface............................................................................33

4.2 "ehavioral re9uirements..................................................................44

3.2.1 &"ass of users.............................................................................................33

3.2.2 timu"us......................................................................................................33

3.2.3 *unctiona".................................................................................................33

4.4 (on"ehavioral re9uirements.........................................................45

3.3.1 +erformance ,e-uirements.......................................................................34

3.3.2 ua"itative re-uirements..........................................................................34

4.5 -)pected Future -nhancements............................................................45

4. ther Re9uirements.......................................................................4

3.4.1 Database...................................................................................................3#


5/20



U!V"#PR

1 .ntroduction

11 Purpo)e and .ntended !udience34

!he purpose o& the o&tware Re9uirement peci&ication $R% is to *ive the taeholders a clear and

precise description o& the &unctionalit o& the PaySelfy to be developed.

!his document is intended &or both Cu)tomer and De"eloper) o& the sstem.

5or cu)tomer, the R will e)plain the purpose and &eatures o& the sstem, the inter&aces o& the sstem,

the constraints under which it must operate and how the sstem will react to e)ternal stimuli.

5or t$e De"eloper, it will be a re&erence point durin* so&tware desi*n, implementation and Maintenance.

1' Scope of Product34

!his R is desi*ned to develop a /ael& that establishes a process &or:

+$e !dmin to :

• bilit to add;edit contests.

• dmin ri*hts to reenerate list o& users who participated in a contests alon* with details.

• Messa*in* individual users re*ardin* winners.

• elect advertisements.

• ccess to data lie avera*e weel active users etc. alon* with demo*raphics.

+$e Cu)tomer) to :

• /ro&ile creation and lo*in.

• electin* contest and uploadin* pictures

• Redeem mone.


6/20



U!V"#PR

1.4 Definition) and !bbre"iation)34

1.4.1 Definition)

!he de&initions in this section are *iven in the conte)t o& the product bein* developed. !he intention is to

assist the user in their understandin* o& the re9uirements &or the sstem.

+ER% DE5..+.O

#atabase structured 9uer relational database $?' erver% stored on one or

more machines.

Mappin* !he lina*es o& two ob


7/20



U!V"#PR

1(' !bbre"iation)

!##REV.!+.O %E!.

e.*. For e)ample

i.e. !hat is

In&o. In&ormation

?I ontinuous ?ualit Improvement

#"M #atabase Mana*ement stem

>+I >raphical user Inter&ace

R o&tware Re9uirements peci&ication

!"# !o "e #etermined

R;@ Read;@rite

16 O"er"iew of t$e )y)tem34

!he PaySelfy is divided into two ma


8/20



U!V"#PR

1 +$e cu)tomer) who interact with the &ront end inter&ace o& /ael&. !hese users can:

• /ro&ile creation and lo*in.

• electin* contest and uploadin* pictures

•!ain* instant sel&ies or uploadin* &rom the old ones.

• Redeemin* mone

• ontact administrator

' !dmin is solel responsible &or the operation o& the so&tware. dmin can:


• dvertisements selection




1. +ec$nolo&ie) to be u)ed34

7'EE87a"a ' Enterpri)e Edition934

Aava /lat&orm, -nterprise -dition or Aava -- is racleBs enterprise Aava

computin* plat&orm. !he plat&orm provides an /I and runtime environment &or

developin* and runnin* enterprise so&tware, includin* networ and web services, and

other lar*escale, multitiered, scalable, reliable, and secure networ applications.

!ndroid Studio34

!ndroid Studio is the o&&icial inte*rated development environment $I#-% &or developin*

&or the !ndroid plat&orm. It was announced on Ma 16, 2014 at the >oo*le I;

con&erence. !ndroid Studio is &reel available under the pache 'icense 2.0.

7!V!34

Aava is a set o& several computer so&tware and speci&ications developed b un

Microsstems, later ac9uired b racle orporation, that provides a sstem &or developin* application so&tware and deploin* it in a crossplat&orm computin*

environment

!pac$e +omcat Ser"er34

!omcat server is the maretleadin* Internet in&rastructure so&tware &or buildin*, runnin*,

and inte*ratin* business applications across a variet o& computin* plat&orms. "uilt

http://en.wikipedia.org/wiki/Java_(software_platform)http://en.wikipedia.org/wiki/Platform_(computing)http://en.wikipedia.org/wiki/APIhttp://en.wikipedia.org/wiki/Enterprise_softwarehttp://en.wikipedia.org/wiki/Network_servicehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Computer_softwarehttp://en.wikipedia.org/wiki/Sun_Microsystemshttp://en.wikipedia.org/wiki/Sun_Microsystemshttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Cross-platformhttp://en.wikipedia.org/wiki/Java_(software_platform)http://en.wikipedia.org/wiki/Platform_(computing)http://en.wikipedia.org/wiki/APIhttp://en.wikipedia.org/wiki/Enterprise_softwarehttp://en.wikipedia.org/wiki/Network_servicehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Computer_softwarehttp://en.wikipedia.org/wiki/Sun_Microsystemshttp://en.wikipedia.org/wiki/Sun_Microsystemshttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Cross-platform


9/20



U!V"#PR

accordin* to clients= desires &or innovative, standardsbased, hi*hl reliable, and scalable

so&tware,

S:L Ser"er3

It is a nochar*e database used in development and deploment. /rovidin* the same core

data server &eatures, development inter&aces, and sstem limits, s ?' server is in a

smaller paca*e, it o&&ers a solid base to build and deplo all applications.

!;a< 8!)ync$ronou) 7a"a )cript and =%L934


10/20



U!V"#PR

' eneral De)cription

2.1 Product Per)pecti"e34

/ael& is desi*ned to provide dmin and staeholders with tools that &acilitate eas control and

access.

It will help the dmin to mana*e:






2.2 Product 5eature)34

2.2.1 Data %ana&ement34

#ata mana*ement includes the entr, stora*e, manipulation and deletion o& di&&erent Records that

e)ist in database.

" #ata mana*ement we mean:

• dd new in&ormation to the database.

• -dit e)istin* in&ormation in the database.

• r*aniDe, view and *enerate in&ormation in di&&erent was.

• hare the in&ormation with the user.

2.4 U)er C$aracteri)tic)34

!heU)er)

are e)pected to be nontechnical users, once he;she will mae an account b si*nin*

up, he will be able to participate in the di&&erent sel&ie related tass showin* on his app=s screen.

"ecause the sstem will have a >+I with a standard &ormat, the u)er) will need not to have a

hi*h level o& technical e)pertise.

!he !dmin is e)pected to be technical staeholder and will mana*e all the activities re*ardin*

addin*;editin* contests, advertisements selection, choosin* winners, mana*in* users= accounts as

well.


11/20



U!V"#PR

2.4.1 U)e Ca)e Dia&ram) and t$eir de)cription34

U)e Ca)e 5or !dmini)trator 34

U)e ca)e for Cu)tomer?Client) 34

U)e Ca)e

amedmin

#rief

De)cription!he dmin will be able to view all the &unctionalities o& the sstem includin*

mana*ement o& users and contests.

!ctor dministrator

Scenario • Maintain client;customer details

• ddin*;-ditin* ontests

• @inners selection

• /riDe mone !rans&er

• /ersonal messa*in* to users



12/20



U!V"#PR

U)e Ca)e

ameustomer

#rief

De)cription

!he ustomer can si*nup, si*nin and update their details.

!ctor ustomer

Scenario • +pdate pro&ile details.

• han*e password.

• ontest selection to participate

• Redeemin* mone

• !ain* instant sel&ies or uploadin* &rom the old ones

• ontact administrator


13/20



U!V"#PR


14/20



U!V"#PR

2.4.2 Sta>e$older) of t$e Sy)tem34

PaySelfy onsists o& Followin* taeholders:

!he !dmini)trator o& the sstem will be able to mana*e the addin*;editin*

contests, advertisements selection, choosin* winners, mana*in* users= accounts.

!he U)er can +pdate pro&ile details, chan*e password, contest selection to

participate, redeemin* mone and contact administrator.

'6 on4be$a"ioral C$aracteri)tic)34

'@' Deployment Dia&ram34


15/20



U!V"#PR

'0 eneral Con)traint)34

!he *eneral constraints on the development o& the sstem are as &ollows:

• U)er .nterface Con)traint)3+sin* the /ael&ie must be &airl simple and intuitive. user must have to be

&amiliar with the basic browser navi*ation sills to be able to understand all

&unctionalit provided b the sstem.

• *ardware Con)traint)!he /ael&ie should wor on most mobile phones which support ndroid operatin*

sstem.

• Software Con)traint)

!he /ael& would be intended to run on ndroid 5.0 and above.• Data %ana&ement Con)traint)

/ael& shall be able to inter&ace with other components accordin* to their

speci&ications.

• Operational Con)traint)!he /ael& is limited b its operatin* server in terms o& the ma)imum number o&

users it can support at a *iven time.


16/20



U!V"#PR

'@ !))umption) and Dependencie)34

!he assumptions are as &ollows:

• -ach user has access to an ndroid device havin* an internet browsin* capabilit.

• !he in&ormation should be stored in database so that it is easil accessible.

• !he /ael& should support &ast transaction.

• +sers must have correct username and password so as to enter into their online

accounts and do action.

!he #ependencies are as &ollows:

• !he peci&ic o&tware on which the /ael& will run.

• !he peci&ic Eardware on which /ael& will be runnin*.


17/20



U!V"#PR

( Specific Requirement)

(1 E


18/20



U!V"#PR

(1' *ardware .nterface)

!his section describes the basic re9uirements &or client server sstem:

5or Client )y)tem3

RM 42 M"

tora*e 42 M"

stem so&tware plat&orm: ndroid based #evice

5or Ser"er )y)tem3

RM 1>"

E## 0 >"

stem so&tware plat&orm: @indows )p;vista;G;7;7.1;10 &or dmin /anel

pplication o&tware plat&orm:

• Aavacript and CM' enabled @eb browser

• M?'

• !omcat erver

(1( Software .nterface)

!he sstem will inter&ace with the &ollowin* so&tware sstems:

M?'$"ac end%

!omcat erver

basic "rowser to access internet.

ndroid tudio

(16 Communication .nterface)

• !he /ael& will run over the @orld @ide @eb $internet%.

• !he /ael& will be developed as a clientserver application with the server

providin* data access services onl.


19/20



U!V"#PR

(' #e$a"ioral Requirement)

('1 Cla)) of U)er)

!o use the /ael& the user must be authoriDed. !he re9uirements in this section address

authoriDation and access issues.

• @hen the user lo*s into /ael&, it will as the user to enter a password.

• nl users whose lo*ins are authoriDed, or who own the orrespondin* section,

will be able to update their pro&ile details or view their previous booin* details.

('' Stimulu)

!he &ollowin* re9uirement applies to all userentered values in /ael&:

• &ter the user enters a lo*in and password, the sstem will validate the password.

I& the password is validated, then the respective &unctionalit screen will appear

otherwise the sstem will displa and error messa*e.

• I& the user selects the option to chan*e his;her password, the sstem will prompt

the user &or a new password and will as the user to renter the password.

('( 5unctional

• /ael& provides 25)G vailabilit.

• In /ael&, onl re*istered +sers can access the 'o*in ections.

• Re*istered users must have Valid 'o*in I# and password to access their respectivesections.

• Valid ran*es and values should be checed a*ainst the speci&ication o& the tables, i& the

user enters an invalid value or ran*e, an error messa*e will be displaed.

• @henever the user submits in&ormation to the database, the sstem will as the user to

con&irm the submission.

(( on4#e$a"ioral requirement)34

3.3.1 Performance Requirement)

/er&ormance re9uirements include human interaction to the pp as a whole. !he/ael& &ul&ills all the minimum level o& tatic $Response time, Recover time and

startin*up;powero&& time% and #namic $!hrou*hput, utiliDation rate and no. o&

concurrent users% re9uirements o& the standard sstems.

((' :ualitati"e requirement)

Security34


20/20



U!V"#PR

!he /ael& will be able to control unauthoriDed access to the sstem.

%aintainability34

!he /ael& is bein* desi*ned in such a wa so as to allow the &ollowin*chan*es:

• +se o& database 9ueries.

Portability34

!he /ael& is capable o& runnin* on multiple ndroid versions.

Reu)ability34

!he /ael& is capable o& bein* reused in another sstem.

(6 Ea; Rat$ore

payselfy mobile app srs

Documents