Hình II-15. Sơ đồ khai thác “Hồn tiền cho khách hàng”. Use Case ID UC 11
Use Case Description Chức năng này giúp Bộ phận kế tốn thực hiện hồn tiền cho kháchhàng. Actor(s) Bộ phận kế toán.
Priority Must have.
Trigger Bộ phận kế tốn chọn chức năng hồn tiền.
Pre-Condition(s) Bộ phận kế tốn có tài khoản đăng nhập vào hệ thống và cần hoàntiền cho khách hàng. Post-Condition(s) - Hệ thống thơng báo hồn tiền thành cơng.
Basic Flow
1. Bộ phận kế tốn chọn “Danh mục các tour yêu cầu hủy”. 2. Hệ thống hiển thị danh sách các tour yêu cầu hủy.
3. Bộ phận kế toán nhấn vào tour cần hủy.
4. Bộ phận kế tốn tính tốn chi phí hủy/ phát sinh và số tiền hoàn. 5. Bộ phận kế tốn cập nhật phần chi phí.
6. Tiến hành thanh tốn tiền hồn theo hình thức thanh tốn tour ban đầu.
7. Bộ phận kế tốn cập nhật trạng thái “Đã hồn tiền” và nhấn “cập nhật”.
8. Hệ thống thơng báo cập nhật thành cơng.
Alternative Flow Khơng có.
Exception Flow Khơng có.
Business Rule Khơng có.
Non-Functional
Requirement Khơng có.
II.3.2 Cập nhật thanh tốn của Khách hàng
Hình II-16. Sơ đồ khai thác “Cập nhật thanh toán của Khách hàng”. Use Case ID UC 12
Use Case Name Cập nhật thanh toán của khách hàng.
Use Case Description Chức năng này giúp Bộ phận kế toán cập nhật các thanh toán củakhách hàng. Actor(s) Bộ phận kế toán.
Trigger Bộ phận kế toán chọn chức năng cập nhật thanh tốn khách hàng.
Pre-Condition(s) Bộ phận kế tốn có tài khoản đăng nhập vào hệ thống và cần cậpnhật các thanh toán lên hệ thống.
Post-Condition(s) - Hệ thống hiển thị danh sách các thanh tốn.
- Hệ thống thơng báo cập nhật thành cơng.
Basic Flow
1. Bộ phận kế tốn chọn “Danh sách các thanh toán của khách hàng”.
2. Hệ thống hiển thị danh sách các thanh toán của khách hàng. 3. Bộ phận kế toán nhấn vào thanh toán cần cập nhật.
4. Hệ thống hiển thị chi tiết thơng tin thanh tốn tour của khách hàng.
5. Bộ phận kế tốn kiểm tra thơng tin. 6. Bộ phận kế toán nhấn “cập nhật”. 7. Hệ thống thơng báo cập nhật thành cơng.
Alternative Flow Khơng có.
Exception Flow
5a. Thơng tin khơng chính xác.
5a1. Gửi mail/thơng báo Khách hàng về việc sai thông tin và yêu cầu khách hàng cập nhật thơng tin chính xác.
Use case dừng lại.
Business Rule BR1.12: Khách hàng khơng cập nhật lại thơng tin chính xác trongvòng 24 giờ, tour của Khách hàng sẽ bị hủy. Non-Functional
II.4 Tác nhân “Bộ phận Dịch vụ khách hàng & Quản lý chất lượng”
Hình II-17. Sơ đồ khai thác của tác nhân “Bộ phận Dịch dụ khách hàng & Quản lý chất lượng”.
II.4.1 Quản lý thơng tin khách hàng
Hình II-18. Sơ đồ khai thác “Quản lý thông tin khách hàng”. Use Case ID UC 13
Use Case Name Quản lý thông tin khách hàng.
Use Case Description
Bộ phận giao dịch khách hàng và quản lý chất lượng cần quản lý danh sách thông tin khách hàng với các thao tác như: Tạo/Xem/Sửa/Xóa dữ liệu
khách hàng trong danh sách khách hàng.
Actor(s) Bộ phận giao dịch khách hàng và quản lý chất lượng.
Priority Must Have.
Trigger Bộ phận giao dịch khách hàng và quản lý chất lượng mở danh sáchthông tin khách hàng.
Pre-Condition(s) Bộ phận giao dịch khách hàng và quản lý chất lượng có tài khoản vàdanh sách khách hàng. Post-Condition(s) - Danh sách thông tin khách hàng.
Basic Flow
1. Bộ phận giao dịch khách hàng và quản lý chất lượng chọn chức năng chọn quản lý danh sách khách hàng.
2. Hệ thống hiện danh sách khách hàng và các chức năng: Tạo, Sửa, Xóa.
3. Bộ phận giao dịch khách hàng và quản lý chất lượng chọn “tạo mới”.
4. Hệ thống sẽ mẫu để nhập thông tin khách hàng.
5. Bộ phận giao dịch khách hàng và quản lý chất lượng sẽ nhập thông tin vào và nhấn nút “Lưu”.
6. Hệ thống xác nhận thông tin. 7. Hệ thống lưu thông tin khách hàng.
Alternative Flow
3a. Bộ phận giao dịch khách hàng và quản lý chất lượng chọn “Sửa”. 3a1. Bộ phận giao dịch khách hàng và quản lý chất lượng chọn tên khách hàng muốn sửa từ danh sách khách hàng.
4a. Hệ thống hiện mẫu thông tin của khách hàng đó.
5a. Bộ phận giao dịch khách hàng và quản lý chất lượng sửa thông tin lại cho phù hợp và nhấn nút “Lưu”.
Use case tiếp tục bước 6.
3b. Bộ phận giao dịch khách hàng và quản lý chất lượng chọn “Xóa”.
3b2. Bộ phận giao dịch khách hàng và quản lý chất lượng chọn khách hàng cần xóa và nhấn nút “Xóa”.
4b. Hệ thống hiển thị thơng báo xác nhận loại bỏ.
4b1. Nếu Bộ phận giao dịch khách hàng và quản lý chất lượng nhấn nút “đồng ý”, hệ thống hiển thị thơng báo “khách hàng này đã được xóa”. Nếu Bộ phận giao dịch khách hàng và quản lý chất lượng nhấn nút “không đồng ý”, hệ thống hiển thị lại danh sách khách hàng.
Use case dừng lại.
Exception Flow
6c. Hệ thống xác nhận thông tin không thành công.
6c1. Người dùng kiểm tra, điền lại các thơng tin cho chính xác.
Use case tiếp tục bước 7.
Business Rule Khơng có.
Non-Functional
II.4.2 Phản hồi feedback/khiếu nại
Hình II-19. Sơ đồ khai thác “Phản hồi feedback/khiếu nại”. Use Case ID UC 14
Use Case Name Phản hồi feedback/khiếu nại.
Use Case Description Bộ phận Dịch vụ khách hàng và Quản lý chất lượng phản hồi lạinhững feedback/khiếu nại của khách hàng. Từ đó, cải thiện hệ thống hơn.
Actor(s) Bộ phận Dịch vụ khách hàng và Quản lý chất lượng.
Priority Must have.
Trigger Bộ phận Dịch vụ khách hàng và Quản lý chất lượng chọn chức năngphản hồi feedback/khiếu nại từ khách hàng.
Pre-Condition(s) Bộ phận Dịch vụ khách hàng và Quản lý chất lượng phải truy cập vàhệ thống và có danh sách khách hàng. Post-Condition(s) - Hệ thống hiển thị thông báo “Đã gửi phản hồi thành công”.
Basic Flow
1. Bộ phận Dịch vụ khách hàng và Quản lý chất lượng truy cập và hệ thống và chọn vào chức năng “feedback/khiếu nại”.
2. Hệ thống hiển thị danh sách khách hàng gửi feedback/khiếu nại. 3. Bộ phận Dịch vụ khách hàng và Quản lý chất lượng chọn tên khách hàng muốn gửi phản hồi.
4. Hệ thống hiển thị cuộc trị chuyện với khách hàng đó.
5. Bộ phận Dịch vụ khách hàng và Quản lý chất lượng nhập nội dung phản hồi và nhấn nút “Gửi”.
6. Hệ thống hiển thị thông báo “Đã gửi phản hồi thành công”.
Alternative Flow
1a. Bộ phận Dịch vụ khách hàng và Quản lý chất lượng phản hồi feedback/khiếu nại qua hotline.
1a1. Hệ thống ghi âm và cập nhật vào danh sách cuộc gọi phản hồi khách hàng.
Use case dừng lại
Business Rule Khơng có.
Non-Functional
Requirement Khơng có.
II.5 Tác nhân “Bộ phận hệ thớng phân phới”
II.5.1 Xử lý hồ sơ đăng ký đại lý
Hình II-21. Sơ đồ khai thác “Xử lý hồ sơ đăng ký đại lý”. Use Case ID UC 15
Use Case Name Xử lý hồ sơ đăng ký đại lý.
Use Case Description Bộ phận Hệ thống phân phối xử lý hồ sơ đăng ký đại lý. Actor(s) Bộ phận Hệ thống phân phối.
Priority Must Have.
Trigger Bộ phận Hệ thống phân phối có tài khoản để đăng nhập vào hệthống.
Pre-Condition(s) Bộ phận Hệ thống phân phối truy cập vào hệ thống và chọn danhsách hồ sơ đăng ký đại lý. Post-Condition(s) - Hệ thống hiển thị “Kết quả đăng ký đại lý được gửi thành công”. Basic Flow 1. Bộ phận Hệ thống phân phối chọn Danh sách hồ sơ đăng ký đại
lý.
2. Hệ thống hiển thị danh sách các hồ sơ đăng ký đại lý. 3. Người dùng nhấn vào hồ sơ cần xử lý.
4. Hệ thống hiển thị chi tiết hồ sơ đăng ký đại lý.
5. Bộ phận Hệ thống phân phối xem xét và xác thực thông tin đăng ký đại lý hợp lệ.
6. Bộ phận Hệ thống phân phối chọn “Lưu" thông tin đăng ký đại lý thành công.
7. Hệ thống hiển thị trạng thái xử lý hồ sơ đăng ký. 8. Bộ phận Hệ thống phân phối nhấn “Gửi kết quả". 9. Hệ thống hiển thị thông báo xác nhận.
10. Người dùng chọn “Đồng ý".
11. Hệ thống gửi thông tin kết quả đăng ký đại lý cho bên đăng ký.
Alternative Flow
5a. Bộ phận Hệ thống phân phối xem xét và xác thực thông tin đăng ký đại lý không hợp lệ.
6a. Bộ phận Hệ thống phân phối chọn “Huỷ bỏ" thông tin đăng ký đại lý.
7a Hệ thống hiển thị trạng thái xử lý hồ sơ đăng ký.
8a Bộ phận Hệ thống phân phối nhập nguyên nhân hồ sơ không hợp lệ vào ô “Lý do hồ sơ không hợp lệ" và nhấn “Gửi kết quả".
Use case tiếp tục bước 9.
Exception Flow 10b. Người dùng chọn “Bỏ qua".
Use case trở lại bước 5.
Business Rule Khơng có.
Non-Functional
Requirement Khơng có.
II.5.2 Quản lý thơng tin đại lý
Hình II-22. Sơ đồ khai thác “Quản lý thông tin đại lý”. Use Case ID UC 16
Use Case Name Quản lý thông tin đại lý
Use Case Description Bộ phận Hệ thống phân phối cần quản lý danh sách thơng tin đại lývới các thao tác như: Tạo/Xem/Xóa/Sửa đại lý trong danh sách đại lý.
Priority Must have.
Trigger Bộ phận Hệ thống phân phối mở danh sách thông tin đại lý.
Pre-Condition(s) Bộ phận Hệ thống phân phối có tài khoản và danh sách đại lý. Post-Condition(s) - Danh sách thông tin đại lý.
Basic Flow
1. Bộ phận Hệ thống phân phối chọn chức năng chọn quản lý danh sách đại lý.
2. Hệ thống hiện danh sách đại lý và các chức năng: Tạo, Sửa, Xóa.
3. Bộ phận Hệ thống phân phối chọn “Tạo mới”. 4. Hệ thống sẽ hiển thị mẫu để nhập thông tin đại lý.
5. Bộ phận Hệ thống phân phối sẽ nhập thông tin vào và nhấn nút “Lưu”.
6. Hệ thống xác nhận thông tin.
7. Lưu thông tin đại lý và hiển thị danh sách đại lý.
Alternative Flow
3a. Bộ phận Hệ thống phân phối chọn “Sửa”.
3a1. Bộ phận Hệ thống phân phối chọn tên đại lý muốn sửa từ danh sách đại lý.
4a. Hệ thống hiện mẫu thơng tin của đại lý đó.
5a. Bộ phận Hệ thống phân phối sửa thông tin lại cho phù hợp và nhấn nút “Lưu”.
Use case tiếp tục bước 6.
3b. Bộ phận Hệ thống phân phối chọn “Xóa”.
3b1. Người dùng chọn đại lý cần xóa và nhấn nút “Xóa”. 3b2. Hệ thống hiển thị thông báo xác nhận.
3b3. Nếu người dùng nhấn nút “Đồng ý”, hệ thống hiển thị thông báo “Đại lý này đã được xóa”. Nếu người dùng nhấn nút “khơng đồng ý”, hệ thống hiển thị lại danh sách đại lý.
Use case dừng lại.
Exception Flow
6c. Hệ thống xác nhận thông tin không hợp lệ.
6c1. Bộ phận Hệ thống phân phối kiểm tra, điền lại các thơng tin cho chính xác.
Use case tiếp tục bước 7.
Business Rule Khơng có.
Non-Functional
II.6 Tác nhân “Nhân viên phụ trách tour”
II.6.1 Huỷ tour
Hình II-24. Sơ đồ khai thác “Hủy tour”. Use Case ID UC 17
Use Case Name Hủy Tour.
Use Case Description Nhân viên phụ trách tour thực hiện huỷ tour khách hàng đã đặt.
Đại lý thực hiện huỷ tour khi có nhu cầu.
Actor(s) Nhân viên phụ trách tour, Đại lý.
Priority Must Have.
Trigger Nhân viên phụ trách tour/Đại lý chọn chức năng hủy Tour.
Pre-Condition(s) Nhân viên phụ trách tour/ Đại lý có tài khoản và đã đặt Tour thànhcông. Post-Condition(s) - Thông báo “Tour đã được xử lý thành công”.
Basic Flow 1. Người dùng chọn chức năng “Huỷ tour”.
2. Hệ thống hiển thị các yêu cầu huỷ tour từ khách hàng cần xử lý. 3. Người dùng chọn Tour muốn huỷ.
5. Người dùng điền vào ơ “Chi phí huỷ" sau đó nhấn “Cập nhật”. 6. Hệ thống lưu lại thơng tin về chi phí huỷ tour.
7. Người dùng chọn “Gửi”.
8. Hệ thống hiển thị thơng báo gửi chi phí huỷ. 9. Người dùng nhấn “Đồng ý".
10.Hệ thống tiến hành gửi thông tin chi phí huỷ đến cho khách hàng và bộ phận kế tốn để thực hiện hồn tiền cho khách hàng và hiển thị thông báo “Tour đã được xử lý thành công”.
Alternative Flow Khơng có.
Exception Flow
5a. Người dùng nhấn “Bỏ qua".
Use case trở lại bước 4.
9b. Người dùng nhấn “Bỏ qua".
Use case dừng lại.
Business Rule Khơng có.
Non-Functional
Requirement Khơng có.
II.6.2 Quản lý các tour đã đặt
Hình II-25. Sơ đồ khai thác “Quản lý các tour đã đặt”. Use Case ID UC 18
Use Case Name Quản lý các tour đã đặt.
Use Case Description Nhân viên phụ trách tour theo dõi tình trạng các tour đã đặt. Actor(s) Nhân viên phụ trách tour.
Priority Must Have.
Trigger Người dùng có tài khoản để đăng nhập vào hệ thống.
Pre-Condition(s) Người dùng chọn chức năng quản lý tour đã đặt.
Post-Condition(s) - Nhân viên phụ trách tour xem được trạng thái tour đã đặt. Basic Flow 1. Người dùng chọn chức năng quản lý tour đã đặt.
3. Người dùng nhấn vào tour cần xem.
4. Hệ thống hiển thị chi tiết trạng thái của tour đã đặt đó (đã thanh tốn hết hay chưa, thơng tin khách hàng đã đặt tour đó).
Alternative Flow Khơng có.
Exception Flow Khơng có.
Business Rule Khơng có.
Non-Functional
Requirement Khơng có.
II.7 Tác nhân “Đại lý”
II.8 Tác nhân “Hệ thớng Fiditour”