Evidence Inventory

Evidence Inventory Tracking System Design Report

Dec05-06

Client: Boone Police Department

Faculty Advisor: Dr. Thomas Daniels

Team Members: Eric Hand Daniel Pruckler Thomas Brezinski Vignesh Vijayakumar

April 27, 2005

Disclaimer: This document was developed as a part of the requirements of a computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student- prepared document that is required to be under the responsible charge of a licensed engineer. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator. Some parts may also be copyrighted by the City of Boone Police Department.

ii Table of Contents 1. Introductory Material...... 1 1.1. Executive Summary...... 1 1.2. Acknowledgement...... 1 1.3. Problem Statement and Solution...... 1 1.4. Operating Environment...... 2 1.5. Intended User(s) and Intended Use(s)...... 2 1.6. Assumptions and Limitations...... 3 1.7. Expected End Product and Other Deliverables...... 3 2. Approach Used...... 4 2.1. Design Objectives...... 4 2.2. Functional Requirements...... 4 2.3. Constraints Considerations...... 5 2.4. Technical Approach Considerations...... 6 2.5. Testing Requirements Considerations...... 6 2.6. Project Continuation...... 7 3. Detailed Design...... 8 3.1. User Interface Design...... 8 3.2. Database Design...... 26 4. Resource Requirements...... 27 4.1. Personal Effort Requirements...... 27 4.2. Financial Requirements...... 29 4.3. Schedules...... 30 5. Closing Materials...... 35 5.1. Project Team Information...... 35 5.2. Closing Summary...... 36 5.3. References...... 36

i List of Figures Figure 3.1.1. System Flow Diagram...... 8 Figure 3.1.2. Login Page...... 9 Figure 3.1.3. Home Page...... 10 Figure 3.1.4. Search Database...... 11 Figure 3.1.5. Quick Item Custody Transfer...... 12 Figure 3.1.6. Add New Case...... 13 Figure 3.1.7. Edit Current Case...... 14 Figure 3.1.8. Add New Evidence / Property...... 15 Figure 3.1.9. Edit Evidence / Property...... 16 Figure 3.1.10. Add File To Case...... 17 Figure 3.1.11. Reports System...... 18 Figure 3.1.12. Chain of Custody Report...... 19 Figure 3.1.13. Inventory Report...... 20 Figure 3.1.14. Administration...... 21 Figure 3.1.15. Add Officer...... 22 Figure 3.1.16. Edit Officer...... 23 Figure 3.1.17. Backup Database...... 24 Figure 3.1.18. Restore Database...... 25 Figure 3.2.1. Database Design...... 26 Figure 5.1. Original Project Schedule...... 32 Figure 5.3. Deliverables Schedule...... 34

ii List of Tables Table 4.1.1. Original Estimated Personal Effort Hours...... 28 Table 4.1.2. Revised Estimated Personal Effort Hours...... 28 Table 4.2.1 Original Financial Budget...... 29 Table 4.2.2 Revised Financial Budget...... 30

iii List of Definitions

Term Description A list of where the select piece of evidence has gone and when, Chain of custody and who checked it out. The documentary or oral statements and the material objects Evidence admissible as testimony in a court of law. Megabyte: A unit of computer memory or data storage capacity MB equal to 1,048,576 (220) bytes. An object-oriented programming language developed by Sun Java Microsystems. Java supports programming for the Internet in the form of platform-independent Java applets. MySQL An open source database. Open source, server side, embedded scripting language used to PHP create dynamic Web pages. Graphical User Interface, A user interface based on graphics GUI instead of text; uses a mouse as well as a keyboard as an input device. Structured Query Language, a query language used in performing SQL operations on databases. HyperText Transfer Protocol, a medium for accessing web pages HTTP through a browser. GPL General public license.

iv 1. Introductory Material This section will define the problem, operating environment, intended users and uses, assumptions and limitations, and expected end product of the project.

1.1. Executive Summary Evidence can be the key in convicting someone of a crime, or of acquitting a person of charges brought against them. It is important that evidence is handled carefully and documented accordingly. This cataloging system will include additions, searching, reporting, and printing.

The police department will be able to search for evidence by many different constraints. This would be a very helpful tool for a diversity of applications, either for evidence or for writing a research document. This would help out the police department very much as it will help organize their data and reduce the clutter that paperwork causes.

1.2. Acknowledgement The team would like to acknowledge the Boone Police Department for committing significant time to revise the project specifications to their current needs.

1.3. Problem Statement and Solution The problem statement was provided by the client to the senior design team. The solution was created by the senior design team and approved by the client.

1.3.1. Problem Statement Evidence is crucial to court cases. It can contribute to the decision of whether a criminal goes to jail or goes free. Keeping track of the evidence can be a task though. Currently the chain of custody is stored on either the bag the evidence is stored in or a tag on the evidence. This system can create many problems. Should the tag on the evidence be lost it must be recreated from the memory of the officers. Also should an officer want to review the chain of custody or see where a piece of evidence is

1 currently located they must locate the information on the physical evidence.

1.3.2. Solution Approach The team will create a computer system which will replicate the information normally only stored on the evidence. Authorized officers will be able to view and update this information from any computer within the Boone Police Department.

1.4. Operating Environment The system will be restricted to the offices of the Boone Police Department. Restricting access to office computers only will be the responsibility of the computer consultant contracted by the Boone Police Department. Officers will be able to access the system from any computer system capable of running a modern web browser. A server will host the information for the client computers. The team recommends that with current software, a server system meeting at least the minimum specifications below should be utilized.

Recommended Server Specifications: Pentium Class 1.0 GHz Processor 256 Megabytes of RAM 40 Gigabytes of hard drive space

1.5. Intended User(s) and Intended Use(s) The system will be used exclusively by the Boone Police Department for evidence inventory and tracking purposes.

1.5.1. Intended User(s) The intended users for this application are strictly the officers of the Boone Police Department. Even then only specific groups of people will have specific capabilities as specified by different access levels. No one outside the department would be allowed to have access to the system. The system will be user-friendly and have a minimal learning curve.

2 1.5.2. Intended Use(s) This application will be used in the compiling, tracking and storage of evidence. It will create an object for each collected piece of evidence and store it in a database. It will allow for the search of the database using different search terms related to the evidence. Editing, updating, and fixing entries will be available options, although restricted to certain levels of users.

1.6. Assumptions and Limitations Taking into account the uses and users of the system the following assumptions and limitation of the system are listed below.

1.6.1. Assumptions  The user has basic knowledge of the Microsoft Windows computing environment.  The user has sufficient storage space to create a backup corresponding to the size of the database.  The user has hardware appropriate to run the system.  The user understands the English language fluently.  The user understands the current manual process used for evidence tracking.

1.6.2. Limitations  The system must be completed by December 2005.  The maximum response time per query must be less than ten seconds.  Server must have at least a 1.0 GHz Processor, 256 Megabytes of RAM and 40 gigabytes of storage space for application and data.

1.7. Expected End Product and Other Deliverables In this first semester the team has completed a number of deliverables. The project plan and design documents have been completed. Also several revisions of the prototype system screenshots have been delivered and reviewed by the client.

In the second semester the team will be delivering and assisting in instillation of the final product. The final product will meet the client’s

3 specifications which have been approved through the use of several detailed prototype screenshots. Also a detailed user manual will be delivered to the client for later reference.

A final report will also be created detailing the final specifications and functionality of the system. It will also review all the problems encountered in the implementation and their solutions. Also included will be an explanation of the system documentation that may be utilized to later expand the system.

2. Approach Used This section details the development approach and design of the end- product.

1.8. Design Objectives The end product shall be designed to provide:  User Interface The system will have an easy to use graphical interface accessible through a modern web browser.

 Security The system will provide user authentication to restrict the system and specific functions to authorized users.

 Chain of Custody The system will be able to provide a printable chain of custody report for any piece of evidence in the system.

 Inventory Reports The system will be able to create custom inventory reports showing what is currently in the evidence lockup.

 Ease of Use Simplicity of the system is a major concern of the client. The system must be easy to use with little to no learning curve.

1.9. Functional Requirements The end product shall meet the following requirements:

4  Database With 4-level Access Restriction A database will be created to store the system information. There will be four different access levels to the system. An “Administrator” will have full access to the system and all it’s functions. A “Standard” user will have access to all data entry and report screens but will not have access to the administration panel. A “Backup” user will only be able to access the database backup screen to create and download a compressed backup of the database. A “No-Access” user will be unable to login to the system but will be listed in dropdown menus of data entry screens. This is because while all officers will be collecting evidence only a select few will have access to add that evidence to the system.  Ability to Attach Files to a Case The system will allow files to be attached to a case and be stored in the database. The database will support any file type.  Searching the Database The user will be able to search the database for records based on multiple different fields.  Limited Deletion For security reasons only files attached to cases may be removed. This is to facilitate file updates. Also the database size could be reduced by removing older unneeded attached files. All other information such as cases and evidence can not be removed.  Easy Backup The system will provide a simple interface for making regular backups of the database.

1.10. Constraints Considerations The constraints on the end-product are:

 Database Size Database size shall only be constrained by the amount of physical storage space available on the server. An initial database with no evidence entries will require less than one megabyte of storage space.  Computer Resource Usage Client computer will require only the resources required to run a modern web browser. Server computer will require adequate resources to run

5 the required database and web server software.  Technical Support Since no technical support will be available to the client after the projects is complete, adequate documentation and support resources will be made available to the client.  Budget Limitation The client will be expected to provide all computer hardware required to run the system.

1.11. Technical Approach Considerations The team considered using existing database solutions that can be bought commercially as well as creating the team’s own database system from scratch. An existing system would only require tweaking to the team’s specific application and building from scratch would take considerable research and programming hours. As such the team decided to use MySQL as the database system and PHP for the front-end solution as both are open-source and are easily modifiable. In addition both technologies have significant user bases around the globe which shows the maturities of the technologies. The web server will Apache as it is also open source and provides excellent integration of PHP and MySQL. The operating system will be Red Hat Linux. Linux usually provides a more stable system than Microsoft Windows and is a proven platform to integrate Apache, PHP, and MySQL on. While the Boone Police Department does not currently use Linux, their contracted computer consultant has agreed to support the platform.

1.12. Testing Requirements Considerations A detailed test plan shall be created when initial programming is near completion. This testing will include a through testing of all aspects of the system focusing on user input validation. Since the system is relatively simple and the programming team is significantly proficient in the language at project start, the team does not feel it necessary to test parts of the system before initial programming completion.

6 The system will be deployed for further testing by the Boone Police Department. During this testing phase the Boone Police Department will begin entering currently held evidence into the system. Newly collected evidence shall be entered into the system on a limited basis. Once stability and functionally of the system is fully confirmed it will immediately be available to the client for full use.

1.13. Project Continuation The team will be continuing the project as currently envisioned. Both the team and client are satisfied with the current design and as such the project will continue as currently scheduled.

7 3. Detailed Design This section describes in detail how the software is designed. The software will consist of two main components: the graphic user interface (GUI) and database. For each component, a detailed description and explanation will be provided and diagrams will be used for better understanding of the implementation of the component.

1.14. User Interface Design After several revisions these screenshots of the user interface have been approved by the Boone Police Department for use in the final design. However additional features or enhancements may be added later as desired by the client or required by the design.

1.14.1. System Overview This figure provides an overview of the system layout and flow.

Quick Search Reports Add Case Adminisration Transfer

Add/Edit System Inventory User Settings

Chain of Custody Edit Case

Add Evidence Edit Evidence Add File

Figure 3.1.1. System Flow Diagram

8 1.14.2. Login Page This will be the first screen seen by all officers. Officers may login to the system using their three digit ID number and password.

Figure 3.1.2. Login Page

9 1.14.3. Home Page This is a prototype of the main homepage for the system. From here the officer can choose what task they would like to do. The administration selection will be hidden from officers who do not have access to that section.

Figure 3.1.3. Home Page

10 1.14.4. Search Database From this form the officer can search the case and evidence inventory by many different criteria. When search by “Date of Recovery” is selected the criteria section will change to the second one shown. When “Recovered By” is selected the criteria will change to a dropdown box as shown in the third one.

Figure 3.1.4. Search Database

11 1.14.5. Quick Item Custody Transfer This page will be most useful if the officer has the physical evidence tag with them. If the case number and item number are known, a custody transfer can be quickly recorded with this screen. The date and time will be automatically populated with the current date and time.

Figure 3.1.5. Quick Item Custody Transfer

12 1.14.6. Add New Case From here the officer can add a new case to the system. The agency field will default to “Boone Police Department” but will be editable. After this screen the edit case screen will be displayed so that evidence and files can be added to the case.

Figure 3.1.6. Add New Case

13 1.14.7. Edit Current Case This page is the main interface for a case. All items will be populated with the information currently in the database. It allows changes to all the items specified when the case was added. It also provides a listing of evidence and files attached to the case. The evidence list will display the date the item was recovered and the file list will display the date the file was posted. The description fields will be truncated to fit on one line in the space allowed. By clicking on a piece of evidence the user can bring up the screen to edit the evidence entry.

Figure 3.1.7. Edit Current Case

14 1.14.8. Add New Evidence / Property From this screen the officer can add a new piece of evidence to a case. The “Item No” will automatically populate with the next available item number. The date and time will auto populate with the current date and time. The dropdown box for “Recovered By” is populated with a list of officers provided in the administration site. Evidence types may be edited in the administration site.

Figure 3.1.8. Add New Evidence / Property

15 1.14.9. Edit Evidence / Property After evidence has been entered the officer can edit it via this screen. Unlike the add evidence screen this one will allow the addition of a chain of custody entry and disposition. Date and time fields on the change custody and disposition will automatically populate with the current date and time. To see reasons for transfers the officer will need to create a chain of custody report by clicking the “Create Report” button.

Figure 3.1.9. Edit Evidence / Property

16 1.14.10. Add File to Case Using this screen the officer can add a file to a case. Simply click the browse button and select your file, enter a description, and click submit.

Figure 3.1.10. Add File To Case

17 1.14.11. Reports System Using this screen an officer can generate a chain of custody or inventory report. For the chain of custody report both fields are required. For the inventory report the officer may enter any combination of the criteria options, however at least one will be required.

Figure 3.1.11. Reports System

18 1.14.12. Chain of Custody Report This is the printable chain of custody report which can be generated for an item. It contains all the information located on the “Evidence / Property tag.” The disposition will be displayed if it exists.

Figure 3.1.12. Chain of Custody Report

19 1.14.13.Inventory Report This screen will give a printable inventory report based on the criteria specified. The report may be resorted by clicking on any of the headers in the table.

Figure 3.1.13. Inventory Report

20 1.14.14. Administration This is the system administration menu that will be available to administrators. From here the officer will be able to add or edit officers in the system and change system settings. Also the database can be backed up or restored.

Figure 3.1.14. Administration

21 1.14.15.Add Officer From this screen an officer may be added to the system. The ID No. field will be the department assigned three digit ID number. There will be four access levels which are:

 Administrator – Full access officer who has access to all administration options and system content.  Standard – Access to all system content and no access to any administration options.  Backup Only – Officer will be sent directly to the backup database screen and will only have access to that screen. This way a secretary or other designated person can handle backups on a regular basis.  No Access – Officer will not be able to login to the system. However they will be listed in all officer list dropdowns such as the ones on the case and evidence screens. For this access level a password does not need to be specified.

Figure 3.1.15. Add Officer

22 1.14.16.Edit Officer From this screen an officer in the system may be edited. All fields will have the same specifications as the Add Officer screen. Officers may not be deleted from the system but may be changed to “No Access”. Since officers will have records associated with them, deleting an officer would cause problems.

Figure 3.1.16. Edit Officer

23 1.14.17.Backup Database From this screen an officer may create a backup of the database which will then be downloaded to the officer’s computer for later storage on an external media such as a CD-Recordable disc.

Figure 3.1.17. Backup Database

24 1.14.18.Restore Database From this screen an officer administrator may restore the database from a backup file. This process will clear all data currently stored in the database. This function is provided so that if the system must be moved to a different server the data can easily be restored to the new server.

Figure 3.1.18. Restore Database

25 1.15. Database Design The main entity of the database will be the “Case”. It will rely on the “Items” table, which will store all the evidence/property information, and the “CaseFiles” which will store the files attached to the case. The items table will rely on four other tables. The “Users” table will store the information about all the officers registered in the system. The “ChainOfCustody” table will store all the changes of custody for the evidence/property. The “EvidenceType” table will store the types that can be applied to the evidence/property such as alcohol or weapon. Last is the “Disposition” table which will store the disposition record after the evidence has been removed from inventory.

Users ChainOfCustody

PK,FK1 _id PK,FK1 _id

username itemid officerid date password from firstname to lastname reason active admin write read Items EvidenceType PK,FK1 _id PK,FK1 _id

Case caseid name itemnum active PK _id description date casenum evidtype agency officerid Disposition offense location PK,FK1 _id suspect stored victum picture itemid comments comments result date CaseFiles

PK,FK1 _id

caseid name data comments Figure 3.2.1. Database Design

26 4. Resource Requirements This section shows the original and current estimates for the resources needed to complete the project.

1.16. Personal Effort Requirements This section shows the original personnel effort estimation and revised personnel effort after taking into account completed tasks and modified estimations. The tasks referred in the tables below correspond to the tasks listed below:

Task 1: Problem Definition Subtask 1a: Identify End Users and End Uses Subtask 1b: Identify Project Constraints and Limitations

Task 2: Technology Considerations and Selection Subtask 2a: Research existing systems Subtask 2b: Research Existing Programming and Database Management

Task 3: End-Product Design Subtask 3a: Automate Input Entry Procedure for Client Subtask 3b: Break down project to facilitate implementation

Task 4: Prototype Implementation Subtask 4a: Work delegation Subtask 4b: Code documentation

Task 5: End-Product Testing Subtask 5a: Individual Component Testing Subtask 5b: Component Integration and Testing Subtask 5c: Whole System Testing

Task 6: End-Product Documentation Subtask 6a: Develop User’s Manual Subtask 6b: Develop Instillation / Maintenance Manual

27 Task 7: End-Product Demonstration Subtask 7a: Demonstration Planning Subtask 7b: Faculty Advisor Presentation Subtask 7c: Industrial Review Panel Presentation

Task 8: Project Reporting Subtask 8a: Weekly E-mails of Project Status Subtask 8b: Project Plan Subtask 8c: Project Poster Subtask 8d: Design Report Subtask 8e: Final Report

These tasks were obtained from the project plan, more detailed information on these tasks may be found in the project plan.

Table 4.1.1 shows the original personnel effort estimation while Table 4.1.2 shows the revised personnel effort after taking into account completed tasks and modified estimations based on change of project scope.

Table 4.1.1. Original Estimated Personal Effort Hours

Names Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Totals Thomas 6 7 25 55 30 10 8 21 162 Eric 4 5 25 50 30 10 7 23 154 Vignesh 3 4 19 65 32 13 3 15 154 Daniel 2 4 21 60 33 12 4 14 150 Totals 15 20 90 230 125 45 22 73 620

Table 4.1.2. Revised Estimated Personal Effort Hours

Names Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Totals Thomas 6 7 15 15 10 10 8 30 101 Eric 4 5 11 5 30 10 9 25 99 Vignesh 3 4 10 50 5 13 3 7 95 Daniel 2 4 8 40 5 19 4 8 90 Totals 15 20 44 110 50 52 24 70 385

28 Changes: Task 3 – 46 hours were removed to match actual time spent and account for changes in the project scope.

Task 4 – 120 hours were removed to account for the simpler system design desired by the client. Also since the bulk of the programming will be completed by Vignesh and Daniel, the hours for Thomas and Eric have been reduced.

Tasks 5, 6, and 7 – 66 hours were removed to account for the reduced project scope.

Task 8 – 3 hours were removed and work was redistributed to mainly Thomas and Eric since Vignesh and Daniel will be completing the bulk of the system programming.

1.17. Financial Requirements Table 4.2.1 shows the original financial budget estimation while Table 4.2.2 shows the revised financial budget after taking into account completed tasks and modified estimations based on change of project scope.

Table 4.2.1 Original Financial Budget

Item Without Labor With Labor Materials: Signature Pad (purchased previously) (purchased previously) Barcode Scanner $200.00 $200.00 Poster $50.00 $50.00 Subtotal $250.00 $250.00 Labor at $10.50 per hour: Thomas Brezinski $1,701.00 Eric Hand $1,617.00 Vignesh Vijayakumar $1,617.00 Daniel Pruckler $1,575.00 Subtotal $6,510.00 Total $250 $6,760.00

29 Table 4.2.2 Revised Financial Budget

Item Without Labor With Labor Materials: Poster Board $9.00 $9.00 Misc Printing Costs $40.00 $40.00 Subtotal $49.00 $49.00 Labor at $10.50 per hour: Thomas Brezinski $1,060.50 Eric Hand $1,039.50 Vignesh Vijayakumar $997.50 Daniel Pruckler $945.00 Subtotal $4,042.50 Total $49.00 $4,091.50

Changes: Materials – signature pad and barcode scanner were removed since they will no longer be components of the implementation. Poster cost was replaced with the cost of the poster mounting board since the department printed the poster. Miscellaneous printing costs were added to account for printing of deliverables and other documents.

Labor – The total cost of labor was reduced 38% due to the changes in labor requirements due to the change in scope.

1.18. Schedules The following schedules have been coordinated with the client to produce a successful project within the allocated time table.

1.18.1. Project Schedule The client would like to have the system deployed in the early fall. Also the programming team has decided to push back code completion to midsummer so they may concentrate on finals. The team will complete their part of the testing by early fall when the system will be deployed and

30 final testing will be done by the Boone Police Department.

The deliverables schedule has not changed.

31 Figure 5.1. Original Project Schedule

32 Figure 5.2. Revised Project Schedule

33 Figure 5.3. Course Deliverables Schedule

34 5. Closing Materials Concluding this document is the project team information, closing summary, and reference materials.

1.19. Project Team Information The following is a list of people involved in the project along with their contact information. Student Team Members: Advisor:

Eric Hand (CprE) Dr. Tom Daniels 200 Stanton Apt 205 3222 Coover Hall Ames, IA 50014 Ames, IA 50011 (515) 291-1214 (515) 294-8375 [email protected] [email protected]

Thomas Brezinski (CprE) 6115 Frederiksen Ct Client: Ames, IA 50010 (515) 441-1941 Boone Police Department [email protected] Chief William Skare (515) 432-3456 Vignesh Vijayakumar (CprE) (515) 432-1564 fax 907 B North Dakota Ave Ames, IA 50014 (515) 708-1238 [email protected]

Daniel Pruckler (CprE) 609 Meadow Place Ames, IA 50011 (515) 290-4148 [email protected]

35 1.20. Closing Summary This system will provide the Boone Police Department with a better way of tracking evidence. Currently the evidence process is very inefficient. By using this system the Boone Police Department will be able to streamline their evidence inventory management process which will allow them more time to protect and serve the City of Boone.

1.21. References The following are the websites for the software being used for the system: Apache – www.apache.org MySQL – www.mysql.com RedHat Linux – www.redhat.com PHP – www.php.net