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-001Use the link below to submit your project plans. If link doesnt work you can email your submissions to firstname.lastname@example.org
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.
1) FUNCTIONAL REQUIREMENTS4 ( 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 3) USE CASE DESCRIPTIONUse case ID: 1 Use case ID: 2User Case: Create Itinerary User Case: View own ItineraryActor: Registered-user Actor: Registered-userPre-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 toPost-condition: add itinerary details (trip information) and mange that itinerary.1. A new itinerary is created and redirect to itinerary details page.
9 3) USE CASE DESCRIPTIONUse case ID: 3 2.5 If user clicks add “hotel”User Case: Maintain Itinerary Item .1 User enter hotel detailsActor: Registered-user .2 User saves detailsPre-condition: User logins to system and selects 2.6 If user clicks add “restaurant” an itinerary which has permission. .1 User enter restaurant detailsGoal: 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 detailsMain path: .2 User saves details1. 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 detailsAlternative 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 details2.4 If user clicks “add hire car” page. .1 User enter hire car details .2 User saves details
10 3) USE CASE DESCRIPTIONUse case ID: 4 Use case ID: 5User Case: Set Itinerary Privacy User Case: Post NoteActor: Registered-user Actor: Registered-userPre-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 text3.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 be1. The privacy is changed on the selected itinerary. viewed by other people who have permission.
11 3) USE CASE DESCRIPTIONUse case ID: 6 Use case ID: 7User Case: Search Google map User Case: Invite friendActor: Registered-user Actor: Registered-userPre-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” menuMain path: Alternative path:1. User views and selects an itinerary which has hotel information. 1.1 User selects “add friend” who is registered user2. 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 mapPost-condition:1. System shows restaurants or activities on Google map website using keywords from hotel information.
12 3) USE CASE DESCRIPTIONUse case ID: 8 Use case ID: 9User Case: Mange friend User Case: Print ItineraryActor: Registered-user Actor: Registered-userPre-condition: User logins to system. Pre-condition: User logins to system and selectGoal: To accept/reject, remove an itinerary a friend (unfriend) Goal: To print selected itinerary detailsMain 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 3) USE CASE DESCRIPTIONUse case ID: 10 Use case ID: 11User Case: Share itinerary account User Case: Send e-mailActor: Registered-user Actor: SystemPre-condition: User logins to system Pre-condition: Once new user is created or a and selects an itinerary. non-registered friend is invited byGoal: 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 details3.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 3) USE CASE DESCRIPTIONUse case ID: 12 Use case ID: 13User Case: Login User Case: Register accountActor: Registered-user Actor: GuestPre-condition: User opens the website or tries to Pre-condition: User opens the website. access a non-permission page. Goal: To register itinerary website andGoal: 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 usedAlternative 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 3) USE CASE DESCRIPTIONUse case ID: 14 Use case ID: 15User Case: View public itinerary User Case: View travel tripActor: Guest Actor: GuestPre-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 3) USE CASE DESCRIPTIONUse case ID: 16 Use case ID: 17User Case: Maintain agency User Case: Maintain travelling tripActor: Admin staff Actor: Trip managerPre-condition: Login as admin role Pre-condition: Login as trip manager roleGoal: 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.