Software Requirement Specs (SRS) là gì?

Hiện nay với sự phát triển của cách mạng công nghiệp 4.0, rất nhiều công ty sản xuất phần mềm đã được hình thành và phát triển. Tài liệu đặc tả SRS chính là những yêu cầu về sản phẩm mà đội phát triển phần mềm cần thực hiện. Do vậy, đây là tài liệu rất quan trọng trong quy trình phát triển phần mềm. Chi tiết về tài liệu SRS là gì và làm thế nào để xây dựng được một tài liệu chuẩn, tại bài viết này hãy cùng chúng tôi tìm hiểu ngay nhé!

Xem thêm trang blog kỹ thuật TIGO Solutions: Viết Requirement Specs như thế nào?

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

Tài liệu SRS là từ viết tắt của Software Requirement Specification, được dịch ra tiếng việt là tài liệu đặc tả yêu cầu. SRS là tài liệu được sử dụng để 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. Tài liệu này sẽ hỗ trợ đưa ra các tính năng của hệ thống hay dùng cho việc đọc hiểu hệ thống của bên thứ ba liên quan đến công ty. Đây là một tài liệu quan trọng cho đội phát triển (system analyst, business analyst, code) và kiểm thử (tester).

Nội dung của SRS là mô tả các chức năng và cấu trúc của hệ thống là FR và NFR. Tài liệu đặc tả yêu cầu SRS còn đóng vai trò là cầu nối liên kết giữa người dùng và nhà sáng tạo và từ đó hệ thống có thể đáp ứng được đúng mục đích và yêu cầu của người sử dụng.

Ngoài ra, dựa vào các yêu cầu mà SRS thống kê, ta có thể đánh giá được số lượng scope, thời gian hoàn thành hay những chi phí cần đáp ứng giúp hoàn thành sản phẩm một cách nhanh chóng và dễ dàng hơn.

Tầm quan trọng của tài liệu SRS

SRS là tài liệu đặc tả vô cùng quan trọng trong quá trình phát triển phần mềm, nó có vai trò:

• Giúp cho các bên thứ ba – stakeholders đều hiểu được hệ thống theo cùng một hướng, tránh trường hợp mỗi người một ý.
• Giúp cho đội phát triển xây dựng hệ thống một cách chính xác, đặc tả được các tính năng, không đi lạc hướng so với yêu cầu của khách hàng.
• SRS giúp nhà kiểm thử hệ thống đọc hiểu từ đó xây dựng nên kịch bản kiểm thử chi tiết nhất.
• Giúp cho việc bảo trì hệ thống và cải tiến những chức năng của hệ thống một cách nhanh chóng và dễ dàng.

Tài liệu SRS giúp đội phát triển xây dựng sản phẩm một cách chính xác

Thành phần chính của tài liệu đặc tả yêu cầu SRS

Phần giới thiệu – Introduction

Phần đầu tiên của tài liệu SRS chính là phần giới thiệu. Phần này bao gồm các nội dung:

• Purpose: mô tả chi tiết về mục đích và ý nghĩa của tài liệu đặc tả yêu cầu, giúp người đọc hiểu được khái niệm và tầm quan trọng của nó.
• Application Overview: mô tả hệ thống một cách tổng quan. Nhìn chung, hệ thống phải đảm bảo dduocj các yếu tố như khái quát hệ thống, tính năng, quyền sử dụng, mục đích của hệ thống sinh ra để làm gì,…
• Intended Audience and Reading Suggestions: mô tả các đối tượng sở hữu tài liệu SRS và mục đích sử dụng.
• Abbreviations: danh sách các từ viết tắt và ý nghĩa giúp người đọc nắm rõ hơn.
• References: mục đính kèm mô tả các tài liệu liên quan.

 

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

Những thông tin chi tiết trong phần này gồm có:

• Object Relationship Diagram: mô hình thể hiện mối quan hệ tĩnh giữa các đối tượng của hệ thống. Một đối tượng được xem là một thực thể trong hệ thống.
• Workflow Diagram: là phần đảm nhiệm hiển thị chuỗi công việc hoặc các bước người dùng thực hiện. Mỗi hành động của người dùng hệ thống sẽ được hiển thị ở từng giai đoạn của hệ thống.
• State Transition Diagram: mô tả trạng thái theo từng bước của workflow từ đó người đọc có thể biết được ai là người thực hiện điều đoa và nó có tác động như thế nào đến trạng thái của hệ thống.
• Use Case Diagram: sơ đồ thể hiện cách người dùng sử dụng các tính năng của hệ thống.

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

Nhiệm vụ của phần này là mô tả đầy đủ về nhiệm vụ của người dùng hệ thống, chức năng của người dùng, đồng thời chỉ ra các quyền của người dùng trong hệ thống. Bảng ma trận các nhiệm vụ với mỗi người sử dụng hệ thống sẽ được hiển thị trong phần này.

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

Tại phần đặc tả Use Case, các chức năng của hệ thống và mô tả chi tiết các nhiệm vụ sẽ phải thực hiện về hành vi và đầu vào, đầu ra. Cùng với đó, những tương tác của những tác nhân bên ngoài vào hệ thống và kết quả của việc tương tác đó sẽ được hiển thị ở phần này.

Đặc tả Use Case mô tả những nhiệm vụ sẽ phải thực hiện về hành vi đầu vào và đầu ra

Thiết kế màn hình (Wireframe)

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

Các yêu cầu khác (Other Requirement)

Phần này sẽ thể hiện chi tiết các yêu cầu bổ sung đối với hệ thống, phần này sẽ chuyển đến các yêu cầu phi hệ thống.

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

Bạn có thể đính kèm các tài liệu hoặc các nội dung liên quan đến các hệ thống bên ngoài vào phần này.

Phụ lục (Appendices)

Mục đích của phần này là cho phép người dùng định nghĩa được các lỗi tin nhắn trong hệ thống hoặc các email mẫu trong hệ thống.

Phân biệt các tài liệu SRS, BRD và FRS

Các BA – Business Analyst thường phải tạo ra 9 tài liệu quan trọng trong đó có 3 tài liệu dễ gây nhầm lẫn nhất là SRS, BRD và FRS. Vậy làm thế nào để phân biệt được 3 tài liệu này?

BRD là từ viết tắt của Business Requirement Document – tài liệu yêu cầu nghiệp vụ. Đây là tài liệu ghi lại các yêu cầu nghiệp và yêu cầu của các bên liên quan (ghi lại những mong muốn của doanh nghiệp hơn là yêu cầu). BRD là tài liệu đầu tiên trong quy trình phát triển của tổ chức, mô tả chiến lược của công ty mà họ đã nỗ lực đạt được trong tương lai.

Bên cạnh đó, BRD còn thể hiện mối quan tâm hay nhu cầu của các bên liên quan đến sản phẩm và dịch vụ cuối cùng. Nói một cách dễ hiểu, đây là tài liệu trả lời những câu hỏi tại sao có các yêu cầu trên, một kết quả mong đợi và sự thay đổi từ hệ thống. Đối tượng sử dụng BRD là các nhà tài trợ, quản lý cấp cao, quản lý cấp trung và BA.

Sự khác biệt giữa các tài liệu BRD, FRD và SRS là gì?

FRS (Functional Requirement Specifications) là tài liệu thể hiện thông số kỹ thuật yêu cầu của chức năng. Đây là loại tài liệu chi tiết nhất trong 3 loại tài liệu này, nó sẽ hệ thống dự kiến hoạt động như thế nào để thỏa mãn các yêu cầu được nêu trong các tài liệu BRD và SRS. FRS xây dựng mô tả chi tiết, rõ ràng từng yêu cầu chức năng trong từng trường, và sự tương tác của người dùng trên từng trang của hệ thống.

Không phân biệt được SRS và FRD giống như các thày bói xem voi, sẽ có những quan điểm và mong muốn khác nhau.

FRS được tạo từ quan điểm của người dùng và cách mà hệ thống sẽ tương tác với họ. Tài liệu FRS sau khi hoàn thành sẽ được đưa đến cho quản lý dự án xem xét, tiếp theo sẽ đưa cho khách hàng và được xác nhận lại lần cuối. Sau khi được xác nhận, tài liệu này sẽ là bản chuẩn về cách thức hoạt động của phần mềm.

Tổng kết

Trên đây là những kiến thức về tài liệu SRS, những thành phần chính tạo nên tài liệu và cách phân biệt SRS với các tài liệu BRD và FRS. Vậy qua bài viết bạn đã hiểu về tài liệu SRS là gì chưa? SRS, tài liệu đặc tả yêu cầu đóng vai trò cực kỳ quan trọng, nó giúp cho các đội phát triển hệ thống hiểu rõ hơn về những yêu cầu của khách hàng từ đó đưa ra được sản phẩm đáp ứng nhu cầu và mục đích sử dụng của khách hàng. Chính vì vậy, nếu bạn mong muốn trở thành một nhà phát triển hệ thống hay một kiểm thử viên thì đừng nên bỏ qua tài liệu này. Luôn theo dõi website để cập nhật những thông tin hữu ích nhé.

Tham khảo thêm: https://ajiethkumar.wordpress.com/2012/03/16/business-requirement-document-vs-functional-specification-document

Video hướng dẫn viết đặc tả dự án: