Chào anh em! Nếu đã từng trải qua môn Software Requirement Specification (như SWR302 ở FPTU) hoặc trực tiếp tham gia vào một dự án phần mềm thực tế, chắc chắn bạn đã nếm mùi "đau thương" khi phải viết tài liệu SRS. Viết code thì dễ, nhưng để viết ra một bản đặc tả yêu cầu khiến cả Dev, Tester và Khách hàng đều gật gù hiểu ý nhau thì lại là một nghệ thuật.
Tại devshare.pro.vn, mình đã chứng kiến không ít những dự án "đổ sông đổ biển", hoặc sinh viên phải "ôm hận" mùa Retake chỉ vì những sai lầm cực kỳ ngớ ngẩn trong tài liệu SRS. Hôm nay, hãy cùng mình bóc tách 5 lỗi phổ biến nhất khi viết đặc tả yêu cầu phần mềm (SRS) và bỏ túi ngay những kinh nghiệm "thực chiến" để khắc phục chúng nhé!
Lỗi 1: Yêu cầu mơ hồ, chung chung
Đây là "căn bệnh" kinh điển nhất của các tay mơ. Thay vì đưa ra các thông số cụ thể, nhiều bạn lại thích dùng những tính từ cảm tính như: "Hệ thống phải chạy nhanh", "Giao diện thân thiện", "Dễ sử dụng"...
Nhưng mấy bồ ơi, "nhanh" là bao nhiêu giây? "Thân thiện" theo tiêu chuẩn nào? Nếu viết như vậy, khi nghiệm thu dự án, sản phẩm cuối cùng có thể khác xa mong đợi, dẫn đến việc cãi nhau om sòm giữa Dev và Khách hàng rồi lại tốn công chỉnh sửa.
Kinh nghiệm sinh viên IT chia sẻ:
- Luôn dùng con số, tiêu chí cụ thể (ví dụ: “thời gian phản hồi ≤ 2 giây”, “hỗ trợ tối thiểu 500 người dùng đồng thời”).
- Tránh xa các từ mơ hồ vô thưởng vô phạt nếu không có tiêu chuẩn đo lường đi kèm.
- Nếu chưa xác định rõ, hãy ghi chú (TBD - To Be Determined) phần cần xác nhận lại với khách hàng để tránh sót thông tin.
Lỗi 2: Thiếu tính nhất quán trong tài liệu SRS
Một lỗi thường gặp khác khi viết đặc tả yêu cầu phần mềm (SRS) là thiếu sự nhất quán trong cách dùng thuật ngữ, ký hiệu, hoặc mô tả chức năng. Điều này khiến người đọc cảm thấy rối não và dễ gây hiểu lầm. Ví dụ kinh điển:
- Phần đầu gọi là “Người dùng”, phần sau lại cao hứng dùng “Khách hàng” cho cùng một vai trò.
- Biểu đồ Use Case ghi “Đăng nhập”, phần mô tả yêu cầu chi tiết lại chèn tiếng Anh là “Login”.
- Một số chức năng viết cực kỳ chi tiết, số khác lại bỏ lửng chỉ mô tả chung chung.
Khi tài liệu không đồng bộ về thuật ngữ và chi tiết mô tả, dev và tester sẽ khó bám sát yêu cầu ban đầu, dễ dẫn đến sai sót khi triển khai hoặc test hệ thống.
Mẹo khắc phục:
- Xây dựng ngay glossary (bảng thuật ngữ) ở đầu tài liệu và dùng thống nhất xuyên suốt.
- Giữ cùng một phong cách viết (tone & voice) và mức độ chi tiết cho tất cả các chức năng.
- Rà soát kỹ trước khi nộp bài hay bàn giao, tránh tình trạng “râu ông nọ cắm cằm bà kia”.
Lỗi 3: Bỏ sót yêu cầu quan trọng
Một trong những lỗi khiến dự án dễ gặp “khủng hoảng” nhất chính là bỏ sót yêu cầu quan trọng. Anh em thường chỉ chăm chăm vào chức năng chính (Functional Requirements - FR) mà quên béng mất các Yêu cầu phi chức năng (Non-Functional Requirements - NFR) cực kỳ quan trọng như: bảo mật, hiệu suất, khả năng mở rộng, hay quy định pháp lý.
Ví dụ: Làm hệ thống thanh toán mà quên yêu cầu về mã hóa dữ liệu (Security) thì coi như "bay màu" dự án.
Lỗi 4: Lẫn lộn giữa Yêu cầu (What) và Giải pháp (How)
Tài liệu SRS sinh ra là để trả lời câu hỏi "Hệ thống cần làm gì?" (What) chứ không phải "Hệ thống làm điều đó như thế nào?" (How). Rất nhiều bạn sinh viên (đặc biệt là dân code cứng) thường có thói quen cầm đèn chạy trước ô tô, chèn luôn cả thuật toán, kiểu dữ liệu hay framework vào tài liệu SRS.
Hãy để phần "How" cho tài liệu System Design Architecture (SDD). Viết SRS mà chèn code vào sẽ làm giới hạn sức sáng tạo của team Dev và khiến tài liệu trở nên nặng nề không cần thiết.
Lỗi 5: Bỏ qua việc xác nhận (Review) cùng Stakeholders
Bạn tự tin rằng mình đã lấy đủ yêu cầu, cắm mặt viết một lèo 100 trang SRS rồi gửi thẳng cho Dev? Khoan đã! Lỗi lớn nhất là bỏ qua khâu Review tài liệu với Khách hàng (Stakeholders).
Hệ quả là Dev làm xong, Khách hàng xem demo rồi phán một câu xanh rờn: "Ủa, anh đâu có yêu cầu cái này?". Để tránh bi kịch đập đi xây lại, hãy chia nhỏ tài liệu và có các buổi Review chốt yêu cầu (Sign-off) định kỳ nhé.
Lời kết:
5 lỗi trên đây đều là những “bài học xương máu” mà sinh viên IT chúng mình thường gặp, và đôi khi cả các dự án thực tế cũng dính phải. Hy vọng bài viết này trên devshare.pro.vn giúp bạn có thêm kinh nghiệm để "sống sót" qua môn học, và quan trọng hơn là áp dụng được vào công việc thực tế sau này.
Nếu thấy bài viết hữu ích, đừng ngần ngại chia sẻ cho bạn bè cùng lớp để không ai phải “chữa cháy” vì SRS viết sai nữa nhé! Chúc anh em code mượt, bug ít và qua môn nhẹ nhàng!
