Làm thế nào để kiểm tra tài liệu đặc tả yêu cầu của phần mềm (SRS)?

Bài viết được tham khảo từ nguồn:

http://www.softwaretestinghelp.com/how-to-test-software-requirements-specification-srs/

Bài trước tôi đã nêu ra định nghĩa về tài liệu đặc tả yêu cầu, tôi nhắc lại để các bạn tiện theo dõi.

Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực hiện của đội phát triển phần mềm. Tài liệu đặc tả yêu cầu nên bao gồm tất cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu của hệ thống. Tài liệu đặc tả yêu cầu không phải là tài liệu thiết kế hệ thống. Nó chỉ thiết lập những gì hệ thống phải làm chứ không phải việc mô tả rõ nó sẽ làm việc như thế nào?

Như chúng ta biết “Hầu hết bugs trong phần mềm là do yêu cầu chức năng không đầy đủ hoặc không chính xác”. Mã phần mềm, việc nó được viết thế nào không phải là vấn đề quan trọng, chúng ta sẽ không thể làm bất cứ điều gì nếu có những sự mơ hồ trong các yêu cầu.

Những sự mơ hồ về requirement và sửa chữa chúng trong thời gian sớm của vòng đời phát triển phần mềm là tốt nhất. Chi phí của việc sửa chữa lỗi sau khi phần mềm đã hoàn thành hoặc là đã release là khá cao. Vì vậy, điều quan trọng là có những phân tích yêu cầu và nắm bắt những yêu cầu không chính xác trước khi thiết kế và giai đoạn thực hiện dự án của vòng đời phát triển của phần mềm.

Làm thế nào để chắc chắn về sự hiểu đúng đắn của chúng ta về tài liệu đặc tả yêu cầu?

Đúng vậy, chúng ta cần phải định nghĩa một vài tiêu chuẩn test và đảm bảo chắc chắn về sự hiểu đúng đắn của chúng ta về yêu cầu của phần mềm. Mỗi một yêu cầu được đánh giá là hoàn thiện thông qua việc kiểm tra chúng mà bạn có thể đánh giá và đóng băng các yêu cầu chức năng.

Chúng ta hãy cùng theo dõi một ví dụ để hiểu rõ hơn về vấn đề này:

Bạn đang làm việc dựa trên nền tảng ứng dụng Web. Yêu cầu như sau:

“Ứng dụng Web sẽ có thể phục vụ cho các truy vấn người sử dụng càng sớm càng tốt”.

Làm thế nào bạn sẽ đóng băng yêu cầu trong trường hợp này?

Điều gì sẽ là tiêu chí đánh giá sự hài lòng yêu cầu của bạn? Để có được câu trả lời, bạn nên đặt câu hỏi tới các bên liên quan: Bao nhiều thời gian đáp ứng là đủ cho bạn?

Nếu họ nói rằng, chúng tôi chấp các phản ứng nếu nó trong vòng 2 giây, thì đây là biện pháp yêu cầu của bạn.

Ngừng phát triển các yêu cầu này và thực hiện các thủ tục tương tự cho các yêu cầu tiếp theo.

Chúng ta nên làm thế nào để đo lường các yêu cầu và ngừng phát triển chúng trong thiết kế, thực hiện và kiểm tra các giai đoạn.

Bây giờ chúng ta hãy lấy một ví dụ khác. Tôi đã được làm việc trên một dự án dựa trên web. Khách hàng (bên liên quan) quy định các yêu cầu dự án cho giai đoạn đầu của sự phát triển của dự án. Quản lý của tôi lưu hành tất cả các yêu cầu trong các nhóm cho việc review. Khi chúng tôi bắt đầu thảo luận về các yêu cầu này, chúng tôi bị sốc! Mọi người đều có quan niệm riêng của mình về các yêu cầu. Chúng tôi tìm thấy rất nhiều sự mơ hồ về quy định tại các văn bản yêu cầu, mà sau này được gửi cho khách hàng để xem xét / làm rõ.

Khách hàng sử dụng nhiều thuật ngữ mơ hồ, mà đã có rất nhiều ý nghĩa khác nhau, làm cho nó khó khăn để phân tích ý nghĩa chính xác. Phiên bản tiếp theo của các yêu cầu từ khách hàng rõ ràng, đủ để đóng băng trong giai đoạn thiết kế.

Từ ví dụ này, chúng ta học được "Yêu cầu phải rõ ràng và phù hợp"

Tiêu chí tiếp theo để thử nghiệm các đặc tả yêu cầu là "Khám phá những thiếu xót trong yêu cầu".

Nhiều nhà thiết kế dự án không có ý tưởng rõ ràng về các module cụ thể và họ chỉ nghĩ đơn giản là thừa nhận một số yêu cầu trong giai đoạn thiết kế. Bất kỳ yêu cầu nào đều không nên được dựa trên các giả định. Yêu cầu phải được hoàn thành, bao phủ mỗi phần và toàn bộ các khía cạnh của hệ thống được phát triển.

Thông số kỹ thuật cần nêu cả hai loại: Những gì hệ thống nên làm và những gì không nên?

Nói chung tôi sử dụng phương pháp riêng của mình để phát hiện ra các yêu cầu không xác định. Khi tôi đọc các tài liệu yêu cầu phần mềm đặc điểm kỹ thuật (SRS), tôi ghi lại sự hiểu biết của tôi về các yêu cầu được quy định, cộng với các yêu cầu tài liệu SRS khác cần phải bao phủ. Điều này giúp cho tôi để hỏi những câu hỏi về các yêu cầu không xác định làm cho nó rõ ràng hơn.

Để kiểm tra các yêu cầu tiến tới sự hoàn chỉnh, yêu cầu phân chia thành ba phần:

• Yêu cầu 'Phải thực hiện'

• Những yêu cầu không quy định nhưng cần đưa ra các giả định để xác minh.

• Loại thứ ba là 'tưởng tượng' loại yêu cầu.

=> Kiểm tra xem tất cả các loại yêu cầu được giải quyết trước giai đoạn thiết kế phần mềm.

Đôi khi các bên liên quan có chuyên môn riêng của họ, những điều mà họ mong đợi trong hệ thống được phát triển. Họ không nghĩ rằng nếu yêu cầu đó là có liên quan đến dự án trong tay. Hãy chắc chắn để xác định các yêu cầu như vậy. Cố gắng tránh các yêu cầu không thích hợp trong giai đoạn đầu của chu kỳ phát triển dự án. Nếu không thể hỏi những câu hỏi đến các bên liên quan: lý do tại sao bạn muốn thực hiện các yêu cầu cụ thể này? Điều này sẽ mô tả các yêu cầu cụ thể chi tiết làm cho nó dễ dàng hơn cho việc thiết kế các hệ thống xem xét phạm vi trong tương lai.

Nhưng làm thế nào để quyết định các yêu cầu có liên quan hay không?

Câu trả lời đơn giản: Đặt mục tiêu dự án và đưa ra những câu hỏi cho những vấn đề liên quan: Nếu không thực hiện yêu cầu này sẽ gây ra bất kỳ vấn đề nào trong việc đạt được mục tiêu quy định? Nếu không, thì đây là yêu cầu không liên quan. Đặt câu hỏi tới các bên liên quan nếu họ thực sự muốn thực hiện các loại yêu cầu.

Trong đặc tả yêu cầu ngắn (SRS) nên giải quyết như sau:

• Chức năng của dự án (Điều gì nên làm và những gì không nên).

• Phần mềm, giao diện phần cứng và giao diện người dùng.

• Tính đúng đắn của hệ thống, an ninh và tiêu chí thực hiện.

• Vấn đề thực hiện (rủi ro) nếu có.

KẾT LUẬN:

Nội dung bên trên đã bao gồm tất cả các khía cạnh của phép đo yêu cầu. Để cụ thể về yêu cầu, tôi sẽ tổng kiểm tra yêu cầu trong một câu:

"Yêu cầu phải rõ ràng và cụ thể với sự không chắc chắn, các yêu cầu cần phải đo lường được về mặt giá trị cụ thể, yêu cầu phải được kiểm chứng có một số tiêu chí đánh giá cho từng yêu cầu, và các yêu cầu cần được hoàn chỉnh, không có bất kỳ mâu thuẫn"

Thử nghiệm nên bắt đầu từ giai đoạn yêu cầu để tránh tiếp tục yêu cầu liên quan đến lỗi. Giao tiếp nhiều hơn và nhiều hơn nữa với các bên liên quan của bạn để làm rõ tất cả các yêu cầu trước khi bắt đầu thiết kế và thực hiện dự án.