Quote from bsdinsight on 5 June 2025, 18:14

Bạn gặp khó khăn khi viết SRS trong vai trò Business Analyst?

SRS là gì?

SRS (Software Requirements Specification) là tài liệu mô tả chi tiết yêu cầu của một hệ thống phần mềm. Đây là tài liệu trọng yếu nhằm đảm bảo sự hiểu biết chung giữa nhóm phát triển và khách hàng, tránh sai sót và tối ưu hiệu quả.

Mục đích của SRS

Tài liệu SRS mô tả phần mềm sẽ làm gì và hoạt động như thế nào. Nó là cơ sở cho thiết kế, phát triển và kiểm thử phần mềm.

Liên quan đến các bên liên quan

SRS phải phản ánh được yêu cầu từ doanh nghiệp, người dùng, và các bên liên quan khác. Vai trò của Business Analyst là cực kỳ quan trọng trong việc khai thác, phân tích và xác nhận các yêu cầu này.

Hướng dẫn cho nhóm phát triển

SRS không chỉ là tài liệu mô tả mà còn là hợp đồng giữa bên yêu cầu và nhóm phát triển. Nó giúp cả hai bên thống nhất phạm vi và chức năng phần mềm.

Nội dung chính của SRS

Tài liệu cần bao gồm các yêu cầu chức năng, phi chức năng, yêu cầu giao diện, các mô hình dữ liệu và kịch bản sử dụng (use cases). Ngoài ra, các yêu cầu liên quan đến hiệu năng, bảo mật, khả năng mở rộng cũng cần được làm rõ.

Ngôn ngữ dễ hiểu

SRS nên được viết bằng ngôn ngữ rõ ràng, không gây hiểu nhầm, và phù hợp cho cả người kỹ thuật và không kỹ thuật.

Lợi ích của việc có SRS

SRS giúp giảm lỗi, tránh làm lại, và tiết kiệm thời gian và chi phí trong quá trình phát triển. Nó cũng là cơ sở để viết test case và kiểm thử phần mềm.

Kỳ vọng có thể đạt được

Tài liệu phải phản ánh kỳ vọng thực tế – những gì phần mềm có thể làm được trong phạm vi và giới hạn công nghệ hiện tại.

Vai trò của Business Analyst

• Thu thập yêu cầu: Thông qua phỏng vấn, khảo sát, quan sát người dùng.

• Phân tích và đặc tả yêu cầu: Ưu tiên theo giá trị kinh doanh, phân loại theo độ phức tạp.

• Xác nhận và xác minh: Làm việc với stakeholder để đảm bảo yêu cầu đầy đủ, hợp lý và có thể kiểm thử.

• Kết nối và truyền đạt: Là cầu nối giữa người dùng và nhóm phát triển.

Lưu ý khi viết SRS

• Tham gia đầy đủ các stakeholder.

• Sử dụng ngôn ngữ rõ ràng, không gây hiểu nhầm.

• Tận dụng sơ đồ: Use case, ERD, Data flow diagram….

• Luôn rà soát, cập nhật tài liệu định kỳ theo từng giai đoạn.

Định dạng SRS có thể khác nhau

Tùy theo loại dự án, phương pháp (Agile hay Waterfall), yêu cầu pháp lý (như trong lĩnh vực y tế, tài chính…), và yêu cầu riêng từ khách hàng mà cấu trúc SRS có thể linh hoạt.

Các phần thường có trong SRS

• Giới thiệu: mục đích, phạm vi, định nghĩa, đối tượng sử dụng

• Mô tả tổng quan: mô tả hệ thống, người dùng, môi trường vận hành, các giả định

• Yêu cầu cụ thể: chức năng, phi chức năng, bảo mật, giao diện người dùng

• Mô hình dữ liệu, luồng xử lý

• Tính năng hệ thống: mô tả hành vi và kịch bản

• Yêu cầu giao tiếp: tích hợp, API, UI

• Phụ lục: viết tắt, thuật ngữ chuyên ngành

Bạn có thể tham khảo thêm mẫu cụ thể trong tài liệu đính kèm để áp dụng trực tiếp vào dự án của mình. Chúc bạn viết SRS dễ dàng và hiệu quả hơn!