[Công nghệ Thông tin] -- [Web] -- [Công nghệ phần mềm] -- [PhoThong] -- [TỪ ĐIỂN] -- [----] -- [Học viên cũ] -- [10.000 giờ]
--------------- <> -----------------
---  KHOA HỌC - CÔNG NGHỆ - GIÁO DỤC - VIỆC LÀM ---
---  Nhận làm website, web app, chạy quảng cáo, digital marketing --->>>  LIÊN HỆ...

Tìm kiếm trong Blog

Lập trình Scratch (8) - Phép chia dư

Bài trước: Lập trình Scratch (7) - Kỹ thuật lập trình (3)
-----

8. Phép chia dư

8.1 Dùng phép chia dư để lặp

Ở phần trước bạn đã biết cách sử dụng lệnh change by để tăng một biến liên tục lên 1 đơn vị, khi đạt đến một giá trị bất kỳ, sử dụng lệnh set to để đặt lại giá trị của biến.

Có một cách khác để lặp lại một việc liên tục (ví dụ tăng giá trị một biến) là dùng phép chia dư (modulo hoặc mod). Phép chia dư sẽ trả về phần dư của phép chia.

Ví dụ:

5 chia 6: được 0, dư 5

6 chia 6: được 1, dư 0

7 chia 6: được 1, dư 1

8 chia 6: được 1 dư 2

Bạn hãy kiểm tra kết quả ở trên bằng phép toán mod.

Ví dụ:

Ví dụ, đoạn mã sau sẽ tăng biến đếm lên một đơn vị mỗi khi bạn bấm phím space. Biến đếm sẽ tăng từ 0, 1, 2, 3, 4 và 5; sau đó lại bắt đầu lại từ 0 tới 5.

Để bộ đếm bắt đầu từ 1 thay vì 0, bạn thay đổi nội dung khối lập trình như sau:


Đoạn mã trên sẽ lặp lại và xuất các số lần lượt là 1, 2, 3, 4.

Bài tập 8a. Tạo 3 bộ trang phục (costumes) cho một nhân vật, đặt tên lần lượt là bo1, bo2, bo3. Mỗi khi người dùng bấm phím mũi tên xuống (down arrow), nhân vật sẽ thay đổi bộ trang phục mới, thứ tự thay đổi là bo1, bo2, bo3; tiếp tục lặp lại nếu người dùng tiếp tục bấm. Yêu cầu có sử dụng phép chia dư.

Bài tập 3.4b. Giả lập đồng hồ gồm ô hiển thị [giờ:phút:giây]. Khi bấm nút chạy, đồng hồ sẽ chạy tự động, từ 00:00:00. Yêu cầu có sử dụng phép chia dư.

-----

Gợi ý làm bài tập:

Bài tập 8a. Tạo 3 bộ trang phục (costumes) cho một nhân vật, đặt tên lần lượt là bo1, bo2, bo3. Mỗi khi người dùng bấm phím mũi tên xuống (down arrow), nhân vật sẽ thay đổi bộ trang phục mới, thứ tự thay đổi là bo1, bo2, bo3; tiếp tục lặp lại nếu người dùng tiếp tục bấm. Yêu cầu có sử dụng phép chia dư.

Bước 1: Chuẩn bị nhân vật và trang phục

  1. Mở Scratch và chọn một nhân vật. Ví dụ, bạn có thể chọn nhân vật Cat (Mèo).

  2. Chuyển sang thẻ Costumes (trang phục).

  3. Tải lên hoặc vẽ thêm 2 trang phục khác cho nhân vật để có tổng cộng 3 trang phục. Đặt tên các trang phục lần lượt là bo1, bo2, và bo3 để dễ theo dõi.

Bước 2: Lập trình với phép chia dư

  1. Chuyển sang thẻ Code và tạo một biến mới có tên là ThuTuTrangPhuc (thứ tự trang phục).

  2. Thêm khối lệnh when down arrow key pressed (khi bấm mũi tên xuống) từ danh mục Events (sự kiện).

  3. Tiếp theo, bạn sẽ sử dụng một công thức có phép chia dư để cập nhật giá trị của biến ThuTuTrangPhuc.

- Thêm khối lệnh Set ThuTuTrangPhuc to.

- Trong ô giá trị, hãy sử dụng phép toán chia dư (mod).

- Lấy giá trị của biến hiện tại ThuTuTrangPhuc chia dư cho 3 (vì bạn có 3 trang phục). Công thức sẽ là ThuTuTrangPhuc mod 3.

- Cuối cùng, để kết quả luôn là 1, 2, 3 (thay vì 0, 1, 2), hãy cộng thêm 1 vào kết quả. Công thức hoàn chỉnh là (ThuTuTrangPhuc mod 3) + 1.

  1. Sau khi đã tính được giá trị mới, thêm khối lệnh switch costume to [ThuTuTrangPhuc] (thay trang phục thành ThuTuTrangPhuc).

Bài tập 8b. Giả lập đồng hồ, gồm ô hiển thị [giờ:phút:giây]. Khi chạy chương trình, đồng hồ sẽ chạy tự động, từ 00:00:00. Yêu cầu có sử dụng phép chia dư.

Mục tiêu: Tạo một đồng hồ hiển thị giờ, phút, giây và chạy tự động.

Các bước thực hiện:

  1. Tạo các biến:

- Tạo ba biến có tên là giay, phut,gio.

- Bạn có thể chọn hiển thị các biến này trên màn hình kết quả.

  1. Lập trình cho khối lệnh bắt đầu:

- Sử dụng khối when clicked để khởi động đồng hồ.

- Đặt giá trị ban đầu cho tất cả các biến về 0. Dùng lệnh set [tên biến] to [0], thay tên biến lần lượt là gio, phut, giay

- Thêm khối forever để đồng hồ chạy liên tục.

  1. Lập trình hiển thị giây:

- Trong vòng lặp forever, sử dụng khối wait 1 seconds (đợi 1 giây).

- Sau đó, sử dụng khối change giay by 1 (thay đổi giây một lượng là 1).

- Bạn chạy thử xem số giây đã chạy chưa, nếu chạy rồi là được, nếu không thì kiểm tra lại đoạn mã xem làm đúng chưa.

- Tiếp theo, để đồng hồ giây quay lại 0 khi đạt đến 60, bạn sẽ sử dụng phép chia dư:

+ Sử dụng khối set giay to (đặt giây thành).

+ Trong ô giá trị, sử dụng công thức giay mod 60. Công thức này sẽ trả về số dư của phép chia giây cho 60, đảm bảo giá trị luôn nằm trong khoảng từ 0 đến 59.

  1. Lập trình hiển thị phút và giờ:

+ Sử dụng khối if…then… (nếu...thì…) để kiểm tra nếu giây đã trở về 0. If giay = 0 then.

+ Nếu giây bằng 0, điều đó có nghĩa là đã trôi qua 60 giây, vậy bạn cần tăng biến phút lên 1. Sử dụng khối change phut by 1 (thay đổi phút một lượng là 1).

+ Lặp lại logic tương tự cho biến phut gio. Sử dụng phép chia dư phut mod 60 để phút quay lại 0 khi đạt 60.

+ Tiếp theo, sử dụng một khối if...then... khác để kiểm tra nếu phút đã quay lại 0, thì tăng biến gio lên 1.

+ Sử dụng phép chia dư gio mod 24 để giờ quay lại 0 khi đạt 24.

8.1 Use modulo to wrap

Another way to wrap around is the function modulo or mod which returns the remainder of a division.

This is shorter:


How does it work ? You can place only the mod block on the programming canvas and test it by entering numbers and clicking with the mouse to evaluate the expression.

You will see 5 mod 6 is 5 (the reminder of 5 divided by 6).


You will see 6 mod 6 is 0 (the reminder of 6 divided by 6).



The counter i cycles through the 6 values 0, 1, 2, 3, 4, 5.

To start with 1 instead of 0 we can modify the expression to this.


The counter i cycles now through the 4 values 1, 2, 3, 4.

8.2 Lặp theo chiều ngược

Ở phần trên bạn đã biết điều khiển vòng lặp, bằng việc tăng biến đếm mỗi lần lên 1 đơn vị.

Ở phần này, bạn sẽ tạo ra vòng lặp bằng, bằng cách giảm biến đếm mỗi lần 1 đơn vị.

Đây là khối mã:


Khối mã trên sẽ giảm biến đếm mỗi khi bạn bấm phím space.

Giá trị của i sẽ lần lượt là 3,2,1, 0. Rồi lặp lại liên tục.

Bài tập 8c. Làm đồng hồ giống Bài tập 8b, tuy nhiên nó là đồng hồ đếm ngược. Cụ thể, đồng hồ sẽ bắt đầu chạy ở giờ [24:00:00], và sẽ dừng lại khi chạy ngược về [00:00:00]

8.2 Cycle the other way

We can also decrement and cycle back when reaching 0.

Here the counter i cycles through the range 3, 2, 1, 0.

-----
Bài sau:

Math_English (11): Grade5 - Australian - Unit 6A Number and Algebra

Bài trước: Math_English (10): Unit 5B Measurement, Geometry, Statistics and Probability
-----

Unit 6.A Number and Algebra

Number and Algebra

1. 

+

8

6

5

9

3

89

1








2. 

-

11

6

4

8

7

22

2








3. 

/

42

56

28

63

49

84

7








4. Write 2864 in words.

[ ]

5. Count backwards from 1836 in hundreds.

[  ], [  ], [  ]

6. Draw 10 equal parts. Shade 3/10.

7. I had $20. I spent $9.45.

How much have I now?

[  ]

8. If 0.7 is shaded, what decimal fraction is unshaded?

[  ]

9. Round off 5751 to the nearest thousand.

[   ]

10. The bus leaves at 9:03 am. 

I get to the bus stop at 8:47am. 

How long do I wait?

-----
Bài sau:

Phân tích và thiết kế PM (3) - Yêu cầu

Bài trước: Phân tích và thiết kế PM (2) - Các mô hình phát triển phần mềm
-----
3. Yêu cầu

3.1 Yêu cầu là gì

Trong phát triển phần mềm, yêu cầu (requirements) là những mô tả về các điều kiện, khả năng, và tính năng mà một hệ thống phần mềm phải có để đáp ứng nhu cầu của người dùng hoặc các bên liên quan. Nói một cách đơn giản, yêu cầu là cầu nối giữa mong muốn của khách hàng và sản phẩm cuối cùng.

Yêu cầu là nền tảng cho toàn bộ quá trình phát triển phần mềm. Nếu không có các yêu cầu rõ ràng và chính xác, dự án sẽ gặp rủi ro lớn vì nhóm phát triển có thể xây dựng một sản phẩm không đáp ứng được mục đích ban đầu, dẫn đến lãng phí thời gian và nguồn lực.

3.2 Các loại yêu cầu

Trong phát triển phần mềm, chúng ta quan tâm tới 3 loại yêu cầu sau:

- Yêu cầu người dùng (user requirements).

- Yêu cầu nghiệp vụ (domain requirements).

- Phi yêu cầu (non-requirements).

Chúng ta cùng tìm hiểu chi tiết hơn về mỗi loại yêu cầu:

[1] Yêu cầu người dùng

Yêu cầu người dùng (user requirement) là những nhu cầu, mong đợi, và kỳ vọng của người dùng cuối về một sản phẩm, hệ thống, hoặc dịch vụ. Nó mô tả những gì người dùng mong đợi hệ thống thực hiện để giải quyết vấn đề của họ.

Yêu cầu người dùng chia thành 2 loại: chức năng (tính năng của hệ thống) và phi chức năng (tốc độ, hiệu suất, tin cậy).

Yêu cầu được viết bằng ngôn ngữ tự nhiên, dễ hiểu, không mang tính kỹ thuật. Yêu cầu người dùng thường được thu thập thông qua phỏng vấn, khảo sát, và các buổi họp với khách hàng hoặc người dùng cuối.

Yêu cầu này thường được ghi lại trong một tài liệu gọi là Tài liệu đặc tả yêu cầu người dùng (User Requirement Specification - URS) để làm cơ sở cho việc thiết kế và phát triển sản phẩm. 

Mục đích của yêu cầu người dùng

- Định hướng phát triển: Giúp đội ngũ phát triển và kỹ sư hiểu rõ nhu cầu của người dùng để xây dựng sản phẩm đúng mong muốn.

- Đảm bảo sự hài lòng: Sản phẩm cuối cùng sẽ đáp ứng các kỳ vọng của người dùng, mang lại trải nghiệm tốt và sự hài lòng.

- Quản lý dự án: Là cơ sở để lập kế hoạch, ước tính chi phí, kiểm soát dự án và đánh giá thành công. 

Đặc điểm của yêu cầu người dùng

- Từ góc độ người dùng: Tài liệu URS được viết theo góc nhìn của người dùng cuối, không quá kỹ thuật hay phức tạp, và để người dùng có kiến thức chung về hệ thống có thể hiểu được. 

- Chức năng và phi chức năng: Bao gồm các tính năng mà hệ thống cần có (chức năng) và các yếu tố khác như hiệu suất, tốc độ, độ tin cậy (phi chức năng).

- Làm cơ sở cho tài liệu kỹ thuật: Là nền tảng cho các tài liệu đặc tả kỹ thuật do đội ngũ phát triển tạo ra, quy định cách thức đáp ứng yêu cầu của người dùng. 

Yêu cầu chức năng

Yêu cầu chức năng là các tính năng cụ thể mà một hệ thống phải thực hiện để đáp ứng nhu cầu của người dùng.

Ví dụ, yêu cầu tính năng của hệ thống Bán sách trực tuyến, gồm:

1. Yêu cầu liên quan đến Người dùng

Các yêu cầu này tập trung vào việc quản lý thông tin và tương tác của người dùng với hệ thống.

(FR là viết tắt của Functional Requirements: yêu cầu chức năng)

- Đăng ký và Đăng nhập:

+ FR-1.1: Hệ thống phải cho phép người dùng mới đăng ký tài khoản bằng cách cung cấp email, tên đầy đủ và mật khẩu.

+ FR-1.2: Hệ thống phải xác thực thông tin đăng nhập của người dùng đã có tài khoản.

+ FR-1.3: Hệ thống phải cung cấp tính năng "Quên mật khẩu", cho phép người dùng đặt lại mật khẩu qua email.

- Quản lý Tài khoản Cá nhân:

+ FR-1.4: Người dùng phải có khả năng cập nhật thông tin cá nhân của họ, bao gồm tên, địa chỉ, số điện thoại.

+ FR-1.5: Người dùng phải có thể xem lịch sử mua hàng của họ, bao gồm các đơn hàng đã đặt, trạng thái đơn hàng và chi tiết các sản phẩm đã mua.

2. Yêu cầu liên quan đến Sản phẩm và Tìm kiếm

Những yêu cầu này mô tả cách người dùng tương tác với danh mục sản phẩm.

- Tìm kiếm và Lọc sản phẩm:

+ FR-2.1: Hệ thống phải cho phép người dùng tìm kiếm sách theo tiêu đề, tác giả, hoặc nhà xuất bản.

+ FR-2.2: Người dùng phải có khả năng lọc kết quả tìm kiếm theo nhiều tiêu chí như thể loại (tiểu thuyết, kinh tế, khoa học), giá cả, hoặc đánh giá của người dùng.

- Hiển thị Thông tin sản phẩm:

+ FR-2.3: Hệ thống phải hiển thị một trang chi tiết cho mỗi cuốn sách, bao gồm hình ảnh bìa, mô tả, giá, tác giả, và các thông số kỹ thuật khác (số trang, năm xuất bản).

+ FR-2.4: Trang chi tiết sản phẩm phải hiển thị các đánh giá và nhận xét từ những người dùng khác.

3. Yêu cầu liên quan đến Giỏ hàng và Thanh toán

Các yêu cầu này mô tả quy trình mua hàng, từ khi thêm sản phẩm vào giỏ đến khi hoàn tất thanh toán.

- Quản lý Giỏ hàng:

+ FR-3.1: Người dùng phải có khả năng thêm một hoặc nhiều cuốn sách vào giỏ hàng.

+ FR-3.2: Người dùng có thể chỉnh sửa số lượng sách trong giỏ hàng hoặc xóa sách ra khỏi giỏ.

+ FR-3.3: Giỏ hàng phải tự động cập nhật tổng giá trị đơn hàng khi có thay đổi về số lượng hoặc sản phẩm.

- Thanh toán và Đặt hàng:

+ FR-3.4: Hệ thống phải cho phép người dùng lựa chọn phương thức thanh toán.

+ FR-3.5: Hệ thống phải gửi một email xác nhận đơn hàng tới người dùng sau khi thanh toán thành công, kèm theo chi tiết đơn hàng và mã theo dõi.

4. Yêu cầu liên quan đến Đánh giá và Nhận xét

- FR-4.1: Người dùng đã mua một cuốn sách phải có khả năng viết đánh giá và xếp hạng (ví dụ, từ 1 đến 5 sao) cho cuốn sách đó.

- FR-4.2: Các đánh giá phải được hiển thị trên trang chi tiết sản phẩm và được sắp xếp theo thời gian hoặc độ hữu ích.

Yêu cầu phi chức năng

Yêu cầu phi chức năng không tập trung vào các tính năng cụ thể, mà quan tâm tới chất lượng của hệ thống, như tốc độ, bảo mật, khả năng mở rộng, độ tin cậy.

Ví dụ:

Các yêu cầu phi chức năng của hệ thống Bán sách trực tuyến:

1. Hiệu suất (Performance)

- Tốc độ tải trang: Trang chủ và trang danh sách sản phẩm phải tải hoàn toàn trong vòng dưới 3 giây, ngay cả trong giờ cao điểm.

- Thời gian phản hồi: Hệ thống phải xử lý yêu cầu tìm kiếm và lọc sản phẩm trong vòng chưa đầy 2 giây.

- Khả năng chịu tải: Hệ thống phải có khả năng xử lý đồng thời 5.000 người dùng mà không bị chậm hoặc ngừng hoạt động.

2. Khả năng sử dụng (Usability)

- Giao diện trực quan: Giao diện người dùng phải dễ hiểu, các nút và liên kết phải rõ ràng để người dùng có thể dễ dàng tìm kiếm, thêm sách vào giỏ hàng và thanh toán mà không cần hướng dẫn.

- Tương thích đa nền tảng: Website phải hiển thị và hoạt động tốt trên các trình duyệt phổ biến như Chrome, Firefox và trên các thiết bị di động (điện thoại, máy tính bảng) với các kích thước màn hình khác nhau.

- Trợ giúp và Hỗ trợ: Hệ thống nên có các mục FAQ (câu hỏi thường gặp) hoặc chatbot để trả lời các câu hỏi cơ bản của người dùng.

3. Bảo mật (Security)

- Bảo vệ dữ liệu người dùng: Tất cả thông tin cá nhân của người dùng, bao gồm tên, địa chỉ, và mật khẩu, phải được mã hóa và lưu trữ an toàn.

- Bảo mật thanh toán: Toàn bộ giao dịch thanh toán phải tuân thủ các tiêu chuẩn bảo mật quốc tế (ví dụ: PCI DSS) để đảm bảo thông tin thẻ tín dụng của người dùng được bảo vệ.

- Chống tấn công: Hệ thống phải có cơ chế bảo vệ chống lại các cuộc tấn công mạng phổ biến như SQL Injection và XSS (Cross-Site Scripting).

4. Độ tin cậy (Reliability)

- Thời gian hoạt động (Uptime): Hệ thống phải đảm bảo thời gian hoạt động ít nhất 99.9% mỗi tháng, tức là không được ngừng hoạt động quá 44 phút.

- Sao lưu dữ liệu: Dữ liệu người dùng và đơn hàng phải được sao lưu tự động hàng ngày để có thể khôi phục lại trong trường hợp xảy ra sự cố.

5. Khả năng mở rộng (Scalability)

- Mở rộng kho sách: Hệ thống phải được thiết kế để dễ dàng thêm hàng nghìn đầu sách mới mà không ảnh hưởng đến hiệu suất.

- Hỗ trợ tính năng mới: Kiến trúc hệ thống phải cho phép tích hợp các tính năng bổ sung trong tương lai, chẳng hạn như hệ thống tích điểm thưởng cho khách hàng hoặc chương trình giới thiệu sản phẩm.

[2] Yêu cầu nghiệp vụ

Yêu cầu nghiệp vụ (domain requirements) là những quy tắc, chính sách, và nguyên tắc kinh doanh mà một hệ thống phần mềm phải tuân thủ. Chúng không phải là các chức năng cụ thể mà người dùng tương tác, mà là những ràng buộc nền tảng quyết định cách hệ thống hoạt động trong một lĩnh vực cụ thể (ví dụ: bán lẻ, tài chính, y tế).

Nói một cách đơn giản, yêu cầu nghiệp vụ trả lời câu hỏi: "Doanh nghiệp/tổ chức của tôi hoạt động như thế nào, và phần mềm này phải tuân theo những quy tắc nào?"

Ví dụ:

Trong một ứng dụng bán sách, yêu cầu nghiệp vụ có thể là: 

Quản lý kho sách:

- Hệ thống phải có khả năng thêm mới, cập nhật, và xóa thông tin sách (tên sách, tác giả, nhà xuất bản, giá, số lượng tồn kho).

- Hệ thống cần tự động trừ số lượng sách khi có đơn hàng được đặt thành công.

- Hệ thống phải thông báo cho người quản lý khi số lượng một đầu sách xuống dưới mức cảnh báo để nhập hàng.

Quản lý đơn hàng:

- Khách hàng phải có khả năng tạo đơn hàng mới với nhiều đầu sách khác nhau.

- Hệ thống cần tính toán tổng giá tiền cho đơn hàng, bao gồm cả thuế và phí vận chuyển.

- Hệ thống phải theo dõi trạng thái của đơn hàng (đang xử lý, đã giao, đã thanh toán, đã hủy) và thông báo cho khách hàng.

Quản lý tài khoản khách hàng:

- Khách hàng phải có khả năng đăng ký tài khoản, đăng nhập, và quản lý thông tin cá nhân (địa chỉ, số điện thoại).

- Hệ thống cần lưu trữ lịch sử đơn hàng của từng khách hàng.

[4] Phi yêu cầu

Phi yêu cầu (non-requirement) là một khái niệm hoặc giả định được xác định trong giai đoạn phân tích dự án, nhưng không phải là một yêu cầu chức năng hay phi chức năng mà hệ thống cần phải thực hiện.

Các "phi yêu cầu" thường là những điều kiện không thể đáp ứng, nằm ngoài phạm vi của dự án, hoặc những giả định cơ bản mà nhóm phát triển cần biết để tránh hiểu lầm. Chúng đóng vai trò làm rõ ranh giới của dự án và giúp tránh lãng phí tài nguyên vào những việc không cần thiết.

Ví dụ về Phi yêu cầu cho Hệ thống Bán sách trực tuyến

- Không hỗ trợ hình thức thanh toán bằng tiền mặt: Hệ thống sẽ chỉ xử lý các giao dịch thanh toán trực tuyến qua thẻ tín dụng, ví điện tử hoặc chuyển khoản ngân hàng. Việc giao hàng và thu tiền mặt không thuộc phạm vi của dự án này.

- Không bao gồm chức năng chatbot tích hợp AI: Hệ thống này sẽ chỉ sử dụng các câu hỏi thường gặp (FAQ) và form liên hệ để hỗ trợ khách hàng, thay vì tích hợp một chatbot phức tạp.

- Không xử lý việc vận chuyển sản phẩm: Hệ thống sẽ chỉ tạo ra đơn hàng và chuyển thông tin cho một đối tác vận chuyển bên thứ ba. Trách nhiệm theo dõi, giao hàng, và xử lý các vấn đề phát sinh trong quá trình vận chuyển sẽ do đối tác đó đảm nhận, nằm ngoài phạm vi phát triển của phần mềm.

- Không hỗ trợ nhiều ngôn ngữ: Hệ thống sẽ chỉ được phát triển với ngôn ngữ tiếng Việt.

Những ví dụ trên giúp làm rõ những gì dự án sẽ không làm, từ đó giúp nhóm phát triển tập trung vào các yêu cầu đã được xác định, tránh việc phát sinh công việc ngoài ý muốn.

3.3 Bài tập

Bài tập 3a. Dựa vào Tài liệu đặc tả yêu cầu người dùng (User Requirement Specification - URS).

Viết URS cho dự án của bạn (nhóm).


[Gợi ý: ví dụ một URS cơ bản]

URS - TÀI LIỆU ĐẶC TẢ YÊU CẦU NGƯỜI DÙNG “HỆ THỐNG BÁN SÁCH TRỰC TUYẾN”


1. Giới thiệu

Tài liệu này trình bày các Yêu cầu Người dùng (User Requirements) cho dự án phát triển hệ thống Bán sách trực tuyến. Hệ thống được xây dựng nhằm cung cấp một nền tảng thương mại điện tử, giúp người dùng dễ dàng tìm kiếm, mua sắm sách và quản lý các đơn hàng của mình. Mục đích của tài liệu là làm rõ những mong đợi và kỳ vọng của người dùng cuối, là cơ sở để đội ngũ phát triển và các bên liên quan cùng hiểu và thực hiện dự án.

2. Các Loại Yêu Cầu

Hệ thống cần đáp ứng cả Yêu cầu chức năng (các tính năng cụ thể) và Yêu cầu phi chức năng (các yếu tố về chất lượng hệ thống).

2.1. Yêu cầu Chức năng (Functional Requirements - FR)

Các yêu cầu này mô tả những tính năng và hành vi mà hệ thống phải thực hiện để đáp ứng nhu cầu của người dùng.

2.1.1. Yêu cầu liên quan đến Người dùng và Tài khoản

  • Đăng ký và Đăng nhập:

    • FR-1.1: Hệ thống phải cho phép người dùng mới đăng ký tài khoản bằng cách cung cấp email, tên đầy đủ và mật khẩu.

    • FR-1.2: Hệ thống phải xác thực thông tin đăng nhập của người dùng đã có tài khoản.

    • FR-1.3: Hệ thống phải có chức năng "Quên mật khẩu", cho phép người dùng đặt lại mật khẩu qua email.

  • Quản lý Tài khoản Cá nhân:

    • FR-1.4: Người dùng phải có khả năng cập nhật thông tin cá nhân của họ, bao gồm tên, địa chỉ và số điện thoại.

    • FR-1.5: Người dùng phải có thể xem lịch sử mua hàng, bao gồm các đơn hàng đã đặt, trạng thái đơn hàng và chi tiết sản phẩm đã mua.

2.1.2. Yêu cầu liên quan đến Sản phẩm và Tìm kiếm

  • Tìm kiếm và Lọc sản phẩm:

    • FR-2.1: Hệ thống phải cho phép người dùng tìm kiếm sách theo tiêu đề, tác giả hoặc nhà xuất bản.

    • FR-2.2: Người dùng phải có khả năng lọc kết quả tìm kiếm theo nhiều tiêu chí như thể loại (tiểu thuyết, kinh tế, khoa học), giá cả, hoặc đánh giá của người dùng.

  • Hiển thị Thông tin sản phẩm:

    • FR-2.3: Hệ thống phải hiển thị một trang chi tiết cho mỗi cuốn sách, bao gồm hình ảnh bìa, mô tả, giá, tác giả và các thông số kỹ thuật khác (số trang, năm xuất bản).

    • FR-2.4: Trang chi tiết sản phẩm phải hiển thị các đánh giá và nhận xét từ những người dùng khác.

2.1.3. Yêu cầu liên quan đến Giỏ hàng và Thanh toán

  • Quản lý Giỏ hàng:

    • FR-3.1: Người dùng phải có khả năng thêm một hoặc nhiều cuốn sách vào giỏ hàng.

    • FR-3.2: Người dùng có thể chỉnh sửa số lượng sách trong giỏ hàng hoặc xóa sách ra khỏi giỏ.

    • FR-3.3: Giỏ hàng phải tự động cập nhật tổng giá trị đơn hàng khi có thay đổi.

  • Thanh toán và Đặt hàng:

    • FR-3.4: Hệ thống phải cho phép người dùng lựa chọn phương thức thanh toán trực tuyến.

    • FR-3.5: Hệ thống phải gửi một email xác nhận đơn hàng tới người dùng sau khi thanh toán thành công, kèm theo chi tiết đơn hàng và mã theo dõi.

2.1.4. Yêu cầu liên quan đến Đánh giá và Nhận xét

  • FR-4.1: Người dùng đã mua một cuốn sách phải có khả năng viết đánh giá và xếp hạng (từ 1 đến 5 sao) cho cuốn sách đó.

  • FR-4.2: Các đánh giá phải được hiển thị trên trang chi tiết sản phẩm và được sắp xếp theo thời gian hoặc độ hữu ích.

2.2. Yêu cầu Phi chức năng (Non-Functional Requirements - NFR)

Các yêu cầu này mô tả các thuộc tính chất lượng của hệ thống, không phải là tính năng cụ thể.

  • Hiệu suất (Performance):

    • NFR-1.1: Tốc độ tải trang: Trang chủ và trang danh sách sản phẩm phải tải hoàn toàn trong vòng dưới 3 giây, ngay cả trong giờ cao điểm.

    • NFR-1.2: Thời gian phản hồi: Hệ thống phải xử lý yêu cầu tìm kiếm và lọc sản phẩm trong vòng chưa đầy 2 giây.

    • NFR-1.3: Khả năng chịu tải: Hệ thống phải có khả năng xử lý đồng thời 5.000 người dùng mà không bị chậm hoặc ngừng hoạt động.

  • Khả năng sử dụng (Usability):

    • NFR-2.1: Giao diện trực quan: Giao diện người dùng phải dễ hiểu, các nút và liên kết phải rõ ràng để người dùng có thể dễ dàng tìm kiếm, thêm sách vào giỏ hàng và thanh toán mà không cần hướng dẫn.

    • NFR-2.2: Tương thích đa nền tảng: Website phải hiển thị và hoạt động tốt trên các trình duyệt phổ biến như Chrome, Firefox và trên các thiết bị di động (điện thoại, máy tính bảng) với các kích thước màn hình khác nhau.

    • NFR-2.3: Trợ giúp và Hỗ trợ: Hệ thống nên có các mục FAQ (câu hỏi thường gặp) để trả lời các câu hỏi cơ bản của người dùng.

  • Bảo mật (Security):

    • NFR-3.1: Bảo vệ dữ liệu người dùng: Tất cả thông tin cá nhân của người dùng, bao gồm tên, địa chỉ và mật khẩu, phải được mã hóa và lưu trữ an toàn.

    • NFR-3.2: Bảo mật thanh toán: Toàn bộ giao dịch thanh toán phải tuân thủ các tiêu chuẩn bảo mật quốc tế (ví dụ: PCI DSS) để đảm bảo thông tin thẻ tín dụng của người dùng được bảo vệ.

    • NFR-3.3: Chống tấn công: Hệ thống phải có cơ chế bảo vệ chống lại các cuộc tấn công mạng phổ biến như SQL Injection và XSS (Cross-Site Scripting).

  • Độ tin cậy (Reliability):

    • NFR-4.1: Thời gian hoạt động (Uptime): Hệ thống phải đảm bảo thời gian hoạt động ít nhất 99.9% mỗi tháng, tức là không được ngừng hoạt động quá 44 phút.

    • NFR-4.2: Sao lưu dữ liệu: Dữ liệu người dùng và đơn hàng phải được sao lưu tự động hàng ngày để có thể khôi phục lại trong trường hợp xảy ra sự cố.

  • Khả năng mở rộng (Scalability):

    • NFR-5.1: Mở rộng kho sách: Hệ thống phải được thiết kế để dễ dàng thêm hàng nghìn đầu sách mới mà không ảnh hưởng đến hiệu suất.

    • NFR-5.2: Hỗ trợ tính năng mới: Kiến trúc hệ thống phải cho phép tích hợp các tính năng bổ sung trong tương lai, chẳng hạn như hệ thống tích điểm thưởng cho khách hàng hoặc chương trình giới thiệu sản phẩm.

3. Yêu cầu Nghiệp vụ (Domain Requirements)

Đây là các quy tắc kinh doanh và ràng buộc mà hệ thống phải tuân theo.

  • Quản lý kho sách:

    • Hệ thống phải có khả năng thêm mới, cập nhật và xóa thông tin sách (tên sách, tác giả, nhà xuất bản, giá, số lượng tồn kho).

    • Hệ thống cần tự động trừ số lượng sách khi có đơn hàng được đặt thành công.

    • Hệ thống phải thông báo cho người quản lý khi số lượng một đầu sách xuống dưới mức cảnh báo để nhập hàng.

  • Quản lý đơn hàng:

    • Hệ thống cần tính toán tổng giá tiền cho đơn hàng, bao gồm cả thuế và phí vận chuyển.

    • Hệ thống phải theo dõi trạng thái của đơn hàng (đang xử lý, đã giao, đã thanh toán, đã hủy) và thông báo cho khách hàng.

  • Quản lý tài khoản khách hàng:

    • Hệ thống cần lưu trữ lịch sử đơn hàng của từng khách hàng.

4. Phi yêu cầu (Non-Requirements)

Phần này xác định những gì nằm ngoài phạm vi của dự án.

  1. Không hỗ trợ thanh toán bằng tiền mặt khi nhận hàng: Hệ thống sẽ chỉ xử lý các giao dịch thanh toán trực tuyến qua thẻ tín dụng, ví điện tử hoặc chuyển khoản ngân hàng.

  2. Không bao gồm chức năng chatbot tích hợp AI: Hệ thống này chỉ sử dụng các câu hỏi thường gặp (FAQ) và form liên hệ để hỗ trợ khách hàng.

  3. Không xử lý việc vận chuyển sản phẩm: Hệ thống chỉ tạo ra đơn hàng và chuyển thông tin cho một đối tác vận chuyển bên thứ ba.

  4. Không hỗ trợ nhiều ngôn ngữ: Hệ thống chỉ được phát triển với ngôn ngữ tiếng Việt.

-----
Bài sau: