<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 Done
1. 6ntroduction
S!stem Concept
2. 'usiness 8ase and 0roject 9ision
:. $ta5e%olders
S!stem Requirements
4. $ystem !ctors
;. $cope o& <or5
=. >unctional ?e7uirements
@. +onA>unctional ?e7uirements
B. Candated 8onstraints
D. ?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
!. Flossary o& Terms and !cronyms
'. !ctor 8ards
8. 'usiness 0rocess Codel
E. (se 8ase Eiagram
". Transitional Catri3- '0C and (se 8ases
>. (se 8ases- >unctional ?e7uirements
F. Eata Codel
G. Transitional Catri3- 8?(E
<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 contain-
Eeli)erable 1-
2a4 ! 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 4-
2%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)erable-
2i4 ?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 : sections-
a4 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. 6mportant-
your 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 : possibilities-
214 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& actors-
214 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.ing-
a7 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 are-
a7 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) Personality: (I, E, R or F) Abstract: (Yes/No)
Role Description:
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 (prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s)
Use Case
Elaboration
P#ase
Ini!ia$ use case descrip!ion
Actors
Description
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
Ass&mptions
(o&rce
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 (prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s)
Use Case
Elaboration
P#ase
(ase use case
Actors
Description ()rief) (No!e* if you inc$ude manua$ f$os, 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.
Post$conditions
Alternati!e
%lo"s
()rief$y descri)e a$!erna!i,e f$os "ere for )ase Use Cases3 ex!end !"is in!o
comp$e!e condi!iona$ f$os of e,en!s in !"e correspondin# E$a)ora!ed Use
Cases)
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
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
E$a)ora!ed use case
Actors
Pre$
conditions
*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 (prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s)
Use Case
Elaboration
P#ase
E$a)ora!ed use case
Actors
Description ()rief)
Pre$conditions
%lo" o) E!ents
(inc$ude
condi!iona$ f$os
"ere as !"ey
occur)
/.
0.
1.
2. If xxx
2./
2.0
7. E$se
7./
7.0
8.
9. e!c.
Post$conditions
Alternati!e
%lo"s
()rief$y descri)e a$!erna!i,e f$os "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)
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
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 (prefix your Use Case IDs i!" UC, !o dis!in#uis" !"em from o!"er mode$s)
Use Case
Elaboration
P#ase
E$a)ora!ed use case
Actors
Description
()rief)
(ystem (teps B&siness (teps
Pre$conditions
%lo" o) E!ents
(inc$ude
condi!iona$ f$os
"ere as !"ey
occur)
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.
Post$conditions
Alternati!e
%lo"s
()rief$y descri)e a$!erna!i,e f$os "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)
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
Ass&mptions
*&tstandin+
Iss&es
(o&rce
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 (same ID as !"e )ase Use Case ID, )u! i!" suffix :/, :0, e!c., for eac"
a$!erna!i,e f$o Use Case)
Use Case
Elaboration
P#ase
(indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case)
Actors
Description ()rief)
Insertion Point (s!ep in (ase Use Case "ere !"is a$!erna!i,e f$o s"ou$d )e inser!ed)
Pre$conditions (c$ear$y indica!e under "ic" condi!ions !"e a$!erna!i,e f$o is !ri##ered)
Alternati!e %lo"
o) E!ents
/.
0.
1.
2.
7.
Post$conditions
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
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 (same ID as !"e )ase Use Case ID, )u! i!" suffix E/, E0, e!c., for eac"
ex!endin# Use Case)
Use Case
Elaboration
P#ase
(indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case)
Additional
Actors
(on$y $is! ac!ors no! $is!ed in !"e ex!ended use case)
Description ()rief)
Extended Use
Case
(ID and name)
Extension Point (s!ep in (ase Use Case "ere i! is ex!ended)
&ard Condition (pre5condi!ion in !"e ex!ended Use Case !"a! causes i! !o execu!e)
%lo" o) E!ents /.
/./
/.0
0.
1.
Conditional
%lo"s
2.
7.
Post$conditions
Alternati!e
%lo"s
()rief$y descri)e a$!erna!i,e f$os "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)
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
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 (prefix your Use Case IDs i!" IUC, !o dis!in#uis" !"em from o!"er Use
Cases)
Use Case
Elaboration P#ase (indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case)
Description ()rief)
Incl&din+ Use
Cases
($is! a$$ Use Cases !"a! use !"is Inc$uded Use Case)
Pre$conditions
%lo" o) E!ents /.
/./
/.0
0.
1.
Conditional %lo"s 2.
7.
Post$conditions
Alternati!e %lo"s ()rief$y descri)e a$!erna!i,e f$os "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)
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
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 (prefix your Use Case IDs i!" UC)
Use Case
Elaboration
P#ase
(indica!e "e!"er i!;s ini!ia$, )ase or e$a)ora!ed use case)
Actors (prefix ac!ors i!" <P= for primary and <S= for secondary)
Description ()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.)
Pre$conditions
%lo" o) E!ents 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
()rief$y descri)e a$!erna!i,e f$os "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)
Priority (%i#", &edium or 'o)
Non$%&nctional
Re'&irements
(on$y !"ose associa!ed i!" !"is use case, if any)
Ass&mptions
*&tstandin+
Iss&es
(o&rce
2PM:9se Case Transitional Matri5 *orm
BPM Use Case
(tep Name Type UC , UC - UC . Etc/
P/
P0
P1
E!c.
CR9D Matri5 *orm
28reate, ?ead, (pdate, Eelete4
Entity
Use Case
UC , UC - UC . Etc/
En!i!y /
En!i!y 0
E!c.
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/: Re'&irement Type: Use Cases:
Description:
Rationale:
(o&rce:
%it Criterion:
C&stomer (atis)action Ratin+: C&stomer Dissatis)action Ratin+:
Dependencies: Con)licts:
0istory: (&pportin+ Materials:
T T%e !tlantic $ystems Fuild Qimited