parkerduell.files.wordpress.com · web view2020. 4. 20. · the system will be ran on the src...

System Requirements

The system requirements display the functionality that we expect out of our system. These requirements are the specific functions that our system can provide for the user and the specific actions that fulfill these requirements are reflected in the use cases. The functional requirements are the specific things we expect out of our system, while the non-functional requirements are the constraints on our system and represent the things that our system requires to function at the most efficient level. The functional requirements displayed below is organized as a hierarchy based on staff, member and manager usage.

Functional Requirements:

Members

1. The consolidated website will communicate information effectively and efficiently to

both employees and SRC members.

2. The system will allow members to pay online using credit cards and automatic payments

will be available.

3. The system will print and email receipts that reflect payments made by members which

are stored within our database for later access.

4. The system will provide consolidation for each member’s information and allow member

info to be edited as needed.

5. The system will allow lockers to be reserved online.

Staff

1. The system will generate daily, weekly, and monthly reports to help keep updated

information regarding machine use and class attendance.

2. The system will generate important reports regarding finances, users, and equipment use.

3. The system will have an employee portal with each employees information

4. The system will allow employees to check in gym members upon entry into the gym.

5. The system will have a portal for payments to be accepted for guest visiting the SRC.

6. The system will have a count feature in which count sheets can be generated every hour

and saved into a database.

7. The system will have a database with spreadsheets and past count sheets saved that can

be accessed at anytime.

8. The system will have filters that allow employees to filter out count sheets based on time

and date.

9. The system will have filters specific for filtering receipts and past transactions.

10. The system will have an employee portal that contains important information such as

work schedules and announcements.

11. The system will have features that allow the staff to send out mass emails to members

and staff including promotions and other important announcements.

Managers

1. The system will have a portal specific for managers that contain their personal

information and allow them additional access to member profiles that aren’t accessible to

the average staff member.

2. The system will allow managers to track processes made within the system to prevent

errors from being made.

3. The system will allow managers to correct and edit spreadsheet info, membership status,

and locker status after the process has already been executed.

4. The system will have filters specific for filtering receipts and past transactions.

Non-Functional Requirements:

1. The system will be hosted using A2 hosting and will be built using WordPress.

2. The system will function with hardware including printers and routers.

3. The system will be process online payments through PayPal.

4. The system will be generate spreadsheets every hour that are required to be stored in a

cloud database.

5. The system data will be stored within our MySQL database.

Use Case Diagram

The Use Case Diagram is meant to show how all of the use cases relate to each other and how the use cases relate to each potential user. The use cases are in blue, the potential users are the green stick figures, and the blue lines are the connections between the use cases and users.

The diagrams below represent what each user can use from the above diagram to represent the capabilities of each user more clearly.

Manager

Member

Trace Matrix

The Trace Matrix weighs the system requirements to the system use cases (features or functions). It shows which use cases are fulfilling each system requirement. The system requirements are listed on the X-axis and the use cases are listed on the Y-axis.

Use Cases

This section describes each use case, their flow of events and requirements. The flow of events describes the chain of events of actions and responses while using the use case. The requirements describe what must be present or what needs to be done for the use case to be functional.

Display Member Portal

Description:

The member will be able to access their member profiles through the member portal on the website. Their member profile allows them access to their personal information, membership renewal, the SRC PayPal link, locker rentals, class schedules, along with view information such as their outstanding balances and gym attendance. This use case is the core for member functionality. This is where members will go in order to perform their necessary tasks.

Flow of Events:

Basic Flow:

1. The user will enter their username and password

2. The system will validate the username and password are correct

3. The system will redirect the user from the login page to the member portal

4. The user will have access to all member tools

Alternative Flows:

1. If the user enters the incorrect username or password, authentication fails

2. If the user forgets their username or password, they can use the “forgot username/password” link to reset the username or password to access the member portal

Special Requirements:

First Requirement:

· The system must be connected to the internet in order to access the login page and member portal

Second Requirement:

· The user must be an enrolled SRC member to access the member portal

Third Requirement:

· The system must validate that the username and password are correct

Preconditions:

First Condition:

· The system must be connected to the internet on the user’s side and the SRC’s side

Second Condition:

· The user must be an SRC member and correctly enter their username and password

Postconditions:

First condition:

· The member portal will appear displaying the user profile, and allow access to all member tools and class schedules

Extension Points:

· The user will have the ability to update their personal information

· The user will be able to view the class schedules

· The user will be able to make renewal payments on a locker and membership

Update Personal Information:

Description:

This use case gives members and employees the ability to update personal information as necessary. This information includes address, zip code, state, city, phone number, email, and emergency contact information. The member status is the only data field that the employee will have the ability to change. The staff will also be able to update member personal information.

Flow of Events:

Main Flow:

1. The user clicks the link on the portal to edit their personal information

2. The user will update the necessary information

3. The user will click “Save Changes” and their information is saved

4. The update information tool closes and redirects the user back to the portal

Alternative Flow:

· If a member asks an employee to update their personal information, the employee will access the members profile from the staff portal to access the update information tool

System Requirements:

First Requirement:

· The system must be connected to the internet to access the portal

Second Requirement:

· The user must enter the correct username and password to access the portal

Third Requirement:

· All entry labels of personal information must have a value in order to authenticate and save any updates

Preconditions:

First Condition:

· The user must have access to the internet to access the portal

Second Condition:

· All entry labels of personal information must have a value

Postconditions:

First Condition:

· The updated information of a member or an employee will be saved

Second Condition:

· The information will automatically update the member or employee profile within the portal

Extension Points:

· The user’s information will be correct and the user can be contacted correctly

Make Online Payment

Description:

This use case describes the payment flow. The member will access online payments via the member portal. There will be a button within the member portal that will redirect members to the SRC Paypal. Members will be able to make monthly payments for their membership or locker via paypal, and Paypal will process the payment and transfer the money to the SRC bank account. The member will also be able to set up automatic Paypal payments.

Flow of Events:

Main Flow:

1. The user accesses the portal

2. The user clicks the “Make Locker Payment” or “Make Membership Payment” link on the portal

3. The user is redirected to a secure Paypal page to enter their card information and make a payment

4. Paypal authenticates and transacts the payment

5. Paypal transfers the funds to the SRCs bank account

6. The member’s outstanding balance is updated

Alternative Flows:

1. The user makes a cash or check payment

2. The user makes a card payment in the SRC

3. The user has automatic payments setup


First Requirement:

· The user has access to the internet and access to the portal

Second Requirement:

· The user has an outstanding balance that needs to be paid

Third Requirement:

· The user has a valid debit or credit card

Fourth Requirement:

· The user has enough funds in their bank balance

Preconditions:

First Condition:

· The user has access to the internet and the portal then click an online payment link

Second Condition:

· The user must have an outstanding balance

Third Condition:

· The user must enter their card information into Paypal and have enough funds in their bank balance

Postconditions:

First Condition:

· Paypal authenticates and transacts the payment

Second Condition:

· Paypal transfers funds to the SRCs bank account

Third Condition:

· The user’s outstanding balance is updated, and their membership or locker rental is validated

Extension Points:

· The user’s status and profile will be updated to reflect the payment

· The members “Locker Rental” will validate

· The “Member Check-in” tool will validate the user’s entry to the SRC

Enroll New Member:

Description:

The website will have an option for potential members to apply. This option will redirect the potential member to the “Member Enrollment” link, where they will input the prompted data. Once their application is submitted, a member profile will be automatically created and saved into the member database. Employees will receive a notification when an application is submitted and will have to create a membership card. If a potential member wants to enroll in the SRC, the staff member will access the same “Member Enrollment” link through the staff portal and either enter the potential information for them or give them a laptop or Ipad to enter the information themselves.

Flow of Events:

Main Flow:

1. The user accesses “Member Enrollment” link on the SRC website or staff portal

2. The user enters the required information

3. The member makes a payment

4. The user clicks “confirm”

5. The system automatically adds the member to the database, creates a member profile, and grants access to the portal

Alternative Flows:

· The member enrolls in the SRC and has an employee enroll them


First Requirement:

· The user has internet to access the SRCs website

Second Requirement:

· The user must enter all prompted and required information to validate the new member application

Third Requirement:

· The user makes a payment to complete the enrollment process

Preconditions:

First Condition:

· The user must have internet to access the SRCs website

Second Condition:

· The user must be an employee of the SRC or an alumnus of the University of Louisville

Postcondition:

· The user is enrolled and granted access to the SRC

· The user’s profile is created and is granted access to the portal

· The user is given an SRC identification card

Extension Points:

· The user is granted access to all the member tools on the portal

Reserve Locker

Description:

Members will be able to reserve a locker on the website via the member portal. The button on the member portal will redirect the member to the Locker Application where the member will be prompted to enter data. Once they submit their application, they will be obligated to make a payment. The member will also have to supply their own lock. The system will be responsible for auditing the lockers to ensure that a locker is available for rental. A member can also reserve

a locker in the SRC where the staff member will access the “Reserve a Locker” tool and have the members enter the required information on a laptop or iPad.

Flow of Events:

Main Flow:

1. The user has access to the portal

2. The user clicks the “Reserve a Locker” link

3. The user enters the required information prompted

4. The user makes a payment

5. The system assigns the user an unoccupied locker and processes request

6. The user’s profile is updated to reflect the locker rental

Alternative Flows:

· The user reserves a locker in the SRC and an employee uses the “Reserve a Locker” link from the staff portal


First Requirement:

· The user must have access to the portal

Second Requirement:

· A locker must be available for rental

Third Requirement

· A payment must be made to validate locker rental

Fourth Requirement:

· The user must have their own lock to use on their reserved locker

Preconditions:

First Condition:

· The user must be connected to the internet to access the portal

Second Condition:

· There must be an unoccupied locker available for rental

Postconditions:

First Condition:

· A locker is assigned to the user and reserved for the full term

Second Condition:

· The system accounts for the rental and updates the database of locker rentals and makes the newly rented locker unavailable

Third Condition:

· The system updates the members profile to show their status of locker rental

Extension Points:

· A payment must be made either online or in the SRC

Enroll in Intramurals

Description:

Members will be able to access the intramural portal through a link on the SRC website and member portal. This link will redirect members to the intramural portal where they can enroll.

Flow of Events:

Main Flow:

1. The user accesses the portal

2. The user clicks on “Sign Up for Intramurals” link

3. The user is redirected to the intramural portal

4. The user is redirected back to the staff or member portal once the intramural portal is exited

Alternative Flows:

· The user goes directly to the intramural portal

· The user signs up for intramurals in the intramural office


First Requirement:

· The user must have internet access to access the portal

Second Requirement:

· The user must be currently enrolled in the University of Louisville to be permitted to play intramural sports

Preconditions:

First Condition:

· The user must have access to the portal to access the “Sign Up for Intramurals” link

Postconditions:

First Condition:

· The user will be redirected to the intramural portal

Extension Points:

· The member or staff portal must be accessed

Display Staff Portal

Description:

This use case gives the staff access to all necessary functions via the staff portal. Employees will be able to view/update their profile, view/update member profiles, access the count tool, access the check in tool, view the work schedule, send email blasts, access the enroll new member tool, view transactions, and view filtered data. This use case is not necessarily where they will perform these functions, but the location to access these functions.

Flow of Events:

Main Flow:

1. The user enters their username and password to access the portal

2. The user is redirected to the staff portal where they will have access to all the staff tools

3. The system will automatically log the user out of the staff portal if the system is idle for an hour

Alternative Flows:

· The user forgets their username or password and must gain access through the “Forgot Username or Password” link


First Requirement:

· The user’s device must be connected to the SRCs internet to access the staff portal

Second Requirement:

· The user must be a current employee of the SRC to be granted access to the staff portal

Preconditions:

First Condition:

· The user must be a current employee of the SRC to have access to the staff portal

Second Condition:

· The user’s device must be connected to the SRCs IP address to access the staff portal

Postconditions:

First Condition:

· The user will have access to all the staff tools

Extension Points:

· The user will have access to view their personal profile and member profiles

· The user will have the ability to update member profiles and their profile

· The user will have access to the count tool

· The user will have access to the check-in tool

· The user will be able to view the staff work schedule

· The user will be able to send email blasts

· The user will have access to the enroll new member tool

· The user will be able to view transactions

· The user will be able to filter data

Email Receipt

Brief Description:This case will allow the managers and staff members of the SRC to email any gym members their receipts after a transaction. This use case will be used after a member purchases a membership or reserves a locker for themselves. The Email receipt use case will be used as an alternative method for giving the gym member their receipts as opposed to printing out or hand writing a physical receipt. Flow of Events Basic Flow:

· User enters gym member email address· User clicks the “email” button· System generates an email· System attaches pdf of the receipt· System pastes email address of gym member in to the “To” text box· System sends email

Alternative Flow:

· User clicks “print” button· Device connects to the wireless printer using the IP address· Device pops up printing options for the receipt· User selects preferred settings for the receipt· User clicks print· Wireless printer prints the receipt


First Requirement:The system would need to be connected to the internet with the SRC’s IP address Second Requirement:The system would need to be used on a device that can display a screen and accept user commands such as a computer, tablet, or cellphone

Pre-conditions:

First Condition:The system will need to be able to process a transaction for a membership or a locker reservation. Second Condition:The system will also need to be able to generate a receipt of the transaction being processed as a pdf.

Post Conditions:

First Condition:The system will need to be able to close out of the receipt after being emailed or printed.

Extension Points:

SRC Computers:The system will be used on the SRC computers at the front desk to process any transactions and send email receipts.

Access Receipt

Brief Description:This use case will allow staff members and managers to access the receipts of previous transactions. These transactions can be reprinted or emailed again in cases that the customer didn’t receive a receipt, or a transaction needs to be verified. Flow of Events: Main Flow:

· Click on view receipt lookup button on the staff or manager profile· Filter time or date and click search· Scroll through receipt and click on desired receipt

Alternative Flow:

· User clicks other use case present on the staff or member screen’

System Requirements: First Requirement:

The device that is using the system needs to have a screen to display the website and the receipt.

Second Requirement: The device needs to be connected to the internet with the SRC’s IP address Pre-Conditions: First Condition: The user needs to be logged in with a staff or manager profile Post-Condition: First Condition:

The user needs to be able to exit the view receipt tab to get back to the home page Second Condition:The user needs to be able to print or email the receipt

Extension Points:

SRC Computers:

The system will be ran on the SRC computers at the front desk or in the offices

Restrict Receipt Access

Brief Description:This use case will allow staff members to access the receipts of previous transactions. These transactions can be reprinted or emailed again in cases that the customer didn’t receive a receipt, or a transaction needs to be verified. The restriction that staff will have is a date restriction where they can only access receipts from that current day, but they can still filter the timeFlow of Events: Main Flow:

· Click on view receipt lookup button on the staff or manager profile· Filter time and click search

· Scroll through receipt and click on desired receiptAlternative Flow:

· User tries to click the date filter· The system props for a manager override· Manger inputs username· Manager inputs password· Receipt date is filtered· Click search· Scroll through receipt and click the desired receipt



Second Requirement: The device needs to be connected to the internet with the SRC’s IP addressPre-Conditions: First Condition: The user needs to be logged in with a staff profilePost-Condition: First Condition:

The user needs to be able to exit the view receipt tab to get back to the home pageSecond Condition:The user needs to be able to print or email the receipt

Extension Points:

SRC Computers:


Display Manager Profile

Brief Description:This use case will allow managers to log into their profile which gives them the same actions that can be taken by staff members, as well as additional permissions and features that aren’t on the staff profile.Flow of Events: Main Flow:

· Manager enters username· Manager enters password· Manager clicks enter

Alternative Flow:

· Member or staff enter username· Member or staff enter password· Member or staff clicks enter



Second Requirement: The device needs to be connected to the internet with the SRC’s IP addressPre-Conditions: First Condition:

The system needs to be able to accept usernames and passwords in order to log into a profile Second Condition:The system needs to be able to verify a username and password

Post-Condition: First Condition:

The user needs to be able to logoutSecond Condition:The system needs to be able to generate the profile

Extension Points:

SRC Computers:


Manager Use of Staff Functions

Brief Description:This use case will allow the manager to do everything the staff can do on their profile. This means they have the ability to count, process transactions, and open receipts.Flow of Events: Main Flow:

· Click desired use case

Alternative Flow:· Click Manager exclusive use case



Second Requirement: The device needs to be connected to the internet with the SRC’s IP address Pre-Conditions: First Condition: The user needs to be logged in with a manager profilePost-Condition: First Condition:

The user needs to be able to open the staff functions Second Condition:The user needs to be able to execute staff functions Third Condition:The user needs to be able to exit staff functions

Extension Points:

SRC Computers:


Access Member Information

Brief Description:This use case will allow managers to search for gym members and pull up any personal information provided by the member. It will be searched through filters of first name, last name, or start date. Flow of Events: Main Flow:

· Click on account lookup· Filter desired first name, last name, or start date filter· Click search· Scroll and select desired profile· Open profile

Alternative Flow:· User selects a different function on manager profile



Second Requirement: The device needs to be connected to the internet with the SRC’s IP addressPre-Conditions: First Condition: The user needs to be logged in with a manager profilePost-Condition: First Condition:

The user needs to be able to exit the account lookup tab to get back to the home page

Extension Points:

SRC Computers:


Access Staff Information

Brief Description:This use case will allow managers to access staff information if necessary, to edit any information as needed.Flow of Events: Main Flow:

· Click on staff look up· Enter staff member name by first name or last name to filter· Click search· Select desired staff member

Alternative Flow:· Use a different manager function



Second Requirement: The device needs to be connected to the internet with the SRC’s IP address Pre-Conditions: First Condition: The user needs to be logged in with a manager profile Post-Condition: First Condition:

The user needs to be able to exit the staff lookup tab to get back to the home page Second Condition:

The user needs to be able to edit staff information

Extension Points:

SRC Computers:


Make Corrections

Brief Description:This use case will allow the manager to make any corrections to a spreadsheet, time card, or anything function that could be edited. To make corrections the manager would have access to a corrections tab which would allow them to filter through some of the functions performed through the day and edit any when necessary.\Flow of Events: Main Flow:

· Click on the corrections tab· Filter through functions performed by date or by time· Click search· Find desired function and open it· Click edit button to make any changes· When finished, click save

Alternative Flow:· Use a different manager function



Second Requirement: The device needs to be connected to the internet with the SRC’s IP addressPre-Conditions: First Condition: The user needs to be logged in with a manager profile Second Condition:

Functions need to have already been performed by staff members or other managers

Post-Condition: First Condition:

The user needs to be able to exit the corrections tab to get back to the home pageSecond Condition:The user needs to be able to edit the function selected

Third Condition:The user needs to be able to save the changes made to a selection

Extension Points:

SRC Computers: The system will be ran on the SRC computers at the front desk or in the officeExamine Schedule

Brief Description:

The manager profile will allow the manager to see everyone who is scheduled to work on any given day. It will also give the manager the ability to update the schedule for any changes.

Flow of Events:

Basic Flow:

● Manager logs into staff portal

● Manager navigates to staff schedule tab

● Manager can then edit schedule as needed

● Manager can print schedule

Alternate Flow:● N/A


● The system requires wifi to access the staff portal

Pre-Condition:

● Staff schedule must be uploaded to the staff portalPost-Condition:

● N/A

Send Mass email Member/Staff:

Brief Description:The manager will have the ability to send out mass emails to everyone with a registered email on file to send out any event information or information relating to the staff.

Flow of Events:Basic Flow:


● Manager navigates to mass email tab

● Manager can search for names and filter to select from the list of emails on file.

● Manager types email

● Manager selects the names from the email list

● Manager sends email to everyone on email list

Alternate Flow:

● NA

Special Requirements:First Requirement:

● The user needs to use a device that can connect to the internet

Pre-Condition:

● System must have access to the database that contains the email list

Post-Condition:

● A mass email will be sent to everyone along with a confirmation email sent back to the manager

Add/Delete Profiles:

Brief Description:The manager will be able to add profiles or delete profiles, as necessary.



● Manager navigates to view list of member profiles

● Manager can search for and select profiles

● Manager can delete profiles as needs

Alternate Flow:


● Manager navigates to view list of member profiles

● Manager can search for and select profiles

● Manager can add profiles as needs

Special Requirements:The user needs to use a device that can connect to the internet

Pre-Condition:● System must have access to the database containing all member profiles

Post-Condition:

● If manager is adding a profile the system will take the manager to the membership signup page

View and Filter Transactions:

Brief Description:The manager will be able to see the transactions that have taken place for any given day to allow them to account for any income. The manager will be able to filter specific dates for income to see specific time frames



● Manager navigates to transaction history

● Manager can view all past transactions and filter them as needed

● Manger can print a report based on these filtersAlternate Flow:

● Customer walks into SRC to request a past transaction


● Manager navigates to transaction history

● Manager can view all past transactions and filter them as needed

● Manger can print a report based on these filters



● User must have a printer to print reports

Pre-Condition:

● System must have access to the database containing all the past transaction

● System must update transaction list in real timePost-Condition:

● Reports will be generated containing the requested information

View and Filter receipts:

Brief Description:The manager will be able to see all in gym and online receipts that come in for any given day for all transactions. The manager will be able to filter dates to see all receipts that come in for specific days or time frames



● Manager navigates to receipt history

● Manager can view all past receipts and filter them as needed

● Manger can generate and print a report based on these filtersAlternate Flow:

● Customer walks into SRC to request a past receipt


● Manager navigates to receipt history

● Manager can view all past receipts and filter them as needed

● Manger can generate and print a report based on these filters



● User must have a printer to print receipts

Pre-Condition:

● System must have access to the database containing all the past receipts

● System must update transaction list in real timePost-Condition:

● Reports will be generated containing the requested information

● Reports can be given to customers if requested

Transact Day Passes

Brief Description:This Use Case will allow the staff to access the web profile and be able to accept one time payments for single day users visiting the gym.


● Non-member enters the gym● Staff member is notified of gym status● Staff member initiates transaction process for a single time period

● Staff member accepts payment● Staff member print receipts

Alternate Flow:N/A

Special Requirements:The non-member has to be able to pay within the gym specifically for a pass, cannot be done online

Pre-Condition:● User entering gym must not be a current member

Post-Condition:● N/A

Use Count Tool:

Brief Description:This case will allow the staff to access that will contain a link to a counting tool staff members can use to update a count sheet within the database profiling the active use of specific equipment and areas within the gym. This can be done as often as desired.


● Staff member opens member profile● Staff member clicks link to count sheet● Staff member walks to specified area● Staff member counts and tallies total usage● Staff member enters number into spreadsheet under corresponding section● Staff member clicks submit● System adds submitted count to total count

Alternate Flow:

● Staff member obtains physical count sheet● Staff member walks to specified area● Staff member counts and tallies total usage● Staff member notes the total on paper for corresponding section● Staff member takes count sheet back to binder

● Staff member calculates hourly totals● Staff member calculates daily totals so far● Staff member calculates weekly totals so far● Staff member calculates monthly totals so far

Special Requirements:First Requirement:The user needs to use a device that can connect to the internet

Second Requirements:The user’s system would need to have a screen to display the web page

Pre-Condition:System must have access to the database and current running totals so far

Post-Condition:The system must add the total from the current count to the total count, and be able to track the time it was submitted

Display Count History:Brief Description:This case will allow employees to enter the staff profile and be able to pull up the days current counting spreadsheets as well as those from previous times.


● Staff member opens staff profile● Staff opens Count History tab● Enters starting date● Enters starting time● Enters ending date ● Enters ending time● Submit filter and view data

Alternate Flow:

● Staff opens database● Staff pulls every record for desired dates● Staff sorts out times specifically desired● Staff cleans up and views data


Pre-Condition:● Must have some count sheets in the database prior to accessing


View Work Schedule:

Brief Description:This case will allow employees to access the staff profile and give an overview of the staff schedule and the times they are assigned to work that week.


● Staff member opens staff profile● Staff opens link to schedule● Staff views desired information

Alternate Flow:● Staff walks into SRC● Staff requests necessary information● Staff receives desired information


Pre-Condition:● Staff member must be on the schedule to work that week to view their data


Generate Receipts;

Brief Description:The staff profile will give staff members the ability to access a virtual receipt after a transaction


● Gym user starts transaction within the gym● Gym user pays and completes transaction● Staff member confirms payment and opens receipt

Alternate Flow:● N/A

Special Requirements:Gym user must be present in the gym to produce a receipt of this type

Pre-Condition:● Gym user must be completing some transaction for this process to start

Post-Condition:● The system will need to note transaction and store it within the database

Print Receipt;

Brief Description:This case will allow the managers and staff members of the SRC to print off a receipt for any gym members after a transaction. This use case will be used after member purchases a membership or reserves a locker for themselves.


● Staff member clicks “print” button● Device connects to the wireless printer using the IP address● Device pops up printing options for the receipt● User selects preferred settings for the receipt● User clicks print● Wireless printer prints the receipt

Alternate Flow:● User enters gym member email address● User clicks the “email” button● System generates an email● System attaches pdf of the receipt● System pastes email address of gym member in to the “To” text box

● System sends emailSpecial Requirements:

Pre-Condition:● Gym user must be completing some transaction for this process to start


Sequence DiagramsThe sequence diagrams show the flow of events between user actions and system responses to execute a use case. It describes how a user triggers an action and how the system responds to prompt or execute what the user asks for. It will also show alternative ways to access the use case.

Make Online Payment

Enroll New Member

Reserve a Locker

Enroll in Intramurals

Display Staff Portal

Display Member Portal

Update Information

Restrict Access ReceiptClick on the access receipt link in the manager or staff profileEnter the desired filterIf on the staff profile, the system will ask for manager override when filtering datesDisplay Receipts from desired filter by clicking the search buttonOpen desired receipt

Access Receipt1. Click on the access receipt link in the manager or staff profile2. Enter the desired filter3. Display Receipts from desired filter by clicking the search button4. Open desired receipt

Manager Profile1. Enter Username2. Enter Password3. Click Enter4. System opens manager profile based on the username and password of

the user

Manager capabilities are the same as Staff

1. Enter Username2. Enter Password3. Click Enter4. Manager profile is displayed and the profile has the same processes

that can be performed as the staff

Access Member Information1. From the manager profile, click “member information” link2. Filter the desired filter by name, date, or age3. Click search to view all desired members in the filter4. Click on the member to view their profile

Access Staff Information1. From the manager profile, click “staff information” link2. Filter the desired filter by name or hire date3. Click search to view all desired staff in the filter4. Click on the staff to view their profile

Make Corrections1. Click the desired member, staff, or receipt2. Click the edit button3. Edit the desired information4. Function is only available for the Manager

Transact Day Passes● Non-member enters the gym● Staff member is notified of gym status● Staff member initiates transaction process for a single time period● Staff member accepts payment● Staff member print receipts

Use Count Tool

● Staff member opens member profile● Staff member clicks link to count sheet● Staff member walks to specified area● Staff member counts and tallies total usage● Staff member enters number into spreadsheet under corresponding

section● Staff member clicks submit● System adds submitted count to total count

Display Count History

● Staff member opens staff profile● Staff opens Count History tab● Enters starting date● Enters starting time● Enters ending date ● Enters ending time● Submit filter and view data

View Work Schedule

● Staff member opens staff profile● Staff opens link to schedule● Staff views desired information

Generate Receipts

● Gym user starts transaction within the gym● Gym user pays and completes transaction● Staff member confirms payment and opens receipt

Print Receipt

● Staff member clicks “print” button● Device connects to the wireless printer using the IP address● Device pops up printing options for the receipt● User selects preferred settings for the receipt● User clicks print● Wireless printer prints the receipt

Examine Schedule:

Main Flow

1. Manager logs into staff portal

2. Manager navigates to staff schedule tab

3. Manager can then edit schedule as needed

4. Manager can print schedule

Send Email:

Main Flow

1. Manager logs into staff portal

2. Manager navigates to mass email tab

3. Manager can search for names and filter to select from the list of emails on file.

4. Manager types email

5. Manager selects the names from the email list

6. Manager sends email to everyone on email list

Filter Transactions:

Main Flow

1 Manager logs into staff portal2. Manager navigates to transaction history

3. Manager can view all past transactions and filter them as needed

4. Manger can print a report based on these filters

Filter Receipts

Main Flow

1. Manager logs into staff portal2. Manager navigates to receipt history

3. Manager can view all past receipts and filter them as needed

4. Manger can generate and print a report based on these filters

Add and Delete

Main Flow

1 Manager logs into staff portal2.Manager navigates to receipt history

3.Manager can view all past receipts and filter them as needed

4.Manager can generate and print a report based on these filters

Class Diagram:The class diagram shows the relationship between the system’s classes, attributes, objects, and methods. The classes are the blueprint for creating objects (Login, Member, Employee, Manager, etc). The attributes are the characteristics of each class denoted with a dash in front of the attribute name. The methods are the actions a class can perform denoted with a + before the method name. The objects are what are being created from the method performing. For example, if “Submit” is clicked for the New Member class, a new member would be created and the new member would be the object.

Database Design and Data Definitions

Data Storage Classes:Count Table

Employee Table

Locker Table

Manager Table

Member Table

New Member Table

Data Dictionary:

Our data dictionary includes a breakdown of all the attributes contained within our system. This includes a brief description of each attribute with the associated types (whether its an integer or a text string) and also the amount of memory (bytes) that will need to be delegated to each attribute. The locations and interactions of these attributes can be found in our ERD.

Name Description Type Size

usernameA unique identifier for each member and employee that is a required field to login to the staff/member portal string 15 bytes

password

A security credential that the user enters and the system registers that the password matches the username to allow entry to the portal string 15 bytes

first_name

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users first name string 15 bytes

last_name

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users last name string 15 bytes

employee_id

A system generated identifier that is assigned to each new member or employee that uniquely identfies the member or employee int 7 bytes

manager_id

A system generated identifier that is assigned to each manager that will uniquely identify managers and grant them access to special tools within the portal int 7 bytes

email

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users email for contacting purposes string 25 bytes

phone_num

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users preferred phone number for contacting purposes int 10 bytes

address

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users address number for mailing and billing purposes string 8 bytes

city

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users home address city for mailing and billing purposes string 15 bytes

state

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users home address state for mailing and billing purposes string 2 bytes

zip

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users home address zip code for mailing and billing purposes int 5 bytes

birthday

A required field for signing up for a membership, reserving a locker, or updating personal information that specifies the users date of birth for liability purposes and member data collection string 9 bytes

em_contact_fnameA filed that allows a user to enter the first name of their emergency contact string 15 bytes

em_contact_lnameA field that allows a user to enter emergency contact last name in the case of an injury or other emergency string 15 bytes

em_contact_phonenum

A field that allows a user to enter emergency contact phone numbers in the case of an injury or other emergency string 10 bytes

locker_status Identifies whether a locker is unavailable or open string 11 bytes

class_statusIdentifies whether a member is enrolled in a class or not string 8 bytes

amount_due Amount of payment due for each member int 2 bytes

gender Field that identifies member gender for member sign-up string 6 bytes

status Identifies if member is active or inactive string 8 bytes

uofl_id Student ID that identifies every uofl student int 7 bytes

areaUsed to show area of gym being counted for count sheet string 2 bytes

male Identify gender for locker rental/count sheet int 2 bytes

female Identify gender for locker rental/count sheet int 2 bytes

caucasion Used to count Caucasion members in the gym int 2 byte

african_american Used to count African American members in the gym int 2 byte

date The day a process takes place string 3 bytes

time The time a process takes place string 3 bytes

locker_type The type of locker being reserved (Big or Small) string 5 bytes

receipt_idReceipts identification number to distinguish between recipts int 8 bytes

member_idMembers identification number to distinguish between members int 7 bytes

ERDOur ERD is a complete break down and organization of all our attributes within our data dictionary. This includes our classes with the attributes filled in with the appropriate primary and foreign keys. The ERD also includes cardinalities along with the verbs that describe each

relationship. Our ERD is broken down by managers, employee, login, count, member, locker, new member, and payment along with the associated attributes. The attributes are data that is going to be collected and labeled as well as the fields that can be found within our prototypes.

User Interface Navigation Diagram and Screen Layouts

System:This is the overview of the interface and how our prototypes will move from one to the next. We start our prototype at the Login screen which connects you to the landing screen that will take you to either a Member, Employee, or Manager account. From these accounts, the user will have various options that they can manipulate that we have made prototypes for and have represented the connections with arrows. The Blue arrows correlate to the general system, the Red correlates with the manager, the Yellow with the Employee, and the green with the Member.

Member:This is the Member section of the interface diagram. It comes from the first diagram of the total interface but is showing specifically the Member portal.

Employee:This is the Employee section of the interface diagram. It comes from the first diagram of the total interface but is showing specifically the Employee portal.

Manager:This is the Manager section of the interface diagram. It comes from the first diagram of the total interface but is showing specifically the Manager portal.

Physical Architecture Design

The diagram below shows the architecture of the system and how all the parts are connected. We have labeled the sources that we will use for website hosting and the database as well as a wireless printer that could potentially be used. The lines represent the connection from one system to the next starting from the user’s computer and ending at the database could storage.

Design Procedures for Security Concerns and Non-functional Requirements

Our design procedures that will be taken to ensure that our system is secure and safe. These security concerns address our non-functional requirements listed at the beginning of this document. These are important to note because they address the architecture and hardware set up of our system and focus specifically on security.

Security Concerns Include:

1. Routers and printers being placed in secure and safe locations to ensure no accidental damage is done and to ensure that only staff can access this hardware

2. Using PayPal as the payment system to ensure that the SRC is not taking on any of the payment process and therefore delegating the security risk to PayPal

3. Ensure that employees are saving spreadsheets and other data to the cloud system that will store our database. This ensures that employees aren’t saving data to locations that aren’t protected by our secure database

4. Ensure that there is restricted access levels for managers, staff, and members. This ensures that members and employees don’t have access to data that is not meant for their respective portals.

5. Ensure that member personal information portals are carefully coded and protected within our system guaranteeing the privacy of our members personal information.

6. Our database will be coded using SQL and we will ensure that our code is carefully written and checked to ensure that there is not information being lost or in places that it shouldn’t be.

Gantt ChartThe Gannt chart is a representation of how our tasks were divided among the group and horizontal bars display task completion time and represent dependencies. Each task that begins directly after another task represents a task that is dependent on the previous task being completed. The columns are divided by the name of the task, start date, finish date, duration, lead member contribution and finally the horizontal bar representation. Although all members of the group contributed and are knowledgeable on each task the name on the member contribution is the person who took the lead on completion of the task. The first Gantt chart displays the work for Iteration 2 and the associated tasks, while the second Gantt chart displays the tasks for the inception phase and near future tasks that still need to be completed. The next Gantt chart depicts the Iteration 5 followed by the elaboration spec Gantt chart.

Iteration 2

Inception Spec and Iteration 3

Iteration 5

This Gantt Chart starts with the completion of the updated use cases and use case diagrams. These updated use cases were then used to develop our high level prototypes. These use cases were divided evenly among the group and each member took a group of uses cases to write out. The data dictionary was then completed by everyone as a group. This was followed by the completion of our navigation diagram and presentation.

Elaboration Spec Gantt Chart

Elaboration Phase PrototypePortal Login:The first page that users will see when they attempt to access their information. In this case, our username is the members email.

Landing Screen:

The landing screen is a visually appealing transition from the user login to the member or employee portal.

Make Online Payment:Users can input payment information in order to make a payment towards gym membership fees or locker room rental fees. Transactions would done through PayPal but we can gather that information locally if we need to

Update User Information:This prototype allows users to enter any information that may have changed since their initial sign up and update it to reflect more accurately the current information. Normally, these boxes will be filled with current info, which can be clicked on to enable editing.

Delete Profile:

This page specifically only the manager would have access to. The ability to delete any member from the system that we no longer want on file for whatever reason that may be.

Member Portal:This is the main page for our gym users. This should show all current information on their own profile plus access to other links that can provide them with the full experience of the SRC. Including links to your locker rental, what classes are available and what you are currently enrolled in. This was designed for the member to find everything they need in one place

Count Sheet:This is a prototype that will be used a significant amount by employees. The ability to quickly locate what area they are in with a drop down bar and typing what count they see into their respective fields. This will all be stored into a database and be time stamped so calculations can be easily made at the end of whatever specified period.

Count History:The Count History prototype is used to access all count data given a specified time period. Once the dates and times are selected and the “View Records” button is selected, a screen will pop up with all count data taken for the times.

Generate Receipts: The Generate Receipts prototype is simply for a visual simulation of how receipts will be generated. The system uses Paypal to transact payments so Paypal will generate all receipts and give us access to them. The system will simply have to search for a member and will be able to access and print their receipt.

Manager Profile:The Manager Profile prototype is where managers will go to access every staff tool. Each button on this prototype will link to the tool and redirect the manager to the tool.

Print Receipt:The Print Receipt prototype is how users can access a physical copy of a receipt from a membership fee or locker rental payments. The information will be automatically generated so this is solely for printing a physical copy or emailing a digital copy to a member.

Transact Day Passes:The Transact Day Passes prototype is where an employee will go to generate a day pass. It simply prompts for the entry of the guests first name and last name along with their accompanying member. Once submitted, an option to pay with a credit card will be made available, a liability waiver will need to be signed, and a day pass will be generated.

Staff Profile:The Staff Profile prototype is where an employee is taken to after login. This was designed for convenience of employees by having every tool accessible from one screen.

View Work Schedule:The View Work Schedule prototype allows a user to select a date and view the employee work schedule or search an employee by ID and view a specific work schedule. This is a function of the Employee portal.

Membership Sign Up:The Membership Sign-Up prototype is the form that users will fill out when enrolling in a membership. The prototype can be used for a user or enroll online or for an employee to assist a new member in the gym. It prompts for basic user information and when submitted, will be stored in a database.

Machine Maintenance:The Machine Maintenance prototype documents when machines need to fixed. The prototype prompts the user to select an area, machine, serial number, date, and issue. It is solely to document when a machine or equipment is broken or out of service.

Mass E-mail:This prototype allows the staff to create and send emails to a large portion of the gym member population all at once. With the ability to select multiple groups or none at all for mass emails, and the ability to add specific users on top of that.

parkerduell.files.wordpress.com · web view2020. 4. 20. · the system will be ran on the src...

Documents