1. Giải đáp câu hỏi “Tài liệu SRS là gì?”
SRS (Software Requirement Specification) hay còn được gọi là Tài liệu đặc tả. SRS là một tài liệu được sử dụng với mục đích mô tả chỉ tiết các yêu cầu chức năng và phi chức năng của hệ thống. SRS sẽ đưa ra các tính năng của hệ thống dành cho bên thứ ba có liên quan để đọc hiểu chi tiết về hệ thống.
Đối với đội ngũ phát triển thì đây là một trong những tài liệu vô cùng quan trọng, SRS sẽ là các thông tin do đội phát triển cùng với các chuyên gia phân tích kinh doanh về dữ liệu môi trường và các chỉ số kinh doanh. Tài liệu đặc tả sẽ mô tả các chức năng và cấu trúc của hệ thống là FR và NFR, nó 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 để từ đó đáp ứng được mục đích, yêu cầu của người sử dụng.
Một tài liệu SRS chuẩn chỉnh xác định cách hệ thống phần mềm sẽ tương tác với tất cả các mô-đun bên trong, phần cứng, giao tiếp với các chương trình khác và tương tác của con người với nhiều tình huống thực tế. Tài liệu đặc tả yêu cầu phần mềm (SRS) được sử dụng trên QA lead, người quản lý tạo kế hoạch kiểm tra. Điều vô cùng quan trọng ở đây là người thử nghiệm phải được hiểu rõ mọi chi tiết được quy định trong tài liệu này, qua dó tránh lỗi trong các trường hợp thử nghiệm và kết quả mong đợi của nó.
Không chỉ vậy, việc áp dụng 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 công việc 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à thuận lợi hơn.
SRS đóng một vai trò rất quan trọng trong quá trình phát triển phần mềm của các công ty, nó có thể giúp cho các bên thứ ba (liên quan đến công ty) hiểu được hệ thống theo cùng một hướng, từ đó thống nhất được quy trình phát triển sản phẩm. Giúp cho phía đội ngũ phát triển xây dựng hệ thống một cách chuẩn xác, đặc tả được những tính năng và đúng hướng với yêu cầu của khách hàng. Không chỉ vậy, tài liệu đặc tả còn hỗ trợ nhà kiểm thử hệ thống đọc hiểu nhằm xây dựng nên kịch bản kiểm thử chi tiết nhất, giúp cho việc duy trì hệ thống và cải tiến chức năng của hệ thống một cách nhanh chóng và dễ dàng hơn.
2. Đặc điểm kỹ thuật của tài liệu SRS là gì?
Để hiểu rõ hơn về tài liệu SRS là gì, cũng như nắm bắt được cách vận hành tài liệu này sao cho tối ưu, các bạn luôn phải đảm bảo những đặc điểm kỹ thuật sau:
- Yêu cầu về tính nhất quán: SRS phải nhất quán trong chính nó và nhất quán với các tài liệu tham chiếu của nó. Nếu bạn gọi một thao tác, bước trong một quy trình là “Bắt đầu và Dừng” ở một nơi, đừng gọi nó là “Bắt đầu / Dừng lại” ở nơi khác. Điều này đặt ra tiêu chuẩn và cần được tuân thủ trong suốt giai đoạn thử nghiệm.
- Kết quả được xác minh rõ ràng: Đặc tả yêu cầu phần mềm SRS không nên được kết thú với các tuyên bố như “Hoạt động như mong đợi”. Thay vào đó, người thực hiện cần nêu rõ rằng những gì được mong đợi vì những người kiểm tra khác nhau sẽ có các khía cạnh suy nghĩ khác nhau và có thể rút ra các kết quả khác biệt từ tuyên bố này.
- Môi trường thử nghiệm: Một số ứng dụng cần các điều kiện cụ thể để thử nghiệm và cũng có một môi trường cụ thể để có kết quả chính xác. SRS phải có tài liệu rõ ràng về loại môi trường cần thiết để thiết lập.
- Điều kiện tiền đề được xác định rõ ràng: Một trong những phần quan trọng nhất của các trường hợp kiểm thử là tiền điều kiện. Nếu chúng không được đáp ứng đúng cách thì kết quả thực tế sẽ luôn khác với kết quả mong đợi. Xác minh rằng trong SRS, tất cả các điều kiện trước đều được đề cập rõ ràng.
- ID yêu cầu: Đây là cơ sở của mẫu trường hợp thử nghiệm. Dựa trên id yêu cầu, id trường hợp thử nghiệm sẽ được viết ra. Ngoài ra, id yêu cầu giúp dễ dàng phân loại mô-đun nên chỉ cần nhìn vào chúng, người kiểm tra sẽ biết mô-đun nào cần tham khảo. Đây là một thành tố bắt buộc phải tồn tại trong tài liệu SRS, chẳng hạn như id định nghĩa một mô-đun cụ thể.
- Tiêu chí về bảo mật và hiệu suất: Bảo mật được ưu tiên khi một phần mềm được kiểm tra, đặc biệt là khi nó được xây dựng theo cách mà nó chứa một số thông tin quan trọng khi bị rò rỉ có thể gây hại cho doanh nghiệp.Tester nên kiểm tra xem tất cả các yêu cầu liên quan đến bảo mật có được xác định đúng và rõ ràng đối với anh ta hay không.
Ngoài ra, khi chúng ta nói về hiệu suất của một phần mềm, nó đóng một vai trò rất quan trọng trong kinh doanh. Chính vì vậy, tất cả các yêu cầu liên quan đến hiệu suất phải được người thử nghiệm rõ ràng và đối tượng này cũng phải biết thời gian, cũng như mức độ tải, áp lực cần kiểm tra để theo dõi hiệu suất.
- Hạn chế yếu tố giả định: Đôi khi người thử nghiệm không đề ra yêu cầu rõ ràng mà lại có xu hướng đưa ra một số giả định liên quan đến tài liệu SRS. Đây không phải là cách đúng đắn để thực hiện thử nghiệm, vì dĩ nhiên các giả định có thể sai và từ đó, kết quả thử nghiệm có thể thay đổi. Tốt hơn là nên tránh các giả định và hỏi khách hàng về tất cả các “yêu cầu còn thiếu” để hiểu rõ hơn về kết quả mong đợi.
- Loại bỏ các yêu cầu dư thừa: Công việc phức tạp, nhiều quy trình, đòi hỏi phải có nhiều hơn một nhóm làm việc trên SRS. Chính vì thế nên có thể một số yêu cầu không liên quan, dư thừa có thể bị đưa vào SRS. Dựa trên sự hiểu biết về phần mềm, người kiểm thử có thể tìm ra những yêu cầu này và loại bỏ chúng để tránh nhầm lẫn và giảm tải công việc.
- Đóng băng yêu cầu: Khi một yêu cầu không rõ ràng hoặc không đầy đủ được gửi đến máy khách để phân tích và người kiểm tra nhận được phản hồi, kết quả yêu cầu đó sẽ được cập nhật trong phiên bản SRS tiếp theo và máy khách sẽ đóng băng yêu cầu đó. Đóng băng ở đây có nghĩa là kết quả sẽ không thay đổi lại cho đến khi và trừ khi một số bổ sung hoặc sửa đổi lớn được đưa vào phần mềm.
3. Một số điều cần lưu ý khi thực hiện công việc với tài liệu SRS là gì?
Hầu hết các khiếm khuyết mà chúng tôi tìm thấy trong quá trình thử nghiệm là do các yêu cầu không đầy đủ hoặc sự không rõ ràng trong SRS. Để tránh những khiếm khuyết như vậy, điều rất quan trọng là phải kiểm tra đặc tả yêu cầu phần mềm trước khi viết các trường hợp kiểm thử. Giữ phiên bản tài liệu SRS mới nhất với bạn để tham khảo và cập nhật cho mình những thay đổi mới nhất được thực hiện đối với tài liệu SRS.
Cách tốt nhất là xem qua tài liệu rất cẩn thận và ghi lại tất cả những nhầm lẫn, giả định và yêu cầu chưa hoàn thiện, sau đó có cuộc họp với khách hàng để làm rõ chúng trước khi giai đoạn phát triển bắt đầu vì việc sửa lỗi sau khi phần mềm được phát triển trở nên tốn kém. Sau khi tất cả các yêu cầu được xóa cho người thử nghiệm, người đó sẽ dễ dàng viết các trường hợp thử nghiệm hiệu quả và kết quả mong đợi chính xác.
Ngoài ra, đôi khi trong SRS, một số từ có nhiều hơn một nghĩa và điều này có thể khiến người kiểm tra nhầm lẫn và khó có được tham chiếu chính xác. Nên kiểm tra những từ mơ hồ như vậy và nói rõ nghĩa để hiểu rõ hơn. Khi người kiểm thử viết các trường hợp kiểm thử, điều đầu tiên cần phải rõ ràng là những gì được yêu cầu từ ứng dụng. Ví dụ: nếu ứng dụng cần gửi dữ liệu cụ thể có kích thước cụ thể nào đó thì nó phải được đề cập rõ ràng trong tài liệu SRS rằng có bao nhiêu dữ liệu và giới hạn kích thước để gửi là bao nhiêu.
4. Review tài liệu đặc tả và các bước review chi tiết và chuẩn nhất
Review tài liệu đặc tả là công việc từ những tài liệu đặc tả, người đọc có thể hiểu được mục đích và ứng dụng, hệ thống hoạt động và phát triển như thế nào.
Để có thể review tài liệu đặc tả SRS một cách rõ ràng và chi tiết nhất bạn có thể tham khảo qua 5 bước dưới đây như sau:
Bước 1: Hãy chắc chắn rằng bạn đã có được bản tài liệu tham khảo chuẩn, bởi vì trong quá trình làm việc bản tài liệu sẽ có nhiều sửa đổi và các thông số cũng được chỉnh sửa. Chính vì thế, việc có một bản tài liệu tham khảo chuẩn sẽ giúp bạn có bản review tài liệu đặc tả chính xác nhất.
Bước 2: Thực hiện việc xây dựng hướng dẫn cụ thể về những mục tiêu của review. Và xây dựng kịch bản kiểm thử chi tiết.
Bước 3: Xây dựng các hướng dẫn của bản mẫu
Bước 4: Mỗi thành viên trong nhóm sẽ có được phân chia nhiệm vụ khác nhau. Từ đây sẽ phát huy được những thế mạnh của từng thành viên và nhanh chóng hoàn thành các đầu công việc có liên quan.
Bước 5: Review tài liệu đặc tả yêu cầu cũng giúp ích trong việc hiểu biết tốt hơn nếu có bất kỳ điều kiện tiên quyết cụ thể cần thiết nào cho việc kiểm tra phần mềm.
Bước 6: Các danh sách truy vấn khó hiểu hoặc có nhiều thông tin cần thiết cần phải được đưa vào chức năng yêu cầu hoặc nếu có lỗi phát sinh trong quá trình làm tài liệu đặc tả đã được định nghĩa trước đó.
Mong rằng nội dung kiến thức mà topcvai.com truyền tải trong bài viết sẽ giúp các bạn giải đáp được câu hỏi “Tài liệu SRS là gì?”, cũng như áp dụng loại tài liệu này một cách thật hiệu quả trong công việc nhé!
Tham gia bình luận ngay!