1- use cases

7/23/2019 1- Use Cases

http://slidepdf.com/reader/full/1-use-cases 1/27

Requirements

SpecifcationUse Cases

7/23/2019 1- Use Cases


There are two types o requirements:

1.Functional“In sotware enineerin! a functional

requirement "efnes a unction o asotware system or its component. # unction is"escri$e" as a set o inputs! the $eha%ior! an"outputs &see also sotware'.(&http:))en.wi*ipe"ia.or)wi*i)Functional+requirement'

,. -onunctional

/eneral system properties.

,

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Software_system

http://en.wikipedia.org/wiki/Portal:Software

http://en.wikipedia.org/wiki/Portal:Software

http://en.wikipedia.org/wiki/Software_system

http://en.wikipedia.org/wiki/Software_engineering

7/23/2019 1- Use Cases


Functional Requirements

• Functional requirements may $e calculations! technical "etails! "atamanipulation an" processin an" other specifc unctionality that "efnewhat a system is suppose" to accomplish. 0eha%ioral requirements"escri$in all the cases where the system uses the unctionalrequirements are capture" in use cases. Functional requirements aresupporte" $y nonunctional requirements &also *nown as qualityrequirements'! which impose constraints on the "esin or implementation

&such as perormance requirements! security! or relia$ility'. How a systemimplements unctional requirements is "etaile" in the system design.• #s "efne" in requirements enineerin! unctional requirements speciy

particular results o a system. This shoul" $e contraste" withnonunctional requirements which speciy o%erall characteristics such ascost an" relia$ility. Functional requirements "ri%e the applicationarchitecture o a system! while nonunctional requirements "ri%e thetechnical architecture o a system.

• Typically! a requirements analyst enerates use cases ater atherin an"%ali"atin a set o unctional requirements. ach use case illustrates$eha%ioral scenarios throuh one or more unctional requirements.

&http:))en.wi*ipe"ia.or)wi*i)Functional+requirement'

2

http://en.wikipedia.org/wiki/Use_cases

http://en.wikipedia.org/wiki/Non-Functional_Requirements

http://en.wikipedia.org/wiki/Requirements_analysis


http://en.wikipedia.org/wiki/Reliability

http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Reliability


http://en.wikipedia.org/wiki/Requirements_analysis


http://en.wikipedia.org/wiki/Use_cases

7/23/2019 1- Use Cases


Use Cases

3hat Is # Use Case4# use case in sotware enineerin an" systemsenineerin is a "escription o a system5s $eha%ior asit respon"s to a request that oriinates rom outsi"e

o that system. In other wor"s! a use case "escri$es6who6 can "o 6what6 with the system in question. Theuse case technique is use" to capture a system7s$eha%ioral requirements $y "etailin scenario"ri%enthrea"s throuh the unctional requirements.

&http:))en.wi*ipe"ia.or)wi*i)Use+case'

There are two ways o e8pressin a use case:1. Use Case 0ries,. Fully 9resse" Use Cases

7/23/2019 1- Use Cases


Use Case 0ries

# ew sentences that outline the oalo the use case an" the $eha%ior othe actors an" the system nee"e" toachie%e that oal.

;

7/23/2019 1- Use Cases


Fully 9resse" Use cases

# “ormal "ocument $ase" on a"etaile" template with fel"s or%arious sections< an" it is the most

common un"erstan"in o themeanin o a use case.(


=

7/23/2019 1- Use Cases


Typical Use Case TemplatesI0>:• The sections o a use case• Name. The name shoul" implicitly e8press the user7s intent or purpose o the use case! such as 6nroll Stu"ent in Seminar.6• Identier [Optional]. # unique i"entifer! such as 6UC1?@1!6 that can $e use" in other proAect artiacts &such as your class mo"el'

to reer to the use case.• Description. Se%eral sentences summariBin the use case.• Actors [Optional]. The list o actors associate" with the use case. #lthouh this inormation is containe" in the use case itsel! it

helps to increase the un"erstan"a$ility o the use case when the "iaram is una%aila$le.• Status [Optional]. #n in"ication o the status o the use case! typically one o: wor* in proress! rea"y or re%iew! passe" re%iew!

or aile" re%iew.• Frequency. ow oten this use case is invoked $y the actor. This is oten a reeorm answer such as once per each user loin or

once per month.• Preconditions. # list o the con"itions! i any! that must $e met $eore a use case may $e in%o*e".• Postconditions. # list o the con"itions! i any! that will $e true ater the use case fnishes successully.• Extended use case [Optional]. The use case that this use case e8ten"s &i any'. #n e8ten" association is a eneraliBation

relationship where an e8ten"in use case continues the $eha%ior o a $ase use case. The e8ten"in use case accomplishes this $yinsertin a""itional action sequences into the $ase usecase sequence. This is mo"ele" usin a usecase association with theDDe8ten"EE stereotype.

• Included use cases [Optional]. # list o the use cases this one inclu"es. #n inclu"e association is a eneraliBation relationship"enotin the inclusion o the $eha%ior "escri$e" $y a use case within another use case. This is mo"ele" usin a usecaseassociation with the DDinclu"eEE stereotype. #lso *nown as a uses or a has-a relationship.

• Assumptions [Optional]. #ny important assumptions a$out the "omain that you ha%e ma"e when writin this use case. #t somepoint you shoul" %eriy these assumptions an" e%ol%e them either into "ecisions &see $elow' or simply into parts o the $asiccourse or alternate courses o action.

•

asic course of action. The main path o loic an actor ollows throuh a use case. ten reerre" to as the happy path or themain path $ecause it "escri$es how the use case wor*s when e%erythin wor*s as it normally shoul".• Alternate courses of action. The inrequently use" paths o loic in a use case! paths that are the result o an alternate way to

wor*! an e8ception! or an error con"ition.• !"an#e "istory [Optional]. 9etails a$out when the use case was mo"ife"! why! an" $y whom.• Issues [Optional]. # list o issues or action items! i any! that are relate" to the "e%elopment o this use case.• Decisions. # list o critical "ecisions! typically ma"e $y your S>s! pertainin to the content o the use case. It is important to

recor" these "ecisions to maintain a group memory .

&http:))www.i$m.com)"e%eloperwor*s)we$ser%ices)li$rary)wstip"ocusecase.html'

?

7/23/2019 1- Use Cases


Typical Use Case Templates

>icrosot:$ersion %istory!ontri&utorsAppro'al Si#no( )se !ase Information• )se !ase *•

)se !ase Name• PurposeActor+s,Assumption+s,Pre-!ondition+s,.ain case +%appy Pat",#lternate Gath&s'

Exception Pat"+s,usiness /ules/eferenceutstan"in Issues(ofce.microsoft .com/en-us/ templates /TC3!"#!#33.asp$%

H

7/23/2019 1- Use Cases


Typical Use Case Templates

3i*ipe"ia "efnition o use case template:Use case nameJersion/oalSummary

#ctorsGrecon"itions

Trier0asic course o e%ents#lternati%e pathsGostcon"itions

0usiness rules-otes#uthor an" "ate&http:))en.wi*ipe"ia.or)wi*i)Use+case'

K

7/23/2019 1- Use Cases


Use Case Sections

Use case name # use case name pro%i"es a unique i"entifer or the

use case. It shoul" $e written in %er$noun ormat&e..! &orrow &ooks! 'ithdraw Cash'! shoul""escri$e an achie%a$le oal &e..! egister )ser is$etter than egistering )ser ' an" shoul" $esuLcient or the en" user to un"erstan" what theuse case is a$out. /oal"ri%en use case analysis willname use cases accor"in to the actor7s oals! thusensurin use cases are stronly user centric. Two to

three wor"s is the optimum. I more than our wor"sare propose" or a name! there is usually a shorteran" more specifc name that coul" $e use".


1@

7/23/2019 1- Use Cases


Use Case Sections

Jersionten a %ersion section is nee"e" to inormthe rea"er o the stae a use case hasreache". The initial use case "e%elope" or$usiness analysis an" scopin may well $e%ery "iMerent rom the e%ol%e" %ersion othat use case when the sotware is $ein"e%elope". l"er %ersions o the use case

may still $e current "ocuments! $ecausethey may $e %alua$le to "iMerent userroups.


11

7/23/2019 1- Use Cases


Use Case Sections

/oal

3ithout a oal a use case is useless.

There is no nee" or a use case whenthere is no nee" or any actor toachie%e a oal. # oal $rieNy"escri$es what the user inten"s to

achie%e with this use case.


1,

7/23/2019 1- Use Cases


Use Case Sections

Summary

# summary section is use" to capture theessence o a use case $eore the main $o"y

is complete. It pro%i"es a quic* o%er%iew!which is inten"e" to sa%e the rea"er romha%in to rea" the ull contents o a usecase to un"erstan" what the use case isa$out. I"eally! a summary is Aust a ewsentences or a pararaph in lenth an"inclu"es the oal an" principal actor.


12

7/23/2019 1- Use Cases


Use Case Sections

#ctors#n actor is someone or somethin outsi"e thesystem that either acts on the system O aprimary actor O or is acte" on $y the system O a

secon"ary actor. #n actor may $e a person! a"e%ice! another system or su$system! or time.#ctors represent the "iMerent roles thatsomethin outsi"e has in its relationship withthe system whose unctional requirements are$ein specife". #n in"i%i"ual in the real worl"can $e represente" $y se%eral actors i theyha%e se%eral "iMerent roles an" oals in rear"sto a system. These interact with system an" "osome action on that.

&http:))en.wi*ipe"ia.or)wi*i)Use+case'1

7/23/2019 1- Use Cases


Use Case Sections

Grecon"itions# preconditions section "efnes all the con"itions that must $etrue &i.e.! "escri$es the state o the system' or the trigger &see$elow' to meaninully cause the initiation o the use case. Thatis! i the system is not in the state "escri$e" in the precon"itions!the $eha%ior o the use case is in"eterminate. -ote that theprecon"itions are not the same thin as the 6trier6 &see $elow':

the mere act that the precon"itions are met "oes -T initiate theuse case. owe%er! it is theoretically possi$le *oth that a use caseshoul" $e initiate" whene%er con"ition P is met and that con"itionP is the only aspect o the system that "efnes whether the usecase can meaninully start. I this is really true! then con"ition Pis *oth the precon"ition an" the trier! an" woul" appear in $othsections. 0ut this is rare! an" the analyst shoul" chec* careully

that they ha%e not o%erloo*e" some precon"itions which are parto the trier. I the analyst has erre"! the mo"ule $ase" on thisuse case will $e triere" when the system is in a state the"e%eloper has not planne" or! an" the mo"ule may ail or $eha%eunpre"icta$ly.


1;

7/23/2019 1- Use Cases


Use Case Sections

Triers# 7triers7 section "escri$es the e%ent that causes the use case to$e initiate". This e%ent can $e e8ternal! temporal or internal. I thetrier is not a simple true 6e%ent6 &e..! the customer presses a$utton'! $ut instea" 6when a set o con"itions are met6! there willnee" to $e a trierin process that continually &or perio"ically' runs

to test whether the 6trier con"itions6 are met: the 6trierine%ent6 is a sinal rom the trier process that the con"itions arenow met. There is %aryin practice o%er how to "escri$e what to "owhen the trier occurs $ut the precon"itions are not met.ne way is to han"le the 6error6 within the use case &as ane8ception'. Strictly! this is illoical! $ecause the 6precon"itions6 arenow not true precon"itions at all &$ecause the $eha%ior o the usecase is "etermine" e%en when the precon"itions are not met'.#nother way is to put all the precon"itions in the trier &so that theuse case "oes not run i the precon"itions are not met' an" create a"iMerent use case to han"le the pro$lem. -ote that i this is the localstan"ar"! then the use case template theoretically "oes not nee" aprecon"itions sectionQ

1=

7/23/2019 1- Use Cases


Use Case Sections

0asic course o e%ents#t a minimum! each use case shoul" con%ey a

primary scenario! or typical course o e%ents!also calle" 6$asic Now6! 6happy Now6 an"

6happy path6. The main $asic course oe%ents is oten con%eye" as a set o usuallynum$ere" steps. For e8ample: 1. The system prompts the user to lo on!,. The user enters his name an" passwor"!2. The system %erifes the loon inormation!. The system los user on to system.


1?

7/23/2019 1- Use Cases


Use Case Sections

#lternati%e pathsUse cases may contain secon"ary paths or alternati%e scenarios! which are%ariations on the main theme. ach teste" rule may lea" to an alternati%e path an"when there are many rules the permutation o paths increases rapi"ly! which canlea" to %ery comple8 "ocuments. Sometimes it is $etter to use con"itional loic oracti%ity "iarams to "escri$e use case with many rules an" con"itions.8ceptions! or what happens when thins o wron at the system le%el! may also $e"escri$e"! not usin the alternati%e paths section $ut in a section o their own.

#lternati%e paths ma*e use o the num$erin o the $asic course o e%ents to showat which point they "iMer rom the $asic scenario! an"! i appropriate! where theyreAoin. The intention is to a%oi" repeatin inormation unnecessarily.#n e8ample o an alternati%e path woul" $e: 6The system reconiBes coo*ie onuser7s machine6! an" 6/o to step &>ain path'6. #n e8ample o an e8ception pathwoul" $e: 6The system "oes not reconiBe user7s loon inormation6! an" 6/o to step1 &>ain path'6#ccor"in to #nthony Simons an" Ian /raham &who openly a"mits he ot itwron usin ,@@@ use cases at Swiss 0an*'! alternati%e paths were not oriinallypart o use cases. Instea"! each use case represente" a sinle user7s interaction withthe system. In other wor"s! each use case represente" one possi$le path throuhthe system. >ultiple use cases woul" $e nee"e" $eore "esins $ase" on themcoul" $e ma"e. In this sense! use cases are or e8ploration! not "ocumentation. #n#cti%ity "iaram can i%e an o%er%iew o the $asic path an" alternati%e path.


1H

7/23/2019 1- Use Cases


Use Case Sections

Gostcon"itions

The post-conditions section "escri$eswhat the chane in state o thesystem will $e ater the use casecompletes. Gostcon"itions areuarantee" to $e true when the use

case en"s.


1K

7/23/2019 1- Use Cases


Use Case Sections

0usiness rules0usiness rules are written &or unwritten' rules orpolicies that "etermine how an oraniBation con"uctsits $usiness with rear" to a use case. 0usiness rulesare a special *in" o requirement. 0usiness rules may

$e specifc to a use case or apply across all the usecases! or across the entire $usiness. Use casesshoul" clearly reerence $usiness rules that areapplica$le an" where they are implemente".0usiness Rules shoul" $e enco"e" inline with the

Use Case loic an" e8ecution may lea" to "iMerentpost con"itions. .. Rule,. that a cash with"raw willlea" to an up"ate o the account an" a transactionlo lea"s to a post con"ition on successulwith"rawal $ut only i Rule1 which says there must$e suLcient un"s tests as true.

&http:))en.wi*ipe"ia.or)wi*i)Use+case' ,@

7/23/2019 1- Use Cases


Use Case Sections

-otes

8perience has shown that howe%erwell"esine" a use case template is!

the analyst will ha%e some importantinormation that "oes not ft un"er aspecifc hea"in. Thereore all oo"templates inclu"e a section &e 6-otesto 9e%elopers6' that allows lessstructure" inormation to $e recor"e".


,1

7/23/2019 1- Use Cases


Use Case Sections

#uthor an" "ate This section shoul" list when a %ersion o theuse case was create" an" who "ocumente"it. It shoul" also list an" "ate any %ersions o

the use case rom an earlier stae in the"e%elopment which are still current"ocuments. The author is tra"itionally liste"at the $ottom! $ecause it is not consi"ere"to $e essential inormation< use cases are

inten"e" to $e colla$orati%e en"ea%ors an"they shoul" $e Aointly owne".


,,

7/23/2019 1- Use Cases


3hat5s 8pecte" o ou

In this course we won5t e8pect your use cases to inclu"e all the sectionso a proessional ully "resse" use case. 3e will e8pect! at aminimum:

Use case name an" num$er)i"entiferRis* assessment

Importance assessment9escription)Summary#ctor&s'Grecon"itionsGostcon"itions)Success /uarantee0asic Flow

/oo" to a"" $ut not require":

>inimum /uarantee/oal)#ctor /oals

,2

7/23/2019 1- Use Cases


imitations o Use Cases

Use case Nows are not well suite" to easilycapturin noninteraction $ase" requirements o asystem &such as alorithm or mathematicalrequirements' or nonunctional requirements

&such as platorm! perormance! timin! or saetycritical aspects'. These are $etter specife""eclarati%ely elsewhere.

Use case templates "o not automatically ensure

clarity. Clarity "epen"s on the s*ill o the writer&s'.


,

7/23/2019 1- Use Cases


-onunctionalRequirements

-onunctional requirements are eneralsystem properties inclu"in:

1.ualities o the system,.Constraints on the system

These are oten "escri$e" as thosesystem properties that "o not len"themsel%es well to $ein "escri$e" in ause case.

,;

7/23/2019 1- Use Cases


-onunctionalRequirements

-onunctional Requirements shoul"not $e specifc an" not %aue

3hene%er possi$le they shoul" $ee8presse" in terms o a metric.

e.. The system shoul" ha%e a >TTF oH hours.

,=

7/23/2019 1- Use Cases


Functional or -onunctional

1. Response time

,. #$ility to loin

2. System an")or "ata security. Relia$ility

;. Usea$ility

=. #""in a course?. >aintaina$itlity

,?

1- use cases

Documents