myTABA

Beta Test
Functional Design Document
Created: March 27, 2023

1
Table of Contents
Change Control
Introduction
Purpose of this document
Scope of this document
Overview
Business Context
General Description of Platform
Purpose of this document
User Characteristics
User Problem Statement
User Objectives
General Constraints
Architecture Overview
Beta Test Business Requirements
Minimally Viable Product Business Requirements
Conclusion
Payment Schedule
Agreed and Accepted
Appendix
Enhancements Business Requirements
Verbiage Guide
Functional and System Requirements
The following is needed in order to support the development and launch of the myTABA MVP:
Business Requirements - Template

2
 Change Control

Date Author(s) Change Overview Description

3/27/2023 Nick Possi-Moses N/A Creation of document

10/15/2023 Nick Possi-Moses Addition of functional Added Beta Test functionality

specifications Added MVP functionality

3
Introduction

Purpose of this document

myTABA is launching its next-generation machine-learning-enabled travel platform. This document is
intended for the developers and functional stakeholders of the myTABA platform who will design and
implement this system to use to validate the requirements

The specifications stated in this document are myTABA’s best understanding of the requested systems
requirements. Any changes to this document must be agreed upon by both parties.

Scope of this document

This document is divided into the following seven sections:

1. Introduction
o This section describes the overall objectives of myTABA and the problems it will solve.
It also describes the contractual obligations.
2. General Description
o This section provides an overview of the myTABA architecture.
3. Beta Test Business Requirements
o This section describes each beta test business requirement in greater detail, including
the functional specifications that comprise each business requirement.
4. MVP Business Requirements
o This section describes each MVP business requirement in greater detail, including the
functional specifications that comprise each business requirement.

Overview
myTABA is a web-based platform that provides users (hereon referred to as travelers) with an
interactive experience that presents personalized point-of-interest (POI) recommendations. Travelers
will be able to create profiles and interact with a recommendation system through an internal and
proprietary API.

Business Context
Travelers currently spend about 20 hours and visit 150 websites while planning a vacation. MyTABA will
provide a visually interactive environment which enables a traveler to rapidly obtain personalized POI
recommendations. This eliminates hours of research and provides a traveler with recommendations that
a traveler would not find using popularity-based recommenders.

4
General Description of Platform

Purpose of this document

myTABA will provide a web-based platform where travelers can interact with destinations and point-of-
interests to generate personalized recommendations for upcoming trips. Travelers can take a brief quiz
that generates personalized recommendations. Travelers can also interact with the quiz results to save
desired POIs or generated lists.

User Characteristics
Users of the myTABA platform are those people who are interested in travel and planning to take a trip.
Users are interested in planning a trip as opposed to contracting out to a third party vendor to plan a
trip for them. They desire autonomy and authority in trip-planning, yet want the ability to expedite
planning via personalized and curated recommendations.

User Problem Statement

The average traveler spends 20 hours planning a week-long trip. In the process of planning, they visit
over 140 different websites in order to design their own adventure. Trip-planning is exhausting - for
something that should be relaxing, the process is anything but!

User Objectives
User’s objective is to streamline trip-planning through a web-based platform. This will eliminate the
need to navigate through at least a hundred different web pages to curate content for an upcoming trip.

General Constraints
Not Applicable

Architecture Overview
MyTABA will utilize a microservice architecture to serve the business logic and data handling for the
website. These functions are complete, tested, and documented via the fastapi “swagger”. The
documentation is available here. The backend will be required to use and comply with the formatting of
each internal microservice API.

5
Beta Test Business Requirements

1. The myTABA website should be functional and meet the basic criteria for an effective online
presence

a. Description
The myTABA website should have the basic functionality that is present in all web pages,
including home page, about us, etc.

b. Functional Specification(s)
i. Home Page
● Clear and compelling brand identity
● Navigation menu with intuitive categorization
○ Home (logo) - left-aligned
○ My Recommendations - center-aligned
■ Conditionally shown when user takes a
recommendation quiz in the same session
■ Should fetch results from the user’s cache
○ Saved & Liked - center-aligned
○ Blog - center-aligned
○ About-Us - center-aligned
○ Log-in/Sign-up - right-aligned
● Three sections:
○ Engaging hero section with relevant imagery and concise tagline
■ Video background
■ Opaque call to action overlaying the video:
‘Find your next adventure’
○ Company introduction and product/service information
■ Find your next adventure in 5-minutes!
■ Get personalized recommendations
■ Save recommendations and view them later
○ Sign-up section
■ Call to action section to get new customers to sign-up
ii. About Us
● Information about the company’s history, mission, and value
○ Mission: Inspire wanderlust and global citizenship
○ Vision: To get travelers there and back again
● Personalized bios and photos of key team members
○ Ben
○ Nick
○ Rob
● Company’s achievements and milestones
○ Dynamic timeline (scroll left/right)
iii. Contact Us
● Contact form with fields for name, email, subject, and message
● Option for users to connect via social media

6
 iv. Blog
● Integration of wordpress site
v. Site-wide Navigation and Accessibility
● Consistent navigation structure across all pages
● Ensure accessibility for users with disabilities (compliance with WCAG
guidelines)
vi. SEO (Search Engine Optimization)
● Implement best practices for on-page SEO, including meta tags,
headers, and keyword optimization
vii. Analytics Integration
● Integration with Google Analytics for tracking user behavior
viii. Security
● Implement SSL encryption for data protection
ix. Mobile Responsiveness
● The website should be fully functional and visually appealing on various
screen sizes

c. Non-Functional Specification(s)
i. Performance
● Fast loading times and optimized media files for a smooth user
experience
ii. Scalability
● The website should be capable of handling increased traffic as the
business grows
iii. Browser Compatibility
● Compatibility with major browsers (Chrome, Firefox, Safari, etc.)

d. Design Requirements
i. Click Here

e. Key Deliverables
i. Deployed website - (www.mytaba.com)
ii. Code, with detailed comments

f. KPI(s)
i. Load Time - web page(s) should load in under 2 seconds
ii. Mobile Responsiveness - webpage(s) should perform on mobile and desktop
devices of different screen sizes.
iii. Browser Responsiveness - webpage(s) should perform on a variety of browsers

g. Testing and Quality Assurance

i. Load Time - user is able to load the website in under 2 seconds
ii. Navigation - user is able to navigate to each page as described in Business
Requirement 1.B.
iii. Navigation Load - user is able to navigate to each page as described in Business
Requirement 1.B. – the page should load in under 2 seconds
iv. Hero Section - user is able to view the videos in the hero section - there should
be no lag or delay

7
 v. Mobile Display - user is able to view the website on both mobile and desktop
without display issues
vi. Browser Display - user is able to view the website on a variety of different
websites without display issues
vii. Cosmetic/Display - identify cosmetic defects (or display issues)

h. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
1.G.

8
2. Users should be able to sign-up, log-in, and log-out of myTABA

a. Description
myTABA uses the Clerk for its user management and authentication functionality.
Specifically, Clerk is used for sign-up and log-in functionalities. Users should be able to
successfully login, logout, and sign-up for the myTABA website.

b. Functional Specification(s)
i. User should be able to sign-up for the myTABA website using the sign-up
functionality
● Required Fields:
○ First Name
○ Last Name
○ Username
○ E-mail address
○ Password
ii. User should be able to sign-up for the myTABA website using the following 3rd
party vendors:
● Google
● Facebook
iii. User should be able to reset their password
iv. User’s data should be stored in the myTABA database when they sign-up via the
microservice ‘check-traveler’ from section 4.
v. User should be driven to the page they are currently on upon successful login
vi. User should be driven to the myTABA home page upon successful log-out
vii. Updates to traveler profiles through Clerk to be propagated to myTABA system
database

c. Use Cases
i. User signs up to myTABA using email
ii. User signs up to myTABA using Gmail
iii. User signs up to myTABA using Facebook

iv. User logs into myTABA using existing email account

v. User logs into myTABA using existing Gmail account
vi. User logs into myTABA using existing Facebook account

vii. User logs out of myTABA using existing email account

viii. User logs out of myTABA using existing Gmail account
ix. User logs out of myTABA using existing Facebook account

x. User resets password using existing email account

xi. User resets password using existing Gmail account
xii. User resets password using existing Facebook account

d. Key Deliverables
i. Deployed website - (www.mytaba.com)

9
 ii. Code, with detailed comment

e. KPI(s)
i. User is able to log into myTABA using their email, G-Mail, and Facebook
accounts
ii. User is able to sign-up to myTABA using their email, G-Mail, and Facebook
accounts
iii. User is able to sign-out of their myTABA account
iv. User’s data is stored upon successful sign-up to myTABA via the microservice
‘check-traveler’ from section 4.

f. Testing and Quality Assurance

i. User signs up to myTABA using email
ii. User signs up to myTABA using Gmail
iii. User signs up to myTABA using Facebook

iv. User logs into myTABA using existing email account

v. User logs into myTABA using existing Gmail account
vi. User logs into myTABA using existing Facebook account

vii. User logs out of myTABA using existing email account

viii. User logs out of myTABA using existing Gmail account
ix. User logs out of myTABA using existing Facebook account

x. User is able to log-in to myTABA using different browsers

xi. User is able to log-out of myTABA using different browsers
xii. User is able to sign-up to my TABA using different browsers

xiii. User is able to log-in to myTABA using mobile and desktop device(s)
xiv. User is able to log-out of myTABA using mobile and desktop device(s)
xv. User is able to sign-up for myTABA using mobile and desktop device(s)

xvi. Cosmetic and display issues

xvii. Validations thrown when not all required fields are completed

g. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
2.G.

10
3. Users should be able to take a short quiz to get the myTABA platform to generate
personalized recommendations for them

a. Description
Users should be able to navigate to a page that enables them to take a short quiz. Upon
completion of that quiz, the myTABA platform will use the inputs to generate 15-
recommendations for them via myTABA’s proprietary algorithm.

b. Functional Specification(s)
i. Required components
● Select desired location from list
○ For Beta, up to 6 options should be shown
○ Only enable users to click the ‘Barcelona’ option
○ All other tiles, if any, should say ‘Coming Soon!’
○ Users should be able to request a new city by clicking a button
■ User should be driven to a textbox where they can
submit their request
■ The submission will be stored to the database
■ User should be able to click back to the main quiz
○ Upon submit of desired location, drive user to next question
● Select desired trip type
○ 6 options should be shown. These options are retrieved using
the ‘get-city’ microservice outlined in section 4.
■
○ User may select up to 3 options, no more
○ User must select at least one option to submit
○ Upon submit of desired trip type, drive user to next question
● Indicate interest of 5 different Points of Interest (POI)
○ POIs will be selected by running the ‘get-rec’ microservice
outlined in section 4.
○ User indicates on a likert scale their level of interest in the POI
that is shown to them
○ User must select their level of interest in the queued up POI in
order to submit
○ Upon submit, user should be driven to the next POI, if there is
any. If there are no remaining POIs, user should be driven to the
results page
● Upon completion of quiz, myTABA algorithm should be able to consume
the user-inputted data to generate recommendation(s) via the ‘get-rec’
microservice outlined in section 4.

11
 c. Design Requirements

The below image is a screenshot of the existing ‘quiz’ page; however, please note that we are open to
deviations from the look/feel of the quiz itself so long as it abides by the aforementioned requirements.

i. First screen of the quiz

12
ii. Second screen of the quiz

13
iii. Third screen of the quiz

14
iv. Fourth screen of the quiz

15
d. Use Cases
i. User takes quiz and completes it
ii. User submits new location
iii. User submits new location and returns to take quiz

e. Key Deliverables
i. Deployed website - (www.mytaba.com)
ii. Code, with detailed comments

f. KPI(s)
i. Load Time - quiz web page(s) should load in under 2 seconds
ii. Mobile Responsiveness - quiz webpage(s) should perform on mobile and
desktop devices
iii. Browser Responsiveness - quiz webpage(s) should perform on a variety of
browsers

g. Testing and Quality Assurance

i. User takes quiz and completes it
ii. User submits new location
iii. User submits new location and returns to take quiz
iv. User’s quiz inputs are stored in myTABA database
v. User’s quiz inputs are able to be consumed by the myTABA algorithm

h. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
1.G.

16
4. The myTABA microservices are required to run all data saving, data manipulation, and
recommendations.

a. Description
myTABA architecture is constructed through a series of microservices. These
microservices will run all business logic and data handling. These APIs are required to be
used. Backend will link in as required. No business logic will be conducted directly on the
backend. Documentation for the microservices can be viewed here.

b. Functional Specification(s)
i. Profile Quiz - microservices listed below in order of usage
● Scenario 1: User is not signed in and initiates the profile quiz
a. ‘get-city’ microservice will provide the cities 'topics that can be
selected with the S3 location of the image representing the
topic. Contractor is required to pull these images directly from
S3 for display.
b. ‘create-session’ microservice allows the traveler to initiate a
session given the topics selected. The original (oc) profile is
created from this.
c. ‘get-rec’ (without save parameter) microservice then is used to
retrieve a single POI that the user then can rate.
d. ‘update-session’ microservice takes the POI rating information
and makes alterations to the profile.
e. ‘get-rec’ and ‘update-session’ must be called x5 times to give
the traveler the opportunity to rate 5 different POIs.
f. ‘get-rec’ (with save parameter) microservice produces the final
recommendations to be displayed for the user.
g. ‘get-required’ microservice retrieves the information of the
required recommendations given the city. These will also be
displayed.
h. If Traveler attempts to save the session then the traveler will be
prompted to sign in via clerk
i. ‘check-traveler’ microservice is used to determine if this is a
returning or new user. Either way this service will return the
traveler_id.
j. ‘claim-session’ microservice allows the session to be claimed by
the now signed in traveler
● Scenario 2: User is signed in prior to initiating profile quiz
a. ‘check-traveler’ microservice is used to determine if this is a
returning or new user. Either way this service will return the
traveler_id.
b. Follow steps ‘a’ through ‘g’ in Scenario 1. The traveler_id can be
used to ‘claim’ the session in step ‘b’. this prevents the
requirement to do steps ‘i’ and ‘j’.
ii. Interactions with Recommendations
● The traveler will have the opportunity to interact with the
recommendations. Each interaction will need to utilize the following
microservices to ensure information is captured.

17
 a. ‘save-session’ microservice can only be utilized if the traveler is
logged in. This will ‘mark’ the session as saved and enable
retrieval for display on the ‘My Recommendations’ Page
b. ‘like-dislike’ microservice can be used with or without the
traveler having to be logged in. This enables the user to retrieve
liked POIs on the ‘My Recommendations’ Page.
iii. Displaying ‘My Recommendations’
● Signed in travelers will have the opportunity to view past ‘sessions’ and
liked POIs. All images must be retrieved through the S3 or utilizing
respective APIs as available.
a. ‘get-liked-pois’ microservice retrieves all POIs liked by that
particular traveler.
b. ‘get-saved-session-pois’ microservice retrieves all sessions
saved by that traveler.

c. Use Cases
1. Logged in travelers take profile quizzes, interact with recommendations, and
may wish to save recommendations.
2. Non-logged travelers take profile quizzes, interact with recommendations, and
may wish to save recommendations.
3. Logged in traveler wishes to view pasted recommendations or liked pois

d. Key Deliverables
i. No new microservices will be created by contractor
ii. Contractor will utilize microservices as prescribed in the web product

e. KPI(s)
i. Connection - 99.99% successful microservice interaction

f. Testing and Quality Assurance

i. Travelers do not trigger 400 errors when using the microservice
● myTABA will serve as testing ‘travelers’ to determine quality.

g. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
1.G.

18
5. Users should be able to view their recommendations

a. Description
On generation of recommendations upon completion of the quiz, the user should be
able to view the recommendations.

b. Functional Specification(s)
i. Display Recommendations to traveler for each request
● The web app should take the Recommendation API response as a JSON
file and send it to the web app for display.
● The web app should display the Recommendation API response to the
traveler
● The screen should be bifurcated such that the user can view their
personalized recommendations and ‘must-see’ recommendations on
one side of the screen and a map of those locations on the other side of
the screen
● The user should be able to ‘flip’ between the ‘Recommended for you’
and ‘Must-See’ POIs
● 15 personalized recommendations should be generated and displayed
to the user
● Each recommendation should include the following components:
a. POI Name (myTABA database)
b. POI Image (myTABA database)
c. POI Match % (myTABA database)
d. POI Rating (Google API)
e. POI Description (myTABA database)
f. POI Tag(s) (myTABA database)
g. Thumbs-up (like) and Thumbs-down (dislike) icons
● External API called (i.e. Google, Trip Advisor) will only be called once for
the duration that the traveler is viewing the results page.
a. Must conform to respective API terms and conditions.
● Users should be able to click the Thumbs-up and Thumbs-down icons.
When they are clicked, they should be colored-in to indicate selection
● If a traveler selects (or unselects) one of the Thumbs icons, the data (i.e.
‘Yes’/’No’) should be stored in the database
● Each saved recommendation list should be stored in a separate ‘Saved’
section tile on the ‘Saved & Liked’ page
● Each liked POI (Thumbs-up) should be stored in a separate ‘Liked’
section tile on the ‘Saved & Liked’ page

19
c. Design Requirements

Please note the following features as shown by the screenshot above:

1) The map is fully functional; the user may interact with the map
2) Each POI is plotted on the map
3) The ‘Recommended for you’ should be the default view; however, users may
click on the ‘Must See’ tab. Both tabs should look, feel, and behave the same
way.

20
d. Use Cases
i. User takes quiz and is shown their recommendations
ii. User views their recommended POIs
iii. User views the ‘must-see’ POIs for their desired location
iv. User toggles between their recommended and must-see POIs
v. User likes and unlikes a POI

e. Key Deliverables
i. Deployed website - (www.mytaba.com)
ii. Code, with detailed comment

f. KPI(s)
i. Load Time - web page(s) should load in under 2 seconds
ii. Mobile Responsiveness - webpage(s) should perform on mobile and desktop
devices
iii. Browser Responsiveness - webpage(s) should perform on a variety of browsers

g. Testing and Quality Assurance

Describes the testing process(es), including user-testing, functionality testing,
integration testing, etc. Define the acceptance criteria.

h. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
1.G.

21
6. Users should be able to save generated lists of POI recommendations

a. Description
myTABA enables users to save the list of their recommended POIs so that they can
return to it at a later time and view it. Users should be able to view the saved list by
navigating to the ‘Saved & Liked’ page.

b. Functional Specification(s)
i. On the web app, a traveler can save their recommendations to refer to later by
clicking the ‘Save Now’ button. This is referred to as a save request.
ii. If a traveler is signed in and if they click the ‘Save Now’ button, a save request
should be passed to the database and stored such that it is associated with the
traveler and their recommendations. This is completed by using the ‘save-
session’ microservice outlined in section 4.
iii. If a traveler is not signed in, the traveler should be prompted with the option to
sign in/sign up before the request is passed to the database. Once the traveler
has either signed in or signed up, they should be able to view the
recommendations.
iv. The recommendation should be stored in the browser cache for travelers to
refer to later if they return to the page and don’t request a new
recommendation

c. Use Cases
i. User navigates to the ‘Saved & Liked’ page to view their saved list.
ii. User is not logged in, takes the recommendation quiz, and tries to save the list.
User is prompted to sign-up or log-in. User logs in.
iii. User does not have an account, takes the recommendation quiz, and tries to
save the list. User is prompted to sign-up or log-in. User signs-up.
iv. User does not have an account, takes the recommendation quiz, and tries to
save the list. User is prompted to sign-up or log-in. User does not sign-up.
v. User is logged in, takes the recommendation quiz, and tries to save the list.

d. Key Deliverables
i. Deployed website - (www.mytaba.com)
ii. Code, with detailed comment

e. KPI(s)
i. User is able to save a recommendation list
ii. User’s recommendation list is associated to their account when they log-in/sign-
up
iii. User is able to view their previous recommendation list(s)

f. Testing and Quality Assurance

i. User is able to navigate to the ‘Saved & Liked’ page to view their saved list
ii. User is not logged in, takes the recommendation quiz, and tries to save the list.
User is prompted to sign-up or log-in. User logs in and their recommendation list
is associated with their account.

22
 iii. User does not have an account, takes the recommendation quiz, and tries to
save the list. User is prompted to sign-up or log-in. User signs-up and their
recommendation list is associated with their account.
iv. User does not have an account, takes the recommendation quiz, and tries to
save the list. User is prompted to sign-up or log-in. User does not sign-up and
the recommendation list is not associated with their account.
v. User is logged in, takes the recommendation quiz, and tries to save the list. User
is able to view the list in the ‘Saved & Liked’ page as it is associated with their
account.

g. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
1.G.

23
7. Users should be able to save individual POIs

a. Description
myTABA enables users to save a specific POI from their recommendation list so that
they can return to it at a later time and view it. Users should be able to view the saved
POIs by navigating to the ‘Saved & Liked’ page. Saved POIs are synonymous with Liked
POIs (i.e. when the user clicks the ‘Thumbs Up’ icon next to the POI).

b. Functional Specification(s)
i. On the web app, a traveler can like an individual POI to refer to later by clicking
the empty ‘Thumbs-up’ icon. The ‘Thumbs-up’ then shows as filled, alerting the
traveler of their action. This is referred to as a ‘like’ and results in a like request.
ii. On the web app, a traveler can unlike an individual POI and remove it from
referring to later by clicking the filled ‘Thumbs-up’ icon. The ‘Thumbs-up’ icon
then shows as unfilled, alerting the traveler of their action. This is referred to as
an ‘unlike’ and results in an unlike request.
iii. If a traveler is signed in and if they click the ‘Thumbs-up’ or ‘Thumbs-down’
icons, a save request should be passed to the database and stored such that it is
associated with the traveler.
● If a traveler is not signed in, the traveler should be prompted with the
option to sign in/sign up before the request is passed to the database.
Once the traveler has either signed in or signed up, the request should
be passed to the database and stored such that it is associated with the
traveler.
●
iv. An unlike request can be fulfilled on both the ‘Recommendations’ page and the
‘Saved & Liked’ page
v. Any ‘liked’ or ‘unliked’ interactions will be captured in via the ‘like-dislike’
microservice outlined in section 4.

c. Use Cases
i. User navigates to the ‘Saved & Liked’ page to view their liked POIs
ii. User is not logged in, takes the recommendation quiz, and tries to like a POI.
User is prompted to sign-up or log-in. User logs in.
iii. User does not have an account, takes the recommendation quiz, and tries to like
a POI. User is prompted to sign-up or log-in. User signs-up.
iv. User does not have an account, takes the recommendation quiz, and tries to like
a POI. User is prompted to sign-up or log-in. User does not sign-up.
v. User is logged in, takes the recommendation quiz, and tries to like a POI.

d. Key Deliverables
i. Deployed website - (www.mytaba.com)
ii. Code, with detailed comment
e. KPI(s)
i. User is able to like and dislike a recommended POI from both the ‘Saved &
Liked’ page as well as the recommendation list.
ii. User’s liked and/or disliked POI is associated to their account when they
log-in/sign-up

24
 iii. User is able to view their liked POIs

f. Testing and Quality Assurance

i. User is able to navigate to the ‘Saved & Liked’ page to view their liked POIs.
ii. User is not logged in, takes the recommendation quiz, and tries to like and
dislike a POI. User is prompted to sign-up or log-in. User logs in and their liked
(or dislike) POI is associated with their account.
iii. User does not have an account, takes the recommendation quiz, and tries to like
and dislike a POI. User is prompted to sign-up or log-in. User signs-up and their
liked (or dislike) POI is associated with their account.
iv. User does not have an account, takes the recommendation quiz, and tries to like
and dislike a POI. User is prompted to sign-up or log-in. User does not sign-up
and the liked/disliked POi(s) are not associated with their account.
v. User is logged in, takes the recommendation quiz, and tries to like and dislike a
POI. User is able to view the list in the ‘Saved & Liked’ page as it is associated
with their account.

g. Maintenance and Support

i. Defects - defects identified during testing (within one week of delivering the
website) are to be handled by the development team, free of cost. This includes
functionality and cosmetic issues identified, as outlined in Business Requirement
1.G.

25
Conclusion

Payment Schedule
Service provider will invoice myTABA in installments as set forth below:

a) 50% of total payment upon delivery of 50% of all business requirements defined by scope
b) 50% of total payment upon delivery of 100% of all business requirements defined by scope

Agreed and Accepted

Service Provider, Printed Service Provider, Signature Date

myTABA Co-Founder, Printed myTABA Co-Founder, Signature Date

myTABA Co-Founder, Printed myTABA Co-Founder, Signature Date

myTABA Co-Founder, Printed myTABA Co-Founder, Signature Date

26