Exploring the Future Potential of AI-Enabled Smartphone Processors
Itinerary Analysis and Design
1. ANALYSIS AND DESIGN
DOCUMENT
FOR
TRAVEL ITINERARY PROJECT
Functional Requirements, Use Case Diagram, Use Case Description and Class Diagram
Created by Team Members
Reviewed by Team Members
Module: Web Application Design and Modeling (WDAM)
Created Date 25 Dec 2011
Assignment: Final Assignment (Itinerary 2012 project) Revised Date 12 Jan 2012
Revision No. 3.1
Team Name: As a Whole
Document Name F01-001
Use the link below to submit your project plans. If link doesn't work you can email your submissions to d.shadija@shu.ac.uk
3. 3 1) FUNCTIONAL REQUIREMENTS
Functional Requirements
Registered user can create and manage travel itineraries (Trip information).
Registered user can add and manage itinerary items (Trip Details) as following; flight, train,
cruise, hire car, hotel, activity and restaurant.
Registered user can shared own itineraries to other people as three mode; PUBLIC, PRIVATE
and FRIEND (Assumption).
Registered user can shared note of own particular itinerary to view and post by other people
as three mode; PUBLIC, PRIVATE and FRIEND (Assumption).
Registered user can view shared itineraries that he/she has permission.
Registered user can view and post note on shared itineraries which he/she has a permission.
Registered user can print own itinerary to use for travelling (Assumption).
Registered user can add friends, accept/reject friends who are members of the itinerary
website.
Registered user can send e-mail to invite friends in order to join the Itinerary website.
Registered user can share an own itinerary to friends for updating together.
Registered user can search activities and restaurants where are near his/her hotel or
accommodation by using with Google map.
4. 1) FUNCTIONAL REQUIREMENTS
4
( CONT.)
Functional Requirements (Cont.)
Guest and registered user can view public itineraries (Assumption).
Guest and registered user can view travelling trips posted by trip managers (Assumption).
Trip manager can add and manage trips to advertise on the website (Assumption).
System can support three user’s roles; user, admin staff and trip manager (Assumption).
Admin staff can maintain trip manager account ( He can promote the role from the normal
user to trip manager, and put more information such as company name and address)
(Assumption).
System can support registration of user account, editing profile, changing password, login
and log-off functions.
System can support web browser on mobile equipment (Assumption).
8. 8 3) USE CASE DESCRIPTION
Use case ID: 1 Use case ID: 2
User Case: Create Itinerary User Case: View own Itinerary
Actor: Registered-user Actor: Registered-user
Pre-condition: User logins to system and Pre-condition: User logins to system and select
selects “create itinerary” “view own itinerary”
Goal: To create Itinerary header in order Goal: To view an own itinerary details
to fill trip information in order to manage trip
information.
Main path:
1. User enters itinerary header details. Main path:
2. User selects privacy (public, private or friend). 1. System shows list of own itineraries.
3. User saves itinerary. 2. User chooses an own itinerary.
3. System show the selected itinerary with details.
Alternative path:
3.1 If there is an error, user will be asked to re-enter details. Post-condition:
1. The selected itinerary is previewed with details and ready to
Post-condition: add itinerary details (trip information) and mange that itinerary.
1. A new itinerary is created and redirect to itinerary details page.
9. 9 3) USE CASE DESCRIPTION
Use case ID: 3 2.5 If user clicks add “hotel”
User Case: Maintain Itinerary Item .1 User enter hotel details
Actor: Registered-user .2 User saves details
Pre-condition: User logins to system and selects 2.6 If user clicks add “restaurant”
an itinerary which has permission. .1 User enter restaurant details
Goal: To insert, update and delete .2 User saves details
itinerary header and itinerary 2.8 If user clicks “add meeting”
items. .1 User enters meeting details
Main path: .2 User saves details
1. User views and selects an itinerary. 2.9 If user clicks “add activity”
2. System shows itinerary details. .1 User enter activity details
.2 User saves details
Alternative path: 2.10 If user clicks “delete itinerary”
2.1 If user clicks “add flight” .1 User confirms deleting
.1 User enters flight details .2 System deletes itinerary
.2 User saves details 2.11 If use click “edit itinerary item”
2.2 If user clicks “add train” .1 System shows itinerary details
.1 User enter train details .2 User updates details
.2 User saves details .3 User saves details.
2.3 If user clicks “add cruise”
.1 User enter cruise details Post-condition:
.2 User saves details 1. System operates all changes and return to view itinerary details
2.4 If user clicks “add hire car” page.
.1 User enter hire car details
.2 User saves details
10. 10 3) USE CASE DESCRIPTION
Use case ID: 4 Use case ID: 5
User Case: Set Itinerary Privacy User Case: Post Note
Actor: Registered-user Actor: Registered-user
Pre-condition: User logins to system Pre-condition: User logins to system
and selects an itinerary which has and selects an itinerary which has
permission. permission.
Goal: To set itinerary privacy Goal: To post note for sharing to
or note privacy. view by other people who have
permission.
Main path:
1. User searches and selects an itinerary. Main path:
2. User changes privacy 1. User searches and selects an itinerary.
3. Uses clicks save 2. System shows itinerary details.
3. User selects “post note”
Alternative path: 4. System shows note(s) posted on the selected itinerary and text
3.1 If user changes “itinerary privacy” boxes to fill a new note.
.1 System saves privacy of itinerary into system 5. User enters note details.
3.2 If user changes “note privacy” 6. User saves note.
.1 System save privacy of note into system
Post-condition:
Post-condition: 1. A new note is created on the selected itinerary which can be
1. The privacy is changed on the selected itinerary. viewed by other people who have permission.
11. 11 3) USE CASE DESCRIPTION
Use case ID: 6 Use case ID: 7
User Case: Search Google map User Case: Invite friend
Actor: Registered-user Actor: Registered-user
Pre-condition: User logins to system and Pre-condition: User logins to system.
selects an itinerary which has Goal: To invite a friend who is a
hotel information. registered or non-register user.
Goal: To search restaurants and
activities near by a hotel Main path:
or accommodation 1. User selects “Friends” menu
Main path: Alternative path:
1. User views and selects an itinerary which has hotel information. 1.1 User selects “add friend” who is registered user
2. User selects search restaurants or activities .1 System shows list of friends.
3. System uses location and post code as keyword to search. .2 User clicks invite friend.
4. System links to Google map website with those keywords and .3 System sets status as “WAITING”
show nearby activities or restaurants on Google map site. 1.2 User selects “send e-mail to invite friend” who is non-registered
user.
Alternative path: .1 User enters e-mail address and content.
4.1 If user selects “search restaurants” .2 User clicks send e-mail to invite.
.1 System shows nearby restaurants on map .3 System sends e-mail to the invited friend.
.2 User find details of nearby restaurants on map Post-condition:
4.2 If user selects “search activities” 1. A friend (registered user) is invited or a friend (non-register user)
.1 System shows nearby activities on map will receive e-mail from system to join itinerary website.
.2 User find details of nearby activities on map
Post-condition:
1. System shows restaurants or activities on Google map website
using keywords from hotel information.
12. 12 3) USE CASE DESCRIPTION
Use case ID: 8 Use case ID: 9
User Case: Mange friend User Case: Print Itinerary
Actor: Registered-user Actor: Registered-user
Pre-condition: User logins to system. Pre-condition: User logins to system and select
Goal: To accept/reject, remove an itinerary
a friend (unfriend) Goal: To print selected itinerary details
Main path: Main path:
1. User selects a friend menu. 1. User searches and selects an itinerary.
2. System shows list of friends. 2. System shows itinerary details.
3. User selects print itinerary.
Alternative path: 4. System shows printing preview page.
1.1 If user selects “Accept/reject” 5. User click confirms to print.
.1 System shows list of friends who adds you as 6. System prints trip information out.
a friend.
1.2 If user selects “See friend list” Alternative path:
. 1 System shows all of your friends. 5.1 If User click “cancel to print”
1.3 If user selects “request friend status” .1 System closes printing preview page
.1 System shows status of friends invited by you. .2 System redirects to preview itinerary page.
2.1 if user selects “accept friend”
.1 System adds that friend to your list of friends. Post-condition:
2.2 if user selects “reject to friend” 1. The itinerary is printed out via a selected printer.
.1. System marks as reject to that friend.
2.3 If user selects “remove friend”
.1 System removes friend (unfriend) from your
friend list.
Post-condition:
1. Friend status is updated.
13. 13 3) USE CASE DESCRIPTION
Use case ID: 10 Use case ID: 11
User Case: Share itinerary account User Case: Send e-mail
Actor: Registered-user Actor: System
Pre-condition: User logins to system Pre-condition: Once new user is created or a
and selects an itinerary. non-registered friend is invited by
Goal: To add or cancel a friend in order registered user.
to update itinerary together Goal: To send e-mail from system.
Main path: Main path:
1. User views and selects an own itinerary. 1. System receives e-mail information.
2. User clicks “manage friend to update this trip” 2. System sends e-mail out.
3. System shows list of friends.
4. User clicks “add friend” or “cancel friend” Alternative path:
1.1 If system receives information from register user page.
Alternative path: .1 System uses e-mail subject as Welcome details
3.1 If friend was already added to share before 1.2 If system receives information from invited page.
.1 System shows “cancel friend to update this trip” .1 System uses e-mail subject about invitation to
button on that showed record. join website.
3.2 If friend was not already added to share .2 System provides inviter information and
.1 System shows “add friend to update this trip” link which is easy to register on e-mail
button on that showed record. content.
4.1 If user clicks “add friend to update this trip”
.1 System adds permission to update that itinerary. Post-condition:
4.2 If user clicks “cancel friend to update this trip” 1. E-mail is sent from system and sending e-mail log is recorded.
.1 System cancels permission to update that
itinerary.
Post-condition:
1. The sharing permission for update together is updated.
14. 14 3) USE CASE DESCRIPTION
Use case ID: 12 Use case ID: 13
User Case: Login User Case: Register account
Actor: Registered-user Actor: Guest
Pre-condition: User opens the website or tries to Pre-condition: User opens the website.
access a non-permission page. Goal: To register itinerary website and
Goal: Login to System to use specific use itinerary features.
itinerary pages following Main path:
permission. 1. User opens the homepage.
2. User selects “Register User”
Main path: 3. User provides personal details.
1. User enters user name/e-mail and password. 4. System validates personal details.
2. User clicks login. 5. System records User.
3. System validates user name and password. 6. System sends e-mail to user.
4. System redirect to home page or previous page which is
redirected to login. Alternative path:
4.1 If User name is already used
Alternative path: .1 System notices that user is already used.
3.1 If Username does not exist .2 User fills user name again.
.1 system asks user to check username. 4.2 If user enters different password and confirmed password.
.2 User re-enters the username. .1 System notices that passwords are different.
3.2 If the password is incorrect .2 User fills password again.
.1 System asks user to check password.
.2 user re-enters the password Post-condition:
3.3 If user click cancel 1. User profile is created and an email confirmation is sent to the
.1 System returns to homepage. user’s email address.
Post-condition:
1. User logs onto system and able to use specific pages based on
permission and role.
15. 15 3) USE CASE DESCRIPTION
Use case ID: 14 Use case ID: 15
User Case: View public itinerary User Case: View travel trip
Actor: Guest Actor: Guest
Pre-condition: Guest opens website. Pre-condition: Guest open website.
Goal: To preview public itinerary and Goal: To preview details of trips posted
details. by by travel agencies.
Main path:
1. Guest selects view public itinerary. Main path:
2. System shows public list of itineraries. 1. Guest selects view travel trip.
3. Guest selects an itinerary 2. System shows list of travelling trips.
4. System shows selected itinerary details 3. Guest selects a trip.
4. System shows selected trip details.
Post-condition:
1. Public itinerary information is shown. Post-condition:
1. Travelling trip information is shown.
16. 16 3) USE CASE DESCRIPTION
Use case ID: 16 Use case ID: 17
User Case: Maintain agency User Case: Maintain travelling trip
Actor: Admin staff Actor: Trip manager
Pre-condition: Login as admin role Pre-condition: Login as trip manager role
Goal: To create, edit, delete Goal: To add, delete and update
a trip manager account a travelling trip.
Main path: Main path:
1. Admin staff selects “add trip manager” 1. Trip manager chooses create or view itinerary.
2. System shows list of users.
3. Admin staff selects a user. Alternative path:
4. Admin staff fills trip manager information such as company. 1. If a trip manager chooses “create itinerary”
5. Admin saves information. .1 Trip manager enters itinerary header.
.2 Trip manager adds itinerary details.
Alternative path: .3 Trip manager saves details.
2.1 If admin chooses “create trip manager” 2. If a trip manager chooses “view itinerary”
.1 Admin staff enters trip manager details. .1 System shows selected itinerary details.
.2 Admin staff saves information. .1 If a trip manager click “edit itinerary”
2.2 If admin chooses “cancel trip manager” .1 Trip manager edits itinerary details.
.1 System will change role from trip manager to normal .2 Trip manager saves details.
user .2 If a trip manager chooses “ delete itinerary”
2.3 If admin chooses “edit trip manager” .1 System asks to confirm deleting.
.1 Admin staff updates trip manager details. .1 If trip manager confirms deleting
.2 Admin saves information. .1 itinerary is deleted.
.2 If trip manager cancel.
Post-condition: .1 System redirects to view travelling trip page.
1. Trip manager details are updated. Post-condition:
1. Travelling trip information is updated.