Phân Tích Thiết Kế Hệ Thống Quản Lý Đặt Xe

Phân tích và thiết kế hệ thống quản lý đặt xe giúp tối ưu hóa quy trình đặt xe, nâng cao trải nghiệm người dùng và hiệu quả kinh doanh.

• Đề tài: Phân Tích Thiết Kế Hệ Thống Quản Lý Đặt Xe

Mục lục chi tiết

• LỜI CẢM ƠN
• GIỚI THIỆU CHUNG
• 1. CHƯƠNG 1: KHẢO SÁT ĐỐI THỦ
• 1.1. Khảo sát đối thủ
• 1.2. Khảo sát đối thủ
• 1.3. So sánh tính năng của các đối thủ
• 1.4. Đánh giá tổng kết
• 2. CHƯƠNG 2: YÊU CẦU HỆ THỐNG
• 2.1. Đặc tả hệ thống (System requirements)
• 2.2. Giả định (Assumption) cho hệ thống
• 2.3. Phạm vi của hệ thống (Scope)
• 2.4. Yêu cầu của người sử dụng hệ thống (Users requirements)
• 3. CHƯƠNG 3: PHÂN TÍCH THIẾT KẾ HỆ THỐNG
• 3.1. Ma trận actor và use case
• 3.2. Use case diagram
• 3.3. Đặc tả use case
• 3.4. State machine diagram
• 3.5. Giao diện mockup
• 3.6. Ảnh chụp source control system
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Hướng dẫn toàn diện phân tích hệ thống quản lý đặt xe

Việc phân tích thiết kế hệ thống quản lý đặt xe là một quy trình phức tạp, đòi hỏi sự kết hợp giữa kỹ thuật phần mềm và hiểu biết sâu sắc về nghiệp vụ vận hành. Một hệ thống đặt xe hiện đại không chỉ là một ứng dụng di động, mà là một hệ thống thông tin toàn diện, kết nối ba đối tượng chính: Khách hàng, Tài xế và Quản trị viên. Quá trình này bắt đầu từ việc khảo sát thị trường, xác định các yêu cầu cốt lõi và phạm vi của dự án. Mục tiêu chính là xây dựng một nền tảng ổn định, có khả năng mở rộng và mang lại trải nghiệm người dùng (UX) tốt nhất. Theo tài liệu nghiên cứu của nhóm sinh viên Trường Đại học Ngoại ngữ - Tin học TP.HCM, bước đầu tiên và quan trọng nhất là "Khảo sát đối thủ" để học hỏi ưu nhược điểm và xác định các tính năng cạnh tranh. Một bản phân tích chi tiết sẽ làm nền tảng vững chắc cho các giai đoạn sau, từ mô hình hóa dữ liệu đến kiểm thử phần mềm, đảm bảo dự án đi đúng hướng và giảm thiểu rủi ro trong quá trình phát triển.

1.1. Mục tiêu cốt lõi của việc phân tích hệ thống đặt xe

Mục tiêu chính của việc phân tích hệ thống là chuyển đổi các yêu cầu nghiệp vụ thành một bản thiết kế kỹ thuật chi tiết. Quá trình này giúp xác định rõ ràng các chức năng cần có, luồng hoạt động của người dùng, và các ràng buộc kỹ thuật. Cụ thể, việc phân tích giúp làm rõ cách thức quản lý khách hàng, quản lý tài xế, và quản lý chuyến đi. Nó cũng đặt nền móng cho việc thiết kế kiến trúc hệ thống sao cho linh hoạt và hiệu quả. Việc xác định mục tiêu rõ ràng ngay từ đầu giúp toàn bộ đội ngũ phát triển có chung một tầm nhìn, tránh được việc phải sửa đổi tốn kém ở các giai đoạn sau. Đây là bước không thể thiếu trong mọi quy trình quản lý dự án phần mềm chuyên nghiệp.

1.2. Xác định phạm vi và các tác nhân chính của hệ thống

Phạm vi của hệ thống (Scope) cần được định nghĩa rõ ràng để tránh "scope creep" - hiện tượng các yêu cầu phát sinh không kiểm soát. Dựa trên tài liệu gốc, hệ thống quản lý đặt xe bao gồm ba tác nhân (Actor) chính: Khách hàng, Tài xế, và System (Quản trị viên). Mỗi tác nhân có một vai trò và tập hợp các hành động riêng. Khách hàng có thể đăng ký, đặt xe, thanh toán, và đánh giá. Tài xế có thể nhận cuốc, xem thu nhập và cập nhật thông tin. Quản trị viên chịu trách nhiệm quản lý toàn bộ dữ liệu người dùng, cấu hình hệ thống và xem các báo cáo thống kê. Việc phân định rõ vai trò của từng tác nhân là cơ sở để xây dựng các biểu đồ use case chính xác, mô tả đầy đủ các tương tác giữa người dùng và hệ thống.

II. Cách xác định yêu cầu hệ thống quản lý đặt xe hiệu quả

Giai đoạn phân tích yêu cầu hệ thống là xương sống của toàn bộ dự án. Việc xác định sai hoặc thiếu yêu cầu có thể dẫn đến một sản phẩm không đáp ứng được nhu cầu thị trường. Yêu cầu hệ thống được chia thành hai loại chính: yêu cầu chức năng và yêu cầu phi chức năng. Yêu cầu chức năng mô tả hệ thống sẽ làm gì, ví dụ như chức năng đăng nhập, đặt xe, hay thanh toán. Trong khi đó, yêu cầu phi chức năng mô tả hệ thống sẽ hoạt động như thế nào, bao gồm các tiêu chí về hiệu năng, tính khả dụng, và đặc biệt là bảo mật hệ thống. Tài liệu nghiên cứu đã liệt kê một danh sách dài các Use Case (từ UC01 đến UC58), đây chính là kết quả của quá trình đặc tả chi tiết các yêu cầu chức năng. Việc lập "Ma trận actor và use case" là một phương pháp hiệu quả để đảm bảo không bỏ sót bất kỳ tương tác quan trọng nào.

2.1. Phân tích yêu cầu chức năng Xương sống của hệ thống

Yêu cầu chức năng định nghĩa các hành vi cụ thể của hệ thống. Dựa trên tài liệu phân tích, các chức năng cốt lõi bao gồm: Quản lý tài khoản (Đăng ký, Đăng nhập qua SĐT/Facebook/Gmail), Quản lý đặt xe (Đặt xe thông thường, GrabNow, Thuê xe), Thiết lập phương thức thanh toán (Tiền mặt, Moca, ZaloPay, Thẻ ATM), và Quản lý lịch sử hoạt động. Mỗi chức năng này được đặc tả chi tiết thông qua một use case, ví dụ như UC30 "Đặt xe thông thường" mô tả luồng xử lý từ khi khách hàng chọn điểm đi, điểm đến cho đến khi hệ thống tìm thấy tài xế. Việc này đảm bảo mọi tính năng đều được định nghĩa rõ ràng trước khi bắt đầu lập trình.

2.2. Yêu cầu phi chức năng Đảm bảo hiệu suất và bảo mật

Yêu cầu phi chức năng quyết định chất lượng và độ tin cậy của ứng dụng di động. Đối với một hệ thống đặt xe, các yêu cầu này cực kỳ quan trọng. Hiệu năng: Hệ thống phải phản hồi nhanh chóng, đặc biệt là chức năng định vị GPS và tìm kiếm tài xế. Tính sẵn sàng: Hệ thống phải hoạt động 24/7 với thời gian downtime tối thiểu. Bảo mật: Dữ liệu người dùng, thông tin thanh toán phải được mã hóa và bảo vệ nghiêm ngặt. Khả năng mở rộng: Kiến trúc hệ thống phải cho phép xử lý số lượng lớn người dùng và chuyến đi đồng thời mà không bị quá tải. Cuối cùng, trải nghiệm người dùng (UX) phải mượt mà và trực quan để giữ chân người dùng.

III. Phương pháp phân tích hệ thống đặt xe bằng biểu đồ UML

UML (Unified Modeling Language) là ngôn ngữ mô hình hóa tiêu chuẩn được sử dụng để trực quan hóa, đặc tả và tài liệu hóa các khía cạnh của một hệ thống phần mềm. Trong việc phân tích thiết kế hệ thống quản lý đặt xe, biểu đồ UML đóng vai trò là công cụ giao tiếp hiệu quả giữa các bên liên quan. Nó giúp chuyển các yêu cầu trừu tượng thành các mô hình cụ thể, dễ hiểu. Tài liệu tham khảo đã sử dụng một loạt các biểu đồ UML để làm rõ cấu trúc và hành vi của hệ thống. Biểu đồ Use Case được dùng để mô tả các chức năng từ góc nhìn người dùng. Biểu đồ Tuần tự và Biểu đồ Hoạt động lại đi sâu vào chi tiết luồng xử lý của từng chức năng. Việc áp dụng UML một cách bài bản giúp đảm bảo thiết kế được nhất quán và toàn diện.

3.1. Mô hình hóa nghiệp vụ với Biểu đồ Use Case Use Case Diagram

Một biểu đồ use case tổng quan cung cấp cái nhìn bao quát về các chức năng chính mà hệ thống cung cấp cho từng tác nhân. Tài liệu đã chia các use case thành các package logic như "Quản lý đặt xe", "Quản lý tài khoản", "Thiết lập phương thức thanh toán". Ví dụ, trong package "Quản lý đặt xe", các use case cụ thể bao gồm "Đặt xe thông thường" (UC30), "Nhận cuốc" (UC35), và "Hủy cuốc" (UC36). Mỗi use case này sau đó được đặc tả chi tiết về Actor, Pre-condition (tiền điều kiện), Post-condition (hậu điều kiện) và các luồng xử lý (Standard flow, Alternative flow). Đây là cách tiếp cận chuẩn mực để đảm bảo mọi kịch bản sử dụng đều được xem xét.

3.2. Phân tích luồng tương tác bằng Biểu đồ Tuần tự Sequence Diagram

Nếu Use Case trả lời câu hỏi "Cái gì?", thì biểu đồ tuần tự (sequence diagram) trả lời câu hỏi "Như thế nào?". Nó mô tả chi tiết sự tương tác và thông điệp được trao đổi giữa các đối tượng theo thứ tự thời gian. Ví dụ, biểu đồ cho chức năng "Đặt xe thông thường" cho thấy rõ các bước: Khách hàng gửi yêu cầu từ giao diện, ứng dụng xử lý, hệ thống tìm kiếm tài xế, cơ sở dữ liệu lưu thông tin chuyến đi, và cuối cùng thông báo lại cho khách hàng. Các biểu đồ này cực kỳ hữu ích cho lập trình viên trong giai đoạn triển khai, giúp họ hiểu rõ logic và thứ tự thực hiện của các hàm và phương thức.

IV. Bí quyết thiết kế kiến trúc và cơ sở dữ liệu cho hệ thống

Sau khi hoàn thành giai đoạn phân tích, giai đoạn thiết kế sẽ định hình bộ khung kỹ thuật cho toàn bộ hệ thống. Thiết kế kiến trúc hệ thống quyết định cách các thành phần phần mềm được tổ chức và tương tác với nhau. Đối với một ứng dụng quy mô lớn như quản lý đặt xe, kiến trúc microservices thường được ưu tiên để đảm bảo khả năng mở rộng và bảo trì. Song song đó, thiết kế cơ sở dữ liệu là nền tảng lưu trữ toàn bộ dữ liệu vận hành. Một mô hình dữ liệu được thiết kế tốt sẽ đảm bảo tính toàn vẹn, hiệu suất truy vấn và khả năng phát triển trong tương lai. Sơ đồ ERD (Entity-Relationship Diagram) trong tài liệu gốc đã phác thảo các thực thể chính và mối quan hệ giữa chúng, là đầu vào quan trọng cho việc tạo ra cấu trúc bảng trong hệ quản trị cơ sở dữ liệu (SQL, NoSQL).

4.1. Thiết kế cơ sở dữ liệu Database Design qua sơ đồ ERD

Sơ đồ ERD là công cụ trực quan để mô hình hóa dữ liệu. Tài liệu nghiên cứu đã xây dựng một sơ đồ ERD bao gồm các thực thể cốt lõi như User, Driver, Trip, Vehicle, Payment, Rating. Mối quan hệ giữa chúng được định nghĩa rõ ràng, ví dụ: một Driver có thể thực hiện nhiều Trip, và một Trip được thực hiện bởi một Driver (quan hệ một-nhiều). Từ sơ đồ ERD này, các nhà phát triển có thể tạo ra các bảng trong cơ sở dữ liệu với các khóa chính, khóa ngoại và các ràng buộc cần thiết, đảm bảo dữ liệu luôn nhất quán và chính xác. Đây là bước thiết yếu để xây dựng một hệ thống thông tin vững chắc.

4.2. Xây dựng giao diện người dùng UI và trải nghiệm người dùng UX

Thiết kế giao diện người dùng (UI) và trải nghiệm người dùng (UX) quyết định sự thành bại của một ứng dụng hướng đến người dùng cuối. Phần "Giao diện mockup" trong tài liệu gốc cho thấy sự đầu tư vào việc phác thảo các màn hình chính của ứng dụng. Một thiết kế UI/UX tốt cần đảm bảo tính đơn giản, trực quan và nhất quán. Luồng đặt xe phải nhanh chóng chỉ qua vài thao tác. Các thông tin quan trọng như vị trí tài xế, thời gian dự kiến, giá cước phải được hiển thị rõ ràng. Việc tối ưu hóa UX giúp tăng tỷ lệ giữ chân người dùng và tạo ra lợi thế cạnh tranh trên thị trường.

V. Top module chức năng chính trong hệ thống quản lý đặt xe

Một hệ thống quản lý đặt xe hoàn chỉnh được cấu thành từ nhiều module chức năng khác nhau, mỗi module đảm nhiệm một nghiệp vụ cụ thể. Việc phân tách hệ thống thành các module giúp cho việc phát triển, quản lý và bảo trì trở nên dễ dàng hơn. Dựa trên phân tích từ các biểu đồ Use Case, có thể xác định các module trọng tâm. Module quản lý tài khoản xử lý toàn bộ vòng đời của người dùng. Module quản lý chuyến đi là trái tim của hệ thống, điều phối mọi hoạt động từ khi có yêu cầu đặt xe đến khi chuyến đi kết thúc. Module thanh toán đảm bảo các giao dịch tài chính diễn ra an toàn và minh bạch. Mỗi module này đều cần được kiểm thử phần mềm kỹ lưỡng để đảm bảo hoạt động chính xác và ổn định.

5.1. Module Quản lý chuyến đi Từ đặt xe đến theo dõi GPS

Đây là module phức tạp và quan trọng nhất. Nó bao gồm các chức năng: khách hàng tạo yêu cầu đặt xe, hệ thống sử dụng thuật toán và định vị GPS để tìm và "Ghép tài xế và khách hàng" (UC45) phù hợp nhất. Sau khi tài xế chấp nhận, module sẽ cập nhật trạng thái chuyến đi theo thời gian thực, cho phép khách hàng theo dõi vị trí của tài xế trên bản đồ. Khi chuyến đi kết thúc, module ghi nhận và chuyển thông tin sang module thanh toán và đánh giá. Việc tích hợp API với các dịch vụ bản đồ như Google Maps là yếu tố then chốt cho sự thành công của module này.

5.2. Module Thanh toán trực tuyến và Quản lý thu nhập

Module này chịu trách nhiệm xử lý mọi giao dịch tài chính. Nó hỗ trợ đa dạng các phương thức thanh toán như được mô tả trong các use case UC40 đến UC42: tiền mặt, ví điện tử (Moca, ZaloPay), và thẻ ngân hàng. Một hệ thống thanh toán trực tuyến an toàn và đáng tin cậy là yếu tố sống còn. Về phía tài xế, module này cung cấp các chức năng để "Xem thống kê thu nhập" (UC56) và "Rút tiền" (UC57), giúp họ quản lý tài chính một cách minh bạch và hiệu quả. Các báo cáo thống kê về doanh thu, số chuyến đi cũng được tạo ra từ dữ liệu của module này để phục vụ cho quản trị viên.

Trích đoạn nội dung tài liệu

Bộ Giáo Dục Và Đào Tạo Trường Đại Học Ngoại Ngữ - Tin Học Thành Phố Hồ Chí Minh Khoa Công Nghệ Thông Tin MÔN HỌC : PHÂN TÍCH THIẾT KẾ PHẦN MỀM ĐỀ TÀI : PHÂN TÍCH THIẾT KẾ HỆ THỐNG QUẢN LÝ ĐẶT XE Giáo Viên Hướng Dẫn : Bùi Thị Thanh Tú Thành Viên : 1. Nguyễn Ngọc Hiền Thanh – MSSV: 21DH114103 2. Lê Thị Hải Yến – MSSV: 21DH112244 3. Võ Thiện Nhân – MSSV: 21DH111296 Mssv – Họ tên Học kỳ… Năm học 20.

Hồ chí minh, Ngày …. năm … ii | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Nhận xét của giảng viên. Page 3 of 90 Mssv – Họ tên Học kỳ… Năm học 20.

Lời cảm ơn 4|Page Mssv – Họ tên Học kỳ… Năm học 20. Giới thiệu chung. Khảo sát đối thủ.9 <Tên Đối thủ 1>.9 <Tên Đối thủ 2>. So sánh tính năng của các đối thủ.

Đánh giá tổng kết. Phân tích thiết kế hệ thống. Đặc tả hệ thống (System requirements). Giả định (Assumption) cho hệ thống.

Phạm vi của hệ thống (Scope). Yêu cầu của người sử dụng hệ thống (Users requirements). Ma trận actor và use case. Use case diagram.

Đặc tả use case. State machine diagram. Giao diện mockup. Ảnh chụp source control system.

Tài liệu tham khảo.10 5|Page Mssv – Họ tên Học kỳ… Năm học 20. Danh mục hình ảnh 6|Page Mssv – Họ tên Học kỳ… Năm học 20. Danh mục bảng biểu 7|Page Mssv – Họ tên Học kỳ… Năm học 20. Danh mục từ viết tắt 8|Page Mssv – Họ tên Học kỳ… Năm học 20.

Bảng phân công công việc Thành viên Nhiệm vụ Mức độ hoàn Mức độ tích cực (Tên + MSSV) thành Nguyễn Ngọc Hiền +Vẽ usecase diagram Thanh + Đặc tả UC 01-13, 21DH114103 25-35 + Vẽ sequence, activity, state, ERD (Đặt xe, đăng nhập, nhận cuốc, đăng xuất, xóa tài khoản) Võ Thiện Nhân + Vẽ usecase diagram 21DH111296 + Đặc tả UC 14-24, 36-47 + Vẽ sequence, activity, state, class (Đăng ký, đăng nhập bằng SĐT/Gmail/FB, đánh giá tài xế) Lê Thị Hải Yến 21DH112244 9|Page Mssv – Họ tên Học kỳ… Năm học 20. Giới thiệu chung Giới thiệu sơ yêu cầu bài tập (có thể copy phần yêu cầu trong file case study). Dựa trên danh sách yêu cầu, xác định danh sách các yêu cầu chức năng của hệ thống. Sau đó mới dẫn nhập là dựa trên yêu cầu, nhóm đã khảo sát một số đối thủ sau trên thị trường (đưa tên danh sách đối thủ) - Đối thủ 1 - Trong phần 1.1 sẽ trình bày kết quả khảo sát chi tiết từng đối thủ, phần 1.2 sẽ so sánh tính năng của các đối thủ và 1.3 là phần đánh giá tổng kết 1.

Khảo sát đối thủ <Tên Đối thủ 1> Yêu cầu chức năng Giao diện Chức năng Yêu cầu 1 - Ưu điểm - Ưu điểm - Nhược điểm - Nhược điểm <Tên Đối thủ 2> Yêu cầu chức năng Giao diện Chức năng Yêu cầu 1 - Ưu điểm - Ưu điểm - Nhược điểm - Nhược điểm 2. So sánh tính năng của các đối thủ Đánh giá chất lượng từng yêu cầu A theo thang điểm từ (*) đến (*****), nếu chức năng đó không có thì để trống Yêu cầu chức năng Đối thủ 1 Đối thủ 2 Đối thủ 3 Đối thủ 4 Đối thủ 5 Yêu cầu 1 10 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Đánh giá tổng kết II. Yêu cầu hệ thống 1.

Đặc tả hệ thống (System requirements) 4. Giả định (Assumption) cho hệ thống 5. Phạm vi của hệ thống (Scope) 6. Yêu cầu của người sử dụng hệ thống (Users requirements) III.

Phân tích thiết kế hệ thống 1. Ma trận actor và use case Mã Tên Usercase Actor Package/ Đối tượng Precedents UC UC0 Đăng ký Khách hàng, Tài Quản lý tài khoản - 1 xế người dùng UC0 Đăng nhập UC01 2 UC0 Đăng nhập bằng Facebook - 3 UC0 Đăng nhập bằng Gmail - 4 UC0 Đăng xuất UC02 5 UC0 Quản lý thông tin tài xế System Quản lý dữ liệu người - 6 dùng UC0 - 7 Thêm thông tin tài xế UC0 - 8 Xóa thông tin tài xế UC0 - 9 Sửa thông tin tài xế UC1 Quản lý thông tin khách hàng - 0 UC11 Thêm thông tin khách hàng - UC1 - 2 Xóa thông tin khách hàng UC1 - 3 Sửa thông tin khách hàng UC1 Kích hoạt ví Moca Khách hàng Thiết lập phương thức UC02 4 thanh toán UC1 Thêm phương thức thanh toán UC02 5 11 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. UC1 UC02 6 Thêm thẻ UC1 UC02 7 Liên kết tài khoản ngân hàng UC1 UC02 8 Liên kết ZaloPay UC1 Xem tin nhắn Khách hàng Quản lý tin nhắn và UC02 9 thông báo UC2 Khách hàng UC02 0 Xem thông báo UC2 Khách hàng UC02 1 Xem cuộc trò chuyện UC2 System - 2 Gửi thông báo UC2 Khách hàng UC18 3 Xóa thông báo UC2 Khách hàng - 4 Xóa cuộc trò chuyện UC2 Cập nhật thông tin tài khoản tài Tài xế Quản lý thông tin tài UC02 5 xế khoản tài xế UC2 Xác nhận thay đổi thông tin tài System - 6 xế UC2 Cập nhật thông tin tài khoản Khách hàng Quản lý thông tin tài UC02 7 khách hàng khoản khách hàng UC2 Khách hàng UC02 8 Thiết lập tài khoản liên kết UC2 Khách hàng Quản lý đặt xe UC02 9 Thiết lập đặt xe UC3 Khách hàng, tài UC28 0 Đặt GrabNow xế UC3 Khách hàng, tài UC28 1 Đặt xe thông thường xế, system UC3 UC28 2 Thuê xe UC3 3 Bật chế độ nhận cuốc UC3 4 Tắt chế độ nhận cuốc UC3 Tài xế UC29 5 Nhận cuốc UC3 UC32 6 Hủy cuốc UC3 UC32 7 Xác nhận hoàn thành cuốc UC3 Khách hàng UC28 8 Thanh toán UC3 UC28 9 Thanh toán tiền mặt UC4 Thanh toán qua Moca UC28 0 12 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. UC4 UC28 1 Thanh toán qua thẻ ATM UC4 UC28 2 Thanh toán qua ZaloPay UC4 UC28 3 Sử dụng ưu đãi UC4 System - 4 Ghép tài xế và khách hàng UC4 5 Thông báo thông tin cuốc xe UC4 Khách hàng UC34 6 Đánh giá tài xế UC4 System UC42 7 Xếp hạng ưu tiên nhận cuốc UC4 Khách hàng Quản lý lịch sử hoạt UC02 8 Xem lịch sử hoạt động động UC4 UC28 9 Xem chi tiết chuyến đi UC5 UC02 0 Xem lịch sử tài chính UC5 UC34 1 Đánh giá chuyến đi UC5 UC45 2 Báo cáo sự cố UC5 Tài xế Quản lý lịch sử cuốc xe UC02 3 Xem lịch sử cuốc xe UC5 UC49 4 Xem đánh giá UC5 Tài xế Quản lý thu nhập UC02 5 Liên kết ngân hàng UC5 UC02 6 Xem thống kê thu nhập UC5 UC02 7 Rút tiền UC5 UC02 8 Nạp tiền vào ví 7.

Use case diagram Usecase tổng quát (theo package) 13 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Usecase chi tiết (cho từng package: chi tiết đến mức usecase) 1. Quản lý đặt xe 14 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Quản lý thông tin tài khoản khách hàng 15 | P a g e Mssv – Họ tên Học kỳ… Năm học 20.

Quản lý thông tin tài khoản tài xế 4. Thiết lập phương thức thanh toán 5. Quản lý thu nhập 16 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Quản lý tin nhắn và thông báo 7.

Quản lý lịch sử hoạt động 17 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Quản lý lịch sử cuốc xe 18 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Quản lý dữ liệu người dùng 10. Quản lý tài khoản 19 | P a g e Mssv – Họ tên Học kỳ… Năm học 20.

Đặc tả use case 20 | P a g e Mssv – Họ tên Học kỳ… Năm học 20. Đăng ký Name Đăng ký Code UC01 Description Cho phép người dùng đăng ký tài khoản Actor User Trigger 1. Tại trang đăng nhập/đăng ký, người dùng nhấn nút Đăng ký 2. Khi người dùng chưa đăng nhập, tại trang chủ của ứng dụng, người dùng chọn các chức năng, hệ thống hiển thị form yêu cầu đăng ký/đăng nhập, người dùng nhấn nút Đăng nhập Pre-condition Người dùng chưa có tài khoản Post-condition Hệ thống redirect đến trang đăng nhập Error situations 1.

Hệ thống quá tải 2. Mất kết nối mạng 3. Hệ thống bảo trì System state in error 1. Hệ thống hiển thị thông báo “Hệ thống đang quá tải.

Vui lòng situations thử lại sau” 2. Hệ thống hiển thị thông báo “Mất kết nối Internet/4G. Vui lòng thử lại sau” 3. Hệ thống hiển thị thời gian bảo trì và thông báo “Hệ thống đang bảo trì.

Vui lòng thử lại sau” Standard flow/process 1. Tại trang đăng nhập/đăng ký, người dùng chọn chức năng Đăng ký 2. Hệ thống redirect đến trang Đăng ký 3. Người dùng nhập số điện thoại 4.

Hệ thống gửi mã xác nhận OTP đến số điện thoại người dùng và redirect đến trang nhập mã xác nhận 5. Người dùng nhập mã xác nhận OTP 6. Hệ thống hiển thị thông báo “Đăng ký thành công” và redirect đến trang chủ của ứng dụng Alternative flow/ 3’. Người dùng ấn nút Quay lại Process 1 21 | P a g e Mssv – Họ tên Học kỳ… Năm học 20.

Hệ thống redirect đến trang đăng nhập/đăng ký Alternative flow/ 5’. Người dùng nhập sai mã xác nhận OTP Process 2 6’. Hệ thống hiển thị thông báo “Mã không đúng. Bạn có thể thử thêm 2 lần nữa” 7’.

< Tiếp tục thực hiện bước 5 của nhánh Standard flow > Ở lần nhập mã OTP thứ hai :  Nếu người dùng nhập đúng mã thì hệ thống hiển thị thông báo “Đăng ký thành công” và redirect đến trang chủ của ứng dụng  Nếu người dùng nhập sai mã OTP thì hệ thống hiển thị thông báo “Mã không đúng. Bạn có thể thử thêm 1 lần nữa” Ở lần nhập mã OTP thứ ba :  Nếu người dùng nhập đúng mã thì hệ thống hiển thị thông báo “Đăng ký thành công” và redirect đến trang chủ của ứng dụng  Nếu người dùng nhập sai mã OTP thì hệ thống hiển thị thông báo “Bạn đã thử quá nhiều lần! Vui lòng thử lại sau ít phút” 8’. Người dùng chọn nút OK 9’. Hệ thống redirect đến trang nhập số điện thoại Alternative flow/ 7’’.

Người dùng chọn nút Nhận mã mới Process 3 8’’. Hệ thống gửi mã xác nhận OTP mới đến số điện thoại người dùng 9’’. < Tiếp tục thực hiện bước 5 của nhánh Standard flow > Alternative flow/ 2’. Hệ thống hiển thị thời gian bảo trì và thông báo “Hệ thống đang Process 4 bảo trì.

Vui lòng thử lại sau” Đăng nhập Name Đăng nhập Code UC02 Description Cho phép người dùng đăng nhập vào app Grab bằng nhiều phương thức: Số điện thoại, Facebook, Gmail Actor User Trigger 1.