This document outlines a proposal for automating improvements to the ECCHA Lost and Found system. It describes the key stakeholders, system features, requirements, use cases, and entity relationship diagram for a new automated lost and found system. The system would allow users to generate reports, enter animal information, and enter owner information through a website. The requirements, use cases, and entity relationship diagram specify how the system would function and interact with users.

1. UWEC
ZACH SMITH
ALEX HART
MICHAEL MACALALAD
SAMUEL GRITZMACHER
May 12, 2015
IS 310.001
Lost and Found
Automated Improvements to the ECCHA Lost and Found System

2. 1
Contents
1. Introduction................................................................................................................................ 5
2. Positioning .................................................................................................................................. 5
2.1 Problem Statement................................................................................................................5
2.2 Product Position Statement....................................................................................................6
3. Stakeholder and User Descriptions............................................................................................ 6
3.1 Stakeholder Summary............................................................................................................6
3.2 User Summary.......................................................................................................................7
3.3 User Environment..................................................................................................................7
3.4 Key Stakeholder or User Needs...............................................................................................7
3.5 Alternatives and Competition.................................................................................................8
4. System Overview ........................................................................................................................ 9
4.1 System Perspective................................................................................................................9
4.2 Assumptions, Constraints, and Dependencies........................................................................10
4.3 System Features ..................................................................................................................10
4.4 High-level System Requirements...........................................................................................10
5. Project Risk List........................................................................................................................ 11
6. Requirements Analysis ............................................................................................................. 11
6.1 Requirements Elicitation Plan...............................................................................................11
6.2 Business Requirements ........................................................................................................12
6.3 User and Functional Requirements .......................................................................................12
6.4 Nonfunctional Requirements................................................................................................13
6.5 Common Information...........................................................................................................18
7. Use-Case Diagram and Specifications...................................................................................... 19
7.1 Use Case Diagram................................................................................................................19
7.2.1 Generate Reports..............................................................................................................19
7.2.1.1 Brief Description ............................................................................................................19
7.2.2 Flow of Events ..................................................................................................................19

3. 2
7.2.2.1 Basic Flow......................................................................................................................19
7.2.2.2 Alternative Flows ...........................................................................................................20
7.2.2.2.1 System Can Not Generate Report.................................................................................20
7.2.2.2.2 System Can Not Access Excel........................................................................................20
7.2.3 Special Requirements........................................................................................................20
7.2.3.1 Timely completion......................................................................................................20
7.2.4 Preconditions....................................................................................................................20
7.2.4.1 The Systemis functioning and ready to use......................................................................20
7.2.4.2 The computer is powered on, user accesses Lost and Found page.................................20
7.2.4.3 The computer is powered on, user accesses Excel. .......................................................20
7.2.5 Post conditions.................................................................................................................20
7.2.5.1 All necessary data fields have been filled, and the user submits the information. ...........20
7.2.5.2 Notification window displayed upon completion..........................................................21
7.2.6 Extension Points................................................................................................................21
7.3.1 Enter Animal Information..................................................................................................21
7.3.1.1 Brief Description ............................................................................................................21
7.3.2 Flow of Events ..................................................................................................................21
7.3.2.1 Basic Flow......................................................................................................................21
7.3.2.2 Alternative Flows ...........................................................................................................21
7.3.2.2.1 System Can Not Access Website...................................................................................21
7.3.2.2.2 System Cannot Submit Form........................................................................................21
7.3.3 Special Requirements........................................................................................................22
7.3.3.1 Timely completion......................................................................................................22
7.3.4 Preconditions....................................................................................................................22
7.3.4.1 The Systemis functioning and ready to use..................................................................22
7.3.4.2 The computer is powered on, user accesses Lost and Found page.................................22
7.3.5 Post conditions.................................................................................................................22
7.3.5.1 All necessary data fields have been filled, and the user submits the information............22
7.3.5.2 Notification window displayed upon completion..........................................................22
7.3.6 Extension Points................................................................................................................22
7.4.1 Enter Owner Information...................................................................................................22
7.4.1.1 Brief Description ............................................................................................................22
7.4.2 Flow of Events ..................................................................................................................23
7.4.2.1 Basic Flow......................................................................................................................23

4. 3
7.4.2.2 Alternative Flows ...........................................................................................................23
7.4.2.2.1 System Can Not Access Website...................................................................................23
7.4.2.2.2 System Cannot Submit Form........................................................................................23
7.4.3 Special Requirements........................................................................................................23
7.4.3.1 Timely completion......................................................................................................23
7.4.4 Preconditions....................................................................................................................23
7.4.4.1 The Systemis functioning and ready to use..................................................................23
7.4.4.2 The computer is powered on, user accesses Lost and Found page.................................23
7.4.5 Post conditions.................................................................................................................24
7.4.5.1 All necessary data fields have been filled, and the user submits the information. ...........24
7.4.5.2 Notification window displayed upon completion..........................................................24
7.4.6 Extension Points................................................................................................................24
8. Business Rules and Entity Relationship Diagram .................................................................... 24
8.1 Entity Relationship Diagram..................................................................................................25
8.2 Business Rules.....................................................................................................................26
8.3 Sample Data Tables..............................................................................................................26
9. Data Flow Diagrams ................................................................................................................. 27
9.1 Context Level Diagram .........................................................................................................28
9.2 Level 0 Diagram...................................................................................................................29
9.3 Level 1 of Process 1..............................................................................................................30
9.4 Level 1 of Process 3..............................................................................................................31
10. Prototype Mock-ups................................................................................................................ 32
10.1. Lost and Found Menu........................................................................................................32
10.2 User Sign-in Screen............................................................................................................33
10.2 Generate Reports Form......................................................................................................33
11. Transition Plans ...................................................................................................................... 34
11.1. Test Plan...........................................................................................................................34
11.1.1 Component Testing.........................................................................................................34
11.1.2 Integration Testing..........................................................................................................34
11.1.3 System Testing................................................................................................................34

5. 4
11.1.4 Acceptance Testing.........................................................................................................35
11.2 ImplementationPlan..........................................................................................................35
11.3 Training Plan......................................................................................................................36
11.3.1 Eau Claire Humane Society Staff.......................................................................................36
12. Appendices.............................................................................................................................. 37
12.1 Revision History.................................................................................................................37
12.2 Reference Materials...........................................................................................................38
12.3 Glossary ............................................................................................................................38

6. 5
1. Introduction
The purpose of thisdocumentisto examine anddescribe the needs,risks,andkeyattributesof the Lost
and Foundsystemforthe ECCHA.The objective of thisprojectistocreate an efficientLostandFound
systemforthe ECCHA that allowsuserstoquicklyandeffectivelylocate alostanimal.The systemwill
cut downtime forusers,improve detailedinformationwithinthe online database,reduce humanerror
indocumentation,andreduce retentionratesof lostanimalswhichinturnwill reduce costsatthe
ECCHA.Upon implementation,userswill be providedwithaneasytouse,efficientonlinedatabase that
allowsthemtoquicklysearchanddetectan animal withnoconfusion.The detailsregardinghow this
Lost and Foundsystemwill justifythese needsare presentedinthe documentbelow. Itdescribes
stakeholderroles,contributions,responsibilities,systemrequirements,associatedrisks,use-case
diagramand specifications,dataflowdiagram, entityrelationshipdiagram,prototype mockups,our
transitionplans,andanappendix.
2. Positioning
The current problemsandsolutionswill be discussedfurtherinthissection. Animprovementinthe lost
and foundsystemwouldincreasethe efficiencyof the ECCHA inhelpingownersfindtheiranimals.
2.1 ProblemStatement
Thisprojecthas beenstartedinorderto increase efficiencyandlimitthe time animalsspendon
the Lost and Foundpage. Thisprojectwill determine how tocommunicate effectivelyandina
timelymannerwiththose searchingforan animal,byfurtherdevelopingonlinenotifications
and detectingpotential matches.
The problem of Animal retention rate for lost and found is too high
which
affects Owners who are without their animals, which in
turn raises costs for ECCHA.
the impact of which is Shelter space and resources at ECCHA become
limited and owners remain unhappy.
A successful solution would
be
Improve Lost and Found webpage, request detailed
pictures of members’ animals, and maintain records
of previous Lost and Found animals.

7. 6
2.2ProductPositionStatement
Thisprojectwill improve the lostandfoundsysteminthe organization.The intentof thisproject
isto decrease the time animalsspendinthe Lost andFoundsystem, reduce costs,andincrease
efficiencyof resources.
For The Eau Claire County Humane Association,
who Need to increase the effectiveness of the Lost and
Found System.
the Lost and Found
system
Is a system to manage Lost and Found animals,
that Will increase animals being reunited with owners by
20% (guidestar.com)
Unlike The current paper system,
our product Will make the system more effective, while also
increasing user friendliness.
3. Stakeholder and User Descriptions
The sectionbelow identifiesthe stakeholdersthatwill be effectedbythe changessuggested. The roles
of eachstakeholderandusers,systemrequirements,andthe systemneedsare describedbelow.
3.1 StakeholderSummary
The followingtable representsthe indirectusersof the Lost andFoundsystemand their
responsibilities.
Role: Description: Responsibilities for the
project or system
Donors Donors will provide the
funding for the ECCHA.
Provide funds for the ECCHA
Board of Directors Board of directors make
budget and project decision.
Decide if the system is funded

8. 7
3.2 UserSummary
Thistable describesthe userswhoare directlyimpactedbyoursystem.Eachuserrole,
descriptionof the role,andhowtheywill directlyuse the systemispresentedbelow.
Role Description How this role will use the system
Employee Impute andmanage animal data -Entercustomer/ animal informationonto
online database
-Produce reports
Manager Oversee the use of the systemand
reviewitsoverall effectiveness
-View turnoverdata
-Maintainaccurate records
Animal owner Givesthe systemthe descriptionof
theiranimal
-Enteranimal information
3.3 UserEnvironment
The followinglistcontains environmentalcharacteristicsrelevanttothe improvementof the
Lost and Foundsystem:
- Three to five peoplewouldbe expectedtoaccess the systemsimultaneously
- Each task shouldtake nomore thanfive minutes
- Window7 and office 2010 are the currentsystems
- Each employee will have accesstothe systemwithausername andpassword
- Our systemwouldneedtogetintegratedwithPetPoint
- Potentiallyincorrectanimal descriptionbasedonunderstandingof animals
- Requiresmanual entryof information
- Animal furpresent
3.4 Key StakeholderorUserNeeds
Diagramedinthe table beloware the stakeholder/userneeds,priorityof concern,andthe
solutions.The needsare prioritizedonascale from 1-10, with10 beingthe mostimportant.
Need Priority Concerns Current Solution ProposedSolutions
Compile and
enteranimal
information
9 Human errorin data
entrycouldcause
animal owners
difficultyinrecognition
of theiranimal
Manual with
pencil andpaper
Expanddatabase of
animal pictures,request
member’sanimal
pictures,andmaintain
filesof previously lost
animals.
Update records 8 Human errorin data
entrycouldcause
animalstoremainat
the ECCHA
Manual with
pencil andpaper
Digital records
repositorywithabilityto
update alongwithpaper
and pencil.
Generate reports 8 Inadequacydatawill
leadto incorrect
reports
Obtain
informationfrom
binder
A searchable system
withabilitytofilter

9. 8
3.5 AlternativesandCompetition
The followingisananalysisandcomparisonof whatthe ECCHA currentlyusestokeeptrackof
theiranimals,switchingtoanotheronline database(iShelters),orourlostand foundsystem.
Each systemwill be comparedandevaluatedusingaweighteddecisiontable.
Currently,the ECCHA usesa mix of paperdocumentation,andacomputerdatabase called
“PetPoint.”Whenananimal comesin,itisfirstexaminedbyanemployee.Next,theyhand
documentall the necessaryattributesof the animal onalostand foundreport. Then,the
employeeorvolunteermanuallyentersinthisinformationintotheircomputerdatabase,andif
possible,includesapicture of the animal.Fromthere,the animal’sinformationisretrievable
fromeitherthe paperdocuments,orthe PetPointdatabase.One of the mainissuesof the
currentsystemisits accuracy. The keyproblemthe ECCHA facesis correctlyidentifyingthe
breedof the animal.Also,the systemresultsinaninefficientuse of time.The time spent
handwritingthe animal’sinformation,andthenmanuallyenteringthisinformation,isredundant
and can be improved.
One alternative the ECCHA hasto thissystem, istocompletelytransitiontoadifferentonline
database.Althoughdefinitelyanoption,thisalternative isn’tnecessarilycostortime effective.
These systemscanrange anywhere from$200 to $2500 a month.Also,the capabilitiesand
attributesof these systemsvarygreatly.These systemswill eitheroffernotenoughtothe
ECCHA,or more thantheycouldeveruse.Althoughthiswouldpossiblysave the ECCHA money
inthe longrun bycompletelyeliminatingthe use of LostandFounddocuments,the
implementationcostsandtime neededtotrainemployees,justdoesn’tcompare toour
proposedsystem.
Giventhese options,ourLostandFoundsystemisthe optimal alternative.The improvedLost
and Foundsystemstreamlinesefficiency,anddrasticallyreducesusererror.Oursystemtailors
to whatthe ECCHA currentlyuses,soit will take littletime toimplement,andpresentaneasy
learningcurve.Byusingan easyto findbreedselector,andreducingthe amountof time needed
to inputthe animal’sinformation,the LostandFoundsystemisthe bestalternative available to
the ECCHA.
The followingtable weighsthe needsof the organizationandrankseachtask 0-5 dependingon
the abilityof the systemtomeetor handle thatrequirementorconstraint. (See NextPage)

10. 9
Criteria No Action Online
Alternative
Proposed System
Requirements Weight Rank Score Rank Score Rank Score
Interface with
PetPoint
15 4 60 0 0 5 75
Drop-down
menus
10 0 0 1 10 5 50
Provide detailed
animal
information
15 2 30 2 30 4 60
Reduce usererror 7 3 21 1 7 4 28
Informusersof
matches
10 1 10 3 30 5 50
Track animal
numbers
3 1 3 3 9 3 9
Constraints
Technology
limitations
5 5 25 3 15 4 20
Scarcity of
donations
5 4 20 2 10 2 10
Cost of
implementation
20 5 100 1 20 3 60
Systemlearning
curve
10 5 50 2 20 3 30
Total 100 319 151 392
4. System Overview
This section contains the assumption perspectives dependencies, features, constraints, and high
level requirements for the system.
4.1 System Perspective
The system proposed will be an addition on to the current system of PetPoint. The
system will bridge an information gap between the users and PetPoint. This will be a
public system for use by the employees of the ECCHA to post found animals and also by
the public to post a lost animal.

11. 10
4.2 Assumptions,Constraints,andDependencies
The followingare alistof assumptions,constraints,anddependenciesimportantfor
implementingthe Lost andFoundsystem.
Assumptions
The followinglistof assumptionsare vital toproperlyimplementthe system:
- The systemwill be maintainedandupdated
- Staff will adaptandlearnnew systemcomponents
- The systemwill be developedbystudents
- There are sufficientresourcesandtimeframesneededtocompletethe project
- Staff hoursand roleswill remainthe same
Constraints
Beloware a listof constraints thatour systemmustcomplywith:
- Technologyavailabilitycanbe limitedattimes
- Onlythree tofive userscan accessthe systemsimultaneously
Dependencies
Belowisa listof dependenciesthe Lost andFoundsystemisreliantupon:
- ECCHA mustprovide time totrainstaff
- The Lost and Foundsystemwill continuetointegrate withPetPoint
- MicrosoftOffice 2010 or higherisrequired
- The systemwill be secure sothatonlyECCHA staff can make changes
4.3 System Features
The followingshowsfeaturesof the LFS andthe priorityassociatedwitheach.The scale ranges
from1-10 with10 beingthe mostimportant.
System Features Priority
Informusersof possible matches 10
Connectto PetPoint 10
Assistinguserswithaccurate datainputviadropdownmenus. 9
Retaininformationaftermatchhasbeenmade 7
Track annual and seasonanimal numbers 4
4.4 High-level SystemRequirements
The table belowisa table of the specifichighlevelrequirementsthatthe systemrequiresto
function. The requirementsare rankedinprioritywith1beingthe lowestand10 beingthe
highest.
System Requirements Priority
Hard Drive Containing 250GB 10
Internet access 10
Compatibility with PetPoint 10
Computer system cannot come in direct
contact with animals
10
Windows 7 Compatibility 9
2 GB of RAM Memory 8
Core i3 2.0 Ghz Processor 6

12. 11
5. Project Risk List
The following table contains a list of possible risks as well as mitigation strategies. The ranking
from 10 (largest project impact) to 1 (least project impact) shows the importance of each risk.
Priority Risk Description and Impact Mitigation Strategy and/or
Contingency Plan
10 Doesnot findthe LFS to be necessaryor
beneficial,the Boardof Directorsmaynot
approve funding.
Provide more factsandestimatesto
the Board to show the importance of
the LFS
10 There isinsufficientfunding. Reorganize fundinganddonationsas
well asrestructure componentsof
systemtobe cheaper
8 Donorsmay not provide enoughfunding. Continue toraise awarenessand
requestdonationsthroughevents,
emails,andotherdonationtechniques
7 Users don’tlike change. Describe how the systemwill benefit
comparedto othersystems.Showhow
will reduce workloadandpaperwork.
7 Cannotfindan efficientwaytotrack lostand
founddata.
Propose solutionsthatdraw from
systemswithsimilardataand product
flowsfromothercompanies.
6 Time neededtomaintainthe systemmakesusers
reluctantto use.
Show usershow the time takento
maintainthe systemcanpositively
impactthe community.Weighted
decisiontable.
6 Developerunclearof scope andneedsof the LFS. Clarifyorget new developer.
6. Requirements Analysis
The followingsectionillustratesthe necessaryrequirementsneededtosuccessfullyimplementthe Lost
and Foundsystem.Itcontainsthe elicitationplan,businessrequirements,userandfunctional
requirements,andnon-functional requirements.
6.1 RequirementsElicitationPlan
In orderto elicitrequirementsforthe Lostand FoundSystem, ourgroupaimsto developa
surveythatwill be providedtothe membersandcustomersof the ECCHA.We will sendanemail
to our customersandmemberswiththe surveyattached,aswell asaskthose whocome into
the Humane Associationtotake a minute tofill outthe survey.The purpose of the surveys,
whichwill be writtenandconductedby‘Mike andAlex,will be toidentifythe aspectsof the
currentLost and Foundsystemthatare working,and whichaspectsof the systemtheywould
like improvedorchanged.There willbe 25 surveysfilledoutbycustomers,members,and
employeeswhichwill consistof 15 questionseach.Resourcesneededinclude the questionnaire

13. 12
template andanappropriate timeframe of 10minutestosurvey. Alongwiththe surveys,our
groupwill conducta fewbrief interviews.ZachandSam will be conductingthe interviewson
twocurrent ECCHA employeesandKarenherself.We willbe selectingthe employeesbasedon
theirinvolvementinthe Lostand Foundprocess.Due to the employees’tightschedules,Sam
will be emailingKarenatECCHA in orderto setup a time that isconvenientforheremployees.
Zach and Sam will be preparingseveral questionsaheadof time andwill bringajournal totake
detailednotes.Resourcesneededforthistechnique include copiesof the interview questions
template andemail accesstoKaren.
6.2 BusinessRequirements
The followingstatementexplainsourrequirementsandhow the systemwillimpactthe Humane
Association.
BusinessRequirementStatement
The purpose of The Lost andFoundSystemisto create a unifiedsystem that
automaticallyinterfaceswithPetPointsothatanimal reportsare more easilygenerated,
filesandlostanimal historyare more easilyaccessed,andlesspaperisusedonanimal
files.
6.3 Userand Functional Requirements
The followingtable showsthe userandfunctional requirementsforthe Lost and FoundSystem.
It describesthe differentstepsuserswill needtotake,andwhatthe Lost and FoundSystem
needstodo to supportthose steps.
We usedRelationshiptoOtherRequirementsmethodbecause oursystemneedstobe able to
interface andmeetrequirementsof PetPoint.Examplesof thisinclude beingable tomatchthe
data entryfieldswithcorrectinformationeventhoughwe wouldlike toincorporate adropdown
menuforbreeds.If our systemcannot accuratelyenterdataintoPetPointitbecomesuseless.
As well,we usedMoSCoWanalysistodocumentthe rankings.
M = Must be includedinthe system
S = Shouldbe includedinthe system
C = Couldbe includedinthe system
W = Won’tbe includedinthe system
ColumnHeaderKey:CI= CommonInformationIdentifier,ST= Status
StatusColumnKey:A = Accepted C= Changedsince lastreview,N (orBlank) =New since last
review.
ID Userand SystemFunctional RequirementStatements CI [Ranking] ST
User
Role
Owner/ Employee
Goal U2 Enter Animal Information CI2 M N
U2.1 User selectsLost andFound
U2.1F1 Systemdisplayshome page withoptionbars
U2.2 User selectsanimal breed
U2.2F1 Systemdisplayspicturesof breedoptions
U2.3 User entersanimal information CI2
U2.3F1 Systemdisplaysonline “Lost”form which displays
information regarding the lost animal

14. 13
U2.4 User attachesdetailedphotosof lostanimal
U2.4F1 Systemprovidesuploadlink
U2.5 User submitsform
U2.5F1 Systemdisplayssubmitbutton
User
Role
Owner/ Employee
Goal U3 Enter Owner Information M N
U3.1 User selectsLost andFound
U3.1F1 Systemdisplayshome page withoptionbars
U3.2 User selectsOwnerInformation
U3.2F1 Systemdisplayspicturesof breedoptions
U3.3 User entersOwnerinformation
U3.3F1 Systemdisplaysonline “Lost”form which displays
information regarding the lost animal
U3.5 User submitsform
U3.5F1 Systemdisplayssubmitbutton
User
Role
Manager
Goal U4 Generate Reports M A
U4.1 SelectManagerTasks A
U4.1F1
Systemdisplayshome page withoptionbars A
U4.2 Validate User A
U4.2F1
Systemdisplays“Username andpassword” A
U4.2F2
User isan authorizeduser CI1 N
U4.3 User selectsgenerate reports A
U4.3F1
Systemdisplaysmanagersreports inexcel A
6.4 Nonfunctional Requirements
The followingare the nonfunctional requirementsnecessaryforthe Lost and Foundsystemto
functionuponimplementation.
ID Nonfunctional RequirementStatements CI ST
OPERATION Requirements:How well doesthe system performfor daily use?
AccessSecurity How well is the systemguarded againstunauthorized access?
The extentto which the system issafeguardedagainstdeliberate and intrusive faults from internal and external sources.
N-ACS1 Employeeswill be providedwithauthorizedusernamesaswell as
passwords.
CI1 C
N-ACS2 An email addresswillbe connectedwithemployees’accounts. C

15. 14
ID Nonfunctional RequirementStatements CI ST
N-ACS3 Each passwordisto be changedeverysix monthsbyeach
authorizeduser.If usernamesorpasswordsare forgotten,the
informationwill be senttothe email addressof the user.
CI1
C
N-ACS4 Passwordswill notbe shownatany pointintime duringthe login
process.
A
N-ACS5 Non-authorizeduserswill notbe requiredtoenterausername or
passwordto make entries. However,non-authorizeduserswillnot
be able to change any data currentlyinthe system.
CI1
A
N-ACS6 Each unsuccessful attemptbyan employeetologinshall be
recordedonan audittrail.
A
N-ACS7 If an authorizeduserisloggedinbutidle forlongerthan20
minutes,theywillbe automaticallyloggedout.
CI1 A
Availability How dependable is the systemduring normal operating times?
The degree to which users can depend on the systemto be up (able to function) during “normal operating times.”
N-AVL1 The Lost and FoundSystemwill be available tousers24 hoursper
day,7 days perweek.
A
N-AVL2 In the case of maintenance orsystemoutages,userswill be
notifiedviaemailpriortothe outage.
A
N-AVL3 The Lost and Foundsystemshall maintain99% up time A
N-AVL4 If necessary,maintenance willalwaysbe conductedduringlow
peakhour timesof after1am and before 5am.
A
Efficiency How fastcan itprocess? How many can be processed? How well doesthe system respond?
The extentto which the software systemhandlescapacity,throughput, and responsetime.
N-EFC1 The initial systemshall be able tohandle eachdataentryinless
than one second,andthe full dataform inlessthanfive seconds.
C
N-EFC2 Anyinterface betweenthe userandthe systemshall take nomore
than five seconds.
A
N-EFC3 Once an entry has beeninthe systemtwoweeks,itwill be
removedfromthe Lost and Foundsection,andmovedtothe
Adoptionsectionof the system.
A
N-EFC4 The initial systemshall have anavailable storage space of 2TB. A
N-EFC5 The systemshall produce a storage capacitywarningnotification
whenthe 70% capacity thresholdiscrossed.
A
N-EFC6 The systemwill be able toaccommodate 10 userssimultaneously
at any giventime.
A
Integrity How accurate and authentic are the data?
The degree to which the data maintained by the softwaresystem are accurate, authentic,and withoutcorruption.
N-INT1 Anyentrymade by an authorizedusertothe systemwill be
reviewedbyanotherauthorizeduserormanagerbefore the entry
issubmitted.
CI1 A
N-INT2 To avoidtotal lossdue to an unexpectedsystemfailure,eachentry
will be savedtoa word documentpriortobeingsubmitted.
A
N-INT3 Data shall be added,updated,orremovedona dailybasisasto
avoidinaccurate or irrelevantdata.
A

16. 15
ID Nonfunctional RequirementStatements CI ST
N-INT4 Anycorrupt data submittedbyanon-authorizeduser,suchasdata
that isobviouslyinaccurate,shallbe removedbyanemployee or
managerimmediatelyuponfinding.
CI1 A
N-INT5 The systemwill be screenedweeklytoensure LostandFound
submissionsbyownersare legitimate.
C
Reliability How immune is the systemto failure?
The extentto which the software systemconsistently performsthe specified functionswithoutfailure.
N-REL1 Managers or directorswill be notifiedastoanysystemoutages. A
N-REL2 The rate of entryfailure shall be 1/1000 (1 occurrence in1000
days).Failure meansthe systemfailstosave anentryof a lost
animal.
A
N-REL3 The mean time tofailure of the systemtimingoutshall be 1/1000
(1 occurrence in 1000 entries).Failuremeansthe systemmust
cancel the current processandallow the userto re start.
A
N-REL4 Afterfive unsuccessful loginattempts,the systemwill recognize an
unauthorizeduserandfreeze the systemuntil amanagerlogsin
and unfreezesthe system.
CI1 A
N-REL5 If the systemfailstoaccepta Lost and Foundsubmission,anerror
box will appeartonotifythe user.
A
N-REL6 A basicsystemfunctionstestwill be performedeveryweekto
ensure all aspectsare workingasintended.
C
Survivability How resilientis the systemfrom failure?
The extentto which the software systemcontinues to function and recoversin the presence ofa systemfailure.
N-SRV1 If informationsubmittedbyauserfailsto update,the userwill
immediatelyreceiveanemail withanotification.
A
N-SRV2 In the case of a systemfailure,usersthathave submitted
informationwill be informedthattheirentrieswillbe recovered
and postedagain.
A
N-SRV3 The systemwill be inspectedonce every12monthsinorder to
ensure efficiencyandresistance tofailure.
A
N-SRV4 Employeesandmanagersare authorizedtoperformsystem
recoveryprocedures.
A
N-SRV5 The systemisable to functiononminimal hardware requirements.
Thus increasingitslongevity.
A
Usability How easy is itto learn and operate the system?
The ease with which the user is able to learn, operate, prepare inputs, and interpretoutputs through interaction with a system.
N-USE1 The systemwill take nomore than 15 minutestolearnand
operate.
A
N-USE2 Non-authorizeduserswill be able torecognize andfigure outhow
to use the systemwithinfive minutes.
CI1 A
N-USE3 Authorizeduserswill be requiredtoarrive tothe ECCHA earlyon
the firstday of the systemimplementationfora15 minute training
session.
CI1 A
N-USE4 Users shall be able tofill outa formin the systemwithinfive
minutes.
A
REVISION Requirements:Howeasy is it to correct errors and add functions?

17. 16
ID Nonfunctional RequirementStatements CI ST
Flexibility How easy is itto modify to workin differentenvironments?
The ease with which the softwarecan be modified to adaptto differentenvironments, configurations,and user expectations.
N-FLX1 No piece of textthatmightbe displayedtoauser shall reside in
program source code.Everypiece of textthata usermightsee
mustbe modifiable without changingsource code.
A
N-FLX2 The systemwill be able tofunctionwithupdatedversionsof
Microsoftproducts.
A
N-FLX3 The systemwill be updatedwheneverPetPointisupdatedtostay
updated.
A
N-FLX4 The systemwill have the abilitytobe able to have language
changedat the requestof the user.
A
N-FLX5 The abilitytoadd a mobile versioncanbe made available atthe
usersrequest
A
N-FLX6 The report customizationoptionsmustbe flexibletorespondto
the user’sneeds.
A
Maintainability How easy is itto upkeep and repair the system?
The ease with which faults in a software system canbe found and fixed.
N-MNT1 The maintenance logshall be storedwithinthe systemtorecord
updatesmade tothe system.
A
N-MNT2 A systemdevelopment teammemberwhohasat leastone yearof
experience supportingsoftware applicationsshall be able toadda
newproductfeature withnomore than one weekof labor
A
N-MNT3 The systemshall notbe shut downformaintenance more than
once in a 24-hour period.
A
N-MNT4 The systemwill runa self-checkeverythree monthstodetermine
any problemsthatcouldarise
A
N-MNT5 The systemshall notbe shut downformaintenance more than
once in a 24-hour period.
A
N-MNT6 The systemsource code is properly documentedsochangescanbe
easilymade.
A
Scalability How easy is itto expand or upgrade the system’scapabilities?
The degree in which the system isable to expand its processing capabilities upward and outward to supportbusinessgrowth.
N-SCL1 The effortneededtoadministerthe systemshall nothave a
significantincreasedue to anincrease inthe numberof animals.
C
N-SCL2 The systemwill be usable oncomputeraswell asall mobile
applications.
C
N-SCL3 Addingextrafunctionalitieswillnotmake the systemitself less
functional.
A
N-SCL4 The elapseddurationof time requiredtoproduce anystatement
or reportshowinginformationabouttransactionsshall be based
uponhowmuch data is presentedratherthanthe total quantityof
storeddata
A
N-SCL5 Whena newversionof the systemisreleased,itshall be available
to be upgradedfromany previousversion
A
N-SCL6 The systemdoeshave the abilitytoincrease the possible amount
of users.
A

18. 17
ID Nonfunctional RequirementStatements CI ST
Verifiability How easy is itto show the system performs its functions?
The extentto which tests,analysis, and demonstrations are needed to prove thatthe system will function as intended.
N-VER1 Users of the systemshouldparticipate insystemreviewsthatwill
occur on a monthlybasis
C
N-VER2 Software alphatestingwillrequirethe use of atest database with
data extractedfromthe productiondatabase.Thistestdatabase
will be deletedaftersuccessful implementationof the software
system.
A
N-VER3 The systemwill be pre-testedbyusersafterthe alphatesting
phase to validate systemrequirementsare beingsatisfied.
A
N-VER4 User manualswill be available tousers.Definitionsandstep-by
stepinstructionsof the system’smainfunctionswill be highlighted.
A
N-VER5 If the systemfailsbeforethe authorizedusersavesall new animal
and ownerinputs,the systemshall be able torecoverall changes
updatedupto one minute priorto the failure
CI1 A
TRANSITION Requirements:How easyis it to adapt to changes in the technical environment?
Interoperability How easy isitto interface with another system?
The extentto which the software systemis able to couple or facilitate the interface with other systems.
N-IOP1 The systemmustbe able to interface withPetPoint’sdataentry
fields.
A
N-IOP2 The systemmustnot displayimagesoffensivetopossibleusers. A
N-IOP3 The systemmustuse Englishas itscommondisplaylanguage to
increase effectivenessandreduce errorsinprocessing.
A
N-IOP4 Non-authorizeduserswill notbe able togenerate reportsfromthe
data.
CI1 A
N-IOP5 Reportsgeneratedcanbe exportedtoapplicable Microsoft
Applications.
A
N-IOP6 Upgradesto the systemwill notinterferewithabilitytointerface
withPetPoint.
A
N-IOP7 Systemwill be able toconvertpaperrecordsto digital viascanning
themintothe system.
A
Portability How easy isitto transport?
The ease with which a software systemcan be transferred from its currenthardwareor software environmentto another.
N-POR1 Time Zone will needtobe seteachtime the systemis
implementedorupdated.
A
N-POR2 Productwill be customizableuponimplementationtomeetuser’s
needs.
A
N-POR3 Productwill have bothcomputerandmobile/tablet capabilities. A
N-POR4 Systemmustbe able to functiononwindows7and up operating
systemsaswell asAndroidandiOSmobile operatingsystems.
A
N-POR5 Software shouldalsosave toa “Cloud”serverforoffsite backup. A
N-POR6 All time references will be basedoff of the time zone whichthe
systemwasimplementedin.
A
N-POR7 The systemwill be able tohave limitedfunctionwhennot
connectedtothe internet.
A

19. 18
ID Nonfunctional RequirementStatements CI ST
Reusability How easy isitto convertfor use in another system?
The extentto which a portion ofthe software systemcan be converted for use in another.
N-REU1 Productcan be implementedasa subsystemif anoverarching
managementsystemisimplemented.
A
N-REU2 Will be designedtoadhere toHyperTextMarkupLanguage(HTML)
guidelinesandstandards
A
N-REU3 Currenthard copiesfromECCHA will be scannedintothe system. A
N-REU4 Database will be easilymovedtootherstorage formsinfuture
hardware updates
A
N-REU5 Systemwill be codedtoworkwiththe mostcommon operating
systems
A
6.5 CommonInformation
ID NamedInformation Definitionor BusinessesUsage / Business
elements
CI1 AuthorizedUser The Lost and FoundSystemdisplaystwotext
fieldswithlabels“Username”and“Password.”
A userbecomesauthorized uponsuccessful
completionof the login.
CI2 Animal Information Animal informationincludessex,species,
breed,age,color,weight,andname

20. 19
7. Use-Case Diagram and Specifications
The belowsectionsillustrate the relationshipsbetweenthe usersandthe systemsof the use case.The
use case diagramand the use case specificationsdescribehow the systemandthe usersinteract.
7.1 Use CaseDiagram
The followingsectionillustrates the use case diagram, (Figure 1) andthe specificationsof the
majoruse case withinthe Lostand FoundSystem. The majoruse casesare Fill outlostform,
enteranimal information,enterownerinformation,andgenerate reports
7.2.1 GenerateReports
Belowisdocumentationdescribingthe generatereportsuse case
7.2.1.1 BriefDescription
Generatingreportsisa necessaryfunctionforkeepingtrackof lostandfoundanimals. The
manageris able togenerate reportstokeeptrack of animal information sothattheycan
presentthe informationtostockholders,andkeepstatisticsaccurate.
7.2.2 FlowofEvents
The followingare the basicandalternative flowsfornavigatingthe generate reports use case
7.2.2.1 BasicFlow
Belowisthe basicflowof events,orthe most commonpath,throughthe generate reportsuse
case
1. Use Case beginswhenthe userattemptstologintothe Manager section.
2. Use Case:Validate Userisperformed.
3. User Selectsgenerate reports.
4. User selectsinformationtobe includedin reportusingfilters.
5. The systemgeneratesreportfromselecteddata.
6. The systemdisplaysthe reports inExcel.
7. The use case endssuccessfully

21. 20
7.2.2.2 AlternativeFlows
Beloware some examplesof alternativeflowsfromthe basicflow describedabove forthe use
case Generate Reports.
7.2.2.2.1 System CanNot GenerateReport
1. User Selectsgenerate reports.
2. The systemshowsanerror message thatsays“SystemCan NotGenerate Report”.
3. Systemreturnsto step3.
7.2.2.2.2 System CanNot Access Excel
1. The systemgeneratesreportsforthe lostandfoundanimals.
2. The systemshowsanerror message thatsays“Can Not AccessExcel”.
3. The systemreturnsbackto step4.
7.2.3 Special Requirements
There isone special requirementthatneedstobe fulfilled foroursystemtooperate successfully
7.2.3.1 Timelycompletion
The systemwill needtobe able togenerate reportinformationandbe able toopen excel with
Informationpresentwithin30 secondsof activatingthe system.
7.2.4 Preconditions
The followingare preconditionsnecessarypriorto generatingreports inthe system.
7.2.4.1 TheSystem isfunctioningandreadyto use
The systemhas a secure connectiontothe internet,systemisupto date and readyforuser
input.
7.2.4.2 Thecomputer is poweredon,useraccessesLostand Foundpage.
The user mustenterthe correct URL to navigate tothe webpage andaccessLost and Foundtab.
7.2.4.3 Thecomputeris poweredon,useraccesses Excel.
The user mustopenExcel to view the generatedreports.
7.2.5 Post conditions
The followinglistof postconditionsare possible statesthe systemcanbe infollowingthe
completionof the use case.
7.2.5.1 All necessarydatafieldshavebeen filled,andthe user submitsthe
information.
Fileshave been updated.

22. 21
7.2.5.2 Notificationwindowdisplayeduponcompletion.
The user isnotifiedthattheirsubmissionwassuccessful andisgiventhe optiontocontinue or
exit.
7.2.6 ExtensionPoints
No extensionpointscanbe identified,asthe GeneratesReport use-casedoesnotinclude
extendsrelationships.
7.3.1 Enter Animal Information
Belowisdocumentationdescribingthe EnterAnimal Information use case.
7.3.1.1 BriefDescription
EnteringAnimal Information isanecessaryfunctionforthe lostand foundprocess.Byentering
and maintainingthoroughandcomplete animal informationthe betterthe matchesthe system
can return.
7.3.2 FlowofEvents
The followingare the basicandalternative flowsfornavigatingthe enteranimal information use
case.
7.3.2.1 BasicFlow
Belowisthe basicflowof events,orthe most commonpath,throughthe enteranimal
information use case.
1. The use Case beginswhenthe user opensthe website.
2. User entersthe animal informationintothe appropriate fields.
3. Use Case:EnterOwnerInformation.
4. User submitsform.
5. The use case endssuccessfully.
7.3.2.2 AlternativeFlows
Beloware some examplesof alternativeflowsfromthe basicflow describedabove forthe use
case EnterAnimal Information.
7.3.2.2.1 System CanNot AccessWebsite
1. User attemptstoaccess website.
2. The systemshowsan errormessage thatsays “SystemCanNot AccessPage”.
3. Systemreturnstostep3.
7.3.2.2.2 System CannotSubmitForm
1. Starts at step4.
2. Systemfailstouploadfile.
3. Systempromptsusertotry again.

23. 22
7.3.3 Special Requirements
There isone special requirementthatneedstobe fulfilledforoursystemtooperate
successfully.
7.3.3.1 Timelycompletion
The systemwill needtobe able to processsubmittedinformationinlessthan15 secondsdue to
the simple formatof the entereddataas text.
7.3.4 Preconditions
The followingare preconditionsnecessarypriortoenteringanimal informationinthe system.
7.3.4.1 TheSystem isfunctioningandreadyto use
The systemhas a secure connectionto the internet,systemisupto date and readyforuser
input.
7.3.4.2 Thecomputeris poweredon,useraccessesLostand Foundpage.
The user mustenterthe correct URL to navigate tothe webpage andaccessLost and Foundtab.
7.3.5 Post conditions
The followinglistof postconditionsare possible statesthe systemcanbe infollowingthe
completionof the use case.
7.3.5.1 All necessarydatafieldshavebeen filled,andthe usersubmitsthe
information.
Animal informationfileshave beenupdated.
7.3.5.2 Notificationwindowdisplayeduponcompletion.
The user isnotifiedthattheirsubmissionwassuccessful andisgiventhe optiontocontinue to
the home page or exit.
7.3.6 ExtensionPoints
No extensionpointscanbe identified,asthe EnterAnimal Informationuse-casedoesnot
include extendsrelationships.
7.4.1 Enter OwnerInformation
Belowisdocumentationdescribingthe enterownerinformation use case.
7.4.1.1 BriefDescription
EnteringOwnerInformation isanecessaryfunctionforreconnectinglostandfoundanimals.By
providingaccurate contactinformationthe ownersof the animal canbe notifiedwhenan
animal matchingtheirlostanimal’sdescriptionisfound.

24. 23
7.4.2 FlowofEvents
The followingare the basicandalternative flowsfornavigatingthe EnterOwnerInformation.
7.4.2.1 BasicFlow
Belowisthe basicflowof events,orthe most commonpath,through the enterowner
informationuse case.
1. The use Case beginswhenthe user opensthe website.
2. Use Case:EnterAnimal Information.
3. User entersownerinformationintothe appropriate fields.
4. User submitsform.
5. The use case endssuccessfully.
7.4.2.2 AlternativeFlows
Beloware some examplesof alternativeflowsfromthe basicflow describedabove forthe use
case EnterOwnerInformation.
7.4.2.2.1 System CanNot AccessWebsite
1. User attemptstoaccess website.
2. The systemshowsan errormessage thatsays “SystemCanNot AccessPage”.
3. Systemreturnstostep3.
7.4.2.2.2 System CannotSubmitForm
1. Starts at step4.
2. Systemfailstouploadfile.
3. Systempromptsusertotry again.
7.4.3 Special Requirements
There isone special requirementthatneedstobe fulfilledforoursystemtooperate
successfully.
7.4.3.1 Timelycompletion
The systemwill needtobe able toprocess submittedinformationinlessthan15 secondsdue to
the simple formatof the entereddataas text.
7.4.4 Preconditions
The followingare preconditionsnecessarypriortoenteringownerinformationinthe system.
7.4.4.1 TheSystem isfunctioningand readyto use
The systemhas a secure connectiontothe internet,systemisupto date and readyforuser
input.
7.4.4.2 Thecomputeris poweredon,useraccessesLostand Foundpage.
The user mustenterthe correct URL to navigate tothe webpage andaccess Lost and Foundtab.

25. 24
7.4.5 Post conditions
The followinglistof postconditionsare possible statesthe systemcanbe infollowingthe
completionof the use case.
7.4.5.1 All necessarydatafieldshavebeen filled,andthe usersubmitsthe
information.
Ownerinformationfileshave beenupdated.
7.4.5.2 Notificationwindowdisplayeduponcompletion.
The user isnotifiedthattheirsubmissionwassuccessful andisgiventhe optiontocontinue to
the home page or exit.
7.4.6 ExtensionPoints
No extensionpointscanbe identified,asthe EnterOwnerInformationuse-casedoesnotinclude
extendsrelationships.
8. Business Rules and Entity Relationship
Diagram
The Followingdiagramshowseachentityfromthe LostandFounddatabase and illustratesthe business
rulesas connectionsbetweenentities.Thisdiagramalsodisplaysthe attributesthatare includedineach
entity.Primaryandforeignkeysare identifiedwitha“PK”or “FK” buttonrespectively.

26. 25
8.1 Entity RelationshipDiagram

27. 26
8.2 BusinessRules
The followingbusinessrulesexplainthe relationshipof eachentityfromthe EntityRelationship
Diagram.
Owner and Animal
Every owner may own one or more animals.
Every animal is owned by an owner.
Owner and Phone
Every owner has one or more phone numbers.
Every phone number belongs to one owner.
Owner and Email
Every owner has one or more emails.
Every email belongs to one owner.
Owner and Address
Every owner must have one address.
Every address has oneor more owners.
8.3 SampleDataTables
Owner ID Last Name First Name AddressID
1 Johnson Joey 13
2 O’Neil Neil 11
3 Brown Molly 12
4 Zuckerberg Marcus 12
5 Winfrey Oprah 14
AddressID Street City State Zip
11 516 ½ Menominee St. Eau Claire WI 54701
12 427 NiagaraSt. Eau Claire WI 54702
13 454 SummitAve. Eau Claire WI 54701
14 1111 Rich Dr. Eau Claire WI 54701
Animal ID Name Age Weight Sex Species Breed Owner ID
123 Boots 2 10 F Cat Tabby 3
124 Mr. Pickles 4 12 M Cat Siamese 4
125 Gary 14 95 M Dog German
Shepherd
2
126 Claire 8 20 F Rabbit Flemish
Giant
5
127 Steve 5 75 M Dog Irish
Setter
1
128 Tina 5 362 F Llama Ccara 5

28. 27
Email ID Email Address Type (W,H) Primary Owner ID
21 Animallover234@gmail.com H Y 4
22 Kittycatz4lyfe@msn.com W N 3
23 Doghouse@aol.com H Y 2
24 fuzzyfriends@live.com H Y 3
25 YouGetACat@O.net W Y 5
26 Petsavior2@gmail.com H Y 1
Phone ID Phone Number Type (H, C, W) Primary Owner ID
1111 715-222-3333 H Y 1
2222 715-123-4567 C Y 2
3333 715-236-9840 W Y 4
4444 612-222-9666 C Y 5
5555 715-609-6196 W N 5
6666 952-911-0911 W Y 3
9. Data Flow Diagrams
The Data FlowDiagramisa graphical representationof the proposedlostandfoundsystem.Eachof the
followingisanillustrationof the flow of datawithinthe lostandfoundsystematvariouslevelsof
decomposition.

29. 28
9.1 ContextLevel Diagram
The contextlevel diagram(Figure1) showsanoverview of the systemandthe flow of data
withinthe Lostand FoundSystem. ThisLevel showshow eachactoreffectsthe systemfroma
top down perspective. Italsoshowswhatthe systemgivestoeachactor involvedinthe system.
Figure 1: Context Level Diagram

30. 29
9.2 Level 0 Diagram
The level 0 diagram(Figure 2) displaysthe movementof datainand outof the system. The level
of the diagramshowshowthe systeminteractswiththe datastores. The othermainfeature of
thislevel isthatitshowshowthe data is transformedbetween the processes.
Figure 2: level 0 Diagram

31. 30
9.3 Level 1 of Process1
The data flowdiagram(Figure 3) decomposesthe ProcessInformationprocess.Thislevel of the
diagramshowswhathappenswithinthe processof enterinformation. Itshowswhere the datadirectly
goesand whathappenstoit inthe specificpartsof the processof enterinformation.
Figure 3: Level 1 diagram

32. 31
9.4 Level 1 of Process3
The data flowdiagram(Figure 4) decomposesthe Generate reportsprocess..Thislevel of the
diagramshowswhathappenswithinthe processof generate reports. Itshowswhere the datadirectly
goesand whatspecificinformationisusedincertainpartsinside of the processgenerate reports.
Figure 4: level 1 diagram

33. 32
10. Prototype Mock-ups
The followingsectionsillustrate prototypemock-upscreens.Theseprototypesdisplaythe processthe
userwill follow whenusingthe LostandFoundSystem.Eachform will be providedwithintroductory
textto explain whatthe userisseeing.
10.1. Lost and FoundMenu
Thisis the mainLost and Foundformthat userswill interactwith.The userwill interactwith
drop-downmenusandtextboxestoenterthe requiredinformation.There willalsobe anarea
to uploadimagesof theirpet.

34. 33
10.2 UserSign-inScreen
From thisscreen,the usercan input theirusername andpasswordtosignintothe system.
10.2 GenerateReportsForm
Thisform isviewable afterthe userlogsintothe system.Fromhere,the primaryfunctionof this
page is to generate anyrequiredreport.

35. 34
11. Transition Plans
The followingsectionswill detail the testplan,the implementationplan,andthe trainingplanforthe
Lost and FoundSystem.These plansare tobe implementedtoensure asuccessful installationof the
Lost and FoundSystem.
11.1. Test Plan
The test planisusedto ensure properfunctionalityandneedsof the ECCHA.Thisplanwill
include the following:Component,integration,systems,andacceptance testing.Eachformof
testingwill be describedinthe followingsubsections.
11.1.1 ComponentTesting
Componenttestingoccurswhenthe subsectionsof the systemare testedindividually.First,the
loginscreenwill be testedtoensure thatmanagersare able tosuccessfullylogin.Also,the login
screenwill be testedtoensure thataccessisnot allowedwithoutpropercredentials.Next,the
generate reports componentwill be testedtoensure all aspectsof the formare workingand
filteringproperly.The LostandFoundformwill be testedtoguarantee informationremains
withinthe correctfieldsandcanbe easilyconvertedintoothertextforms.The final component
testfor the systemwill be itsabilitytoaccuratelymatchdescriptionsfromthirdpartydatabases.
The systemdeveloperwillbe responsible forconductingthesetestsonthe prototype.Basedon
requiredfields,sample datawill be createdtotestineachprototype mockup. Fromhere,any
errorsthat may have occurredwill be documentedandcorrectedtoensure properfunctionality.
Componenttestingwill be complete when,andonlywhen,all componentsof the systemare
functioningaccordingtodesign.
11.1.2 IntegrationTesting
At completionof componenttesting,toconfirmthatall componentsare workingtogether,
testingforsuccessful integrationwill commence.Thistestingistoguarantee thatthe Lost and
Foundsystemwill integrate smoothlywithexistingsystemsusedbyECCHA.Toconduct thistest,
the systemdeveloperwill use sampledataandperforma mock-documentation,likethatof an
end-user.Fromthese testresults,we canconfirmthatall data issyncedcorrectlywith
correspondingdatabases.Once anyandall issueshave beenrecorded,corrected,andtested
againto confirmissueshave beenresolved,onlythencanintegrationtestingcanbe completed.
11.1.3 SystemTesting
Upon completionof the integrationtesting,alphatestingwillbeginonthe developmentsite
usingdevelopmentpersonnel.Inordertoavoidfuture modificationsduringonsite testing, any
errorsduringalphatesting will be fixedandthe testwill be runagain.Thisversionof testing
involvesthe bringingtogetherof all the programsthat a systemencompassesfortesting
purposes.Systemtestingwillverifythatthe integratedsystemhascompletelysatisfiedthe
explicitrequirementsof the ECCHA.The system developmentteamwillbe responsible for
conductingthe systemtestingandprovidingtime frame neededforsystemtesting.Testingwill
be consideredcomplete once anydeficiencieshave beencorrected.

36. 35
11.1.4 AcceptanceTesting
Acceptance testingwillbeginatthe developmentsite uponsuccessfulcompletionof system
testing.The developmentteam,the alphatesters,willperformfinal acceptance testingpriorto
the onsite testingatthe ECCHA inorderto guarantee successuponimplementation.Duringthis
phase of the acceptance testing,systemdeveloperswill entersimulateddataintothe system
and attemptto make the systemfail.Duringthisphase,systemdeveloperswill testforsecurity,
recovery,stress,andperformance.
The firstcomponentof acceptance testingissecuritytests.Duringsecuritytesting,system
developerswill attempttoaccessthe systemwithoutpropercredentials.Next,system
developerswill enterpropercredentialstoaccessthe systemandthenrestartthe systemwhile
loggedinwhichwill force the usertore-enterlogincredentials.Thesetestsdemonstrate thata
userwhohas eithernotenteredthe correctcredentialsorhasnotloggedinafterrestarting
theirsystemwill notbe able toenter,edit, orsubmitdataintothe system.
The secondcomponentof acceptance testingisrecoverytests.Duringrecoverytesting,system
developerswill force asystemfailure.The purpose of thistestistodemonstrate the system’s
abilitytopropertyreboot,save informationthatisbothinthe systemandcurrentlyinprogress,
and protectsubmitteddatafromcorruption.
The third componentof acceptance testingisstresstests.Duringstresstesting,system
developerswill logintothe systemonmultiple differentcomputersinordertoputstresson the
system.The purpose of stresstestingistodemonstrate the system’sabilitytohandle multiple
usersaccessingthe systemsimultaneously.
The fourthcomponentof acceptance testingisperformance tests.Duringperformance testing,
systemdeveloperswill ensure the systemperformsasaccordingtodesign.Systemdevelopers
will testthe systemona computeras well asmobile devise.Performance testswill be
consideredcomplete if the systemfunctionswithoutglitchesorerrors.
Aftersuccessful completionof alphatesting,the systemwillbe readyforonsite betatesting.
The ECCHA employeeswillbe the betatesters.Betatestingwill be completedbyeachemployee
whois involvedinthe Lostand Foundprocessinany way.Each employee will complete each
testthat was completedduringalphatesting,includingsecurity,recovery,stress,and
performance.The betatestingwillbe consideredcompleteonce eachtesthasbeensuccessfully
completedbyeachemployee.If anyerrorsorglitchesare encountered,theywill be fixed,and
the employeeswillbe askedtotestthatsectionof the systemagain.Once the beta testingis
completedandthe ECCHA staff signoff on the system, the Lostand Foundsystemwill be
implementedata future date.
11.2 ImplementationPlan
The implementation of the LostandFound Systemwill use the directinstillation approach. The
oldsystemwill be shutdown whenthe new one issetup. The directapproach will be the best
way to implementthe new system, becausethe systemisdesigned tostreamlinethe process
and any overlapwouldcreate repeated dataandwastedtime.

37. 36
The implementation will take place afterall testingandtraininghastakenplace. The systemwill
be implementedbetween11pmand1am as thiswill be atime of little tonouse of the system. If
the systemisnot completely functional byopeninghoursorif it isattemptedtobe usedonline,
a message onthe computerwill appearsaying, “The systemiscurrently unavailable. Pleasetry
later.”The data already enteredintothe currentsystemwill be transferred andtransformed to
match the new system. Lostand Foundsystemwill be fully functional foruse afteritisfully
implemented.
Afterthe implementation of the LostandFound systemthe staff of the ECCHA andthe public
will be able tomore easily inputlostanimalsandowners of lostanimalsintothe database. This
will alsoallow forthe systemtoflagpotential matches. The systemwill alsoallowformanagers
to generate specified reportsthatcancontainimportantinformation.
11.3 Training Plan
Once the Lost and Found systemisfully functionalall employees andauthorized userswill go
throughtrainingto make sure they can getfull use of the system.
11.3.1 EauClaireHumaneSocietyStaff
All employees will be taughthow touse the new Lost andFoundform. All authorized userswill
gettrainingon the generate reportfunction.
The trainingwill be completed bythe systemadministratorinthe formof a one-on-one meeting
for authorized usersandagroup meetingof all the employees. The singletrainingsession will
be heldwhenThe ECCHA isn’topentothe publicandwill lastnolongerthan one anda half
hours. The trainingsessionwill be heldone weekbefore the implementation of the system. In
case of employee turnoverora new authorized userbeingintroduced tothe Lost andFound
system, atrainingmanual will be createdtoguaranty the systemisusedoptimally andproperly.

38. 37
12. Appendices
The belowinformationisrequiredforthe documentationprocessfordesigningthe system.Information
specifictothisdocumentcanbe foundhere tosupplementpriorcontent.
12.1 RevisionHistory
Throughthe developmentof the system, as a groupwe kepttrack of eachstepof whoworked
on the project. Thisinformationisforthe ECCHA to review throughthe progressionof the
improvementof the lostandfoundsystem.
Date Version Description Author
2/24/2015 1.0 Startedinitial formattingandideaof planning Group
3/3/2015 2.0 CompletedProblemStatement,ProductPosition
Statement,andStakeholderSummary
Group
3/10/2015 2.1 Enhancedall of StakeholderandUserDescriptions,
additional formatting
Group
3/12/2015 2.2 CoverPage Mike
3/13/2015 2.3 EnhancedIntroductorytexts,addedadditional table
content
Group
3/13/2015 2.4 Table Formatting Zach
3/15/2015 2.5 Final informationandformatting Group
3/17/2015 3.0 CompletedSystemsPerspective and High-level System
Requirements
Alex andSam
3/17/2015 3.1 AddedProjectRiskList,elaboratedon High-level
SystemRequirements,updatedGlossary
Zach
3/17/2015 3.2 AddedAssumptions,Constraints,andDependencies Sam
3/18/2015 3.3 AddedAlternatives andCompetition Mike
3/18/2015 3.4 AddedSystemFeatures,updatedglossary Group
3/22/2015 3.5 Fixedformatting, revisedsectionnamesinrevision
history,fixedmistakesbasedoff of feedback
Zach
4/7/2015 4.0 Additionof Use Case Diagramand Specifications Group
4/15/2015 4.1 Added RequirementsAnalysis Group
4/21/2015 4.2 AddedData FlowDiagrams Group
5/7/2015 4.3 AddedBusinessandEntityRelationshipDiagrams Group
5/9/2015 4.4 AddedadditionalinformationtoUse Case
Specifications, EntityRelationshipDiagram,
RequirementsAnalysis,andDataflow Diagrams
Group
5/12/2015 4.5 AddedTestPlan,ComponentTesting,Integration
Testing,SystemTesting,andAcceptance Testing
Group
5/12/2015 4.6 AddedImplementationPlanandTrainingPlan Alex
5/12/2015 5.0 Final Formatting Zach

39. 38
12.2 ReferenceMaterials
The belowchart containsthe namesof the documentsanddatabasesusedincreating this
project.
Reference DocumentName BriefDescription Location of Definitive
Source
ClientQuestionResponses Answerstoclientquestions. D2L ClientInfo
Guide Star ECCHA Financial informationfornon-profits www.guidestar.com
SystemService Request D2l Group Locker Group17
Milestone 1 Early versionof thisdocument D2l Group Locker Group17
SystemDescription Early additiontothisdocument D2l Group Locker Group17
Use Case for ProposedSystem Early versionof Use case section D2l Group Locker Group17
SpecifyRequirements Earlierversionof requirementssection D2l Group Locker Group17
Data flowdiagram Earlierversionof DFDsection D2l Group Locker Group17
Milestone 2Updates Combinationof multipleupdatesof
previousassignments
D2l Group Locker Group17
12.3 Glossary
The followingisatable fordefiningsome of the termswe use throughoutthe document.
Term Description
Actor A personor systemthatderivesbenefitfromandisexternal tothe system
Alphatesting Testingof systemat developersite using fictitious data
Attribute A characteristicof an entity
Beta testing Limitedaccesstestingusingreal usersandreal datain the environmentthe systemwill
be implemented
Board of
Directors
The executivesincharge of businessdecisionmakingforECCHA
BusinessRules
Statementsof the processesandpoliciesgoverningthe behaviorof the organization.
Althoughgenerallynotwrittendown,youmustidentifyandthendocumentthose
businessrulesthatdefine orconstrainthe relationshipsamongthe people,places,
thingsandeventsaboutwhichthe organizationismaintainingdata.
Common
Information
Specificinformationthatisreferencedmultiple times
Constraints Eventsand circumstancesthatmayrestrict,limit,orregulate aproject
ContextLevel
Diagram
An overall viewof the “informationsystem”under consideration,showingits
relationshipwithexternal entities
D2L Desire toLearn website forclassandfile hostingforstudents/facultybeingusedbythe
Universityof Wisconsin-EauClaire.
Data Flow
Diagram
A picture of the movementof databetween external entities,the processes,andthe
data storeswithinasystem
Data store
A data repository—eitherpermanentfortemporary—fordatatransformedby
processes.Datastorescan be filesorfull database systems.
Database An organizedsetof informationthatisstoredina computerandaccessible inmultiple
ways

40. 39
Dependent
Entity
An entitywhose existenceisdependentuponanotherentitybecause all orpartof its
primarykeycomprisesaforeignkeyfromanotherentity.Alsoknownasa weakor
identifyingrelationship.
Directand
indirectrisks
(relatedto
systemdesign)
An ongoingorupcomingconcernthat hasa significantprobabilityof adverselyaffecting
the successof majormilestones.
Direct
Installation
An approachto installingnew software where youchange overfromthe oldinformation
systemtoa newone byturningoff the oldsystemwhenthe new one isturnedon.
Director A salariedemployeewhoworksfull timeatThe CommunityTable whodirectsbusiness
on-site andinteracts withthe guests
Donor SuppliesfundsforECCHA operations
ECCHA Eau Claire CountyHumane Society
Entity A person,place,object,eventorconceptinthe userenvironmentaboutwhichthe
organizationwishestomaintaindata
Entity
Relationship
Diagram
A model thatcapturesthe overall structure of organizational data
ForeignKey A fieldinone table thatuniquelyidentifiesarow of anothertable
Functional
Requirements
A statementof whatthe usermustbe able to doand what the systemmustdoto
supportwhatthe usermustbe able todo
GB Gigabyte,ameasure of space ona computerharddrive
Ghz The unitof ratingfor a computerprocessorreferringtothe speedwhichthatcomputer
can complete processesinagivenunitof time.
Graphical User
Interface (GUI)
An illustrationof howapersoninteractswitha computer-basedsystemthrough
graphical iconsand visual indicators(e.g.,contrast,repetition,alignmentandproximity).
Hard drive Internal componentof the computerwhere dataisstored
Information
System
A systemcomposedof peopleandcomputersthatprocessesorinterpretsinformation
InstallationPlan
A planfor installingsoftware atusersites,includingpreparations,usertraining,and
conversionfromexistingsystems.
Integration
Testing
The processof bringingtogetherall of the modulesthataprogram comprisesfortesting
purposes. Modulesare typicallyintegratedinatop-down,incremental fashion.
Level 0 Diagram Representsasystem’smajorprocesses,dataflows, anddatastores
Level 1 Diagram The major processesof a systemare brokendownintolevels,witheachlevel showing
the depthof the system
LFS Lost and Found System
Manager Salariedemployeethatoverseesregularoperations
MicrosoftOffice
2010
Commonprocessingsuite thatcontainsproductssuchas Word,Excel,etc.
MoSCoW Technique usedtocategorize requirementsof asystem(Must,Should,Could,Won’t)
Nonfunctional
Requirements
Specificationsof howwell asoftware systemmustfunction
Operation
(Nonfunctional
Requirements)
Non-functional requirementsfocusedonhow well asystemperformsfordailyuse.

41. 40
PetPoint 3rd
party online database containinglostandfoundinformation
PrimaryKey Unique identifierforarecord withinanentity
RAM RandomAccessMemory,the abilityfora computerto handle multiple tasksatonce
Stakeholder Personwithinterestintothe operationsof ECCHA
System Technologyandprocessesworkingtogethertoachieve tasks
SystemTesting
The bringingtogetherof all the programsthat a systemcomprisesfortestingpurposes.
Programsare typicallyintegratedinatop-down,incrementalfashion.
TestCase A setof conditionsunderwhichatesterwill determinewhetheranapplication,software
systemor one of its featuresisworkingasit wasoriginallydesigned
Testing
An iterative processof examiningthe softwarewiththe purpose of confirmingthatthe
systemsatisfiesrequirements.
Transition
(Nonfunctional
Requirements)
Non-functional requirementsfocusedon how easyitis to adaptto changesin the
technical environment.
Use Case
Relationships
Graphical depictionof connectionbetweenuse-case diagramelements.
Use-Case
Specification
Textual arequirementsdocumentationthatdescribe the step-by-stepprocessauser
goesthroughto achieve aspecificgoal usingasoftware system.Use case specifications
alsodescribe the alternativepaths:a) all the possible waysthe userausercan take to
achievingagoal and b) all the possible thingsthatcan go wrongalongthe way that
preventthe userfromachievingthe goal.
User Anypersoninteractingwiththe system
User Interface The meansby whichthe userand a computersysteminteractorwhat the userseeson
the screen
Weighted
DecisionTable
A table usedtoanalyze alternativeoptionsbyassigningweightsandvaluestodifferent
characteristicsof eachoption.
Windows7 Microsoftoperatingsystem