CxC Studio 151 Inventory System

Transcription

1 CxC Studio 151 Inventory System Team 2 Richard Clark, Lindsay Haley, Jordan James, & Benjamin McCoy Phases 1 & 2 ISDS 4125 October 6, 2014 Page 1

2 Table of Contents Executive Summary... 3 Requirements Analysis... 4 Problem Opportunity Statement... 4 Project Scope/Objectives... 4 System Description... 5 Current System... 5 Requirements Definition... 6 Functional Requirements... 6 Nonfunctional Requirements... 6 Project Initialization... 7 Alternatives... 7 Feasibility Study... 8 Risk Assessment... 9 Use Cases...10 Actor Glossary...10 Use Case Diagram...10 Use Case Narratives...11 Process Models...17 Data Flow Diagram...17 Data Diagrams...19 Entity Relationship Diagram...19 CRUD Matrix...20 Page 2

3 Executive Summary The current database for the LSU CxC Studio is functional but inefficient. The database lacks any clear direction in how to use it and is missing several helpful features. As of now, tracking checkouts is limited to kits but not the individual parts. Also, the layout makes it difficult to use. Our project will streamline the user interface so it is no longer hard to find the forms and reports that the user is searching for. We will also be adding features that allow the individual parts of a kit to be tracked, which worker is checking out the items, improving the search function, and adding permissions for student workers and admins. Page 3

4 Requirements Analysis Problem Opportunity Statement The current CxC Studio 151 database does not adequately track transactions. Currently, the system doesn t record the employer in the check out or any of the individual parts being checked out. The UI is also poorly designed and difficult to use. Project Scope/Objectives Project Objectives Create a program that helps keep track of equipment inventory. Project Description A web-based program will be created that allows the CxC Studio 151 employees to keep track of inventory and the customer that are using their equipment in a more efficient manner than the current system. Business Benefits Improved system for data entry and extraction Monitoring of all items being checked out Increased accountability for worker handling check out Delivered Capabilities Worker log-in Convenient inventory reports Updated check-in/check-out forms Non-Delivered Capabilities 24/7 Support Desktop Support Estimated Project Duration 3.5 Months Page 4

5 System Description Current System The current system is a program called JARVIS. It is used to track what items are checked out of the CxC Studio and by who. The system can produce lists of what is currently checked out, what is overdue, customer and item checkout histories, customer contact info, and also has the ability to add/delete customers and items. JARVIS cannot automatically send out notification s, checkout individual parts, view what employee handled the checkout process, or differentiate between a student employee and an administrator. The current system also has poorly designed UI and a useless search function. JARVIS is a barebones system that is functional but does not track as much data as the CxC Studio needs. Page 5

6 Requirements Definition Functional Requirements 1. Search and Browse 1. The system will allow users to search items by kit name, kit type & accessories 2. The system will allow users to search for customers 3. For customer contact information pages, the system will display customer info, borrow history, and the borrowing status of customer 2. Check In and Check Out 1. The system will track all transactions made in studio 2. The system will allow user to view lists of all items available, checked out, & extra inventory 3. The system will allow for customers to renew check outs on kits 4. The system will allow user to see who checked out an individual item/kit & also what worker completed the transaction 5. At check in, the system will prompt the user if there are missing or broken components in the kit being returned 3. Forms and Reports 1. The system will have forms for entering new customers 2. The system will have forms for entering new inventory information 3. The system will compile information on customers courses for data analysis purposes 4. Notification s 1. The system will send out reminder s when item/kit is almost due 2. The system will send out legal notices via 3. The system will send out reminder s when kit is late and the cost of the items checked out Nonfunctional Requirements 1. Operational 1. The system should be able to work on any Web browser 2. The system should be able to update the inventory 2. Security 1. There should be separate administrator and student worker logins 2. There needs to be a password to access database Page 6

7 1. Update the existing program Project Initialization Alternatives The current system can be modified to remove unnecessary buttons or functions on the forms. The current layout for Contacts page includes buttons and tabs that aren t in use or have the programming or information to back them. The system also does not have a way to track which worker completed each check-out transaction. By adding an additional field or a specific log-in to the program, we can add this information to each transaction. 2. Create a new program using Microsoft Visual Studio Creating a new user interface from scratch will allow us to create more precise web forms as well as allow us to recreate their database to better suit their needs. We will also create a better way to pull necessary information regarding user data as well as a summary of which kits or parts are currently checked out. Page 7

8 Feasibility Study Feasibility Type Microsoft Access Microsoft Visual Studio SQL Server 2012 Technical Team has experience with this software through prior classes and projects. Team has experience with this software through prior classes and projects. Team lacks experience with this software. Operational May have compatibility issues with Mac May have compatibility issues with Mac May have compatibility issues with Mac Schedule Project expected to be completed in time. Project expected to be completed in time. Learning the program will take more time than project duration will allow. Legal/Contractual LSU provides the software license LSU provides the software license LSU provides the software license Economic Page 8

9 Risk Assessment Risk: Team member drops the course Likelihood of Risk: Low - 5% Impact: A member dropping the course would give a heavier workload to the other members and slow down progress. Should the risk occur: Split the workload between the remaining members. Risk: Incorrect Database Likelihood of Risk: Moderate - 60% Impact: Issues with incorrect data connections within the database. Should the risk occur: Test with sample data and make necessary modifications. Risk: Non-Mac compatible Likelihood of Risk: Moderate - 60% Impact: The system not being Mac compatible would render it useless to the CxC studio since they predominantly use Mac computers. Should the risk occur: Modify the program to be compatible with all types of computers. Risk: Projects from other classes interfere with work schedule. Likelihood of Risk: High - 70% Impact: A high workload from other classes could slow down performance and put the 4125 work schedule off track. Should the risk occur: Reschedule group meetings to fit everyone s schedule in order to avoid time conflicts Page 9

10 Use Cases Actor Glossary Term: Description: 1. Worker The student worker or other user of the system. 2. Admin Administrator of the system, the supervisor or manager of student workers. 3. Customer Students or Instructors who wish to borrow inventory. Use Case Diagram Inventory System Access the System Check Out Check In Worker Add New Inventory Admin Add a New Customer Delete a Customer Page 10

11 Use Case Narratives Use Case Name Primary Business Actor Other Participating Actors Description Pre-Condition Trigger Access the System Worker or Admin The student worker logs into the system using the form presented after application startup. The login form is displayed when user opens the application. The worker opens the application. Typical Course of Events Actor Action System Response Step 1: User enters account name and password. Step 3: User clicks the login button. Step 2: The system verifies if the information is correct. Step 4: The system displays the application s main form. Alternate Courses Conclusion Post-Condition Business Rules Implementation Constraints and Specifications Assumptions Open Issues Corresponding Forms and Reports If the user information is incorrect, the system displays an error message. The system brings the user to the main form of the application. The user can access the system. The user must already be in the system. Worker has an account and access to use this program. Main form Page 11

12 Use Case Name Primary Business Actor Other Participating Actors Description Pre-Condition Trigger Check Out a Kit Worker or Admin Customer Worker checks out item with the Customer s information. Customer must already be in the system. Pressing the check-out button. Typical Course of Events Actor Action System Response Step 1: Worker presses the Check-Out button. Step 3: Worker selects which item to Check-out. Step 5: Worker selects which Customer is checking the item out. Step 7: Worker presses the confirm button. Step 2: Systems takes user to Check- Out Screen. Step 4: System verifies the item is available. Step 6: The system displays confirmation window. Step 8: Systems records worker s name and what the customer is checking-out. The system checks-out item in the customer s name. Alternate Courses Conclusion Post-Condition Business Rules Implementation Constraints and Specifications Assumptions The system changes the availability of the item and records the customer that checked the item out. The system marks the kit as unavailable in the database. The kit is marked as available for check-out in the database prior to check out. The kit exists in the database. Open Issues Corresponding Forms and Reports Check out form Page 12

13 Use Case Name Primary Business Actor Other Participating Actors Description Pre-Condition Trigger Check In a Kit Worker or Admin Customer Worker checks in item upon return of a kit. Customer must already be in the system and have a kit checked out. Pressing the check in button. Typical Course of Events Alternate Courses Actor Action Step 1: Worker presses the Check- In button. Step 3: Worker selects which item to Check-in. Step 5: Worker selects which worker is checking-in the returned item and if there are any problems with the item. Worker presses save button. Step 7: Worker clicks the confirm button. System Response Step 2: Systems takes user to Check- In Screen. Step 4: System verifies the item is marked as unavailable. Step 6: The system displays a confirmation message. Step 8: Systems records which worker is checking-in the returned item and there are any problems with the returned item. The system checks-in the item. Conclusion Post-Condition Business Rules Implementation Constraints and Specifications Assumptions Open Issues Corresponding Forms and Reports The system changes the availability of the item and records the worker that checked the item in. The system marks the kit as available in the database. The kit is marked as unavailable for check out prior to check in. The kit exists in the database. Check in form Page 13

14 Use Case Name Primary Business Actor Other Participating Actors Description Pre-Condition Trigger Add New Inventory Admin Admin can enter in information about newly acquired inventory Inventory items don t already exist in database Clicking add new inventory button Typical Course of Events Actor Action System Response Step 1: Admin clicks add new inventory button. Step 3: Admin fills in the form and clicks save button. Step 2: System displays add new inventory form. Step 4: System adds new item to the database. Alternate Courses Conclusion Post-Condition Business Rules Implementation Constraints and Specifications Assumptions Open Issues Corresponding Forms and Reports New items are added into database. The system adds the new item to the database. Kit name does not exist prior to adding new items. Kit name does not already exist in database. Add new inventory form Page 14

15 Use Case Name Primary Business Actor Other Participating Actors Description Pre-Condition Trigger Add New Customer Worker or Admin Customer If a customer is not already in the system, the worker will fill out a form to add them. Customer must not be in database prior to entry Clicking add new customer button Typical Course of Events Actor Action System Response Step 1: Worker clicks add new customer button. Step 3: Worker fills in new customer form and clicks save button. Step 2: System loads new customer form. Step 4: System stores information from form into database. Alternate Courses Conclusion Post-Condition Business Rules Implementation Constraints and Specifications Assumptions Open Issues Corresponding Forms and Reports System creates a profile of the new customer in the database. New customer information is stored in the database. To avoid duplicate entries, customer must not already exist in system. Add new customer form Page 15

16 Use Case Name Primary Business Actor Other Participating Actors Description Pre-Condition Trigger Delete a Customer Admin If there is no longer a need to keep a record of a customer, the Admin can delete them. Customer must already exist in database Clicking delete customer from individual customer s profile page. Typical Course of Events Actor Action System Response Step 1: Admin searches for a particular customer. Step 3: Admin selects delete customer button. Step 5: Admin confirms record deletion. Step 2: System displays customer s profile. Step 4: System displays confirmation window. Step 6: System removes customer s profile information from the database. Alternate Courses Conclusion Post-Condition Business Rules Implementation Constraints and Specifications Assumptions Open Issues Corresponding Forms and Reports Do not delete customer profile. System deletes the profile of selected customer from the database. Customer profile information is removed from the database. Customer profile must exist in the system prior to deletion. Customer contact information page Page 16

17 Process Models Data Flow Diagrams Context Level Level 0 Page 17

18 Level 1 Page 18

19 Data Diagrams Entity Relationship Diagram Page 19

20 CRUD Matrix Activity Entity Name ID Item Check Out RU RU RU Check In RU RU RU Renew U U U Add New Customer C C Delete Customer D D Add Inventory C Reminder U U U Late Notice RU RU RU Search R R R Page 20