SRS là gì? So sánh sự khác biệt giữa ba tài liệu SRS, BRD và FRS

Khi cuộc cách mạng công nghiệp 4.0 diễn ra mạnh mẽ, ngành công nghiệp phần mềm đã phát triển nhanh chóng. Để các công ty phần mềm có thể phát triển sản phẩm thành công, tài liệu SRS đóng vai trò cực kỳ quan trọng, vì đây là nơi ghi lại các yêu cầu cần thiết cho sản phẩm. Vậy SRS là gì và nó bao gồm những yếu tố nào? Tất cả sẽ được Mytour giải đáp trong bài viết dưới đây.

SRS là tài liệu gì?

SRS là tài liệu mô tả các yêu cầu phần mềm, viết tắt của Software Requirement Specification. Nó được dùng để chi tiết hóa yêu cầu về chức năng, phi chức năng, dữ liệu và các giao diện của hệ thống. Nhờ vào SRS, các bên liên quan có thể nắm bắt và hiểu rõ các nghiệp vụ của các chức năng. Đây là tài liệu thiết yếu đối với đội phát triển và đội kiểm thử phần mềm.

Vai trò của tài liệu SRS trong quá trình phát triển sản phẩm phần mềm

Như đã đề cập trước đó, SRS đóng vai trò then chốt đối với đội ngũ phát triển và kiểm thử phần mềm. Vậy tại sao tài liệu SRS lại quan trọng như vậy?

• Giúp các bên liên quan hiểu hệ thống theo một hướng thống nhất: Tài liệu SRS giúp tất cả các stakeholders, hay các bên thứ ba, dễ dàng nắm bắt và hiểu hệ thống một cách nhất quán, tránh sự hiểu lầm hoặc cách hiểu khác nhau từ mỗi người.
• Đội phát triển sử dụng tài liệu để xây dựng hệ thống chính xác: Việc đảm bảo các tính năng phần mềm được xây dựng đúng với yêu cầu của khách hàng không phải là điều đơn giản. Do đó, đội ngũ phát triển cần dựa vào tài liệu SRS để tạo ra hệ thống chính xác và đúng theo yêu cầu, không bị sai lệch.
• Hỗ trợ tester xây dựng test case: Các tester dựa vào tài liệu SRS để hiểu rõ các yêu cầu và từ đó xây dựng các kịch bản kiểm thử chi tiết nhất.
• Dễ dàng bảo trì và cải tiến hệ thống: Nhờ vào SRS, công việc bảo trì hệ thống hoặc việc nâng cấp, cải tiến các tính năng của hệ thống trở nên nhanh chóng và hiệu quả hơn.

Những thành phần cơ bản trong tài liệu SRS

Introduction – Giới thiệu tổng quan

Đây là phần đầu tiên trong tài liệu SRS. Phần giới thiệu bao gồm các thông tin chi tiết như sau:

• Purpose: Phần này giải thích mục đích và ý nghĩa của tài liệu SRS, giúp người đọc hiểu rõ hơn về khái niệm và tầm quan trọng của tài liệu này.
• Application Overview: Mục này cung cấp cái nhìn tổng quan về hệ thống dự định xây dựng, bao gồm các yếu tố như: tổng quan về hệ thống, các tính năng chính, quyền sử dụng, và mục đích xây dựng hệ thống phục vụ cho ai và vì lý do gì…
• Intended Audience and Reading Suggestions: Phần này chỉ ra đối tượng sử dụng tài liệu SRS và những việc họ cần làm với tài liệu này.
• Abbreviations: Cung cấp giải thích và định nghĩa các từ viết tắt xuất hiện trong tài liệu.
• References: Phần này liệt kê các tài liệu tham khảo hoặc mô tả liên quan đến tài liệu SRS.

High Level Requirement – Yêu cầu tổng thể

Phần này bao gồm các thông tin như sau:

• Object Relationship Diagram: Đây là sơ đồ thể hiện mối quan hệ tĩnh giữa các đối tượng trong hệ thống, mỗi đối tượng được coi là một thực thể trong hệ thống.

• Workflow Diagram: Phần này thể hiện chuỗi các bước hoặc quy trình làm việc của người dùng. Mỗi hành động của người dùng sẽ được minh họa qua từng giai đoạn trong quy trình nghiệp vụ của hệ thống.
• State Transition Diagram: Mô tả sự thay đổi trạng thái của hệ thống qua các bước trong workflow, giúp người đọc hiểu được ai là người thực hiện và sự tác động của họ đối với trạng thái trong quy trình của hệ thống.
• Use Case Diagram: Sơ đồ này thể hiện cách người dùng tương tác và sử dụng các tính năng của hệ thống.

Security Requirement – Yêu cầu về bảo mật

Phần này bao gồm mô tả chi tiết về nhiệm vụ, chức năng của người dùng và quyền hạn của họ trong hệ thống. Bên cạnh đó, phần này còn trình bày bảng ma trận các nhiệm vụ của từng người dùng khi sử dụng hệ thống.

Use Case Specification – Đặc tả trường hợp sử dụng

Phần này mô tả các yêu cầu chức năng của hệ thống, bao gồm chi tiết các nhiệm vụ cần thực hiện, hành vi, đầu vào và đầu ra dự kiến. Ngoài ra, mục này còn chỉ ra sự tương tác giữa các tác nhân bên ngoài với hệ thống và kết quả của những tương tác đó.

Wireframe – Mẫu thiết kế giao diện

Mẫu thiết kế giao diện là phần tài liệu đi kèm giúp người đọc dễ dàng hiểu và hình dung các màn hình của hệ thống. Điều này giúp việc xác nhận yêu cầu chức năng hệ thống với khách hàng trở nên nhanh chóng và hiệu quả hơn, đồng thời cho thấy sự thấu hiểu của nhà phân tích nghiệp vụ đối với các yêu cầu của khách hàng. Phần này cũng chứng minh khả năng của đội ngũ thực hiện dự án.

Other Requirement – Các yêu cầu khác

Các yêu cầu bổ sung cho hệ thống sẽ được trình bày chi tiết tại đây, bao gồm các yêu cầu không thuộc phạm vi hệ thống.

Integration – Tích hợp hệ thống

Mục này dùng để đính kèm các tài liệu liên quan đến việc tích hợp với các hệ thống bên ngoài.

Appendices – Phụ lục

Phần này cho phép định nghĩa các lỗi thông báo (error messages) hoặc các mẫu email (email templates) được sử dụng trong hệ thống.

Các bước chuẩn bị cho việc kiểm tra phần mềm

Bước 1: Lập kế hoạch và kiểm soát quá trình kiểm tra

Mục đích của bước này là xác định các loại kiểm tra cần triển khai, với hai hành động chủ yếu:

Quy trình lập kế hoạch kiểm tra

• Định hướng các phương pháp kiểm tra phù hợp.
• Xây dựng chiến lược kiểm tra, xác định các yếu tố cần thiết trong một chu kỳ phát triển phần mềm như: mục tiêu kiểm tra, phương pháp kiểm tra, thời gian và nguồn lực dự kiến cho dự án.
• Lên kế hoạch nguồn lực, bao gồm nhân sự, phần mềm, phần cứng và môi trường cần thiết.
• Lên lịch phân tích và thiết kế các trường hợp kiểm tra, tiến hành và đánh giá kết quả kiểm tra.
• Đưa ra các tiêu chí kết thúc kiểm tra.

Quản lý quá trình kiểm tra

• Đo lường và phân tích các kết quả kiểm tra
• Theo dõi tiến độ, mức độ bao phủ và các tiêu chí kết thúc kiểm tra
• Cung cấp các thông tin liên quan đến quá trình kiểm tra
• Thực hiện các biện pháp khắc phục (nếu cần thiết)
• Ra các quyết định cần thiết.

Bước 2: Phân tích và thiết kế kiểm tra

Mục tiêu của bước này là xác định các test case cụ thể và các bước kiểm tra chi tiết cho từng phiên bản phần mềm.

Bước 3: Thực hiện quy trình kiểm tra

Trong bước này, các kiểm thử viên sẽ tiến hành thực hiện các bước kiểm tra đã được thiết kế trước đó và ghi lại kết quả thu được.

Bước 4: Đánh giá và báo cáo kết quả kiểm tra

Quá trình kiểm tra sẽ được tổng kết, đánh giá và đưa ra các yêu cầu thay đổi cần thiết dựa trên kết quả thu được.

Bước 5: Kết thúc quá trình kiểm tra

Mục tiêu của bước này là hoàn tất quy trình kiểm tra phần mềm và chuẩn bị sẵn sàng để chuyển giao kết quả cho khách hàng.

So sánh giữa các tài liệu SRS, BRD và FRS

Các Business Analyst thường cần phải tạo ra 9 loại tài liệu quan trọng, trong đó có 3 tài liệu dễ bị nhầm lẫn là SRS, BRD và FRS. Vậy sự khác biệt và cách phân biệt chúng như thế nào?

BRD (viết tắt của Business Requirement Document) là tài liệu mô tả các mục tiêu chiến lược mà công ty cần đạt được. BRD cũng thể hiện nhu cầu và mối quan tâm của các bên liên quan đối với sản phẩm hoặc dịch vụ cuối cùng.

Nói cách khác, BRD giải thích lý do tại sao có những yêu cầu đó và xác định kết quả mong muốn, cùng với sự thay đổi mà hệ thống sẽ mang lại. Tài liệu này thường được sử dụng bởi các nhà tài trợ, BA, và các nhà quản lý ở các cấp cao và trung.

FRS (viết tắt của Functional Requirement Specifications) là tài liệu mô tả các yêu cầu chi tiết về chức năng hệ thống. Đây là tài liệu trình bày rõ ràng nhất trong ba loại tài liệu này. FRS sẽ giải đáp câu hỏi hệ thống cần hoạt động như thế nào để đáp ứng các yêu cầu được mô tả trong BRD và SRS.

FRS cung cấp các mô tả chi tiết về từng yêu cầu chức năng trong từng trường hợp cụ thể và sự tương tác của người dùng trên mỗi trang của hệ thống. Tài liệu này được xây dựng từ góc nhìn của người sử dụng, làm rõ cách thức hệ thống sẽ tương tác với họ. Sau khi hoàn thành, FRS sẽ được xem xét bởi các quản lý dự án, sau đó gửi cho khách hàng để xác nhận. Khi được phê duyệt, đây là bản hướng dẫn chính thức về cách hệ thống vận hành.

Ngoài ra, bạn có thể tham khảo bảng dưới đây để phân biệt giữa ba tài liệu SRS, BRD và FRS:

Tổng kết

Trên đây là những kiến thức về tài liệu đặc tả yêu cầu SRS, tầm quan trọng của tài liệu này, các thành phần chính cấu thành SRS, các bước chuẩn bị trước khi tiến hành kiểm tra phần mềm, và cách phân biệt giữa ba tài liệu SRS, BRD và FRS. SRS đóng vai trò quan trọng trong việc giúp đội ngũ phát triển phần mềm hiểu đúng và đủ yêu cầu của khách hàng, từ đó phát triển sản phẩm phù hợp.

Nếu bạn đang quan tâm đến việc phát triển hệ thống, đừng bỏ lỡ bài viết này nhé! Còn rất nhiều bài viết hữu ích khác đang chờ bạn khám phá tại Mytour.