TNT FIREWORK

SRS
REQUIREMENTS
DOCUMENT
2010
Georgia Southern University
DANIE MOORE!C"AD CUNNING"AM!AS"E# RANDA!K#E
$OCK
%&%&'(%(
TABLE OF CONTENTS
Table of Contents
TABLE OF CONTENTS...................................................................................................2
Table of Contents.............................................................................................................2
OVERALL DESCRIPTION...............................................................................................4
Pro!"t #ers#e"t$%e......................................................................................................4
S&ste' $nterfa"es.............................................................................................................4
(ser $nterfa"es..............................................................................................................)
*ar+are $nterfa"es......................................................................................................)
Co''!n$"at$ons $nterfa"es..........................................................................................)
,e'or& "onstra$nts.......................................................................................................-
Pro!"t f!n"t$ons..........................................................................................................-
(ser ".ara"ter$st$"s....................................................................................................../
Constra$nts..................................................................................................................../
Ass!'#t$ons an e#enen"$es...................................................................................0
A##ort$on$n1 of re2!$re'ents .......................................................................................0
SPECIFIC RE3(IRE,ENTS...........................................................................................0
E4ternal $nterfa"es .......................................................................................................5
F!n"t$ons ....................................................................................................................10
Perfor'an"e re2!$re'ents ........................................................................................10
Lo1$"al atabase re2!$re'ents ..................................................................................11
Des$1n "onstra$nts .....................................................................................................11
Stanars "o'#l$an"e ...............................................................................................12
Soft+are s&ste' attr$b!tes ........................................................................................12
Rel$ab$l$t& ................................................................................................................12
A%a$lab$l$t& ..............................................................................................................12
Se"!r$t& ..................................................................................................................16
,a$nta$nab$l$t& .........................................................................................................16
Portab$l$t& ...................................................................................................................16
(se Cases7 S"enar$os7 an Protot&#es ........................................................................16
PROTOT8PES...........................................................................................................1-
OVERALL DESCRIPTION
This section of the SRS should describe the general factors that affect the product and
its requirements. This section does not state specific requirements. Instead, it provides
a background for those requirements, which are defined in detail in Section 3 of the
SRS, and makes them easier to understand.
This section usually consists of si subsections, as follows!
a" #roduct perspective$
b" #roduct functions$
c" %ser characteristics$
d" &onstraints$
e" 'ssumptions and dependencies$
f" 'pportioning of requirements.
Product perspectie
(This subsection of the SRS should put the product into perspective with other related
products. If the product is independent and totally self)contained, it should be so stated
here. If the SRS defines a product that is a component of a larger system, as
frequently occurs, then this subsection should relate the requirements of that larger
system to functionality of the software and should identify interfaces between that
system and the
software. ' block diagram showing the ma*or components of the larger system,
interconnections, and eternal inter)faces can be helpful.. This subsection should also
describe how the software operates inside various constraints. (
T.e s&ste' +$ll o#erate as #o$nt of sale a##l$"at$on t.at +$ll ass$st t.e TNT tent
o#erators 9non:#rof$ts; $n <ee#$n1 tra"< of sales an t.e$r $n%entor&. (sers +$ll .a%e t.e
ab$l$t& to !se a bar "oe s"anner to s"an $te's $nto t.e sales +$no+. On"e a
"o'#let$on .as been totale o!t t.e a##l$"at$on +$ll "o''!n$"ate +$t. a #r$nter $n orer
to #r$nt a sales re"e$#t.
S!ste" interfaces
This should list each system interface and identify the functionality of the software to
accomplish the system requirement and the interface description to match the system.
Bar "oe S"anner
o Ab$l$t& to treat t.e bar "oe reaer as a <e&boar. S.o!l a!to'at$"all&
$nsert t.e "oe $nto t.e #ro1ra' +.en s"ann$n1 a bar "oe.
Re"e$#t Pr$nter
o #r$nte.
#ser interfaces
T.$s s.o!l s#e"$f& t.e follo+$n1=
a; The logical characteristics of each interface between the software product and its
users.
T.e >(I '!st be o#t$'$?e for a 10244/-0 resol!t$on on t.e Netboo< 'ob$le
!n$t@ t.e >(I '!st also be able to $nt!$t$%e !se t.e >(I t.ro!1. t.e !se of a 'o!se
an <e&boar $nterfa"e. T.e >(I '!st also allo+ for #ro#er feeba"< for t.e
.ar+are $nterfa"es.
b; +hat needs to be the characteristics of the interface,
T.e $nterfa"e s.o!l be "lean an eas& to rea
T.e $nterfa"e s.o!l be $nt!$t$%e to t.e !ser.
T.e !ser $nterfa"e s.o!l not be $n a lan1!a1e !ns!$table for t.e tas<.
T.e !ser $nterfa"e s.o!l #ro%$e #ro#er feeba"< for all a"t$ons.
$ard%are interfaces
This should specify the logical characteristics of each interface between the
software product and the hardware components of the system. This includes
configuration characteristics -number of ports, instruction sets, etc.". It also covers
such matters as what devices are to be supported, how they are to be supported,
and protocols. .or eample, terminal support may specify full)screen support as
opposed to line)by)line support.
T.e bar "oe s"anner7 re"e$#t #r$nter7 an "re$t "ar reaer all $nterfa"e +$t. t.e
"o'#!ter %$a (SB. T.e POS a##l$"at$on +$ll not #ro%$e $re"t $nte1rat$on +$t. t.e
"re$t "ar reaer. T.e "re$t "ar reaer $nterfa"es +$t. a t.$r #art& a##l$"at$on to
.anle #!r".ases. T.e POS $nterfa"es +$t. t.e bar "oe s"anner to rea #ro!"t
$s. T.e bar "oe s"anner oes not .a%e to $nterfa"e +$t. t.e $s#la&. T.e bar "oe
s"anner $s essent$all& a <e&boar $n#!t so $tAs #roto"ol for a""ess$n1 ata +$ll be
s$'$lar to t.at of a <e&boar. After an orer $s f$nal$?e a re"e$#t +$ll be sent to t.e
re"e$#t #r$nter an #r$nt a re"e$#t. T.e #roto"ol for t.e #r$nter +$ll be +.ate%er t.e
#r$nter 'an!fa"t!rer s#e"$f$es.
Co""unications interfaces
This should specify the various interfaces to communications such as local network
protocols, etc.
S&n" A##l$"at$on: t.e a##l$"at$on '!st be able to s&n" +$t. t.e ata ser%er7 an
ser%e t.e lo"al atabase to t.e 'ob$le !n$ts 9Netboo<s;.
&e"or! constraints
This should specify any applicable characteristics and limits on primary and
secondary memory.
T.e a##l$"at$on '!st be able to r!n +$t.$n t.e 'e'or& en%$ron'ent on t.e
Netboo<7 an $t '!st also be able to store all e4#ort ata on t.e 'e$!' asso"$ate
+$t. t.e #r$'ar& stora1e.
Product functions
This subsection of the SRS should provide a summary of the ma*or functions that the
software will perform. .or eample, an SRS for an accounting program may use this
part to address customer account maintenance, customer statement, and invoice
preparation without mentioning the vast amount of detail that each of those functions
requires.
Sometimes the function summary that is necessary for this part can be taken directly
from the section of the higher)level specification -if one eists" that allocates particular
functions to the software product. /ote that for the sake of clarity
T.e POS Soft+are +$ll allo+ t.at !ser to enter $n%entor& $nfor'at$on $nto t.e !ser
$nterfa"e an $t +$ll t.en #!s. t.e $nfor'at$on to t.e atabase. T.e Soft+are +$ll t.en
!#loa t.e $nfor'at$on an sen $t to t.e +eb $nterfa"e for "or#orate !se.
a; Transa"t$ons
R$n1 !# "!sto'ers
Pr$"e C.e"<s
Pr$nt re"e$#ts
b; In%entor& V$e+er
Ab$l$t& to %$e+ $n%entor$e $te's
See a'a1e $te's
See n!'bers of $te's sol or st$ll a%a$lable
See total a'o!nt of #ro!"t re"e$%e an "ost
"; S&n"$n1 A##l$"at$on
Ab$l$t& to s&n" sellers B,L f$le +$t. t.e TNT Enter#r$se Ser%er
#ser c'aracteristics
T.$s s&ste' +$ll .a%e one t&#e of !ser
TNT Cl$ents
T.e TNT "l$ents +$ll be t.e $n$%$!al non:#rof$t or1an$?at$ons t.at are sell$n1 f$re+or<s
t.ro!1. TNT
E!"at$on= Irrele%ant
E4#er$en"e= Cno+s t.e bas$"s of sell$n1 $te's. Cno+s .o+ to ret!rn #ro#er
".an1e an "o!nt 'one&.
Te".n$"al E4#er$en"e= >eneral <no+le1e of .o+ to !se a PC. Cno+s .o+ to
a""ess t.e Internet. Cno+s .o+ to #erfor' 1eneral o#erat$ons.
D$ll onl& !se t.e Soft+are $nterfa"e loae on a *P Netboo<.
Constraints
This subsection of the SRS should provide a general description of any other items
that will limit the developer0s options. These include
a; *ar+are l$'$tat$ons 9e.1.7 s$1nal t$'$n1 re2!$re'ents;@
Netboo<
b; Interfa"es to ot.er a##l$"at$ons@
O#erat$n1 s&ste' a""ess of #r$nter.
FTP.
"; A!$t f!n"t$ons@
,!st $nterfa"e +$t. !ser ID
; *$1.er:orer lan1!a1e re2!$re'ents=
Ea%a
e; Rel$ab$l$t& re2!$re'ents
,!st f!n"t$on +$t. '$n$'al fa$l rate7 +$t. all e4"e#t$ons .anle #ro#erl&.
f;Cr$t$"al$t& of t.e a##l$"at$on@
ProFe"t $s not "r$t$"al. T.e "l$ent .as teste ot.er POS soft+are an +as
not .a##&. For t.e last &ear or t+o t.e& .a%e not !se an& POS
a##l$"at$on.
1; Safet& an se"!r$t& "ons$erat$ons.
Deals +$t. non sens$t$%e ate7 'aFor se"!r$t& "on"erns are b&#asse.

Assu"ptions and dependencies
This subsection of the SRS should list each of the factors that affect the requirements
stated in the SRS. These factors are not design constraints on the software but are,
rather, any changes to them that can affect the requirements in the SRS. .or eample,
an assumption may be that a specific operating system will be available on the
hardware designated for the software product. If, in fact, the operating system is not
available, the SRS would then have to change accordingly.
Netboo< t.at are r!nn$n1 a D$no+s BP or ne+er o#erat$n1 s&ste'. T.ese Netboo<s
+$ll also be r!nn$n1 t.e latest %ers$on of Ea%a. De are also ass!'$n1 t.at t.ese
Netboo<s .a%e '!lt$#le (SB #orts
Apportionin( of re)uire"ents
This subsection of the SRS should identify requirements that may be delayed until
future versions of the system.
1. To!". s"reen $nterfa"e
2. Cre$t Car Inte1rat$on
6. C!sto'er Tra"<$n1
4. Sales Trens
). Pro1ra' (#ater
-. Net+or< Ter'$nalsGNet+or< Cars
SPECIFIC RE*#IRE&ENTS
This section of the SRS should contain all of the software requirements to a level of
detail sufficient to enable designers to design a system to satisfy those requirements,
and testers to test that the system satisfies those requirements. Throughout this
section, every stated requirement should be eternally perceivable by users, operators,
or other eternal systems. These requirements should include at a minimum a
description of every input -stimulus" into the system, every output -response" from the
system, and all functions performed by the system in response to an input or in support
of an output. 's this is often the largest and most important part of the SRS, the
following principles apply!

a" Specific requirements should be stated in conformance with all the characteristics
described in 1.3.

b" Specific requirements should be cross)referenced to earlier documents that relate.

c" 'll requirements should be uniquely identifiable.

d" &areful attention should be given to organi2ing the requirements to maimi2e
readability.. 3efore eamining specific ways of organi2ing the requirements it is helpful
to understand the various items that comprise requirements as described in 3.4
through 3.5.

E+ternal interfaces
This should be a detailed description of all inputs into and outputs from the software
system. It should complement the interface descriptions in 6.7 and should not repeat
information there. It should include both content and format as follows!

a" /ame of item$
b" 8escription of purpose$
c" Source of input or destination of output$
d" 9alid range, accuracy, and:or tolerance$
e" %nits of measure$
f" Timing$
g" Relationships to other inputs:outputs$
h" Screen formats:organi2ation$
i" +indow formats:organi2ation$
*" 8ata formats$
k" &ommand formats$
l" ;nd messages.
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
I.
a; Re"e$#t Pr$nter
b; To #r$nt re"e$#ts of !ser transa"t$ons
"; T.e POS +$ll ta<e t.e "!rrent transa"t$on an sen t.e $te' l$st7 #r$"es7 an sale
$nfor'at$on to t.e #r$nter
; Infor'at$on sent to t.e #r$nter nees to be 5)I a""!rate7 .o+e%er $t $s #oss$ble t.at
a #roble' "o!l #!t off t.e ent$re re"e$#t.
e; A'o!nt of ata sent to t.e #r$nter
f; Pr$nter nees to be able to re"e$%e an #r$nt e%er&t.$n1 $n a t$'el& 'anner for t.e
"!sto'er.
1; Pr$nter +$ll .a%e to +a$t !nt$l t.e soft+are sens t.e ata7 so +.ate%er $n#!ts t.e
soft+are rel$es on +$ll also be +.at t.e #r$nter rel$es on.
.; NGA
$; NGA
F; De#ens on $nterfa"e of t.e #r$nter
<; NGA
l; NGA
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
II.
a; Bar Coe S"anner
b; S"ans t.e bar "oes of #ro!"ts to !se $n t.e #o$nt of sale #ro1ra'.
"; t.e so!r"e of t.e $n#!t +$ll be rea fro' t.e bar "oe an !se to 'at". t.e #ro!"t
$n t.e ata store
; T.$s +$ll .a%e to be 100 #er"ent a""!rate $n rea$n1 t.e bar "oe. T.$s ens!res t.at
t.e "!sto'er $s be$n1 #ro#erl& ".ar1e for t.e "orre"t $te' as +ell as ens!r$n1 t.at
#ro!"t $n%entor& re'a$ns a""!rate.
e; NGA
f; NGA
1; T.$s bar "oe s"anner +$ll onl& $nterfa"e +$t. t.e POS a##l$"at$on $tself.
.; T.$s $s a #$e"e of .ar+are t.at oes not $nterfa"e +$t. t.e $s#la& $tself
$; T.$s $s a #$e"e of .ar+are t.at oes not $nterfa"e +$t. t.e $s#la& $tself
F; T.e ata for'at for t.$s +$ll be eter'$ne b& t.e ata for'at of t.e bar "oe
s"anner $tself
<; NGA
l; NGA
Functions
.unctional requirements should define the fundamental actions that must take place in
the software in accepting and processing the inputs and in processing and generating
the outputs. These are generally listed as shall statements starting with <The system
shall=
These include

a; T.e s&ste' s.all7 ".e"< to $ns!re all $n#!t e%$"es are #ro#erl& "onne"te.

b; T.e s&ste' s.all7 a""e#t t.e $n#!t fro' t.e s"anner7 !#ate base on t.e nat!re of
t.e $n#!t eter'$ne t.e a##ro#r$ate a"t$on.

"; Res#onses to abnor'al s$t!at$ons7 $n"l!$n1

1; O%erflo+: S.o!l to '!". $nfor'at$on be $n#!tte t.ro!1. t.e $n#!t e%$"es7 a
s#las. s"reen s.o!l flas. +arn$n1 t.e !ser of o%erflo+ an "lear t.e "a".e.
2; T.e s&ste' s.all .a%e #ro#er error re#ort$n1 an re"o%er& o#t$ons .so!l t.ere be
r!nt$'e errors7 an allo+ for s!##ort t.ro!1. t.e !se of !n$%ersal error "oes.

; Relat$ons.$# of o!t#!ts to $n#!ts7 $n"l!$n1

1; T.e s&ste' s.all .anle all $n#!ts $nto t.e transa"t$on o#erat$on an res!lt $n t.e
#ro#er o!t#!t $n 4'l for'.
Perfor"ance re)uire"ents
This subsection should specify both the static and the dynamic numerical requirements
placed on the software or on human interaction with the software as a whole. Static
numerical requirements may include the following!

a; T.e n!'ber of ter'$nals to be s!##orte@
Onl& one ter'$nal #er TNT tent o#erator

b; T.e n!'ber of s$'!ltaneo!s !sers to be s!##orte@
T.ere +$ll onl& be one !ser for ea". $nstalle ter'$nal
"; A'o!nt an t&#e of $nfor'at$on to be .anle.
55I of transa"t$ons +$ll be #ro"esse $n less t.an a se"on.

Lo(ical database re)uire"ents
This should specify the logical requirements for any information that is to be placed into
a database. This may include the following!

a" Types of information used by various functions$
b" .requency of use$
c" 'ccessing capabilities$
d" 8ata entities and their relationships$
e" Integrity constraints$
f" 8ata retention requirements.
a; In%entor& $nfor'at$on base on #ro!"ts
b; T.$s +$ll be !se on e%er& transa"t$on of t.e POS s&ste'
"; D$ll nee to be a""ess$ble on ea". 'a".$ne7 a S3L$te atabase $s t.e 'ost l$<el&
sol!t$on
; T.e ata 'oel .as not been rafte &et7 +a$t$n1 for f!rt.er $nfor'at$on fro'
"!sto'er.
e; T.e atabase +$ll .a%e to #ro%$e ata $nte1r$t& to ens!re %al$$t& of POS o#erat$ons
f; T.e ata +$ll .a%e to be #ers$stent so t.at $t $s "ons$stent ea". t$'e t.e POS
a##l$"at$on $s la!n".e

Desi(n constraints
This should specify design constraints that can be imposed by other standards,
hardware limitations, etc.
T.e onl& real es$1n "onstra$nts $'#ose on t.$s POS s&ste' are .ar+are l$'$tat$ons.
T.e netboo<s t.at t.$s a##l$"at$on +$ll !t$l$?e .a%e an $n.erent la"< of "o'#!t$n1 #o+er
an 'e'or&7 t.erefore t.$s s&ste' '!st be es$1ne so t.at $t r!ns $n a res#ons$%e
'anor on t.ese netboo<s.

Standards co"pliance
This subsection should specify the requirements derived from eisting standards or
regulations. They may
include the following!

a; Re#ort for'at@

b; Data na'$n1@

"; A""o!nt$n1 #ro"e!res@

; A!$t tra"$n1.

For e4a'#le7 t.$s "o!l s#e"$f& t.e re2!$re'ent for soft+are to tra"e #ro"ess$n1
a"t$%$t&. S!". tra"es are neee for so'e a##l$"at$ons to 'eet '$n$'!' re1!lator& or
f$nan"$al stanars. An a!$t tra"e re2!$re'ent 'a&7 for e4a'#le7 state t.at all
".an1es to a #a&roll atabase '!st be re"ore $n a tra"e f$le +$t. before an after
%al!es.

Soft%are s!ste" attributes
There are a number of attributes of software that can serve as requirements. It is
important that required attributes be specified so that their achievement can be
ob*ectively verified. Subclauses 6.3.>.4 through 6.3.>.6 provide a partial list of
eamples.

Reliabilit!
This should specify the factors required to establish the required reliability of the
software system at time of delivery.

T.$s #ro1ra' s.o!l be rel$able an #ro%$e "at".$n1 of e4"e#t$ons so t.at !n$ntene
res!lts o not o""!r s!". as s&ste' "ras.es7 or ata %al$at$on fa$l!res.
Aailabilit!
This should specify the factors required to guarantee a defined availability level for the
entire system such as checkpoint, recovery, and restart.
As lon1 as t.e Netboo< t.at r!ns t.e POS a##l$"at$on .as #o+er7 t.$s s&ste' s.o!l
al+a&s be a%a$lable. In t.e e%ent t.at t.e a##l$"at$on "ras.es7 $t +$ll be able to restore
$tself fro' $tAs last ".e"<#o$nt.

Securit!
This should specify the factors that protect the software from accidental or malicious
access, use, modification, destruction, or disclosure. Specific requirements in this area
could include the need to
A; T.e #ro1ra' +$ll store ata $n lo"al .$stor& for s&n" +$t. t.e 'a$n enter#r$s$n1
ser%er.
B; Ea". $n$%$!al 'ob$le !n$t +$ll nee to ".e"< t.e "ons$sten"& of $ts o+n ata.

&aintainabilit!
This should specify attributes of software that relate to the ease of maintenance of the
software itself. There may be some requirement for certain modularity, interfaces,
compleity, etc. Requirements should not be placed here *ust because they are
thought to be good design practices.
T.$s s&ste' s.o!l be es$1ne $n a 'o!lar 'anor to ease $n soft+are 'a$ntenan"e.
B& es$1n$n1 'o!larl&7 +e are able to re!"e "o!#l$n1 allo+$n1 ea". 'o!le to
#erfor' a s#e"$f$" f!n"t$on.

Portabilit!
This should specify attributes of software that relate to the ease of porting the software
to other host machines and:or operating systems. This may include the following!

a; None of t.e "o'#onents s.o!l be .ost e#enent7 $f $t "an r!n on a Netboo< $t "an
r!n on an& 'a".$ne +$t. 'at".$n1 or 1reater s#e"$f$"at$ons.

b; Per"enta1e of "oe t.at $s .ost e#enent@
0I
"; De !s$n1 Fa%a7 t.erefore #ortable to all s&ste's r!nn$n1 a ERE@

; (se of a #art$"!lar o#erat$n1 s&ste'.
,!st be on a s&ste' r!nn$n1 a +$no+s o#erat$n1 s&ste' s!". as D$no+s BP or
1reater.
#se Cases, Scenarios, and Protot!pes
#rototype each input:output screen. %se each prototyped screen to create a set of use
cases for each screen. The use cases should cover all possible uses. .or each use
case, give at least one scenario showing how that use case would be played out.
?ave the customer check the prototypes:use cases and agree -sign off" that this is
what is epected for the pro*ect. This prototype can then be referred to in many other
questions in the SRS.

(se Case 1 : ,ana1er s&n"$n1 ata
o Interest= ,ana1er +ants to s&n" ata fro' #r$'ar& +eb $nterfa"e to t.e 'ob$le !n$t.
o Pre:"on$tons= t.e 'ob$le !n$t '!st be #o+ere on an "onne"te to t.e $nternet
o ,a$n S!""ess S"enar$o=
1.,ana1er #o+ers on 'ob$le !n$t
2.,ana1er "onne"ts to $nternet
6.,ana1er r!ns s&n"
4.Soft+are $'#orts ata f$le an #o#!lates lo"al $n%entor&
o S#e"$al Re2!$re'ents=
Clean >ra#.$"al (ser Interfa"e t.at allo+s for ease of o#erat$on an $ntera"t$on
bet+een 'ob$le !n$t an #r$'ar& atabase.
o Te".nolo1& an Data Var$at$on L$st=
:$n%entor& "an be !#ate fro' t.e $nternet b!t t.ro!1. se"!r$t& 'e".an$s' #arent
atabase '!st re'a$n !naffe"te.
:In%entor& nees to be a""ess$ble on 'ob$le !n$t

(se Case 2 J Cl$ent a$n1 a a'a1e $te'.
o Interest= D!r$n1 'an!al $n%entor& t.e "l$ent .as eter'$ne t.at an $te' +as
a'a1e $n 'o%e'ent fro' +are.o!se to s$te.
o Pre:"on$t$ons= ,ob$le !n$t $s #o+ere
o ,a$n S!""ess S"enar$o=
1.Cl$ent #o+ers on 'ob$le !n$t
2.Cl$ent !ses t.e $n%entor& s"reen an e$t.er bar"oe s"ans or $n#!ts $te' "oe
6.Cl$ent sele"ts $te'
4.Cl$ent "l$"<s a a'a1es
).Cl$ent f$lls o!t a'a1es
-. $te' no+ ae to a'a1es atal$st.
o S#e"$al Re2!$re'ents=
Clean >ra#.$"al (ser Interfa"e t.at allo+s for ease of o#erat$on an $ntera"t$on +$t.
$n%entor&
o Te".nolo1& an Data Var$at$on L$st=
:In%entor& nees to be a""ess$ble on 'ob$le !n$t

(se Case 6 J Cl$ent r!nn$n1 a sale transa"t$on
o Interest= C!sto'er +$s.es to #!r".ase #ro!"t7 "l$ent nees to be able #ro"ess POS
transa"t$on
o Pre:"on$t$ons= ,ob$le !n$t $s #o+ere7 "!sto'er .as $te's
o ,a$n S!""ess S"enar$o=
1. Cl$ent #o+ers on 'ob$le !n$t
2. Cl$ent !ses t.e transa"t$on s"reen an e$t.er bar"oe s"ans or $n#!ts $te' "oe
6. Cl$ent !#ates 2!ant$t& an oes t.$s for ea". $te'
4. Cl$ent #ro"esses transa"t$on
). Cl$ent "loses transa"t$on
o S#e"$al Re2!$re'ents=
Clean >ra#.$"al (ser Interfa"e t.at allo+s for ease of o#erat$on an $ntera"t$on +$t.
$n%entor&
o Te".nolo1& an Data Var$at$on L$st=
:In%entor& nees to be a""ess$ble on 'ob$le !n$t
:Bar"oe nees to rea an f!n"t$on "orre"tl&

(se Case 4 J ,ana1er e4#ort$n1 sales.
o Interest= 'ana1er +ants to !#ate #r$'ar& atabase fro' 'ob$le !n$t after a& of
sales
o Pre:"on$t$ons= ,ob$le !n$t $s #o+ere7 an "onne"te to $nternet
o ,a$n S!""ess S"enar$o=
1. ,ana1er Po+ers on 'ob$le !n$t
2. ,ana1er "onne"ts to $nternet
6. ,ana1er "l$"<s e4#ort b!tton an s&n"s se"!rel& +$t. ser%er
4. F$le $s e4#orte an rea b& ser%er
). In%entor& $s !#ate
o S#e"$al Re2!$re'ents=
Clean >ra#.$"al (ser Interfa"e t.at allo+s for ease of o#erat$on an $ntera"t$on +$t.
$n%entor& e4#ort an se"!r$t&
o Te".nolo1& an Data Var$at$on L$st=
:In%entor& nees to be a""ess$ble on 'ob$le !n$t
:$nternet nees to be a%a$lable@ f$le e4#ort '!st 'at". est$nat$on $'#ort.

PROTOT-PES

(sers Start S"reen:allo+s !ser to #$"< a transa"t$on t&#e
INVENTOR8 SCREEN: Allo+s !ser to sear". $n%entor& an ret!rns t.e a'o!nt of
#ro!"t an t.e total +ort. of t.$s #ro!"t on .an
DA,A>ED ITE, SCREEN:Allo+s !ser to $n#!t a'a1e $te' an ta<e a+a& fro'
$n%entor& on .an
(PDATE SCREEN: Allo+s !ser to see t.e stat!s of $n%entor& !#ate.
Transa"t$on *$stor& S"reen :Allo+s !ser to see t.e transa"t$on t.at .as been 'ae.