<Template last updated 1/4/2014>

Project Requirements Specification

Project Name: <your project title>

Team Members <team member 1> <team member 2> <etc.> Client Contact: <contact name, organization name> Professor: . !lberto "spinosa, #ogod $c%ool o& 'usiness, !merican (ni)ersity Last updated: <date last updated> Deliverable Number: <*> Document Revision Number: <*> <+,T"$ $a)e a copy o& t%is document as is .it% t%e name /0rojectTemplate.doc1 2or .doc34 and 5eep it as a re&erence. 6t contains all t%e instructions you .ill need to complete t%e project. $a)e anot%er copy o& t%is document .it% t%e name /0roject.doc1 2or .doc34 and remo)e t%e .ord <Template> and all ot%er te3t .it%in <brac5ets> and template instructions 2li5e t%is one4. !lso, please remo)e all t%e blan5 &orms at t%e end o& t%is document. !ll t%is in&ormation is &or your bene&it, but s%ould +,T appear in your o.n project document. 6n ot%er .ords, your &inal project document s%ould loo5 and read li5e a real re7uirements document as you .ould submit it to a business client. $o, it must %a)e a businessli5e appearance, including- .ell &ormatted grap%ics and tables, clear and concise te3t t%at is readable, in&ormational and &ree o& typos and grammatical errors. !ll project documents must %a)e a co)er page li5e t%is one. ")ery re)ision o& t%is document must %a)e all t%e in&ormation s%o.n on t%is sample co)er page. T%e sections in t%e document must be numbered 2consistent .it% t%is template4 to &acilitate communication .it% your client 2and your pro&essor4 about t%e speci&ics o& your document.

Table of Contents & Status Report Project Component 1. 6ntroduction S!stem Concept 2. 'usiness 8ase and 0roject 9ision :. $ta5e%olders S!stem Requirements 4. ;. =. @. B. D. $ystem !ctors $cope o& <or5 >unctional ?e7uirements +onA>unctional ?e7uirements Candated 8onstraints ?ele)ant >acts and !ssumptions Database Desi"n 10. Eata "ntities and ?elations%ips 11. Eata Codel 12. 9isual 6nter&ace and i?ise $imulation #ppendices !. '. 8. E. ". >. F. G. Flossary o& Terms and !cronyms !ctor 8ards 'usiness 0rocess Codel (se 8ase Eiagram Transitional Catri3- '0C and (se 8ases (se 8ases- >unctional ?e7uirements Eata Codel Transitional Catri3- 8?(E Done

<Hour document must contain a table o& contents in t%e second page, rig%t a&ter t%e co)er page. Hour table o& contents must be numbered and t%e numbers must matc% t%e numbers o& t%e corresponding sections. 6 suggest using page numbers in t%e document, but not in t%e table o& contents because t%ey .ill c%ange &re7uently 2unless you use t%e outline &eature t%at maintains t%e table o& contents automatically4. 6t al.ays %elps to tell t%e reader .%at t%ey s%ould e3pect to &ind in t%e document. 6t is )ery %ard to read a document .%en t%ere is no roadmap up&ront because you donIt 5no. .%at to e3pect. T%e J Eone column is to indicate t%e progress on eac% component. T%is .ill %elp your client &igure out .%at %as c%anged since t%e prior deli)erable.>
Communication Lo"

Date

Communication Topic

Comm T!pe

Participants Team Members Client Reps $t%er

Deliverable &

Deliverable '

Deliverable (

Deliverable )

*inal Project Deliverable+ ,isual Simulation and Presentation

<T%is log is not normally included in t%e re7uirements speci&ication document. >or t%is project, you are re7uired to include it %ere to document your communication .it% your client. Hou donIt need to document your communication .it% t%e pro&essor, only .it% your client and .it% any sta5e%older associated .it% your project. 0lease donIt enter meeting comments or notes, just log your communication and meetings, as you .ould i& you .ere doing t%is &or a billable consulting client. 6n t%e Communication Topic column enter a brie& 2just a &e. .ords4 description o& t%e main topic. 6n t%e Comm T!pe column enter eit%er- Ceeting, $5ype, 0%one, "mail, etc. 6n t%e : Participants column indicate .%o attended t%e meeting or .%o %andled t%e communication. T%e e3pectation is t%at you .ould %a)e at least a couple o& substantial communication interactions .it% your client &or eac% deli)erable.>

<-MP$RT#NT N$T.: students o&ten ma5e t%e mista5e o& .riting t%is speci&ication document in &uture tense 2e.g., t%e system .ill allo. users to .it%dra. cas%4. T%is %as t.o problems. >irst, it increases t%e amount o& .or5 you %a)e to do because once t%e system is &inis%ed you .ill use t%is document as part o& t%e tec%nical documentation o& your system, .%ic% needs to be in present tense. $econd, it ma5es t%e document %arder to read. ! .ell .ritten document in present tense .ill %elp you accomplis% t%e main goal o& t%is document- to clearly and concisely document system re7uirements. $o, please .rite in present tense.> <0lease note t%at se)eral sections o& t%is template %a)e been adopted and adapted &rom t%e /,olere Requirements Template0 2posted on 'lac5board4 recommended by t%e !tlantic $ystems Fuild, 6nc. company, &ully described by $uzanne ?obertson and ames ?obertson in t%eir boo5- /Castering t%e ?e7uirements 0rocess1 2please note t%at Tom EeCarco, one o& t%e most in&luential members o& t%e so&t.are engineering community, is a principal o& t%is company4. T%e 9olere process is a popular re7uirements process used by se)eral companies. <e .ill not use t%is process &or t%is project because .e .ill be &ollo.ing bot%, t%e (ni&ied 0rocess 2(04 o& system de)elopment, .%ic% is a more standard process used t%ese days, and t%e use case 0rocess recommended by >ran5 !rmour in %is te3tboo5, .%ic% is consistent .it% t%e (0. Go.e)er, t%e 9olere process includes a )ery use&ul re7uirements template t%at s%o.s %o. a typical re7uirements document s%ould be structured. 'ecause t%is template is )oluminous, t%e re7uirements template .e .ill use &or t%is course 2subject o& t%is document4 is an adapted and simpli&ied )ersion o& t%e 9olere template. Hou can learn more about t%e /9olere1 ?e7uirements 0rocess and associated resources at %ttp-//....)olere.co.u5/.> < +ote- an important aspect o& client documents 2or any document &or t%at matter4 is t%at e)ery &igure, table, e3%ibit and appendi3 in your document s%ould be re&erenced in t%e main te3t. !ny e3%ibit not re&erenced in t%e main te3t only causes con&usion .it% your readers. ?eaders .ill .onder .%at to ma5e out o& unre&erenced tables and &igures, .%ic% are e3tremely con&using. 6n t%e case o& 5ey arti&acts in appendices 2'0CKs, use case diagrams, data model4, you need to not only to re&erence t%em in t%e main te3t, but also to pro)ide a brie& te3tual description o& t%e arti&act to orient your readers and introduce t%em to t%e arti&act t%ey are about to see in t%e appendi3.> <0lease note t%at all t%e necessary blan5 &orms you .ill need to prepare all re7uirements arti&acts &or t%is speci&ication are pro)ided at t%e end o& t%is template.> &1 -ntroduction <!ll project speci&ication documents must start .it% an introduction t%at tells t%e reader .%at t%ey are about to read. T%is is +,T an introduction to t%e project. Hou .ill do t%at in t%e ne3t section. T%is 6$ an introduction to t%is document, to guide your reader. Hour introduction s%ould say somet%ing li5e t%is- > </6n t%is document .e describe t%e re7uirements &or t%e system Linsert your project name %ereM. <e &irst describe t%e system concept and )ision, &ollo.ed by a description o& actors, system boundary and scope o& t%e system. <e t%en pro)ide more detailed re7uirements using use cases, &ollo.ed by a description o& nonA&unctional re7uirements &or t%e system. >inally

.e pro)ide a data model and ot%er in&ormation management speci&ications. 0lease re&er to !ppendi3 ! &or a glossary o& terms and acronyms used in t%is document.1> '1 2usiness Case and Project ,ision <see !rmour, 8%.:- T%e /9ision Eocument1> <T%is section o& your document s%ould clearly articulate and justi&y .%y t%e system .ill be de)eloped. T%is section needs to clearly articulate t%e business case 2.%y is t%is important to your clientIs businessN4 and .%at system or business application you are proposing to address your clientIs problem. T%is is t%e section t%at sells your project to your client, so you need to ma5e a con)incing case. Hou .ill start .it% business case project )ision statements, along .it% an o)er)ie. o& t%e business process. Hou .ill update t%is section .it% eac% deli)erable to include brie& summaries o& your proposed target process, &unctional re7uirements, data re7uirements and a closing statement connecting e)eryt%ing bac5 to t%e business case. <%en you are &inis%ed .it% t%e project, t%is section s%ould read as a standalone o)er)ie. o& t%e system and its business )alue &or %ig% le)el managers, clients and e3ecuti)es. !t minimum, t%is section s%ould containEeli)erable 12a4 ! description o& .%o your client is 2important note- donIt re&er to your clients by name in t%is section. 8lient reps sometimes c%ange, so it is better not to use t%eir names inside t%e document, just in t%e co)er page.4 $imply name t%e company and/or di)ision/department you are doing t%is &or and brie&ly describe your clientIs business. 2b4 ! statement describing t%e business problems/needs o& your client, .%ic% .ill be t%e &ocus o& your analysis on t%is project. EonIt state t%is problem in terms o& system needs, but describe t%is as a business case. <%y is t%is important to your clientIs businessN 'e )ery speci&ic %ere t%is is t%e reason .%y you are being %ired by your client as a consultant, so ma5e a good case. 2c4 ! brie& o)er)ie. o& t%e present business processes 2i.e., baseline4 and &unctions associated .it% t%e problem you just described abo)e. EonIt describe t%e entire process, but only t%ose parts t%at are associated .it% t%e problem. ?emember t%at t%ere is a &ull business process section later in t%e document. T%is is just a brie& o)er)ie.. 2d4 0ro)ide a brie& discussion o& t%e goals and objecti)es o& t%e system you .ill be proposing. >ocus on %o. t%e proposed system .ill address your clientIs needs discussed abo)e. !t t%is point you donIt 5no. precisely %o. t%e system .ill .or5, but you s%ould %a)e a good idea o& %o. t%e system .ill sol)e your clientIs problem. T%is is a %ig% le)el o)er)ie., not a detailed description so be concise, but in&ormational. Hou .ill describe your system in more detail later. 2e4 !ny ot%er pertinent bac5ground in&ormation.> Eeli)erable 2-

2&4 0ro)ide a brie& o)er)ie. o& t%e proposed business processes 2i.e., target process only i& it is di&&erent t%an t%e baseline4. EonIt describe t%e entire process, but only t%ose parts t%at are associated .it% your proposed solution. ?emember t%at t%ere is a &ull business process section later in t%e document. T%is is just a brie& o)er)ie. and it is a reduced )ersion o& your target process description in section 4 belo.. Eeli)erable :2g4 0ro)ide a brie& o)er)ie. o& t%e proposed system &unctionality o& your solution. Eescribe .%ic% &unctionality .ill support your recommended target process and solution. EonIt describe t%e entire &unctionality, but only %ig%lig%ts o& t%e 5ey 2not all4 actors and &unctionality .ort% %ig%lig%ting to a busy manager reading t%is. ?emember t%at t%ere is a &ull section &or t%e &unctional re7uirements later in t%e document. T%is is just a brie& o)er)ie. and it is a reduced )ersion o& your &unctional re7uirements description in section = belo.. Eeli)erable 42%4 0ro)ide a brie& o)er)ie. o& t%e data objects supporting your solution. EonIt describe t%e entire data model, but just t%e 5ey aspects o& t%e data objects supporting your solution. ?emember t%at t%ere is a &ull section &or t%e data re7uirements later in t%e document. T%is is just a brie& o)er)ie. and it is a reduced )ersion o& your data re7uirements description in section 10 belo.. >inal 0roject Eeli)erable2i4 ?e)ie. e)eryt%ing you %a)e .ritten in t%is section and &ine tune as needed. T%is section is .%at .ill sell your project to clients and %ig% le)el managers, so it C($T be .ell articulated, understandable, co%esi)e, accurate, consistent and con)incing. Cany busy managers and clients .ill not %a)e t%e time to re)ie. all your arti&acts, but t%ey .ill read t%is section care&ully. 6t must be tig%t or you .ill ne)er sell your project to your audience. 2j4 8losing statement. 8onnect e)eryt%ing bac5 to t%e business case. +o. t%at you %a)e pro)ided an o)er)ie. o& t%e business case, current process, process impro)ements, ne. &unctionality, etc., you are in a good position to pro)ide a more impact&ul statement o& t%e tangible bene&its o& your project implementation and %o. it %elps business. !ny 7uanti&ication you may be able to pro)ide %ere .ould be most use&ul 2e.g., increased re)enues, increased pro&its, reduced costs, e&&iciencies gained, 7uality impro)ements, reduced personnel e&&ort, more reliable and timely in&ormation, etc. Hou donIt need all t%ese, but t%in5 care&ully about t%e speci&ic business )alue your implementation is pro)iding to your client4 (1 Sta3e%olders <see !rmour, 8%.=- /0reparing &or (se 8ase Codeling1> <6n t%is section you .ill present your sta5e%older analysis. ! sta5e%older is anyone .%o .ill be a&&ected by, or .%o %a)e an interest 2economic, tec%nical, political, legal, etc.4 in t%e system. 6t includes clients 2i.e., .%o %ired you to do t%e .or54, in)estors 2i.e., .%o is paying &or t%e de)elopment o& t%e system4, users 2i.e., t%ose .%o .ill be interacting .it% t%e

system4, and any ot%er person or entity t%at %as an interest in t%e system 2e.g., regulators, 5ey )endors, &inancing sources4 or .%o .ill be a&&ected by t%e system 2e.g., managers, tec%nical support groups, users/administrators o& related systems t%at .ill interact .it% your system, users o& prior )ersions, etc.4. 6t is important to note t%at all users o& t%e system are sta5e%olders, but not all sta5e%olders are users. $ome indi)iduals are a&&ected by t%e system .it%out necessarily being users 2e.g., t%e legal sta&&, regulators, %uman resources sta&&4.> <$ta5e%olders are important because t%ey represent t%e people you .ill need to inter)ie. &or t%e project 2i& you .ere doing t%is &or real4. !nyone .it% a sta5e in t%e system %as a perspecti)e o& and an opinion about t%e system and, as a consultant, you most de&initely .ant to %ear it. !nyone .%o %as an interest or .%o .ill be a&&ected by t%e system s%ould be inter)ie.ed 2i& you .ere doing t%is &or real4. > <,ne important note about sta5e%olders is t%at t%ey are people, not institutions or departments. 6& you canIt tal5 to %im or %er, it is not a sta5e%older. $o, t%e !ccounting Eepartment is de&initely not a good e3ample o& a sta5e%older. !n accountant or t%e !ccounting Eepartment sta&& are good e3amples. Typically, sta5e%olders s%ould be speci&ic 2e.g., t%e companyIs auditors4, rat%er t%an general 2e.g., accounting employees4.> < T%e sta5e%older analysis section s%ould contain a list o& all sta5e%olders associated .it% your system. >or eac% sta5e%older, you need to pro)ide- 214 a description o& t%e sta5e%older role and/or sta5e .it% respect to t%e system. T%is description s%ould not contain person name names, but roles 2in case t%e people in)ol)e c%ange4O and 224 a description o& %o. t%e sta5e%older is a&&ected by t%e system or .%at is %is/%er )ested interest in t%e system. <6C0,?T!+T +,T" !',(T T"PT +!??!T69"$ ,> !?T6>!8T$ 0lease note t%at all sections associated .it% arti&acts in appendices must %a)e a brie& te3t narrati)e pro)iding an o)er)ie. o& t%e arti&act. T%is narrati)e s%ould contain, at t%e )ery least- 214 a brie& o)er)ie. o& t%e arti&act 2not a &ull articulation o& t%e arti&act4O and 224 any in&ormation necessary &or your readers to understand t%e arti&act. $ome arti&acts cannot be understood .it%out some brie& e3planation o& notations or symbols used, so t%is narrati)e is critical to t%e e&&ecti)e understanding o& .%at you are trying to illustrate in t%e arti&act.> )1 2usiness Process #nal!sis <T%is section o& t%e re7uirements speci&ication is sometimes re&erred to as t%e /scope of 4or30. 6t does t.o important t%ings. >irst, contains an articulation o& your clientIs present 2i.e., baseline or as is4 business process and your proposed 2i.e., target or to be4 business process impro)ements. $econd, and e7ually important, it /bounds1 t%e scope o& your .or5 &or t%is client engagement. ,&ten t%e complete process is muc% larger t%an .%at you are describing %ere. 'y articulating t%e baseline and target business processes, you are in essence establis%ing boundaries &or t%e scope o& your .or5 on t%is project. T%is section needs to %a)e at least : sectionsa4 Baseline Process 0ro)ide a narrative o)er)ie. o& t%e current 2baseline4 business process. T%is description s%ould be brie& and %ig% le)el paragrap%, but s%ould also be

in&ormational. Eescribe %o. t%ings are currently done. Eo not &ocus on t%e current system, unless t%e system is integral to t%e process. >ocus instead on t%e .or5 being done by indi)iduals. T%is description s%ould be accompanied by a baseline 2PM in #ppendi5 2& and t%is '0C s%ould be consistent .it% your te3t description in t%is section. !t t%e end o& your te3t description, you need to re&erence t%e corresponding appendi3, e.g., />or &urt%er details on t%e baseline '0C, please re&er to !ppendi3 '1.1 0lease ensure t%at your te3t narrati)e description in t%e main te3t is consistent .it% your '0C diagram. 6magine t%at you .ant to brie&ly describe your '0C to someone o)er t%e p%one. T%atIs .%at your narrati)e s%ould say. T%is model s%ould +,T contain a lot o& details 2it s%ould &it on one page4, but s%ould gi)e t%e reader a broad o)er)ie. o& t%e current business processes related to t%is implementation. Eo +,T include any process impro)ement recommendations at t%is time. ust &ocus on understanding t%e current business processes. ! Eeloitte client once pro)ided t%is description o& t%e baseline '0C, .%ic% sums it up 7uite nicely- the baseline BPM you deliver represents your demonstrated understanding of your clients business, .%ic% .ill boost your clientIs con&idence in your .or5. !ll '0CIs in t%is document need to %a)e a &unctional band 2i.e., s.im lane4 &or eac% main user type, role, business unit, department or &unction in)ol)ed .it% t%e processes you are automating. ?emember, t%is is a model o& t%e 5ey '($6+"$$ processes and not a system model. Hou need to model .%at people do, +,T .%at t%e system .ill do. T%ese diagrams are use&ul to &oster clear communication .it% your client 2and pro&essor4 and to de)elop a s%ared conceptualization o& t%e .or5 to be done .it%in your team. 6mportantyour project )ision and client problem description need to ma5e re&erence to and be consistent .it% t%is baseline '0C 2ot%er.ise, .%y model itN4. b4 Process Analysis !n analysis o& t%e problems and bottlenec5s in t%e current process just described. T%is section s%ould be one or t.o paragrap%s long in .%ic% you identi&y t%e pain points, ine&&icient steps, redundant steps, .aste&ul loops, etc. T%is description s%ould +,T be &ocused on .%at a system does or .ill do. Go.e)er, since t%e objecti)e o& your client assignment is to de)elop speci&ications &or a system, t%e capabilities t%at computerized systems bring about s%ould be in t%e bac5 o& your %ead as your &ormulate recommendations. Hou need to analyze eac% process step, decision step, &lo. bet.een steps, p%ases, and &unctional bands, and analyze t%ings li5e !re t%ere any steps t%at could be eliminatedN "liminating steps are not al.ays possible or e)en use&ul and you %a)e to be care&ul t%at t%is is ,# .it% your client. 'ut you may %a)e identi&ied steps t%at .ill not be necessary .it% a ne. process or a ne. system, or per%aps t%ere are .aste&ul or ine&&icient steps t%at can be eliminated. !re t%ere any steps t%at could be addedN ?emo)ing steps may simpli&y t%e diagram, but sometimes adding a &e. steps can ma5e t%ings more e&&icient. >or e3ample, you could add a step t%at collects customer data, t%at can later be used &or analysis. !re t%ere any steps t%at could be split into more t%an one stepN $ometimes, a simple step doesnIt do t%e job and you need to add steps.

!re t%ere more t%an one step t%at could be mergedN $ometimes multiple steps can be simpli&ied and consolidated into a single step to gain e&&iciencies. 8an steps be reArouted to ot%er indi)iduals or &unctional bands, or per%aps reAordered to ma5e t%ings more e&&icient. !re t%ere steps in .%ic% e&&iciencies could be le)eraged &rom 6TN !gain, your &ocus at t%is stage is not in 6T per se, but you may .ant to t%in5 about %o. 6T can %elp you impro)e t%e process. 6& your solution re7uires t%at t%e target '0C be identical to t%e baseline '0C, use t%is section to articulate t%e process impro)ements t%at automation and computerization o& t%e process .ill bring about. >or e3ample, i& a particular go)ernment bene&it application process %as .ell de&ined steps t%at need to be &ollo.ed, you may not be able to c%ange t%e process. 'ut you s%ould be able to identi&y .%ic% and %o. manual steps, or .%ic% steps %andled by anti7uated systems .ill be better %andled by t%e ne. system. >inally and 6C0,?T!+TQH, students sometimes ma5e t%e mista5e o& simpli&ying t%e '0C, .it%out simpli&ying t%e process itsel&. >or e3ample, someone may suggest merging t.o steps into a single step in t%e '0C dra.ing, but t%e .or5 t%at needs to be done is t%e same. !ll t%is does is to c%ange t%e )isual representation o& t%e .or5, but does not c%ange t%e .or5 itsel&. 0lease ensure t%at as you &ormulate your business impro)ement recommendations you are impro)ing t%e .or5, not just t%e dra.ing o& t%e '0C.

c4 Target Process ! description o& your proposed business process improvement. Hour proposed impro)ement must &ollo. &rom your analysis abo)e 2ot%er.ise, .%y analyzeN4. 6& your solution does not c%ange t%e current process, please speci&y t%at )ery clearly %ere. ,&ten teams simply omit t%is section and silence can be )ery con&using. T%is description s%ould be concise and )ery speci&ic. Hour '0 impro)ements donIt necessarily %a)e to be large and compre%ensi)e. $ometimes small c%anges in &ocused areas bring about substantial bene&its. 6& your impro)ement is )ery &ocused on a particular aspect o& t%e process, you donIt need to diagram t%e &ull process. ust &ocus in t%e solution or impro)ement you are recommending, but pro)ide some .ay o& &iguring out .%ere you recommendation &its into t%e original process. Eescribe %o. t%ings are currently done. T%is description s%ould be accompanied by a tar"et 2PM in #ppendi5 2' and t%is '0C s%ould be consistent .it% your te3t description in t%is section. !t t%e end o& your te3t description, you need to re&erence t%e corresponding appendi3, e.g., />or &urt%er details on t%e target '0C, please re&er to !ppendi3 '2.1> <Tec%nical notes- Hour '0C s%ould include a &unctional band 2i.e., s.im lane4 &or eac% 5ey &unction, di)ision or role associated .it% t%e process. ?emember, t%is is a model o& t%e 5ey business processes and not a system model. T%ere&ore, you need to model .%at people do, not .%at t%e system does or .ill do. T%ese diagrams &acilitate clear communication .it% your client 2and pro&essor4 and are use&ul to de)elop a s%ared conceptualization o& t%e .or5 to be done .it%in your team. >

<0lease also note t%at in some cases t%e baseline '0C needs to be preser)ed. >or e3ample, t%is is typical o& automation projects in .%ic% t%e client needs to preser)e t%e e3isting processes, but t%e current process is eit%er manual or uses an outdated system. 6& t%is is t%e case, your baseline and target '0Cs are one and t%e same, so t%ere is no need to dra. a second '0C, unless you are proposing some minor re&inements to t%e process. 6n ot%er .ords, .%en you conceptualize a solution to your clientKs problem, t%ere are : possibilities214 Hour solution in)ol)es a business process impro)ement, but no c%an"e in t%e s!stem. T%e solution is entirely based on impro)ing t%e business process and %o. t%ings are done, .it%out altering t%e system. T%is .ould not be a good project &or t%is course, but situations li5e t%is can %appen in a real project. 6n t%is case, your target '0C is critical to your solution. 224 Hour solution in)ol)es no c%an"e in t%e business process, but t%ere are substantial e&&iciencies gained t%roug% automation. T%e business process does not c%ange, eit%er by c%oice or because it is not allo.ed by your client or by some regulation. 6n t%is case, you donKt need to dra. a target '0C, but you need to clearly articulate in t%e analysis and target '0C portion o& t%is document t%at t%e target process is identical to t%e baseline process and .%y. EonKt lea)e it up to t%e reader to interpretO or 2:4 T%e most li3el! possibilit! is t%at your solution in)ol)es some business process improvement combined 4it% some automation. 'ecause your solution in)ol)es a system implementation, t%is presents a uni7ue opportunity to le)erage t%e use o& 6T to impro)e t%e business process. <%en you go &rom a manual or older system, to a ne. system implementation, t%in5 o& .%at aspects o& t%e process could be redesigned to ta5e ad)antage o& t%e ne. system. 6n t%is case, you need to submit a target '0C and mar5 t%e steps t%at .ill be automated, to distinguis% t%em &rom t%e manual steps.> 61 S!stem #ctors <see !rmour, 8%.1- /!ctors1> <! system actor is anyt%ing t%at interacts .it% t%e system. T%ere are t.o 5inds o& actors- 214 Guman !ctors i.e., users o& t%e systemO and 224 "3ternal $ystem !ctors i.e., ot%er systems t%at your system interacts .it%. T%ere are t.o categories o& actors214 0rimary i.e., t%e actors t%at your system aims to pro)ide )alue to, t%at is, actors t%at %a)e goals associated .it% your system. 0rimary actors are o& 5ey importance in re7uirements analysis because an analysis o& t%eir goals leads to t%e disco)ery o& t%e necessary use cases. ,nce you %a)e enoug% use cases to &ul&ill all o& t%e primary actorsI goals, you are doneO and 224 $econdary i.e., actors t%at donIt %a)e goals associated .it% your system, but t%at your analysis indicates t%at your system .ill need t%em &or t%e system to &unction. Hou donIt need to identi&y or analyze secondary actor goals, because t%ere are none. $econdary actors are disco)ered .%en you start .riting use cases and you &ind t%at you need data or processing ser)ices &rom an actor. T%ese are typically 2but not al.ays4 e3ternal system actors.

T%e typical process to identi&y t%e system &unctionality re7uired and t%e respecti)e use cases is- 214 6denti&y all 0rimary !ctorsO 224 !nalyze t%e goals associated .it% t%e system o& t%ese 0rimary !ctorsO 2:4 6denti&y t%e business e)ents or transactions t%at need to occur to &ul&ill t%ese goalsO 244 Translate t%ese transactions into use casesO 2;4 6denti&y any $econdary !ctors you may need. >ollo.ing t%is process, t%is section re7uires t%e &ollo.inga7 Primar! #ctors &ollo.ing your target '0C, identi&y all Primar! #ctors &or t%e system. 6n t%e narrati)e portion o& t%is document, list eac% all primary actors and brie&ly describe t%eir "oals .it% respect to t%e &unctionality t%ey need &rom t%e system. T%en, prepare an #ctor Card &or eac% o& t%ese actors in #ppendi5 C. 6n t%e actor cards, please ensure t%at all t%e actor goals are listed and t%at all &ields in t%e !ctor 8ard are &illed in correctly. Eo not enter t%e use cases associated .it% t%is actor yet. Hou .ill do t%is later in t%e ne3t portion. b7 8ontinue to $ection 8 *unctional Requirements. c7 Secondar! #ctors !s you de)elop t%is section, and as you identi&y and elaborate t%e use cases &or t%is application, proceed to 8 belo. eac% time you identi&y a necessary $econdary !ctor. T%en, prepare an !ctor Card &or eac% o& t%ese actors in #ppendi5 C. >or secondary actors, you donIt need to 2and s%ould not4 list any actor goals. 'y de&inition, $econdary !ctors donIt %a)e goals. > <!t t%e beginning o& t%is section, please include some te3t li5e t%is/!ctors are all t%e entities t%at interact .it% t%e system. !ctors can be %uman 2i.e., users4 or e3ternal systems t%at need to interact .it% our system. !ctors can be o& t.o types- 214 0rimary actors, .%ic% are actors t%at %a)e goals, .%ic% t%is system needs to &ul&illO and 224 $econdary actors, .%ic% donIt %a)e goals associated .it% t%is system, but are needed &or t%e e3ecution o& t%e systemIs use cases. 6n t%is section .e pro)ide a list o& actors .it% brie& descriptions. 0lease re&er to !ppendi3 8 &or t%e corresponding actor cards .it% &ull details.1> 81 *unctional Requirements <see !rmour, 8%s. 2, @, B, D and 10> <6n t%is section you need to pro)ide- 214 a narrati)e pro)iding an o)er)ie. o& t%e &unctionality o& t%e systemO 224 a list o& use cases .it% a brie& descriptionO 2:4 a '0C/(se 8ase Transitional Catri3 in !ppendi3 "O 244 t%e corresponding use cases in appropriate use case &orms in !ppendi3 >O and 2;4 a use case diagram in !ppendi3 E. !t t%e beginning o& t%is section, please .rite an introduction to t%e section, li5e t%is one/6n t%is section .e describe t%e &unctionality o& t%e application. <e pro)ide %ere a brie& description o& t%is &unctionality, along .it% a list o& use cases. T%e corresponding use case diagram is s%o.n in !ppendi3 E. ! '0C/(se 8ase transitional matri3 is s%o.n in !ppendi3 ", .%ic% s%o.s .%ic% use cases support eac% '0C step. T%e corresponding use cases at )arious stages o& elaboration are presented in !ppendi3 >.1> <T%ese are t%e speci&ics &or t%is section-

a7 9se Case List a&ter t%e introduction in abo)e in t%e main te3t, pro)ide a list o& your use cases, s%o.ing t%eir number, name and a )ery brie& description o& .%at eac% use case does. T%is list o& use cases must be compre%ensi)e and su&&icient to &ul&ill all t%e goals identi&ied &or all primary actors. b7 -nitial 9se Cases based on t%is list, prepare initial use case &orms &or all t%e use cases and place t%em in #ppendi5 *. 0lease ensure t%at all t%e necessary &ields in t%e &orm are &illed in correctly and t%at t%e "laboration 0%ase entry says /6nitial use case descriptions1. 0lease ensure t%at you complete all t%e necessary &ields in t%e initial use case &orm and t%at all t%e actors associated .it% t%e use case are listed. (se case descriptions must be concise 2B to 10 lines4, but )ery clear and in&ormational, and s%ould pro)ide a good idea o& t%e &unctions %andled by t%e use case &rom t%e !ctorsK perspecti)e. 0lease note t%at use cases are used mainly to describe system actions .%en interacting .it% t%e actor. T%is is because t%is is t%e only in&ormation t%at system de)elopers need to program t%e application. $o, t%ere is no need to describe manual steps and actions t%at donIt in)ol)e t%e system. Go.e)er, i& you &eel t%at it is important to describe manual steps and actions, you can do t%is, but you must clearly indicate t%at t%ese steps are manual. ,t%er.ise, t%e system de)elopers .ill get con&used. >or e3ample, you could .rite somet%ing li5e t%is- /2Canual4 8ustomer .al5s into t%e store, bro.ses merc%andise and brings to t%e cas%ier. T%e cas%ier initiates t%e sale, scans all items, and completes t%e sale. 2Canual4 t%e customer tenders cas%, c%ec5 or credit card. T%e corresponding payment transaction is recorded. 2Canual4 t%e customer lea)es t%e store.1> <6C0,?T!+T- common mista5e you need to !9,6E is to use a long )ersion t%e use case name as t%e description 2e.g., (8A100 8as% <it%dra.al t%is use case allo.s clients to dra. cas% &rom t%e !TC4. T%is is a useless description because it says not%ing about t%e system steps and not%ing ne. .%ic% .e canIt &igure out &rom t%e use case name. 'e sure t%at your use case description re&lects %o. t%e use case e3ecutes .%en interacting .it% t%e actor. c7 9se Case Dia"ram using in&ormation &rom t%e actor cards and initial use cases, prepare a use case diagram &or t%is application and include it in #ppendi5 D. T%is diagram must be properly dra.n per t%e (CQ notation. d7 9se Case Numbers in #ctor Cards return to t%e actor cards in Section 6 and enter t%e corresponding use case number t%at eac% actor is associated .it%. T%is must be consistent .it% your use case diagram and use cases. e7 2PM:9se Case Transitional Matri5 ; &ollo.ing your '0C, use case diagram and use cases, complete t%e '0C/(se 8ase Transitional Catri3 and include it in #ppendi5 .. T%is matri3 cross re&erences .%ic% use case is associated .it% eac% '0C process or decision step. 6t is an important crossAre&erencing e3ercise to ensure t%at your arti&acts are consistent .it% eac% ot%er. 6& you notice any '0C step t%at is not associated .it% any use case, t%is means t%at t%e '0C step is completely is eit%er manual. 6& not, t%en you must %a)e made an omission some.%ere, so you need to go bac5 and c%ec5. 6& you notice any use case t%at is not associated .it% any '0C step, t%en you eit%er %a)e an unnecessary use case, or your '0C is incomplete, so you need to go bac5 and c%ec5.

f7 .laborated 9se Cases $ome initial use cases .ill be elaborated to a /2ase 9se Case0 p%ase, some to /.laborated0 p%ase, and some .ill remain as /6nitial (se 8ases.1 T%is is typical in consulting projects in .%ic% t%e %ig%est priority use cases get &ully elaborated &irst. >or t%is project, you need to elaborate t%e 8 most important use cases to 2ase 9se Case &orm. Hour base use cases s%ould include all necessary- pre<conditions+ optimistic flo4 of events 2i.e., RsunnyAdayR scenarios4, post<conditions and any pertinent in&ormation in t%e remaining &orm &ields. Hou t%en need to select t%e ( most important use cases out o& t%ese = and &ully de)elop t%em to .laborated p%ase. 6n t%e end, you s%ould %a)e ( base use cases, ( elaborated use cases, and t%e remaining use cases in initial use case p%ase. +o., t%is is t%e minimum re7uirement. ,& course, you can al.ays elaborate more use cases i& you .is%. 6n addition to preAconditions, optimistic &lo. o& e)ents and postAconditions, t%ese use cases must %a)e all t%e necessary conditional flo4s 2i.e., RrainyAdayR scenarios4 or alternative use cases. T%e &lo.s &or t%ese use cases need to be t%oroug% and complete, %andling e)ery possible alternati)e and e3ception t%at t%e respecti)e actors may encounter .%ile e3ecuting t%is use case. Hou can &ully elaborate more t%an : use cases i& you .is%, but : use cases .ell elaborated are su&&icient.> <0lace all your use cases in se7uential order in #ppendi5 *.> <6C0,?T!+T- Hou only need one use case &orm &or eac% use case. T%at is, .%en you elaborate an initial use case into a base use case you s%ould delete t%e initial use case. Ga)ing multiple elaborations o& t%e same use case is more .or5 &or you, con&using to your client and pro&essor, and more importantly, it is incorrect. 6nitial, base and elaborated use cases are elaboration /p%ases1 o& t%e same use case. $o, i& t%ere is a use case (8A01, t%ere s%ould not be anot%er one .it% t%e same name and number.> "7 *unctional Requirements Narrative +o. t%at you %a)e a better understanding o& t%e &unctionality re7uired, prepare one substantial paragrap% t%at describes t%e &unctionality speci&ied in your use case model. $uppose t%at t%e 0o.erpoint projector brea5s do.n be&ore a presentation to your client, and t%e client as5s you to describe your model succinctly and )erbally. <%at .ould you say to gi)e a complete picture o& t%e &unctionality described in your use case diagram and use casesN T%atIs e3actly .%at you need to .rite %ere and it pro)ides an introduction to your use cases. EonIt repeat .%at eac% use case says, but compose a co%erent paragrap% t%at describes t%e general &unctionality. !gain, t%is narrati)e s%ould contain- 214 a brie& o)er)ie. o& t%e use case model and &unctional re7uirementsO and 224 any in&ormation necessary &or your readers to understand t%e use case model. > =1 Non<*unctional Requirements <see !rmour, 8%.11 /$upplemental 6n&ormation> <+onA&unctional re7uirements are an e3tremely important part o& your re7uirements analysis. T%ey %a)e no e&&ect .%atsoe)er on 4%at t%e system does, but it does a&&ect %o4 t%e system does it and t%e o)erall capabilities o& t%e system. +onA&unctional re7uirements o&ten %a)e a substantial impact on t%e systemIs implementation cost. >or e3ample, a system t%at is up and running and a)ailable DD.DDDJ o& t%e time, .it% redundant ser)ers running on multiple cities, .it% data replication and sync%ronization, and capable o& %andling ; million %its a day, .ill

cost substantially more t%an a comparable system .it% identical &unctional re7uirements t%at runs in a standalone 08 %andling 100 %its per day. 'ut bot% systems may %a)e similar &unctionality. ?e7uirements come in many &orms and &la)ors. T%e 9olere template %as an e3cellent re&erence list o& )arious re7uirement types, so please re&er to t%at template. "ac% type o& nonA&unctional re7uirement needs to be listed as a subAsection in t%is section. 0lease use t%e subAsections listed belo. only i& appropriate and t%en delete any subAsections you donIt need and add any ne. ones you need. 0lease donIt ma5e up nonA&unctional re7uirements just to &ill t%is section because t%ey reduce t%e credibility o& your document. > <0lease only list nonA&unctional re7uirements t%at are re7uired by your client and t%ose t%at you t%in5 are important &or your system to operate properly in t%e en)ironment in .%ic% it .ill be implemented. EonIt just list re7uirements to &ill t%is section. !lso, please ma5e your nonA&unctional re7uirements as speci&ic and measurable as possible. +onA&unctional re7uirements t%at are not measurable 2e.g., system must be &ast and reliable4 are totally useless in re7uirements documents because t%ey cannot be en&orced contractually. Core speci&ic and measurable nonA&unctional re7uirements 2e.g., system must be a)ailable DD.DJ o& t%e time and %andle 100,000 transactions per day4 are more use&ul. >inally, be mind&ul o& .%o is paying &or t%ese capabilities. $tudents o&ten ma5e t%e mista5e o& stating t%e %ig%est 7uality, speed and reliability t%ey can t%in5 o&, but i& you are responsible &or deli)ering t%is system &or a &i3ed price, t%en .ill be %urting yoursel& &inancially.> =1&1 Look and Feel Requirements =1'1 Usability Requirements =1(1 Performance Requirements =1)1 Operational Requirements =161 Maintainability and Portability Requirements =181 ecurity Requirements =1=1 !ultural and Political Requirements =1>1 Legal Requirements >1 Mandated Constraints <Hou need to describe in t%is section any constraint imposed by your client on t%e system re7uirements. ,nly list t%ose constraints t%at are important to document &or your system. Candated constraints are indistinguis%able &rom design decisions t%at a system designer mig%t ma5e, e3cept t%at t%ese are re7uired by your client. >or e3ample, as a system designer, you may decide to implement t%e system using an ,racle database management system E'C$4. $uc% as design decision $G,(QE +,T be included in a re7uirements speci&ications li5e t%is one. T%ese decisions come later during t%e design p%ase. Go.e)er, i&

your client .ants to implement t%e system using an ,racle E'C$, t%en t%is is not a design decision, but a mandated constraint and, t%ere&ore, $G,(QE be included in t%e re7uirements speci&ication. 0lease do not ma5e up mandated constraints just to &ill t%is section and only list mandated re7uirements mentioned by your client or t%ose t%at are necessary &or your system to operate. 6& you %a)e not identi&ied mandated constraints, please .rite in t%is section somet%ing li5e t%is /+o mandated constraints %a)e been identi&ied at t%is point.1> ?1 Relevant *acts and #ssumptions ?1&1 Facts <>acts and assumptions are +,T t%e same t%ing. $tudents o&ten ma5e t%e mista5e o& commingling &acts and assumptions. >acts are real, .%ereas assumptions are t%ings you donIt 5no. but .ant to state in .riting. >acts are li5e mandated constraints, e3cept t%at t%ey are not imposed by your client, but by t%e reality o& your system en)ironment 2e.g., t%e system must support "nglis%, $panis% and >renc% spea5ing users4, and t%ey are generally disco)ered as you gat%er re7uirements. >acts are +,T about t%e system 2t%at .ould be &unctional or nonA&unctional re7uirements4. ?at%er, &acts are about t%e en)ironment 2e.g., p%ysical, legal, economic, etc.4 in .%ic% t%e system .ill operate. 0lease do not ma5e up &acts just to &ill t%is section and only list real &acts unco)ered as you gat%ered re7uirements, &acts mentioned by your client, or t%ose t%at are necessary &or your system to operate. 6& you %a)e not identi&ied any rele)ant &acts, please .rite in t%is section somet%ing li5e t%is /+o rele)ant &acts a&&ecting t%e system %a)e been identi&ied at t%is point.1> ?1'1 Assumptions <$tating assumptions protect yoursel& contractually so, .%en in doubt, please clearly articulate your assumptions 2e.g., t%e companyIs 6nternet connection must be operating, all users can interact in "nglis%4. 6n contrast to mandated constraints and &acts, it is ,# to ma5e up assumptions because you are t%e one ma5ing t%ese assumptions. !t t%e same time, please do not ma5e up assumptions just to &ill t%is section and only list assumptions t%at you t%in5 are necessary &or your system to operate. !ssumptions are similar to &acts, e3cept t%at t%ey %a)e not been )alidated by your client yet. ,nce and i& t%ey )alidate t%em, you need to remo)e t%em &rom t%is section and mo)e t%em to t%e Candated 8onstraints or >acts sections. 6& you %a)e not identi&ied any assumptions you .ant to ma5e, please .rite in t%is section somet%ing li5e t%is /+o assumptions about t%e system %a)e been identi&ied at t%is point.1> &@1 Data .ntities and Relations%ips <see !rmour, 8%. 12 /Cap (se 8ases to ,bject Codels> <6n t%is section you need to describe t%e data re7uirements to support t%e impro)ed business process and system &unctionality discussed abo)e. 0lease start by .riting an introduction to t%e section .it% somet%ing li5e/6n t%is section .e describe t%e data re7uirements to support t%is application. <e pro)ide a

brie& description o& t%e data objects necessary &or t%e application .it% a brie& description o& t%ese data objects. <e also pro)ide a data model &or t%is application in !ppendi3 F and a 8?(E Catri3 in !ppendi3 G. T%e 8?(E Catri3 cross re&erences .%ic% data entities support eac% use case, .it% a letter indicating t%e type o& data manipulation associated- 8 create data, ? read data, ( update/modi&y data, and E delete data.1> <T%e components &or t%is section area7 Data Model $vervie4 t%is is a )ery brie& narrati)e t%at you need to include a&ter t%e section introduction pro)iding a %ig% le)el description o& t%e data model. $ince you .ill be describing t%e data objects belo., please be )ery brie& %ere and only &ocus on t%e data elements most central to t%e application !gain, data models are )ery %ard to understand in t%e abstract. 6magine t%at you s%o. your data model to your client and %e/s%e says, please e3plain t%is to me. <%ate)er you t%in5 t%is e3planation s%ould be is e3actly .%at you need to .rite %ere. T%at is, t%is narrati)e s%ould contain- 214 a brie& o)er)ie. o& t%e 5ey aspects o& your data modelO and 224 any in&ormation necessary &or your readers to understand t%e data model. b7 List of Data .ntities (sing t%e in&ormation pro)ided in your use cases, identi&y all t%e data entities 2i.e., database tables4 t%at your system needs to maintain. Eata entities are identi&ied in re7uirements descriptions by &ollo.ing t%e use o& 5ey RnounsR. +ouns usually indicate possible data objects or entities t%at t%e system needs to gat%er and manage data &or 2e.g., in)oices, clients, courses, students4. 0repare a list o& all t%e data entities 2i.e., database tables4 needed. Hou need to %a)e at least 10 tables, but 6 recommend t%at you %a)e no more t%an 12 tables to 5eep t%e project manageable. T%e best .ay to describe a data entity is by mentioning t%e main 2not e)eryt%ing4 data contained in a typical record in t%e table 2e.g., /8ustomers t%is table contains one record &or eac% customer in t%e system, .it% data about t%e customer 6E, customer name, contact in&ormation, c%arge card data, and s%ipping in&ormation.14. c7 Data Model ; 0repare t%e data model 2i.e., entityArelations%ip diagram or "?E4 &or t%is application using C$ 9isio and copy/paste your model into #ppendi5 A. T%e data model must %a)e all entities, relations%ips, cardinalities, minimum cardinalities, primary 5eys, &oreign 5eys, and nonA5ey attributes necessary &or your database implementation. >
<!side- T%e &ocus on t%is project is on de)eloping a data model t%at .ill manage t%e transactional data necessary &or t%e application. Go.e)er, alt%oug% not re7uired &or t%is project, it .ould be )ery use&ul to identi&y additional data entities and relations%ips to collect use&ul data to conduct analytics later on. T%is o&ten in)ol)es 5eeping %istorical records .it% time stamps so t%at you can analyze patterns. >or e3ample, !mazon only needs to 5eep trac5 o& .%at you place in your s%opping cart, so t%at t%ey can process t%e sale and c%arge your card upon c%ec5out. 'ut, li5e many electronic merc%ants, !mazon 5eeps trac5 o& .%at you put, delete or c%ange in your s%opping cart and .%en, so t%at t%ey can analyze your s%opping be%a)ior. !gain, t%is is not necessary &or t%is project, but t%is is t%e era o& big data and analytics, %a)ing a data model t%at pro)ides &or analytic data is 7uic5ly becoming standard practice and t%is .ill only %elp your understanding o& analytics.

d7 CR9D Matri5 0repare your CR9D matri5 in #ppendi5 B. T%e 8?(E matri3 is a mapping o& .%ic% use cases manipulate data in .%ic% data entities. T%is matri3 lists one

ro. &or e)ery database table and a column &or e)ery use case. T%e corresponding cells contain t%e letters 8, ?, ( or >, depending on .%et%er t%e use case creates, reads, updates and/or deletes records in t%e corresponding table. T%is is an important transitional arti&acts t%at cross re&erences use cases .it% t%e necessary data entities t%at .ill support t%em. 6t is important to analyze your 8?(E matri3 to ensure t%at you are not missing anyt%ing and t%at your arti&acts are consistent .it% eac% ot%er. T%e data tables listed in t%e 8?(E matri3 need to matc% t%e data entities listed in t%is section and your data model. T%e use cases listed in t%e 8?(E matri3 need to matc% your use case model. ! use case .it%out association to any database table is possible, but rare. Cost use cases at least read some data, so just double c%ec5 to be sure. ! data table .it%out any use case associated .it% it may point to a super&luous data entity or an use case t%at %as not been completely described. >

&&1 ,isual Model <(se t%is section to pro)ide all t%e necessary in&ormation &or your client and pro&essor about your i?ise simulation. 6n particular, please include all t%e necessary login, pass.ord and important na)igation issues to %elp your readers demo your simulation. 6& you .is% to include screens%ots or any ot%er grap%ics and diagrams, please include t%em in appendices, .it% t%e appropriate re&erence to t%em in t%e main te3t. Hou may .ant to start .it% an introduction t%at reads li5e t%is/6n t%is section .e describe t%e )isual simulation .e prepared &or t%is application. 0lease note t%at t%is is not a complete simulation, but simply an illustration o& t%e 5ey &unctionality o& t%e application. 6n particular, .e &ocus on SSS. 0lease also re&er to !ppendi3 3333 &or t%e illustrations .e discuss.1. 9is

#PP.ND-C # Alossar! of Terms and #cron!ms

#PP.ND-C 2 2usiness Process Model <need separate subsections &or t%e baseline and target '0CIs and also &or any subAdiagrams included please number eac% diagram &or easy re&erence. T%e baseline and target '0CIs need to %a)e a brie& introduction or e3planation o& .%at t%ey are, suc% as- T%e 'aseline '0C pro)ides a )isual illustration o& t%e current or /as is1 process.>

#PP.ND-C C #ctor Cards

<!ctor cards t%at are s%orter t%an one page need to be s%o.n on t%e same page. 6& t%e ne3t actor card doesnIt &it on t%e same page, please add a page brea5 and start t%e ne3t actor card at t%e top o& t%e ne. page. ,nly actor cards t%at span more t%an one page can be bro5en into t%e ne3t page, but t%ey must start at t%e beginning o& a page. !ll arti&acts need to %a)e a brie& introduction or e3planation, suc% as- !ctor cards describe t%e roles o& all %uman and e3ternal system entities interacting .it% t%e system.>

#PP.ND-C D 9se Case Dia"ram <6nclude your systemIs use case diagram in t%is appendi3. T%e use case diagram s%ould contain t%e same actors as t%e conte3t diagram please ensure t%at your diagrams are consistent .it% eac% ot%er. 6n contrast to t%e conte3t diagram, a use case diagram represents t%e system as a bo3 .it% all t%e use cases inside t%e bo3 represented as o)als, as illustrated in t%e e3ample belo.. !lso, t%e meaning o& t%e arro.s in use case diagrams is di&&erent t%an t%ose o& t%e conte3t diagram. !rro.s in conte3t diagrams represent t%e direction o& in&ormation or data &lo.s, .%ereas arro.s in t%e use case diagram indicate .%o triggers/initiates t%e use case. 6& t%e actor triggers t%e use case, t%e arro. %ead points to t%e use case, .%ereas i& t%e system triggers t%e use case, t%e arro. points to t%e actor. !lso, alt%oug% t%e diagram belo. doesnIt s%o. it, it %elps t%e reader 2your client and pro&essor4 i& you include use case numbers in t%e respecti)e o)als, .%ic% need to matc% t%e respecti)e numbers in t%e actual use cases. Hour use case diagram needs to %a)e a brie& introduction or e3planation, suc% as- T%e use case diagram depicts t%e interaction o& t%e )arious actors and use cases in t%e system. "ac% use case depicts a speci&ic &unctionality. T%e direction o& t%e arro.s indicate .%o triggers t%e use case. (se cases .it% arro.s going in are triggered by t%e actor. >

APPENDIX E Transitional Matrix: BPM and Use Cases

<0ro)ide a table t%at %as all your '0C steps as ro.s and your use cases as columns. 6n t%e respecti)e cells place an P to indicate .it% process steps are %andled by .%ic% use case. T%is arti&act is not .ell 5no.n by e)eryone. 6t needs a brie& introduction or e3planation, suc% as- T%e '0C/(se 8ase matri3 s%o.s .%ic% use cases support .it% business process steps and decisions. >

#PP.ND-C * 9se Cases <(se cases t%at are s%orter t%an one page need to be s%o.n on t%e same page. 6& t%e ne3t use case doesnIt &it on t%e same page, please add a page brea5 and start t%e ne3t use case at t%e top o& t%e ne. page. ,nly use cases t%at span more t%an one page can be bro5en into t%e ne3t page, but t%ey must start at t%e beginning o& a page. Cany readers are not &amiliar .it% use cases. 0lease pro)ide a brie& introduction or e3planation, suc% as- "ac% use case describes speci&ic &unctionality pro)ided by t%e system. 8ollecti)ely, all use cases encompass t%e entire &unctional scope o& t%e system. >

#PP.ND-C A Data Model <Cany readers %a)e ne)er seen or %eard about data models. 0lease pro)ide a brie& introduction or e3planation, suc% as- T%e data model s%o.s all t%e data objects maintained by t%e system and t%eir respecti)e relations%ips, in support o& t%e &unctionality re7uired.>

#PP.ND-C B Transitional Matri5: CR9D DCreate+ Read+ 9pdate and Delete7 <0ro)ide a table t%at %as all your data entities 2i.e., database tables4 as ro.s and your use cases as columns. 6n t%e respecti)e cells place a 8, ?, ( and/or E to indicate i& t%e respecti)e use case 284 creates data 2inserts records4, 2?4 reads data, 2(4 updates data or 2E4 deletes records in t%e respecti)e data table. !gain, 8?(E matri3 is not a .ellA5no.n arti&act. ! s%ort introduction or description suc% as t%is one .ould be use&ul- T%e 8?(E matri3 s%o.s .%ic% data tables support .%ic% use cases in t%e system. T%e letters 8, ?, ( and E indicate .%ic% use cases create, read, update and/or delete data in t%e respecti)e tables. >

2L#NE *$RMS

#ctor Cards
Actor Specification Actor Name: Type: (Primary/Secondary) Role Description: Personality: (I, E, R or F) Abstract: (Yes/No)

Actor

oals:

Use Cases In!ol!ed "it#:

9se Cases

-nitial 9se Case *orm

2(se case is described .it% a te3t narrati)e4 Use Case ID Use Case Elaboration P#ase Actors Description Priority Non$%&nctional Re'&irements Ass&mptions (o&rce (prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s) Ini!ia$ use case descrip!ion

(%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

2ase 9se Case *orm

2(se case is described .it% se7uential &lo.s o& e)ents &or sunnyAday scenarios only no conditional &lo.s s%ould be included4 Use Case ID Use Case Elaboration P#ase Actors Description (prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s) (ase use case

()rief) (No!e* if you inc$ude manua$ f$o s, mar+ !"em as suc" and #i,e a no!a!ion !o your readers - e.#. (&) deno!es manua$ s!eps

Pre$conditions %lo" o) E!ents

/. 0. (&) 1. 2. e!c. ()rief$y descri)e a$!erna!i,e f$o s "ere for )ase Use Cases3 ex!end !"is in!o comp$e!e condi!iona$ f$o s of e,en!s in !"e correspondin# E$a)ora!ed Use Cases) (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

Post$conditions Alternati!e %lo"s Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

.laborated 9se Case *orm

2(se case is described .it% se7uential &lo.s o& e)ents &or sunnyAday scenarios and t%en listing all conditional &lo.s or rainy day scenarios in a di&&erent section belo.. start allArainy day scenarios .it% /i&1 and /else1 statements Use Case: 4UC5xx Use Case Name6 Elaboration P#ase Actors Pre$ conditions /. E$a)ora!ed use case

*ptimistic %lo" o) E!ents

Conditional %lo"s

Post$ conditions

2!lternati)e4 .laborated 9se Case *orm

2(se case is described .it% se7uential &lo.s o& e)ents &or bot% sunnyAday and rainyAday scenarios start allArainy day scenarios .it% /i&1 and /else1 statements and t%en list t%e corresponding &lo.s as eit%er- conditional &lo.s .it%in t%is &ormO or as alternati)e &lo.s in a separate &orm &or alternati)e &lo.s4

Use Case ID Use Case Elaboration P#ase Actors Description Pre$conditions %lo" o) E!ents (inc$ude condi!iona$ f$o s "ere as !"ey occur)

(prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s) E$a)ora!ed use case

()rief)

/. 0. 1. 2. If xxx 2./ 2.0 7. E$se 7./ 7.0 8. 9. e!c. ()rief$y descri)e a$!erna!i,e f$o s "ere for )ase Use Cases3 ex!end !"is in!o comp$e!e f$o of e,en!s for E$a)ora!ed Use Cases, ei!"er "ere or in !"e nex! !emp$a!e) (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

Post$conditions Alternati!e %lo"s Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

.laborated 9se Case *orm 4:2usiness Steps

2T%is is t%e same &orm as t%e prior "laborated (se 8ase &orm, but it %as t.o columns .%ere you can di&&erentiate system steps &rom business steps. (se cases normally only %a)e system steps, but describing business steps may pro)ide important conte3t in&ormation &or your application. 6t is important t%at de)elopers can di&&erentiate system actions &rom business actions in your use cases.4

Use Case ID Use Case Elaboration P#ase Actors Description Pre$conditions %lo" o) E!ents (inc$ude condi!iona$ f$o s "ere as !"ey occur) Post$conditions Alternati!e %lo"s Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

(prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s) E$a)ora!ed use case

()rief) (ystem (teps S/. S0. S1. If xxx 1./ S2. E$se 2./ 2.0 S7. e!c. (/. (0. (1. If xxx 1./ (2. E$se 2./ 2.0 (7. e!c. B&siness (teps

()rief$y descri)e a$!erna!i,e f$o s "ere for )ase Use Cases3 ex!end !"is in!o comp$e!e f$o of e,en!s for E$a)ora!ed Use Cases, ei!"er "ere or in !"e nex! !emp$a!e) (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

9se Case *orm for #lternative *lo4s

2!n !lternati)e (se 8ase C($T be associated .it% an e3isting "laborated (se 8ase4 Use Case ID Use Case Elaboration P#ase Actors Description Insertion Point Pre$conditions Alternati!e %lo" o) E!ents (same ID as !"e )ase Use Case ID, )u! i!" suffix :/, :0, e!c., for eac" a$!erna!i,e f$o Use Case) (indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case)

()rief) (s!ep in (ase Use Case "ere !"is a$!erna!i,e f$o s"ou$d )e inser!ed) (c$ear$y indica!e under "ic" condi!ions !"e a$!erna!i,e f$o is !ri##ered) /. 0. 1. 2. 7. (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

Post$conditions Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

*orm for .5tendin" 9se Cases

2!n "3tending (se 8ase C($T be associated .it% an e3isting "laborated (se 8ase4 Use Case ID Use Case Elaboration P#ase Additional Actors Description Extended Use Case Extension Point &ard Condition %lo" o) E!ents (same ID as !"e )ase Use Case ID, )u! i!" suffix E/, E0, e!c., for eac" ex!endin# Use Case) (indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case) (on$y $is! ac!ors no! $is!ed in !"e ex!ended use case) ()rief) (ID and name) (s!ep in (ase Use Case "ere i! is ex!ended) (pre5condi!ion in !"e ex!ended Use Case !"a! causes i! !o execu!e) /. /./ /.0 0. 1. 2. 7. ()rief$y descri)e a$!erna!i,e f$o s "ere for !"e Ex!endin# Use Case3 ex!end !"is in!o comp$e!e f$o of e,en!s in an :$!erna!i,e Use Case form if needed) (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

Conditional %lo"s Post$conditions Alternati!e %lo"s Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

*orm for -ncluded 9se Cases

2!n 6ncluded (se 8ase is generic and can be reAused and included in any ot%er (se 8ase, so it does not need to be associated .it% a speci&ic (se 8ase4 Use Case ID Use Case Elaboration P#ase Description Incl&din+ Use Cases Pre$conditions %lo" o) E!ents (prefix your Use Case IDs i!" IUC, !o dis!in#uis" !"em from o!"er Use Cases) (indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case) ()rief) ($is! a$$ Use Cases !"a! use !"is Inc$uded Use Case)

/. /./ /.0 0. 1. 2. 7. ()rief$y descri)e a$!erna!i,e f$o s "ere for !"e Inc$uded Use Case3 ex!end !"is in!o comp$e!e f$o of e,en!s in an :$!erna!i,e Use Case form if needed) (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

Conditional %lo"s Post$conditions Alternati!e %lo"s Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

*orm for CR9D<T!pe 9se Cases

2$ome (se 8ases do )ery little processing and a lot o& data managementO t%ese use cases donIt %a)e a lot o& detailed &lo.s to describe, but instead t%ey contain a lot o& data management steps e.g., create, read, update and/or delete dataO since database application de)elopers 5no. e3actly .%at to do in suc% cases, it is o&ten simpler to speci&y your &lo.s bro5en do.n by 8?(E acti)ities and using simpler &lo.sO since you .ill later need to use t%ese use cases to identi&y data objects, t%e &ollo.ing use case &ormat is appropriate &or t%ese use cases4 Use Case ID Use Case Elaboration P#ase Actors Description Pre$conditions %lo" o) E!ents (prefix your Use Case IDs i!" UC) (indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case) (prefix ac!ors i!" <P= for primary and <S= for secondary) ()rief - )u! you may a$so an! !o say some!"in# $i+e >!"is use case "and$es s!andard da!a mana#emen! e,en!s for e!c.) Create Data C/. C0. e!c. Read Data R/. R0. e!c. Update Data U/. U0. e!c. Delete Data D/. D0. e!c. Conditional %lo"s Post$conditions Alternati!e %lo"s Priority Non$%&nctional Re'&irements Ass&mptions *&tstandin+ Iss&es (o&rce

()rief$y descri)e a$!erna!i,e f$o s "ere for )ase Use Cases3 ex!end !"is in!o comp$e!e f$o of e,en!s for E$a)ora!ed Use Cases, ei!"er "ere or in !"e nex! !emp$a!e) (%i#", &edium or 'o ) (on$y !"ose associa!ed i!" !"is use case, if any)

2PM:9se Case Transitional Matri5 *orm

BPM (tep P/ P0 P1 E!c. Name Type UC , UC Use Case UC . Etc/

CR9D Matri5 *orm

28reate, ?ead, (pdate, Eelete4 Entity En!i!y / En!i!y 0 E!c. UC , UC Use Case UC . Etc/

Requirements S%ell DRS7 Cards

+ot re7uired &or t%is project, but many re7uirements analysts &ind t%em use&ul to ta5e &ield notes .%ile you are gat%ering re7uirements. >ill one ?$ card &or anyt%ing t%at a sta5e%older describes t%at sounds li5e a re7uirement 2&unctional or nonA&unctional4. ,ne ?$ card may generate zero, one or many use cases or many ?$ cards may be consolidated into one use case. T%in5 o& an ?$ card as an organized .ay to ta5e &ield notes .%en you are gat%ering re7uirements 2i.e., /tra.ling &or 5no.ledge14.

Requirement Shell
Re'&irement No/: Description: Re'&irement Type: Use Cases:

Rationale:

(o&rce: %it Criterion:

C&stomer (atis)action Ratin+: Dependencies: 0istory:

C&stomer Dissatis)action Ratin+: Con)licts: (&pportin+ Materials:

T T%e !tlantic $ystems Fuild Qimited