SRS là gì? Sử dụng thành thạo Srs để giúp ích cho công việc kiểm thử

Chi tiết bài viết

Ở thời đại công nghệ số như hiện nay, với sự xuất hiện của hàng trăm nghìn công ty lập trình. Để tạo ra sự khác biệt trong ngành IT, chỉ có tiến độ và chất lượng phần mềm theo đúng yêu cầu của khách hàng mới giúp các công ty phát triển. Để tạo ra những phần mềm chất lượng việc thực hiện tài liệu đặc tả SRS để mô tả những yêu cầu về sản phẩm mà đội phát triển đang cần theo mong muốn của khách hàng. Chính vì lẽ đó nên tài liệu đặc tả vô cũng quan trọng trong quá trình phát triển phần mềm. Vậy tài liệu srs là gì? Hãy cùng Daotaotester tìm hiểu qua bài viết dưới đây.

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

Tài liệu SRS là gì? Đó là cụm từ viết tắt của cụm từ Software Requirement Specification là một dạng tài liệu đặc tả yêu cầu phần mềm. Cụ thể hơn so với dạng tài liệu đặc tả yêu cầu nói chung. SRS sẽ mô tả chi tiết các yêu cầu về chức năng và phi chức năng của cả hệ thống. Việc mô tả chi tiết các chức năng giúp cho người thực hiện code dễ dàng thực hiện chức năng hệ thống phần mềm và các thành phần bên trong nó.

Dạng tài liệu này đặc biệt có ích đối với các system analyst, business analyst, code cũng như kể cả với fresher test. Với nội dung chính là mô tả function và non-function (cấu trúc của hệ thống) hay còn gọi là tài liệu FR và NFR. Chính vì thế các tài liệu SRS đóng vai trò là cầu nối giao tiếp giữa các end user với developer giúp đảm bảo phần mềm khi được hoàn thiện có được những chức năng đúng theo yêu cầu của các end user, rút ngắn thời gian cũng như chi phí tiêu tốn cho quá trình phát triển.

Lợi ích khi thực hiện viết tài liệu SRS

Sau khi đã hiểu rõ về khái niệm SRS là gì? Chúng ta cùng tìm hiểu về những lợi ích mà lọai tài liệu đặc tả yêu cầu này mang đến cũng như việc tại sao phải bắt buộc thực hiện SRS trước khi phát triển phần mềm:

• Khi thực hiện 1 dự án IT, không chỉ có sự tồn tại của của khách hàng và nhà phát triển. Các bên thứ 3 như khách hàng của khách hàng, software analyst… đề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 loại bỏ và ngăn ngừa các lỗi ở giai đoạn thiết kế Khi tài liệu SRS được viết tốt thì sẽ tối ưu hóa quá trình phát triển khi ngăn chặn sự trùng lặp các nhiệm vụ dễ dàng.
• Giữ cho lộ trình phát triển của dự án đi đúng không không bị lệch ra khỏi quỹ đạo
• Việc bảo trì hệ thống và cải tiến các chức năng của hệ thống một cách nhanh chóng và dễ dàng.

Có thể bạn quan tâm : Blockchain là gì? Tất cả những gì cần biết về blockchain

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

Mở đầu của tài liệu SRS là gì?. Phần này bao gồm các nội dung:

• Purpose: Là mô tả chi tiết về mục đích triển khai, ý nghĩa của tài liệu, giúp người đọc có thể hiểu được những khái niệm cũng như tầm quan trọng của tài liệu
• Application Overview: Cung cấp cái nhìn tổng quát về cấu trúc của hệ thống như là tính năng, bố cục, các quyền sở hữu, các mục đích  của hệ thống được sinh ra để làm gì?
• Intended Audience and Reading Suggestions: Giúp mô tả các đối tượng sở hữu SRS cũng như các mục đích sử dụng
• Abbreviations: Danh sách các từ viết tắt giúp người sử dụng hiểu được ý nghĩa 
• References: Các mục đích và trích dẫn kèm theo các mô tả tài liệu liên quan

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

High level Requirement bao gồm những yêu cầu như sau:

• Mô tả trạng thái mối quan hệ giữa các đối tượng bên trong hệ thống
• Workflow Diagram: Giúp đảm nhiệm hiển thị các chuỗi công việc hay các bước người dùng thực hiện. Mỗi hành động của người dùng giúp hiển thị được từng giai đoạn của một hệ thống
• State Transition Diagram: Đây là một trạng thái từng bước giúp người đọc có thể biết ai là người đang thực hiện điều đó và nó tác động như thế nào đến trạng thái của hệ thống
• Use Case Diagram: Đây là sơ đồ thể hiện người dùng có thể thực hiện những chức năng nào của hệ thống.

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

Chức năng của Security Requirement giúp mô tả cho người xem đầy đủ nhiệm vụ của hệ thống, các chức năng có thể thực hiện cũng như quyền hạn của người truy cập. 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)

Mô tả chức năng của hệ thống để có thể hiểu được chi tiết những dữ liệu ở đầu vào, cũng như dự đoán hành vi sẽ nhận được ở đầ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.

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

Ở phần này người soạn thảo sẽ đính kèm tài liệu đặc tả yêu cầu giúp người đọc có thể di chuyển được đến màn hình của hệ thống. Nhiều chức năng của thiết kế màn hình yêu cầu chức năng hệ thống đối với mỗi khách hàng một cách nhanh chóng và dễ dàng. Để có thể hiểu được và có cái nhìn chính xác hơn về hệ thống cũng như việc thấu hiểu hơn các yêu cầu của khách hàng. Các nhà phân tích nghiệp vụ và thể hiện được năng lực trong nhóm phát triển. 

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

Ngoài các yêu cầu kể trên, những yêu cầu khác về tài liệu srs là gì?

• Nhanh chóng làm rõ các yêu cầu của khách hàng
• Mô tả 1 cách dễ hiểu nhưng cũng phải chi tiết về cấu trúc và chức năng của phần mềm cho khách hàng
• Thể hiện được những yêu cầu của BA và những yêu cầu mong đợi của khách hàng 
• Giúp chứng minh được năng lực của team dự án 
• Dễ tiếp cận, nắm bắt cũng như hiểu nhanh hơn về hệ thống

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

Nơi đính kèm tệp tài liệu, nội dung liên quan từ bên ngoài hệ thống

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

Trong quy trình làm việc của 1 BA analyst thông thường để thực hiện đặc tả yêu cầu phần mềm thì có đến 9 loại tài liệu. Trong số đó 3 loại tài liệu phổ biến nhất là SRS, BRD và FRS. Vậy sự khác nhau giữa BRD và FRS so với SRS là gì? BRD là Business Requirement Document – tài liệu yêu cầu nghiệp vụ. Loại tài liệu này 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).

Nếu như SRS tập trung mô tả các yêu cầu về function và non function thì BRD 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.

FRS (Functional Requirement Specifications) là tài liệu thể hiện chức năng phần mềm qua thông số kỹ thuật yêu cầu. Đâ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 chi tiết hóa 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. 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.

Trên đây là những nội dung chia sẻ của Daotatester.vn về những tài liệu SRS. Mong rằng các bạn có được cái nhìn tổng quát nhất về SRS là gì? Đồng thời được vai trò và các thành phần bên trong 1 tài liệu SRS. Chúng tôi cũng đã so sánh tài liệu SRS với 2 dạng tài liệu đặc tả yêu cầu phần mềm khác là BRD và FRS để bạn có thể áp dụng trong công việc cũng như là áp dụng vào quy trình kiểm thử phần mềm của mình. Bên cạnh đó nếu bạn muốn tìm hiểu rõ hơn về lĩnh vực kiểm thử thì cũng có thể tham gia vào các khóa học kiểm thử phần mềm của chúng tôi để có những cái nhìn chi tiết nhất nhé.