Lĩnh vực phát triển phần mềm đòi hỏi nhiều yếu tố quan trọng cần được xem xét và thử nghiệm để đạt được hiệu quả tối ưu nhất, trong đó, thuật ngữ yêu cầu và tiêu chí chấp nhận là những nội dung quan trọng. Hiểu về hai nội dung này là cơ sở để các doanh nghiệp khắc phục những hạn chế.
Mục lục bài viết
1. Yêu cầu là gì?
Yêu cầu chỉ đơn giản là chức năng, dịch vụ hoặc tính năng mà người dùng cần. Chúng cũng có thể là các ràng buộc, thủ tục, quy tắc kinh doanh hoặc chức năng khác mà một công ty cần để đáp ứng các yêu cầu của người dùng dự kiến.
Các loại yêu cầu:
– Yêu cầu về chức năng: Yêu cầu chức năng nêu những gì cần thiết và làm nổi bật một chức năng hoặc một tính năng. Nó không giải thích làm thế nào một công ty có thể đạt được một giải pháp vật lý.
– Yêu cầu phi chức năng Các yêu cầu phi chức năng mô tả mức độ tốt hoặc mức độ của giải pháp cần được thực hiện. Chúng xác định các thuộc tính của giải pháp như độ tin cậy, bảo mật, tính sẵn sàng, khả năng bảo trì, thời gian phản hồi và hiệu suất. Thời gian phản hồi có thể là: Có sẵn 24 giờ mỗi ngày mỗi ngày hoặc trả lời trong vòng 5 giây.
Các yêu cầu phi chức năng có thể cung cấp toàn bộ giải pháp hoặc ảnh hưởng đến một nhóm các nhu cầu chức năng. Tất cả các khách hàng đang sử dụng chức năng phải có biểu tượng của công ty hoặc tất cả các khách hàng có chức năng phải trả lời yêu cầu trong vòng 5 giây.
Ví dụ về yêu cầu: Ở cấp độ dự án, giám đốc tiếp thị cần cải thiện dịch vụ khách hàng để giữ chân khách hàng của họ. Các dịch vụ mà anh ấy nên cải thiện bao gồm điện thoại, email, trò chuyện trực tiếp và các dịch vụ khách hàng tại chỗ. Các dịch vụ nâng cao sẽ khiến khách hàng phấn khích và đảm bảo họ trung thành với công ty.
2. Phân tích tiêu chí chấp nhận:
Trước khi đi vào nêu rõ sự khác biệt về yêu cầu và tiêu chí chấp nhận, tác giả sẽ có sự phân tích về cơ bản về tiêu chí chấp nhận như sau:
Tiêu chí chấp nhận (AC) là các điều kiện mà sản phẩm phần mềm phải đáp ứng để được người dùng, khách hàng hoặc các hệ thống khác chấp nhận. Chúng là duy nhất cho mỗi câu chuyện của người dùng và xác định hành vi của tính năng từ quan điểm của người dùng cuối.
Các tiêu chí chấp nhận được viết thành văn bản giúp tránh các kết quả không mong muốn ở cuối giai đoạn phát triển và đảm bảo rằng tất cả các bên liên quan và người dùng đều hài lòng với những gì họ nhận được.
Một khía cạnh quan trọng liên quan đến tiêu chí chấp nhận là chúng phải được xác định trước khi nhóm phát triển bắt đầu làm việc trên một câu chuyện người dùng cụ thể. Nếu không, rất có thể các sản phẩm được phân phối sẽ không đáp ứng được nhu cầu và mong đợi của khách hàng.
Các loại tiêu chí chấp nhận
– Tiêu chí chấp nhận theo hướng kịch bản
Các tiêu chí chấp nhận theo định hướng kịch bản ở dạng kịch bản và nêu bật mọi tiêu chí. Nó có chuỗi Given / When / Then (GWT). Nó chủ yếu được viết như sau:
+ Đưa ra một số điều kiện tiên quyết
+ Khi tôi thực hiện một số hành động
+ Sau đó, tôi dự đoán một số kết quả
Phương pháp tiếp cận được áp dụng từ sự phát triển theo hướng hành vi (BDD) và đưa ra các cấu trúc đáng tin cậy mà người thử nghiệm sử dụng để ước tính thời điểm bắt đầu và kết thúc thử nghiệm một tính năng cụ thể. Nó mô tả hành vi của hệ thống từ trước, do đó giúp giảm thời gian nhóm dành cho việc viết các trường hợp thử nghiệm.
Định dạng tiêu chí chấp nhận theo định hướng kịch bản làm nổi bật các tuyên bố sau:
+ Kịch bản – tên của hành vi mà một nhóm phải mô tả.
+ Cho trước – trạng thái ban đầu của kịch bản.
+ Khi nào – hành động cụ thể của người dùng.
+ Sau đó – kết quả của hành động.
+ Và – phần tiếp theo của bất kỳ câu nào trong ba câu trước.
Ví dụ: Câu chuyện người dùng
Người dùng cần khôi phục mật khẩu vào tài khoản của mình để truy cập khi quên mật khẩu.
Tình huống: Quên mật khẩu
Đã cho: Người dùng truy cập trang đăng nhập
Khi nào: Chọn quên mật khẩu
Và: Nhập một email hợp lệ có liên kết để khôi phục mật khẩu
Sau đó: Hệ thống tự động gửi link vào email
Đã cho: Người dùng nhận được liên kết qua email
Khi nào: Người dùng thao tác qua liên kết đã nhận
Sau đó: Hệ thống cho phép người dùng đặt mật khẩu mới
-Tiêu chí chấp nhận theo hướng quy tắc
Một số tình huống không triển khai cấu trúc GWT và chúng bao gồm:
+ Làm việc trên các câu chuyện của người dùng cung cấp thông tin chi tiết về chức năng cấp hệ thống và yêu cầu các phương pháp đảm bảo chất lượng khác.
+ Đối tượng mục tiêu cho các tiêu chí chấp nhận không quan tâm đến các chi tiết cụ thể của các kịch bản thử nghiệm.
+ GWT không thích hợp để mô tả các ràng buộc về trải nghiệm người dùng và thiết kế của một tính năng
AC hướng quy tắc đề cập đến một số quy tắc mô tả tốt nhất hành vi của một hệ thống. Từ ba quy tắc, một công ty có thể soạn thảo các kịch bản cụ thể. Định dạng tiêu chí chấp nhận theo hướng quy tắc chỉ có thể giải quyết những trường hợp này.
3. Mục đích chính của tiêu chí chấp nhận:
Làm cho phạm vi đối tượng địa lý chi tiết hơn.AC xác định ranh giới của câu chuyện người dùng. Chúng cung cấp thông tin chi tiết chính xác về chức năng giúp nhóm hiểu được liệu câu chuyện có được hoàn thành và hoạt động như mong đợi hay không.
Mô tả các kịch bản tiêu cực.AC của bạn có thể yêu cầu hệ thống nhận dạng các đầu vào mật khẩu không an toàn và ngăn người dùng tiếp tục. Định dạng mật khẩu không hợp lệ là một ví dụ về cái gọi là tình huống tiêu cực khi người dùng thực hiện các đầu vào không hợp lệ hoặc hoạt động không mong muốn. AC xác định các tình huống này và giải thích cách hệ thống phải phản ứng với chúng.
Thiết lập giao tiếp. Tiêu chí chấp nhận đồng bộ hóa tầm nhìn của khách hàng và nhóm phát triển. Chúng đảm bảo rằng mọi người đều có hiểu biết chung về các yêu cầu: Các nhà phát triển biết chính xác loại hành vi mà tính năng phải thể hiện, trong khi các bên liên quan và khách hàng hiểu những gì được mong đợi từ tính năng.
Hợp lý hóa thử nghiệm chấp nhận. AC là cơ sở của thử nghiệm chấp nhận câu chuyện của người dùng . Mỗi tiêu chí chấp nhận phải có thể kiểm tra độc lập và do đó có các kịch bản đạt hoặc không đạt rõ ràng. Chúng cũng có thể được sử dụng để xác minh câu chuyện thông qua các bài kiểm tra tự động .
Tiến hành đánh giá tính năng.Các tiêu chí chấp nhận chỉ rõ những gì chính xác phải được phát triển bởi nhóm. Sau khi nhóm có các yêu cầu chính xác, họ có thể chia các câu chuyện của người dùng thành các nhiệm vụ có thể ước tính chính xác.
Vì những người khác nhau có thể có những quan điểm và ý tưởng giải pháp khác nhau liên quan đến một vấn đề, nên việc tạo ra một tầm nhìn thống nhất về cách thực hiện chức năng là cần thiết. Đó chính xác là những gì các tiêu chí chấp nhận bằng văn bản rõ ràng làm.
