Navivo Front-End Gym Membership System

Group 3 Jared Dobbelaer Celso Garcia Jade Itoua Youngsu Han

Table of Contents
Title Page Table of Contents .. Executive Summary . Problem Statement .. Project Plan . Requirements Structural Modeling . Behavior Models . Dynamic Models Design Documents Testing Project Management Documents 1 2 3 4 5, 6 6, 7 8 7, 8 9 10-18 19, 20 20-21

Executive Summary: With our original idea being shut down due to time and cost constraints, we have come up with another solution by creating a front-end web application to help our gyms advertise appropriately. This applications main purpose is to provide critical user information to managers to both gain more members, and keep customer loyalty high. The main benefit of this system is that it is unique in the marketplace. By partnering with Salesforce, the system will roll out quickly, and can begin to pay for itself within the first year.

Cost Savings: Since Navivo is a partner of Salesforce, our team will be able to create this application for just short of five-thousand dollars. The team will consist of three developers and a project manager. The time estimated to complete this project is six months.

Project Phase Time: The planning phase of the project will be started within the week, and last a total of one month. Analysis of the system and what it produces for the company is estimated to last one month. After the systems core elements are inspected the team will begin the design phase of the plan, which is planned to take two months. Once the design phase has met the requirements of the management team and developers, the team will implement the system. The rollout will take about two months to complete, allowing for final debugging.

Systems Proposal: Navivo Gym Management Front-End Application Problem Statement: - The current system in effect does not collect and store data to better benefit the customer. - Current process does not help gym managers find new prospects and keep loyalty of current customers. - There is no other application like this on the market, and the time until the product goes to market is short. Objectives: - Improve revenues by being able to advertise to customer needs. - Increase number of gym memberships. - Reduce costs by analyzing what the customer wants. - Provide Gym Managers a method to obtain information for their location. Scope: This system will address current problems within the infrastructure of the company. By constructing this application, we can cut costs within the company, allow current customers a reason to stay with our gyms, and offer new services for prospective customers. Constraints: - The cost of the new system will total around 5000 dollars + maintenance. - The time needed to create the new system will take 6 months. - Information gathering cannot take place until the system is completed.

Task 1.0 Planning 1.1 Group meeting for first time 1.2 Brainstorming 1.3 Deciding on system we should use 1.4 Writing Memo Rough Draft 1.5 Finalizing Memo 1.6 Turning in Memo 2.0 Analysis 2.1 Discuss Functional Requirements 2.2 Work on class diagram 2.2 Work on Process and Behavior Modeling 2.3 Work on Use case Diagrams 2.4 Interface Design 2.5 Work on Controls for system 2.6 Work on test cases 3.0 Analysis 3.1 Meeting to discuss MS3

Effort 7 days > 1 day > 1 day > 1 day > 1 day > 1 day > 1 day 7 days > 1 day 1 day 2 days

Estimated Start Date 1-21-14 1-21-14 1-23-14 1-24-14 1-26-14 1-27-14 1-28-14 1-30-14 2-5-14 2-7-14

Estimated End Date 1-28-14 1-21-14 1-23-14 1-24-14 1-26-14 1-27-14 1-28-14 1-30-14 2-5-14 2-9-14

Assigned Resources Jared, Celso, Therese Jared, Celso, Therese Jared, Celso, Therese Jared, Celso, Therese Jared Jared, Celso, Therese Jared Jared, Celso, Therese Celso Jared

2 days > 1 day > 1 day 1 day 4 days >1 day

2-11-14 2-12-14 2-15-14 2-16-14 3-25-14 3-25-14

2-13-14 2-13-14 2-16-14 2-17-14 3-29-14 3-25-14

Celso Celso, Jared Jade, Celso, Jared Jade, Celso Jade, Celso, Jared

Task 3.2 Prepare functional and non functional requirements 3.3 Create use case diagrams and descriptions 3.4 Create Class diagram 3.5 Create sequence diagrams 4.0 MS4 4.1 Meet to discuss MS4 4.2 Interface Design 4.3 Work on controls 4.4 Work on software design/ method specifications 4.5 Create test cases

Effort 1 day

Estimated Start Date 3-26-14

Estimated End Date 3-26-14

Assigned Resources Jared

1 day 1 day 1 day

3-27-14 3-28-14 3-29-14 Due 4-18 4-12-14 4-13-14 4-14-14 4-15-14

3-27-14 3-28-14 3-29-14

Celso, Jared Celso, Jared Celso

1 day >1 day 1 day 1 day

4-12-14 4-13-14 4-14-14 4-15-14

Jade, Celso, Youngsu, Jared Celso Celso Jared

1 day

4-15-14

4-15-14

Jade

System Requirements
Functional Requirements

The system will require a membership database that provides information about the client. These fields are lead ID, first name, last name, email address, phone number, street address, city, state, zip, barcode, and member status. Whenever a change is made within the system, the database needs to be able to update this information automatically with the new record, deleting the older file to insure no data duplication. Whenever a lead or prospect is generated, an email needs to be sent to the owner to inform there is a new lead. This should occur as well whenever a member changes their status. The free one week pass page that the user inputs all their information must be linked to the database.

The staff at the gym must be able to manually input or update information within the database if the autoUpdate function does not respond properly. The system must be able to log the amount of time a user spends at the gym from their membership card. This is important to be able to analyze the times most members frequent the gym.

Non-Functional Requirements

There must be web pages ex. (email the club, membership inquiry) that can help owners help obtain new members. The usage report will display the most active members, and the times at which they use the gym. This will be done to be able to advertise to those high usage members and allocate time towards initiating programs that suite their needs. Billing will be handled by a third party vender, however the owners must dictate what types of payment are appropriate to maintain membership.

Security Requirements

The website must be PCI compliant, up to the latest standard. All information collected from customers must be encrypted with the AES 256 standard. Cookies will be used to track habits of customers. This in return can better help the gym allocate resources for the types of products members use within the gym. To help provide more security for our customers, the database must use prepared statements to protect against SQL injection. Information collected by cookies is forbidden to be sold to third party vendors

Member Use Case

Prospect Use Case

Lead Use Case

User Interface
Control Panel The control panel of the application uses salesforce developer software to house the front end of the web application. This portal allows for numerous packages to choose from and easily registering with both the customer interface and billing vendor. Although not so easy on the eyes, this application is fully functional and ready for use.

Prospects Page:

Member Management Page:

Add New Member:

Member Management Continued

Add Family Member Page:

Controls:
Account Address Validation Rules: Zip Code Format
Field Description: Value This control will be a part of the user interface controls of the Members object. This control object will ensure that the Zip Code entered under a members account is a valid zip code. This rule will validate that the account Zip Code is in 99999 or 99999-9999 format. AND( OR( AND(LEN(ZipCode) <>5, LEN(ZipCode) <> 10), NOT(CONTAINS("0123456789", LEFT( ZipCode, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 2, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 3, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 4, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 5, 1))), AND( LEN(ZipCode) = 10, OR( MID( ZipCode , 6, 1) <> "-", NOT(CONTAINS("0123456789", MID( ZipCode , 7, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 8, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 9, 1))), NOT(CONTAINS("0123456789", MID( ZipCode , 10, 1))) ) ) ) ) Zip code must be in 99999 or 99999-9999 format. Zip Code

Formula:

Error Message: Error Location:

Date Validation Rules: End Date Cannot Be Before Begin Date

Field Description: Value This control will be a part of the user interface controls of the Members object. This control object will validate that a custom field called Membership Expiration Date does not come before another custom field called Membership Start Date. Membership_Expiration_Date_c < Membership_Start_Date_c Expiration Date cannot be before Start Date. Membership Expiration Date

Formula: Error Message: Error Location:

Workflow Rule: Follow Up Before Membership Expires

Object Description Evaluation Criteria Rule Criteria (Filter) Immediate Actions Time-Dependent Actions Member Send an email reminder to the renewal manager 20 days before a contracts end date. Evaluate the rule when a record is: created, and any time its edited to subsequently meet criteria. Run this rule if the following criteria are met: (Member: Status equals Green or Yellow) None 20 Days Before Member: Membership Expiration Date Email Alert: Send an email reminder to the manager to confirm whether the member would like an extension.

Workflow Rule: Report Old Leads/Prospects

Object Description Evaluation Criteria Rule Criteria (Filter) Immediate Actions Time-Dependent Actions Prospect Ensure that unattended leads are tracked in a timely manner by notifying the manager if a lead is not updated in two days. Evaluate the rule when a record is: created Run this rule if the following criteria are met: (Prospect: Status equals New Prospect) None 2 Days After Prospect: Created DateEmail Alert: Notify the manager that there are unattended leads in the queue that are older than two days.

Software Design:
Method One: Changing Member Information SQL Query.
Method Name: MemberInfo Contract ID: --Programming Languages: SQL Class Name: Member Programmer: --ID: --Due Date: ---

Triggers/Events: Member wishes to update information. Arguments Received: MemberName, address, city, postal code, MemberID Data Type: String, Int, Boolean Notes: Member has a need to change a portion of their information.

Messages Sent & Arguments Passed: INSERT INTO Member (Address) INSERT INTO Member (Postal Code) INSERT INTO Member (City) INSERT INTO Member (MemberName) INSERT INTO Member (Overdue) Arguments Returned: Notes: Data Type: String, Int, Boolean Algorithm Specification: Create new record for Member Database

Data Type: String Int String String Boolean

Notes:

Member information is changed in database

INSERT INTO Member (MemberName, address, city, postalCode, overdue) VALUES (SomeName, SomeAddress, SomeAddress , SomeCity , FALSE) Misc. Notes:

Method Two: Creating a new object developer action

Method Name: createNewObject() Class Name: --ID: ---

Contract ID: --Programmer: --Due Date: --Programming Languages: --Triggers/Events: Client wishes to add another custom object within the application. Arguments Received: Notes: label, pluralLabel, objectName, recordName, dataType Data Type: String, Picklist Messages Sent & Arguments Passed: INSERT Label INSERT pluralLabel INSERT objectName INSERT recordName INSERT dataType Arguments Returned: Notes: New Custom Object Algorithm Specification: Create new Custom Object for our Member Management Database INSERT (label, pluralLabel, objectName, recordName, dataType) VALUES (SomeLabel, PluralLabel , SomeName , SomeName , Text_or_AutoGenNum) Misc. Notes: Data Type: String String String String Picklist Notes: Example: Member Example: Members Example: Member Example: Member Name Text or AutoNumber Owner has a need to create a new object within his application.

Client now has a new object that he can organize into his application

Method Three: Retrieving details for deleted records query.

Method Name: getDeletedRecord() Class Name: DeletedResults Class ID: --Due Date: ---

Contract ID: --Programmer: --Programming Languages: --Triggers/Events: Client wishes to retrieve details about a deleted record. Arguments Received: getDeletedDate() getId() Data Type: String, ID Notes:

Use the methods getDeletedDate() and getId() to retrieve details about each deleted record. getDeletedDate() - Returns the deleted date of this record. getId() - Returns the ID of a record deleted within the time window specified in the getDeletedRecord() method.

Messages Sent & Arguments Passed: getDeletedDate() getId() Arguments Returned: Deleted Date, ID Data Type: Date, ID Algorithm Specification: Notes:

Data Type:

Notes:

String String

This string would be the Deleted Record's Id This string would be the employee's Id

The getDeletedRecord() method of the DeletedResults class returns a list of DeletedRecord objects.

Get details of deleted records from our Member Management Application. public Date getDeletedDate('DeletedRecordId') public Id getId('SomeIdString') Misc. Notes:

Testing:
Test Case One One of the most crucial rolls in this application is making sure that user information and date numbers and characters are correct. Therefore, the first test case scenario we tested was using different types of characters in the input fields of every form on the member, prospect, and management tabs. In the prospects tab we tested the information that is put into the different fields. The first test done was adding character data within the name and address of the prospect. The first test allowed different characters such as @ and ! to be added in the name and address fields. After adding a conditional if statement to that field, there were no more errors recorded in this section because when someone would try to include the characters they would get an error message that would read "error: invalid characters used cannot use '! @ # $ % ^ & * ( )'. The same method was added to the member tab and family member tab. The next method that was tested involved dates. The first implementation let management add these dates by typing the numbers. However, to save time, we added a javascript function that not only saved time, but also caught format errors input by the operator. These errors included allowing dates that did not correspond with their month, such as having the 31st of February as a valid date. As well we added a function that would not allow the Member Expiration Date to fall before the Member Start Date. If someone were to join today the operator would not be able to put to expiration date as last month. An error message would pop up and say 'error: invalid expiration date. Expiration Date must be after the Start Date'. Test Case Two The second test scenario the team needed to validate as functional was making sure the third party application that handled billing was operational for the front end and billed the client on the right date. To test this, we used an interns debit card and did 3 charges of one cent and changed the date of the system one month ahead. The first test failed due to the database not recognizing a payment below the first price range of a member. This was due to a segment of code that would not allow payments of less than what the membership status was created with. The second implementation corrected this, as it could be an issue if Members decided to upgrade or downgrade their membership. The second test successfully recognized the date change, but billed the interns card for a yellow member status. We fixed the issue by adding an emailing system to verify that the Member chose that membership type. The third test worked perfectly. The system charged the Member with the correct amount, sent the email to confirm, and once it was confirmed by the Member, the transaction was made between the third party billing service and the Members membership status stayed what they paid for.

Test Case Three - The third test case came up when the team was making rules for the membership verification character input test. Management decided that it would be crucial to send potential leads an email after using their free trial. To test this, we created a dummy account and wrote a segment of code that sent a prospect using the trial membership an email after 30 days, and gave an offer of deals that were available for their area. The first test sent the email, but did not offer the correct deals, and used the deals from the headquarters location. To fix this, the team added a test case for the registration form to validate whether the address was valid. After this was created the second test send both the email, as well as advertisements for the correct deals for the gym nearest that location. Minutes Of Meetings: Thursday April 17, 2014 Attendants: Jared, Celso, Therese, Youngsu 7:00pm-8:00pm As a group we discussed the requirements that we need to cover for the 4th milestone. As a group we went through each section of the project and brainstormed on possible ideas for each of the requirements. We had originally planned on each of us coming up with one part of each of the sections (User Interface, Controls, Methods, and Testing) Friday April 18, 2014 Attendants: Jared, Celso 4:00pm-6:00pm Created first of three method specifications and finalized the user interface in the development aspect of milestone 4. We also created the first two test case scenarios for the application. Saturday April 19, 2014 Attendants: Jared, Celso 7:00pm-11:00pm Finished method specifications and created the template for the milestone. Finalized layout and finished last of the testing requirements, and formatted information sent by other group mates.