Trong bất kỳ dự án phát triển phần mềm nào, việc hiểu rõ yêu cầu là nền tảng quyết định sự thành bại. Nếu bạn lao vào coding hay kiểm thử mà không nắm chắc hệ thống cần gì, bạn có thể đang xây dựng một lâu đài trên cát – đẹp đấy, nhưng không bền. Vậy làm thế nào để bắt đầu đúng cách? Hãy dành thời gian tìm hiểu kỹ các yêu cầu trước khi hành động. Bài viết này sẽ hướng dẫn bạn qua các bước cần thiết, kèm checklist cụ thể để không bỏ sót bất kỳ điều gì.

Tại Sao Phải Hiểu Rõ Yêu Cầu?

Hãy tưởng tượng bạn là một đầu bếp được yêu cầu nấu một bữa ăn. Nếu khách chỉ nói “tôi muốn món ngon”, bạn sẽ làm gì? Có thể bạn chọn làm pizza, nhưng khách lại mong đợi sushi. Trong phát triển phần mềm cũng vậy – hiểu sai yêu cầu dẫn đến sản phẩm không đáp ứng kỳ vọng. Dành thời gian ban đầu để nắm rõ mục tiêu không chỉ giúp bạn tiết kiệm công sức sửa lỗi sau này, mà còn đảm bảo hệ thống hoạt động đúng như ý định.

Các checklist cho việc hiểu rõ yêu cầu có thể kể đến:

• Đọc kỹ tài liệu yêu cầu
• Xác định mục tiêu của hệ thống
• Hỏi rõ khi có nghi ngờ
• Hình dung từ góc nhìn người dùng
• Phối hợp với các bên liên quan
• Ghi chép và hệ thống hóa thông tin
• Phân tích Rủi ro Sơ bộ

Phân tích chi tiết

Dưới đây, Better Bytes Academy sẽ đi sâu vào từng checklist để phân tích và lấy ví dụ, giúp bạn hiểu rõ hơn từng phần nhé.

Nghiên cứu và Phân tích Tài liệu

Trước khi bắt đầu kiểm thử, việc nghiên cứu và phân tích tài liệu là bước không thể bỏ qua. Đây là giai đoạn bạn “giải mã” mọi thông tin liên quan để hiểu rõ hệ thống từ gốc rễ. Nếu làm qua loa, bạn có thể bỏ sót yêu cầu quan trọng hoặc hiểu sai ý định của khách hàng. Hãy cùng đi sâu vào cách thực hiện bước này một cách khoa học và hiệu quả.

Xem Xét Tất Cả Tài liệu Liên Quan

Đừng chỉ đọc một tài liệu rồi dừng lại. Hãy thu thập và xem xét toàn bộ:

• Tài liệu đặc tả yêu cầu (SRS): Chứa yêu cầu chi tiết về chức năng và phi chức năng.
• Tài liệu thiết kế: Mô tả kiến trúc hệ thống, giao diện, cơ sở dữ liệu.
• Tài liệu hướng dẫn người dùng: Hé lộ cách hệ thống được kỳ vọng hoạt động từ góc nhìn người dùng.
• Tài liệu nghiệp vụ (BRD): Xác định mục tiêu kinh doanh và quy trình thực tế.
• Tiêu chuẩn pháp lý: Ví dụ, GDPR nếu hệ thống xử lý dữ liệu cá nhân ở châu Âu.
  Mỗi tài liệu cung cấp một mảnh ghép – bỏ sót cái nào cũng làm bức tranh tổng thể bị khuyết.

Ghi Chú Chi Tiết Các Yếu Tố Quan Trọng

Khi đọc, hãy ghi lại những điểm chính:

• Chức năng chính: Ví dụ, “Đăng nhập bằng email” hoặc “Tìm kiếm sản phẩm theo danh mục”.
• Yêu cầu nghiệp vụ: “Hệ thống phải hỗ trợ báo cáo doanh thu hàng ngày”.
• Yêu cầu hệ thống: Phần cứng (RAM tối thiểu 8GB), phần mềm (hỗ trợ iOS 14+), giao diện (API RESTful).
• Yêu cầu phi chức năng: Hiệu suất (tải trang dưới 2 giây), bảo mật (mã hóa AES-256), giao diện (hỗ trợ màn hình retina).
• Ràng buộc đặc biệt: “Hệ thống chỉ hoạt động trên mạng nội bộ”.
• Yêu cầu bảo trì: “Cập nhật phần mềm mỗi 6 tháng”.
  Tôi thường dùng bảng phân loại: cột “Yêu cầu”, “Mô tả”, “Ưu tiên” để không bỏ sót chi tiết.

Sử dụng Kỹ thuật Phân tích Để Trực Quan Hóa

Đọc tài liệu thôi chưa đủ – hãy biến chúng thành hình ảnh hoặc câu chuyện cụ thể:

• Use Case Diagram: Vẽ sơ đồ mô tả luồng nghiệp vụ. Ví dụ, với tính năng “Đặt vé xem phim”, Use Case có thể gồm:
  • Bước 1: Người dùng chọn phim và suất chiếu.
  • Bước 2: Chọn ghế và nhập thông tin thanh toán.
  • Bước 3: Nhận xác nhận qua email.
    Sơ đồ này giúp bạn thấy rõ các bước và điểm tương tác.
• User Stories: Viết câu chuyện từ góc nhìn người dùng. Ví dụ:
  • “Với vai trò là một khách hàng, tôi muốn hủy vé trước ít nhất 2 giờ để linh hoạt thay đổi kế hoạch.”
    User Story này không chỉ xác định tính năng “hủy vé” mà còn đặt ra ràng buộc thời gian cụ thể (2 giờ), giúp kiểm thử dễ dàng hơn.

Xác định mục tiêu của hệ thống

Mục tiêu là “ngọn hải đăng” dẫn dắt mọi quyết định trong dự án. Một lần tôi làm việc với một ứng dụng quản lý kho – đội phát triển tập trung vào giao diện đẹp mắt, nhưng bỏ qua tốc độ xử lý dữ liệu, thứ mà khách hàng thực sự cần để giảm thời gian kiểm kho. Hiểu sai mục tiêu dẫn đến sản phẩm không đáp ứng nhu cầu cốt lõi. Xác định rõ ràng từ đầu giúp bạn tránh lãng phí thời gian và nguồn lực.

Các Bước Để Xác Định Mục Tiêu của Hệ Thống:

Đặt Những Câu Hỏi Cơ Bản

Bắt đầu bằng cách tự vấn hoặc trao đổi với các bên liên quan:

• “Phần mềm này được tạo ra để làm gì?”
  Ví dụ: Một ứng dụng đặt xe công nghệ được tạo để kết nối tài xế và hành khách, tối ưu hóa thời gian di chuyển.
• **“Mục tiêu kinh doanh mà phần mềm hướng đến là gì?” Có thể là tăng doanh thu (qua phí giao dịch), cải thiện hiệu suất (giảm thời gian chờ), hoặc nâng cao trải nghiệm khách hàng (dễ đặt xe hơn).
• “Ai là người dùng cuối?”
  Là tài xế, hành khách, hay quản lý doanh nghiệp? Mỗi nhóm có nhu cầu khác nhau – hành khách muốn giao diện đơn giản, tài xế cần tính năng báo cáo thu nhập.
  Những câu hỏi này làm rõ “bức tranh lớn” mà hệ thống phục vụ.

Tập Trung Vào Kết Quả Mong Đợi (Expected Outcomes)

Mỗi chức năng trong hệ thống phải đóng góp vào một kết quả cụ thể:

• Với tính năng “Tìm kiếm chuyến bay” của một ứng dụng đặt vé: Kết quả mong đợi là người dùng tìm thấy chuyến bay phù hợp trong vòng 5 giây.
• Với tính năng “Thông báo đơn hàng” trong ứng dụng giao đồ ăn: Kết quả là khách hàng nhận thông tin tức thì khi đơn được xác nhận.
  Hãy liệt kê từng chức năng và hỏi: “Chức năng này cần đạt được gì?” Điều này giúp bạn đo lường hiệu quả sau này.

Xác Định Giá Trị Mang Lại Cho Người Dùng và Doanh Nghiệp

Phần mềm không chỉ là tập hợp mã code – nó phải giải quyết vấn đề thực tế:

• Giá trị cho người dùng:
  Ví dụ, ứng dụng học trực tuyến giúp sinh viên ôn thi hiệu quả hơn nhờ tính năng “bài kiểm tra tự động chấm điểm”. Giá trị ở đây là tiết kiệm thời gian và cá nhân hóa trải nghiệm học.
• Giá trị cho doanh nghiệp:
  Cùng ứng dụng đó, doanh nghiệp có thể tăng lượng người dùng trả phí nhờ uy tín từ tính năng chính xác, hoặc giảm chi phí vận hành bằng tự động hóa.
  Hiểu cả hai khía cạnh giúp bạn cân bằng giữa nhu cầu người dùng và mục tiêu kinh doanh.

Ví Dụ Thực Tế

Gần đây, tôi tham gia phát triển một hệ thống đặt lịch khám bệnh. Chúng tôi đặt câu hỏi:

• “Phần mềm này làm gì?” – Giúp bệnh nhân đặt lịch dễ dàng và bác sĩ quản lý lịch khám.
• “Mục tiêu kinh doanh?” – Tăng tỷ lệ đặt lịch trực tuyến, giảm cuộc gọi thủ công cho phòng khám.
• “Người dùng cuối?” – Bệnh nhân (muốn nhanh chóng), bác sĩ (muốn lịch rõ ràng), quản lý (muốn báo cáo thống kê).
  Kết quả mong đợi: Đặt lịch trong 2 phút, thông báo nhắc nhở gửi trước 24 giờ. Giá trị mang lại: Bệnh nhân tiết kiệm thời gian, phòng khám giảm 30% công việc hành chính. Nhờ xác định rõ từ đầu, hệ thống được thiết kế đúng trọng tâm và được khách hàng đánh giá cao.

Xác định Mục tiêu và Đối tượng

• Hỏi: "Phần mềm này được tạo ra để làm gì?" "Mục tiêu kinh doanh mà phần mềm hướng đến là gì?" "Ai là người dùng cuối?"
• Tập trung vào kết quả mong đợi (expected outcomes) của từng chức năng và giá trị mà phần mềm mang lại cho người dùng và doanh nghiệp.

Đặt Câu hỏi Làm Rõ

• Nếu có bất kỳ điểm nào mơ hồ, mâu thuẫn hoặc thiếu thông tin trong tài liệu, hãy đặt câu hỏi ngay lập tức cho đội developer, phân tích nghiệp vụ (BA), khách hàng hoặc quản lý dự án.
• Sử dụng email, cuộc họp, công cụ quản lý dự án để ghi nhận câu trả lời và đảm bảo tất cả các bên liên quan đều nắm rõ.
• Phân loại câu hỏi:
  • Câu hỏi làm rõ (Clarification): "Yêu cầu này có nghĩa là gì trong trường hợp...?"
  • Câu hỏi xác nhận (Confirmation): "Tôi hiểu rằng... có đúng không?"
  • Câu hỏi khám phá (Exploratory): "Điều gì sẽ xảy ra nếu...?"
  • Ví dụ: "Nếu người dùng chọn nhiều ghế khác nhau ở các hàng khác nhau thì hệ thống xử lý như thế nào?"

Hình dung từ Góc nhìn Người dùng

• Đặt mình vào vai trò của người dùng cuối để hiểu cách họ sẽ tương tác với phần mềm.
• Điều này giúp phát hiện các kịch bản thực tế mà tài liệu có thể chưa đề cập.

Phối hợp với Các Bên liên quan

• Làm việc chặt chẽ với đội developer (dev), phân tích nghiệp vụ (BA), hoặc khách hàng để đảm bảo tất cả đều thống nhất về yêu cầu.
• Tham gia các buổi họp yêu cầu (requirement review) để thảo luận và làm rõ các vấn đề.
• Kỹ năng giao tiếp hiệu quả rất quan trọng để trao đổi thông tin rõ ràng và xây dựng mối quan hệ tốt.

Ghi chép, Hệ thống hóa Thông tin và Ưu tiên

• Tạo một bảng hoặc danh sách tóm tắt các yêu cầu chính, ưu tiên chúng theo mức độ quan trọng, mức độ rủi ro hoặc ảnh hưởng đến mục tiêu kinh doanh.
• Chuẩn bị sẵn các câu hỏi hoặc giả định để làm rõ trong quá trình làm việc.

Phân tích Rủi ro Sơ bộ

• Xác định các rủi ro tiềm ẩn liên quan đến yêu cầu, chẳng hạn như rủi ro về bảo mật, hiệu suất, hoặc tuân thủ.
• Ví dụ: "Rủi ro nếu hệ thống thanh toán bị lỗi trong giờ cao điểm sẽ gây ảnh hưởng lớn đến doanh thu và uy tín của rạp."
• Việc này giúp ưu tiên kiểm thử cho các khu vực có rủi ro cao.

Ví dụ cụ thể: Ứng dụng đặt vé xem phim trực tuyến

Giả sử bạn được giao kiểm thử một ứng dụng đặt vé xem phim trực tuyến. Dưới đây là cách áp dụng bước "Hiểu rõ yêu cầu":

1. Nghiên cứu và Phân tích Tài liệu:

   • Tài liệu SRS ghi:
     • Người dùng có thể chọn phim, giờ chiếu, và số lượng vé.
     • Hệ thống phải hiển thị ghế trống và cho phép chọn ghế.
     • Thanh toán phải hoàn tất trong 5 phút, nếu không giao dịch sẽ bị hủy.
     • Hệ thống phải hỗ trợ các phương thức thanh toán: thẻ tín dụng, ví điện tử.
     • Ứng dụng phải tương thích với các trình duyệt Chrome, Firefox, Safari, và Edge.
   • Tài liệu BRD (Business Requirements Document) ghi:
     • Mục tiêu: Tăng doanh thu bán vé trực tuyến lên 20% trong quý tới.
     • Cung cấp trải nghiệm đặt vé dễ dàng, nhanh chóng và an toàn cho khách hàng.
   • Phân tích Use Case Diagram:
     • Use Case 'Đặt vé' bao gồm các bước: Chọn phim -> Chọn giờ chiếu -> Chọn số lượng vé -> Chọn ghế -> Xác nhận thông tin -> Chọn phương thức thanh toán -> Nhập thông tin thanh toán -> Xác nhận thanh toán -> Nhận vé điện tử.
   • Phân tích User Stories:
     • "Với vai trò là một người dùng, tôi muốn có thể xem trailer phim để quyết định xem phim nào."
     • "Với vai trò là một người dùng, tôi muốn có thể lưu thông tin thẻ tín dụng của mình để thanh toán nhanh hơn cho lần sau."
     • "Với vai trò là một quản trị viên, tôi muốn có thể xem báo cáo doanh thu theo phim, theo ngày, theo giờ."

2. Xác định Mục tiêu và Đối tượng:

   • Mục tiêu:
     • Giúp người dùng đặt vé nhanh chóng, chính xác, an toàn và tiện lợi.
     • Tăng doanh thu bán vé trực tuyến cho rạp phim.
   • Người dùng cuối:
     • Người đi xem phim (có thể không rành công nghệ).
     • Người dùng ở nhiều độ tuổi và trình độ khác nhau.

3. Đặt Câu hỏi Làm Rõ:

   • Tài liệu không nói rõ: "Nếu người dùng thoát giữa chừng khi chọn ghế thì sao?"
   • Bạn gửi câu hỏi đến đội developer: "Ghế đã chọn có được giữ tạm thời không, hay sẽ được giải phóng ngay khi người dùng thoát?"
   • Câu trả lời: "Ghế được giữ trong 5 phút kể từ khi chọn, sau đó giải phóng."
   • Câu hỏi làm rõ: "Thời gian giữ ghế 5 phút có áp dụng cho tất cả các khung giờ hay chỉ áp dụng cho giờ cao điểm?"
   • Câu hỏi xác nhận: "Tôi hiểu rằng hệ thống sẽ tự động gửi email xác nhận vé cho người dùng sau khi thanh toán thành công, đúng không?"
   • Câu hỏi khám phá: "Điều gì sẽ xảy ra nếu hệ thống thanh toán của bên thứ ba gặp sự cố?"

4. Hình dung từ Góc nhìn Người dùng:

   • Bạn tưởng tượng: Một người dùng muốn đặt 3 vé xem phim "Avengers" vào 19h tối. Họ chọn ghế, nhưng mạng chậm, họ thoát ra rồi vào lại. Họ mong ghế vẫn còn giữ.
   • Một người lớn tuổi muốn đặt vé nhưng gặp khó khăn khi thao tác trên điện thoại.
   • Một người muốn sử dụng ví điện tử để thanh toán nhưng không thấy tùy chọn này.

Điều này gợi ý cần kiểm tra test case cho kịch bản mạng gián đoạn, giao diện thân thiện với người dùng, và hỗ trợ nhiều phương thức thanh toán.

5. Phối hợp với Các Bên liên quan:

   • Bạn tham gia họp với đội developer và BA, xác nhận:
     • Hệ thống gửi email xác nhận sau khi thanh toán thành công.
     • Có thông báo nếu hết thời gian 5 phút.
     • Ứng dụng hỗ trợ chức năng "lịch sử giao dịch" để người dùng xem lại các vé đã đặt.
   • Điều này bổ sung thông tin cho việc xây dựng test case.

6. Ghi chép, Hệ thống hóa Thông tin và Ưu tiên:

   • Bạn tạo bảng tóm tắt:

     Chức năng	Yêu cầu	Ghi chú	Ưu tiên
     Chọn ghế	Hiển thị ghế trống, cho phép chọn	Giữ ghế trong 5 phút	Cao
     Thanh toán	Hoàn tất trong 5 phút	Hủy nếu hết thời gian, hỗ trợ nhiều phương thức thanh toán	Cao
     Xác nhận	Gửi email sau thanh toán	Kiểm tra nội dung email, đảm bảo thông tin vé chính xác	Cao
     Lịch sử GD	Hiển thị lịch sử các giao dịch đã thực hiện	Sắp xếp theo thời gian, có thể tìm kiếm	Trung bình
     Trailer	Cho phép xem trailer phim	Đảm bảo chất lượng video tốt, tương thích với nhiều thiết bị	Thấp
     Bảo mật	Bảo vệ thông tin cá nhân và thông tin thanh toán	Tuân thủ GDPR	Cao

7. Phân tích Rủi ro Sơ bộ:

   • Rủi ro: Hệ thống thanh toán bị lỗi trong giờ cao điểm. Ảnh hưởng: Mất doanh thu, uy tín của rạp phim. Ưu tiên: Kiểm tra kỹ lưỡng chức năng thanh toán, đặc biệt trong giờ cao điểm.
   • Rủi ro: Lỗi bảo mật làm lộ thông tin thẻ tín dụng của người dùng. Ảnh hưởng: Mất lòng tin của khách hàng, vi phạm pháp luật. Ưu tiên: Kiểm tra bảo mật nghiêm ngặt, tuân thủ các tiêu chuẩn bảo mật.

Lời kết:

Việc "Hiểu rõ yêu cầu" không chỉ là bước đầu tiên mà còn là nền tảng vững chắc cho toàn bộ quy trình kiểm thử phần mềm.

Bằng cách đầu tư thời gian và nỗ lực vào việc phân tích, đặt câu hỏi, hình dung, phối hợp và hệ thống hóa thông tin, người Tester có thể đảm bảo rằng mình đang xây dựng các test case phù hợp, hiệu quả và tập trung vào những gì thực sự quan trọng.

Kết quả là, chúng ta sẽ giảm thiểu rủi ro, tăng chất lượng phần mềm, và mang lại giá trị tốt nhất cho người dùng cuối và doanh nghiệp. Hãy xem đây là một hành trình khám phá, nơi sự tỉ mỉ, cẩn trọng và tư duy phản biện là những người bạn đồng hành không thể thiếu.

Câu hỏi cho bạn đọc

Cách nộp bài: Comment đáp án vào bài post tại link sau để mentors của Better Bytes Academy cùng contributors của cộng đồng "combat" cùng bạn nhé !!

Đề bài: Áp dụng bước "Hiểu rõ yêu cầu" ở trên phân tích Yêu cầu cho Ứng dụng Quản lý Thư viện Trực tuyến (Online Library Management System)

Bối cảnh:

Bạn là một Tester mới gia nhập một dự án phát triển ứng dụng quản lý thư viện trực tuyến cho Thư viện Better Bytes Academy. Ứng dụng này cho phép sinh viên và giảng viên tìm kiếm, mượn, trả sách, gia hạn thời gian mượn, xem lịch sử mượn sách, và đặt chỗ trước cho các tài liệu đang được mượn.

Tài liệu:

Bạn được cung cấp các tài liệu sau:

• 1. Mô tả dự án (Project Description):

  Ứng dụng Quản lý Thư viện Trực tuyến nhằm mục đích số hóa và cải thiện quy trình quản lý tài liệu và dịch vụ của Thư viện Better Bytes Academy. Ứng dụng này sẽ cung cấp một nền tảng trực tuyến dễ sử dụng cho sinh viên và giảng viên để truy cập các tài liệu của thư viện từ bất cứ đâu, bất cứ lúc nào. Ứng dụng cũng sẽ giúp nhân viên thư viện quản lý tài liệu, theo dõi lượt mượn trả, và tạo báo cáo thống kê.

• 2. Tài liệu Đặc tả Yêu cầu Phần mềm (Software Requirements Specification - SRS):

  • 2.1. Yêu cầu Chức năng:
    • 2.1.1. Tìm kiếm Sách:
      • Người dùng có thể tìm kiếm sách theo tiêu đề, tác giả, ISBN (International Standard Book Number), hoặc từ khóa.
      • Hệ thống phải hiển thị kết quả tìm kiếm dưới dạng danh sách, bao gồm thông tin: tiêu đề, tác giả, ISBN, tóm tắt, số lượng bản sao hiện có, và tình trạng (có sẵn, đang mượn, đang đặt chỗ).
      • Người dùng có thể sắp xếp kết quả tìm kiếm theo tiêu đề, tác giả, hoặc năm xuất bản.
    • 2.1.2. Mượn Sách:
      • Người dùng đã đăng nhập có thể mượn sách nếu sách còn bản sao và có sẵn.
      • Thời gian mượn tối đa là 14 ngày cho sinh viên và 30 ngày cho giảng viên.
      • Người dùng có thể mượn tối đa 5 cuốn sách cùng lúc (sinh viên) hoặc 10 cuốn sách cùng lúc (giảng viên).
      • Hệ thống phải hiển thị thông báo xác nhận khi mượn sách thành công, bao gồm ngày trả sách dự kiến.
    • 2.1.3. Trả Sách:
      • Người dùng đã đăng nhập có thể trả sách tại thư viện hoặc thông qua dịch vụ trả sách tự động.
      • Hệ thống phải cập nhật tình trạng sách ngay khi sách được trả.
      • Nếu trả sách muộn, người dùng sẽ bị phạt theo quy định của thư viện (xem mục 2.2.4).
    • 2.1.4. Gia hạn Thời Gian Mượn:
      • Người dùng đã đăng nhập có thể gia hạn thời gian mượn sách trực tuyến (nếu sách chưa có người đặt chỗ).
      • Thời gian gia hạn tối đa là 7 ngày cho sinh viên và 15 ngày cho giảng viên.
      • Người dùng chỉ có thể gia hạn thời gian mượn một lần cho mỗi cuốn sách.
    • 2.1.5. Đặt Chỗ Sách:
      • Người dùng đã đăng nhập có thể đặt chỗ sách đang được mượn.
      • Hệ thống phải thông báo cho người dùng khi sách đã sẵn sàng để mượn.
      • Thời gian giữ sách đặt chỗ là 3 ngày.
    • 2.1.6. Quản lý Tài Khoản:
      • Người dùng có thể đăng ký tài khoản mới, đăng nhập, và thay đổi thông tin cá nhân (tên, email, mật khẩu).
      • Hệ thống phải hỗ trợ chức năng "quên mật khẩu".
      • Nhân viên thư viện có thể tạo, sửa, xóa tài khoản người dùng.
  • 2.2. Yêu cầu Phi Chức năng:
    • 2.2.1. Hiệu năng:
      • Hệ thống phải phản hồi các yêu cầu tìm kiếm trong vòng 3 giây.
      • Hệ thống phải xử lý đồng thời ít nhất 100 người dùng.
    • 2.2.2. Bảo mật:
      • Thông tin cá nhân của người dùng phải được bảo mật và mã hóa.
      • Hệ thống phải tuân thủ các quy định về bảo vệ dữ liệu cá nhân (ví dụ: GDPR).
    • 2.2.3. Khả năng sử dụng:
      • Giao diện người dùng phải thân thiện, dễ sử dụng, và phù hợp với mọi đối tượng người dùng.
      • Hệ thống phải cung cấp hướng dẫn và trợ giúp trực tuyến.
    • 2.2.4. Quy định về Trả Sách Muộn:
      • Phí phạt trả sách muộn là 5.000 VNĐ/ngày cho sinh viên và 10.000 VNĐ/ngày cho giảng viên.
      • Nếu trả sách muộn quá 30 ngày, tài khoản người dùng sẽ bị khóa.