Tìm hiểu SRS thông qua định nghĩa, thành phần, vai trò và cách viết tài liệu cơ bản

Tài liệu SRS đóng vai trò quan trọng trong việc liên kết khách hàng và nhóm phát triển. Nền tảng đảm bảo tất cả các bên hiểu rõ và đồng thuận về yêu cầu của dự án phần mềm. Người dùng có thể tham khảo các thành phần chính và cách viết SRS từ Chí Thanh

SRS là một loại tài liệu cơ bản được dùng trong quá trình phát triển phần mềm. Tài liệu đặc tả những yêu cầu thông dụng về chức năng hoặc phi chức năng trên một hệ thống. Vậy bản chất của SRS là gì? Tài liệu có những thành phần nào? Quá trình triển khai tài liệu SRS ra sao? Mời bạn cùng Chí Thanh khám phá trong bài viết dưới đây!

Thế nào là tài liệu SRS?

Tài liệu SRS (viết tắt của Software Requirements Specification) có nghĩa là Tài liệu Yêu Cầu Phần Mềm. Đây là một tài liệu quan trọng trong quá trình phát triển phần mềm. Nền tảng mô tả chi tiết về những yêu cầu chức năng và phi chức năng của phần mềm, kèm theo đó là các yêu cầu về hiệu suất, an ninh và các thông tin khác.

Trong tài liệu SRS bao gồm nội dung mô tả chi tiết về giao diện người dùng, các chức năng chính, các điều kiện tiên quyết, ràng buộc hệ thống và mô tả về cách thức mà phần mềm sẽ hoạt động trong mọi trường hợp khả thi. Đây là một tài liệu quan trọng để đảm bảo các bên liên quan đều nắm bắt trong quá trình phát triển phần mềm.

SRS có những thành phần nào?

Introduction (Phần giới thiệu)

Phần giới thiệu này có tác dụng định hình cho người đọc cái nhìn tổng quan và hiểu rõ mục đích, phạm vi, đối tượng đọc cũng như nguồn tham chiếu của tài liệu SRS. Introduction trong tài liệu SRS thường bao gồm các thông tin sau:

• Mục tiêu: Mô tả mục tiêu và phạm vi của tài liệu SRS.
• Phạm vi của Dự án: Mô tả về phạm vi của dự án cụ thể mà tài liệu SRS đang thảo luận, bao gồm các hạn chế và ràng buộc.
• Người đọc mục tiêu: Xác định đối tượng người đọc mà tài liệu SRS dành cho, bao gồm các nhóm liên quan như nhà phát triển, quản lý dự án hoặc các bên liên quan khác.
• Tài liệu tham chiếu: Liệt kê các tài liệu tham khảo được sử dụng trong quá trình chuẩn bị tài liệu SRS.
• Tóm tắt: Bảng tóm tắt ngắn gọn của các mục chính và yêu cầu cơ bản trong tài liệu SRS.

High Level Requirement (Yêu cầu mức độ tổng thể)

Yêu cầu mức độ tổng thể (High Level Requirements) trong tài liệu SRS đề cập đến các yêu cầu chức năng và phi chức năng cấp cao của hệ thống theo tiêu chuẩn tổng quan và trừu tượng. Phần này bao gồm nội dung giới thiệu các chức năng chính mà hệ thống cần cung cấp để đáp ứng nhu cầu của người dùng.

Bên cạnh đó, High Level Requirements hỗ trợ các yêu cầu không chức năng như hiệu suất, bảo mật, quản lý dự án và các hạn chế khác. Chẳng hạn như:

• Yêu cầu chức năng: Mô tả các chức năng chính mà hệ thống cần thực hiện. Ví dụ như đăng nhập, quản lý tài liệu, tạo và quản lý tài khoản người dùng và các chức năng quan trọng khác.
• Yêu cầu không chức năng: Bao gồm các yêu cầu về hiệu suất, khả năng mở rộng, bảo mật, tương tác người dùng và quản lý dữ liệu.
• Ràng buộc và giả định: Đưa ra các ràng buộc và giả định liên quan đến hệ thống. Ví dụ như hệ thống phải hoạt động trên nền tảng cụ thể hoặc phải tuân theo các quy định pháp luật cụ thể.

Security Requirement (Yêu cầu bảo mật)

Yêu cầu về bảo mật trong tài liệu SRS mô tả các yêu cầu và hạn chế liên quan đến bảo mật thông tin và hệ thống. Cụ thể, phần Yêu cầu Bảo mật có thể bao gồm những điều sau:

• Quản lý truy cập: Mô tả cách thức xác định, xác thực và quản lý quyền truy cập của người dùng vào hệ thống. Điều này bao gồm việc xác định vai trò và quyền hạn của từng người dùng, đăng nhập đa yếu tố và quản lý phiên đăng nhập.
• Bảo vệ dữ liệu: Mô tả cách thức bảo vệ dữ liệu quan trọng, bao gồm cả dữ liệu trong chuyển động và ở trạng thái nghỉ. Đây là những vấn đề liên quan đến mã hóa dữ liệu, kiểm soát truy cập vào dữ liệu nhạy cảm và đảm bảo tính toàn vẹn của dữ liệu.

Use Case Specification (Đặc tả Use Case)

Đặc tả Use Case trong tài liệu SRS mô tả các tình huống sử dụng cụ thể mà người dùng có thể gặp phải khi sử dụng hệ thống và cách thức mà hệ thống sẽ đáp ứng vào những tình huống đó. Mỗi Use Case thường đề cập đến một chức năng hoặc tính năng cụ thể của hệ thống. Đặc tả Use Case có thể bao gồm các phần sau:

• ID và Tên Use Case: Định danh và tên của Use Case để xác định một cách duy nhất và dễ nhớ.
• Mô tả: Mô tả ngắn gọn về mục tiêu và nội dung của Use Case.
• Các bước chính: Mô tả các bước cụ thể mà người dùng thực hiện và cách thức mà hệ thống phản hồi trong quá trình thực hiện Use Case.
• Tiên điều kiện: Mô tả các điều kiện phải được thỏa mãn trước khi Use Case có thể được thực hiện.
• Kết quả mong đợi: Mô tả kết quả mà người dùng mong đợi khi hoàn thành Use Case.
• Luồng chính và Luồng thay thế: Mô tả các kịch bản chính và các kịch bản thay thế có thể xảy ra trong quá trình thực hiện Use Case.

Other Requirement (Những yêu cầu khác)

Other Requirement bổ sung về các khía cạnh khác của hệ thống một cách chi tiết hơn. Từ đó đảm bảo rằng mọi khía cạnh quan trọng đều được mô tả một cách cụ thể và chi tiết trong tài liệu SRS.

• Yêu cầu về giao diện người dùng: Mô tả các yêu cầu liên quan đến giao diện người dùng, bao gồm yêu cầu về thiết kế, trải nghiệm người dùng và tương tác người dùng.
• Yêu cầu về dữ liệu: Đặc tả các yêu cầu về dữ liệu mà hệ thống cần quản lý, lưu trữ và xử lý. Hệ thống bao gồm cấu trúc dữ liệu, quy định về nhập liệu và yêu cầu về bảo mật dữ liệu.

Integration (Yêu cầu tích hợp)

Trong tài liệu SRS, phần yêu cầu tích hợp mô tả các yêu cầu liên quan đến tích hợp các phần mềm khác, hệ thống bên ngoài hoặc các dịch vụ mạng. 

Phần này thường bao gồm các yêu cầu về giao diện, chuẩn giao tiếp, cách thức tích hợp với các hệ thống khác. Bên cạnh đó còn có các yêu cầu về khả năng tương tác và liên kết với các thành phần bên ngoài. Cụ thể, phần yêu cầu tích hợp trong SRS có thể bao gồm:

• Giao diện người dùng: Mô tả yêu cầu về giao diện người dùng và cách thức tích hợp với các giao diện người dùng khác nếu cần thiết.
• Kết nối với hệ thống bên ngoài: Mô tả yêu cầu về kết nối và tương tác với các hệ thống bên ngoài như giao tiếp qua giao thức mạng, API hoặc các dịch vụ web.
• Chuẩn giao tiếp: Xác định các chuẩn giao tiếp hoặc các giao thức cụ thể mà hệ thống cần tuân theo khi tích hợp với các phần mềm hoặc hệ thống khác.

Appendices (Phụ lục)

Phần phụ lục trong tài liệu SRS thường chứa các thông tin bổ sung và hỗ trợ nhưng không nằm trong phạm vi chính của tài liệu. Các nội dung thông thường có thể bao gồm:

• Biểu đồ và sơ đồ: Các biểu đồ luồng dữ liệu, sơ đồ lớp, sơ đồ thực thể-quan hệ, biểu đồ UML và các biểu đồ khác liên quan đến phân tích, thiết kế hệ thống.
• Dữ liệu thực nghiệm: Các dữ liệu mẫu, kịch bản kiểm thử, kết quả kiểm thử và các dữ liệu thực nghiệm khác sẽ được thể hiện trong phần này.
• Tài liệu tham khảo: Danh sách các tài liệu tham khảo, sách, bài báo hoặc tài liệu khác mà tác giả đã sử dụng để chuẩn bị tài liệu SRS.

Những vai trò quan trọng của tài liệu SRS

Tài liệu SRS (Software Requirements Specification) có vai trò quan trọng trong quá trình phát triển phần mềm. Cụ thể, vai trò của tài liệu SRS bao gồm:

• Xác định yêu cầu: Tài liệu SRS giúp xác định và mô tả chi tiết các yêu cầu chức năng và phi chức năng của hệ thống phần mềm. Điều này giúp hệ thống hiểu rõ các yêu cầu từ góc nhìn người dùng, quản lý dự án và nhóm phát triển.
• Cơ sở cho thiết kế: SRS cung cấp cơ sở cho quá trình thiết kế hệ thống bằng cách mô tả chức năng, hiệu suất, giao diện người dùng và các yêu cầu về dữ liệu cần thiết.
• Hỗ trợ trong quá trình kiểm thử: SRS cung cấp thông tin cụ thể để phát triển kịch bản kiểm thử và xác định các tiêu chí kiểm tra để đảm bảo rằng hệ thống phần mềm đáp ứng các yêu cầu.
• Hướng dẫn phát triển và triển khai: Tài liệu SRS hỗ trợ việc phát triển phần mềm bằng cách cung cấp hướng dẫn chi tiết và đầu mối để triển khai các tính năng, chức năng và yêu cầu phần mềm.
• Thành phần quản lý dự án: SRS có thể được sử dụng như một căn cứ để theo dõi và đánh giá tiến độ của dự án, đảm bảo rằng mục tiêu và yêu cầu đã được đáp ứng.

Hướng dẫn cách viết tài liệu SRS

Quá trình viết tài liệu Software Requirements Specification đòi hỏi sự kiên nhẫn và cẩn thận của người thực hiện. Từ đó đảm bảo các yêu cầu về chức năng và phi chức năng của hệ thống phần mềm đều được mô tả một cách rõ ràng, đầy đủ. Dưới đây là một số điều kiện quan trọng để viết tài liệu SRS:

• Tìm hiểu và thu thập thông tin từ các nguồn khác nhau như khách hàng, người dùng cuối, quản lý dự án và các bên liên quan khác để hiểu rõ về yêu cầu của hệ thống phần mềm.
• Mô tả chi tiết các chức năng cần phải có trong hệ thống phần mềm theo góc độ người dùng, bao gồm cả luồng hoạt động và đặc điểm của từng chức năng.
• Mô tả các yêu cầu về hiệu suất, bảo mật, tương tác người dùng và các yêu cầu phi chức năng khác mà hệ thống phần mềm cần phải đáp ứng.
• Sử dụng thuật ngữ kỹ thuật chính xác và tránh sử dụng ngôn ngữ mơ hồ để mô tả yêu cầu. Sử dụng biểu đồ và sơ đồ để minh họa và làm rõ yêu cầu khi cần thiết.
• Xác nhận lại các yêu cầu với khách hàng và các bên liên quan để đảm bảo rằng tài liệu phản ánh đúng và đầy đủ những yêu cầu thực sự của hệ thống.
• Tổ chức các thông tin theo cấu trúc logic và dễ hiểu. Đảm bảo rằng tài liệu SRS có phần giới thiệu, mô tả yêu cầu và phần phụ lục, thuật toán, đặc tả ngôn ngữ và các bảng dữ liệu.