916 Medical Skin Studio

Project Proposal

Kyle Sunde
Ryan Such
Matt Edwards

Will Weyrich

Houa Lee

October 2, 2008

Table of Contents

Problem Statement…………………………………………………….2-3

Entity Relationship Diagram…………………………………………3

Entities………………………………………………………………....4-5

Use Case Diagram………………………………………………….....6

Use Case Descriptions…………………………………………………7-10

I. Problem Statement/Requirements Definition:

916 Medical Skin Studio is a local medical spa owned by Tatja Renee. They are an exclusive medical spa that offers a high standard of professionalism and exceptional one on one customer care in a comfortable, relaxed setting. Tatja needs a website that is aesthetically appealing to advertise her business. She also needs a database to process client transactions and maintain client history in a quick and efficient manner. When clients are paying or their services or scheduling an appointment, she wants them to be able to navigate a clean and organized interface. Client transactions should be quick and easy to process.

Our project consists of building a website and a database for Tatja to use for easy access to what she needs to manage her business. It will store patient records, be able to manage appointments, and allow her patients remote functionality over the Internet such as requesting appointments and viewing available products and services. The website will advertise products and services that the spa offers to her clients, as well as manage and store client information and visit history.

2. Entity Relationship Diagram

I. Use Cases

The following are the use cases for the spas database and website that are being implemented:

Use case descriptions:

Use Case:	Add/Edit Client Info
Actor(s)	Administrator, Employee, Client
Description:	The administrators and clients will be able to add and edit client info such as names, addresses, phone numbers, contact information, etc. The employees can only add client information but will not be able to edit it other than adding comments. This allows storage and collection of data that will help the employees provide a better more personal experience for the client. Since the information with the client is important and subject to change, it may not be sufficient to have only the owner in charge of keeping it up to date.

Use Case:	View Client Info
Actor(s)	Administrator, Employee, Client
Description:	Administrators, employees, and clients are all able to view client information.

Use Case:	Add/Edit Referrals
Actor(s)	Administrator, Employee, Client
Description:	The client can specify who referred them to the spa. Administrators and employees can also add a referral if the client doesn’t specify a referral themselves but was referred to the spa by another customer. Referrals will be stored in each client’s information.

Use Case:	View Referrals
Actor(s)	Administrator, Employee, Client
Description:	Administrators and employees can view any client’s referrals. A client can only view their own referrals.

Use Case:	Add/Edit Appointments
Actor(s)	Administrator, Employee, Client
Description:	Administrators and employees can schedule appointments directly and have them saved to the calendar. Clients will be able to request certain appointment times but are unable to directly add an appointment without employee/administrator approval. Appointments are not guaranteed until an employee or administrator contacts the client. The appointment will then be inserted into the appointment table. The administrator and employee can both cancel any appointment. The client can request to cancel their own appointments.

Use Case:	View Appointments
Actor(s)	Administrator, Employee, Client
Description:	Administrators and employees will be able to view any appointments in a given time frame in calendar format. Hours that are available on a requested date will be shown to the client along with their already scheduled appointments.

Use Case:	Add/Edit Tickets
Actor(s)	Administrator, Employee
Description:	An administrator or employee will add or change tickets. Tickets will include the total cost of the treatment and products, the tax, the tip, ticket number, date and patient ID. Tickets will also note payment type including cash, credit, gift certificate, etc.

Use Case:	View Tickets
Actor(s)	Administrator, Employee, Client
Description:	An administrator or employee can view any client’s tickets. A client can only view their own tickets.

Use Case:	Add/Process Gift Certificate
Actor(s)	Administrator, Employee
Description:	An administrator or employee can add a gift certificate. They can create a gift certificate by designating the amount or service(s) and confirming payment for the gift certificate. Gift certificates will be given an ID number, a value or service(s), and will indicate who they are for and from. Once a gift certificate is processed, the ID will become void in the system. A client’s ticket will indicate what gift certificate was used on it.

Use Case:	Add/Edit Services/Products
Actor(s)	Administrator
Description:	If new services or products become available, only the administrator can add them. They are also capable of editing or removing current products or services. Each service or product will be noted by a corresponding ID number, price (retail and wholesale), and description.

Use Case:	View Services/Products
Actor(s)	Administrator, Employee, Client
Description:	Administrators and employees can view the service and product wholesale values. All of the service and product information such as the ID and description are available for view as well. The client will see a simplified version of the information with the description and retail value.

Use Case:	View Client Purchase History
Actor(s)	Administrator, Employee, Client
Description:	Report would be run for a specific client for a specified date range. Report would list invoice (ticket) & payment history for the client in chronological order. Tickets could be listed in detail (all line items showing) or summary (only ticket header (date/total/main reason)) formats. A running balance down the side would be calculated.

Use Case:	Generate Client Reminders
Actor(s)	Administrator, Employee, System
Description:	Report could be run to select Patients based up on Last Visit, specific services received, birthdays upcoming, missed appointments, etc. Output would be a comma delimited file OR formatted for mailing labels and include Patient Name, Patient Address, Patient Number.

Use Case:	Email Client Reminders
Actor(s)	Administrator, System
Description:	The system will automatically notify the client based on the e-mail reminders already generated. The administrator will also be able to e-mail the clients and their own discretion. The generated e-mails sent by the system could include scheduled appointments, birthday reminders, and other notifications.

Use Case:	Generate Deposit Slip
Actor(s)	Administrator, Employee, System
Description:	Run for a specific day (or register, if that feature is active). Deposit slip would list all individual check and bankcard transactions processed during that time. Patient Name, Patient Acct #, Card Type/Check # and amount. Report would be subtotaled by Checks and by Bank Cards. A Cash total would be included, though not broken out by transaction. This report is useful for finding errors when balancing the drawer.

Use Case:	Generate Appointment Report
Actor(s)	Administrator, Employee, System
Description:	Report could be run for one or more days. Report could be run for one or more employees. Output would be list of appointments during specified time period booked for specified employee. Data would include Patient Name, Patient Acct #, reason for visit (service booked), time allotted, and patient phone number. Appointments could be filtered by Closed/Missed status.

Use Case:	Generate Inventory Report
Actor(s)	Administrator, Employee, System
Description:	Report would be run off of “In Stock” quantity for products and could be run for those below a certain value on hand. Data would include Product Code, Product Name, Quantity on Hand, Date Last Sold.

Use Case:	Generate Register Transaction Report
Actor(s)	Administrator, Employee, System
Description:	Run for a specific day (or register, if that feature is active). Register transaction would list date, Ticket #, Patient, ticket total, payment amount, payment type, card type/check #, and transaction total (ticket amount – total amount). Report would need to handle multiple payments on a single Ticket, also multiple tickets per payment.

Use Case:	Generate Employee Production Report
Actor(s)	Administrator, Employee, System
Description:	An administrator or the system can create production reports for any given employee. An employee can generate production reports only for themselves. They will be able to specify the date range (day, week, month, etc.) and it will include items credited to that employee during that time period and payroll information.

Use Case:	Generate Company Production Report
Actor(s)	Administrator, System
Description:	An administrator or the system will be able to specify date range (to run for day, week month, etc.), and employees, either singly or in combination, or for the company as a whole to run a report for line items credited to that employee(s) during the specified time period along with payroll information. If run for specific employees, will be subtotaled by employee.