Vì sao phải phân tích hệ thống trước khi viết dòng code đầu tiên?

Bài viết hệ thống hóa lý do và cách thực hiện phân tích hệ thống ở mức vừa đủ: (1) phân biệt “ý tưởng” và “yêu cầu”; (2) các bước phân tích từ stakeholder - use case - dữ liệu - ràng buộc; (3) tài liệu tối thiểu cần có trước khi code; (4) minh họa qua một case study hệ thống quản lý đặt hàng; (5) lộ trình luyện tập phân tích hệ thống cho các em trong 4 tuần.

Từ khóa: phân tích hệ thống, yêu cầu phần mềm, use case, user story, ERD, kiến trúc, phạm vi dự án.

1. ĐẶT VẤN ĐỀ

Trong môi trường học tập, các em thường bị cuốn vào việc “code cho nhanh để có sản phẩm”. Nhưng trong kỹ thuật phần mềm, tốc độ viết code không quyết định thành công; tốc độ hiểu đúng vấn đề mới quyết định.

Tôi quan sát thấy một mẫu lặp lại ở nhiều đồ án:

- Tuần đầu: code giao diện, dựng database theo cảm tính.

- Những tuần giữa: phát hiện thiếu chức năng, đổi luồng nghiệp vụ, sửa database.

- Tuần cuối: vá lỗi, thiếu thời gian test, tài liệu rời rạc.

Phân tích hệ thống không phải là thủ tục “hình thức”. Nó là bước giúp các em giảm làm lại, giảm tranh cãi trong nhóm và tăng khả năng hoàn thành đúng hạn.

2. MỤC TIÊU VÀ PHẠM VI

2.1. Mục tiêu

- Làm rõ vì sao phân tích hệ thống là bước bắt buộc trước khi lập trình.

- Hệ thống hóa các bước phân tích tối thiểu cho dự án các em.

- Giới thiệu bộ tài liệu “vừa đủ” để nhóm triển khai thống nhất.

- Minh họa quy trình qua case study cụ thể.

- Đề xuất lộ trình 4 tuần để luyện kỹ năng phân tích.

2.2. Phạm vi

- Bài viết tập trung vào phân tích ở mức dự án nhỏ - vừa (đồ án môn học, nhóm 2-3 người).

- Không đi sâu vào UML đầy đủ hay quy trình doanh nghiệp phức tạp.

- Coi phân tích như một hoạt động liên tục: làm trước khi code và cập nhật khi hiểu thêm.

3. CƠ SỞ LÝ THUYẾT: PHÂN TÍCH HỆ THỐNG LÀ GÌ?

3.1. Phân tích hệ thống vs Thiết kế hệ thống vs Lập trình

Để tránh nhầm lẫn, tôi tóm tắt nhanh:

- Phân tích hệ thống (Analysis): hệ thống cần làm gì? cho ai? trong phạm vi nào?

- Thiết kế hệ thống (Design): hệ thống sẽ được xây như thế nào? dữ liệu ra sao? kiến trúc gì?

- Lập trình (Implementation): hiện thực hóa thiết kế bằng code.

Nếu bỏ qua phân tích, các em sẽ phải “thiết kế lại” ngay trong lúc code - và đó là lúc chi phí thay đổi cao nhất.

3.2. Tư duy chi phí sửa sai (cost of change)

Một thay đổi ở yêu cầu nếu phát hiện sớm (trước khi code) thường chỉ mất vài phút để sửa tài liệu. Nhưng nếu phát hiện muộn (sau khi đã code, đã có dữ liệu), chi phí sẽ tăng theo cấp số nhân: sửa code, sửa database, migrate dữ liệu, sửa test, sửa tài liệu, và đôi khi còn ảnh hưởng các module khác.

Vì vậy, phân tích tốt không làm dự án chậm lại; nó giúp dự án chạy nhanh hơn ở giai đoạn sau.

4. QUY TRÌNH PHÂN TÍCH TỐI THIỂU TRƯỚC KHI CODE

Dưới đây là quy trình tôi thường khuyến nghị cho nhóm các em. Mỗi bước đều có sản phẩm đầu ra rõ ràng.

Hình 1. Quy trình tối thiểu và sản phẩm đầu ra trước khi triển khai code.

(Nguồn: https://itnavi.com.vn)

 4.1. Xác định stakeholder và mục tiêu người dùng

 Ví dụ hệ thống bán hàng online thường có các vai trò:

 - Khách hàng: tìm sản phẩm, đặt hàng, theo dõi đơn.

 - Nhân viên/Quản trị: quản lý sản phẩm, duyệt đơn, cập nhật trạng thái.

 - Hệ thống thanh toán/vận chuyển (bên thứ ba): nhận yêu cầu, trả kết quả.

 Nếu không xác định rõ vai trò ngay từ đầu, nhóm dễ quên chức năng quan trọng như phân quyền, lịch sử thao tác, hoặc cơ chế xử lý khi bên thứ ba thất bại.

 4.2. Chốt phạm vi: “phiên bản 1 làm đến đâu?”

 Nhiều đồ án bị vỡ kế hoạch vì tham quá nhiều tính năng. Tôi khuyến nghị chốt phạm vi theo nguyên tắc:

 - Làm tốt 60% tính năng cốt lõi còn hơn làm 100% nhưng lỗi.

 - Bắt buộc có: đăng nhập, CRUD chính, luồng nghiệp vụ chính, phân quyền tối thiểu.

 - Nâng cao (optional): realtime, chatbot, recommendation, thanh toán online.

 Khi chốt scope, hãy ghi rõ “ngoài phạm vi” để tránh tranh cãi về sau.

 4.3. Mô tả nghiệp vụ bằng use case/user story

 Hai cách viết phổ biến:

 1) Use case (mô tả luồng): Actor -> Trigger -> Main flow -> Alternative flow.

 2) User story (gọn hơn): “Là một <vai trò>, tôi muốn <mục tiêu> để <giá trị>.”

 Ví dụ user story:

 - “Là khách hàng, tôi muốn thêm sản phẩm vào giỏ để chuẩn bị đặt hàng.”

 - “Là quản trị, tôi muốn cập nhật trạng thái đơn hàng để khách theo dõi tiến độ.”

 Điểm quan trọng: mỗi story nên có tiêu chí chấp nhận (acceptance criteria) để biết thế nào là xong.

Hình 2. Use Cases và User Stories

4.4. Thiết kế dữ liệu sơ bộ (ERD) trước khi tạo bảng

Thiết kế dữ liệu sớm giúp các em tránh sửa database nhiều lần. Với dự án các em, các em có thể bắt đầu bằng ERD sơ bộ:

- Thực thể chính (entities): User, Product, Order, OrderItem, Payment.

- Quan hệ: Order 1-n OrderItem; Product 1-n OrderItem; User 1-n Order.

Sau đó, kiểm tra lại bằng câu hỏi: “Nếu khách đổi địa chỉ giao hàng thì lưu ở đâu?”, “Nếu đơn hàng có nhiều sản phẩm thì biểu diễn thế nào?”.

Chỉ cần trả lời được những câu hỏi này, các em đã tránh được nhiều lỗi thiết kế dữ liệu.

Hình 3. Ví dụ về sơ đồ ERD (Nguồn: https://fptshop.com.vn/tin-tuc/danh-gia/erd-la-gi-161693)

 4.5. Yêu cầu phi chức năng (NFR) - phần hay bị bỏ quên

 NFR thường quyết định trải nghiệm và độ ổn định. Một checklist tối thiểu:

 - Bảo mật: mật khẩu hash, phân quyền, validate input.

 - Hiệu năng: phân trang, index cơ bản, tránh truy vấn N+1.

 - Độ tin cậy: logging, xử lý lỗi, backup database (mức cơ bản).

 - Khả năng mở rộng: tách module, cấu trúc thư mục rõ ràng.

 Không cần làm tất cả, nhưng cần viết ra để cả nhóm thống nhất.

5. CASE STUDY: HỆ THỐNG QUẢN LÝ ĐẶT HÀNG (MINI E-COMMERCE)

5.1. Chốt phạm vi phiên bản 1

- Khách hàng: đăng ký/đăng nhập, xem danh sách sản phẩm, thêm giỏ, tạo đơn hàng.

- Quản trị: CRUD sản phẩm, xem danh sách đơn, cập nhật trạng thái (pending -> shipping -> done).

- Ngoài phạm vi: thanh toán online, khuyến mãi phức tạp, realtime tracking.

5.2. 3 user story cốt lõi + tiêu chí chấp nhận

1. Story 1 - Tạo đơn hàng: Khi khách bấm “Đặt hàng”, hệ thống tạo Order và OrderItem; tổng tiền tính đúng; giỏ hàng được làm rỗng.

 2. Story 2 - Quản trị cập nhật trạng thái: Admin có thể chuyển trạng thái đơn theo luồng hợp lệ; không được nhảy trạng thái tùy ý.

 3. Story 3 - Xem lịch sử đơn: Khách chỉ xem đơn của chính mình; hiển thị trạng thái và danh sách sản phẩm.

 5.3. ERD tối thiểu (mô tả bằng lời)

 Một ERD tối thiểu có thể gồm:

 - users(id, name, email, password, role)

- products(id, name, price, stock)

 - orders(id, user_id, status, total, created_at)

 - order_items(id, order_id, product_id, quantity, unit_price)

 Từ ERD, nhóm có thể bắt đầu code với mức rủi ro thấp, vì luồng dữ liệu đã tương đối rõ.

 6. LỘ TRÌNH LUYỆN PHÂN TÍCH HỆ THỐNG TRONG 4 TUẦN

 4. Tuần 1: Chọn 1 bài toán quen thuộc (quản lý lớp, đặt đồ ăn, thư viện). Viết stakeholder + scope + 10 user story.

 5. Tuần 2: Vẽ luồng nghiệp vụ chính (happy path) + 3 luồng ngoại lệ. Viết acceptance criteria cho 5 story quan trọng.

 6. Tuần 3: Thiết kế ERD sơ bộ + rà soát bằng câu hỏi tình huống. Chốt danh sách bảng/field tối thiểu.

 7. Tuần 4: Viết tài liệu 3-5 trang (SRS rút gọn) + tạo backlog nhiệm vụ. Sau đó mới bắt tay vào code.

 7. KẾT LUẬN

 Phân tích hệ thống không phải là việc “viết giấy tờ”, mà là hoạt động tư duy để hiểu đúng vấn đề và giảm chi phí sửa sai. Đối với các em, phân tích tốt giúp dự án rõ ràng, nhóm làm việc ít tranh cãi, code ra mạch lạc và dễ bảo trì.

 Tôi khuyến nghị: trước khi mở IDE, hãy mở một trang giấy. Chỉ cần chốt stakeholder, scope, 5-10 user story và một ERD sơ bộ, các em sẽ tiết kiệm được rất nhiều thời gian ở giai đoạn cuối.

 TÀI LIỆU THAM KHẢO

 [1] T. Đ. Quế và N. M. Sơn, Giáo trình Phân tích và thiết kế hệ thống thông tin. Hà Nội: Học viện Công nghệ Bưu chính Viễn thông, 2012.

Thầy Huỳnh Luân - Giảng viên Khoa CNTT-ĐT