Làm thế nào để đọc hiểu tài liệu đặc tả yêu cầu và tổng hợp Q&A một cách hiệu quả?

Trong Vòng đời phát triển phần mềm (SDLC) , bước đầu tiên là tổng hợp yêu cầu cẩn thận với việc đọc Tài liệu đặc tả yêu cầu phần mềm (SRS- Software Requirements Specification) , hiểu yêu cầu, đưa ra các thắc mắc về các yêu cầu không đầy đủ hoặc không rõ ràng. Mục đích chính của giai đoạn này là để hiểu và làm rõ các yêu cầu khác sâu xa hơn chưa được đề cập trong tài liệu.

SRS- Software Requirements Specification

SRS là một tài liệu được tạo bởi nhóm phát triển phối hợp với các nhà phân tích kinh doanh và nhóm phân tích môi trường / dữ liệu. Thông thường, tài liệu này sau khi hoàn thành sẽ được chia sẻ với nhóm QA thông qua một cuộc họp đế chia sẻ, trao đổi và phân tích chi tiết. Đôi khi, đối với một ứng dụng đã có sẵn, chúng ta có thể không cần một cuộc họp chính thức và có một ai đó hiểu nhất về dự án sẽ hướng dẫn và giải thích giúp chúng ta thông qua tài liệu này. Qua tài liệu SRS chúng ta cũng có thông tin chính thống cần thiết để có thể tự tìm hiểu và phân tích yêu cầu của dự án.

Nếu nhóm phát triển bắt đầu thực hiện triển khai dự án mà không giải quyết các yêu cầu còn thiếu hoặc không rõ ràng thì điều này sẽ gây ra các lỗi không đáng có trong ứng dụng phần mềm.

Sẽ luôn luôn tốt hơn nếu nắm bát và giải quyết sớm sự mơ hồ trong tài liệu SRS. Chi phí sửa chữa các khiếm khuyết trong giai đoạn đầu sẽ thấp hơn so với sửa chữa các khiếm khuyết trong các giai đoạn sau. Điều quan trọng nhất là xác định sự mơ hồ trong yêu cầu trước khi các thông số thiết kế kỹ thuật và các giai đoạn về sau khi thực hiện dự án của SDLC, do đó giai đoạn đầu tiên này còn được gọi là bước "Ngăn ngừa Khiếm khuyết".

Trong bài viết này, chúng ta sẽ thảo luận về các hướng dẫn chi tiết về danh sách kiểm tra và danh sách kiểm tra tài liệu đặc tả yêu cầu:
Checklist to review software requirements specification

• Đảm bảo rằng tất cả các nhóm đều đang tham gia vào review tài liệu đặc tả yêu cầu phần mềm, đọc tài liệu đặc tả kỹ lưỡng và thảo luận từng điểm với các thành viên khác trong nhóm của bạn.
  
  Ví dụ phân chia 2 member cùng tìm hiểu spec của chức năng Signup/ Signin. Sau khi tìm hiểu có thể trao đổi với nhau xem có hiểu giống nhau không hoặc có thể chia sẻ những điểm khác biệt của chức năng Signup/ Signin trong ứng dụng này với các thành viên khác trong team.
  Teamwork

• Phần chính của SRS sẽ trình bày về chức năng và phần này sẽ cho chúng ta biết về phần mềm: "Phần mềm phải làm gì?" Sẽ là hữu ích hơn nếu SRS còn trình bày cả về "Những gì mà phần mềm không yêu cầu làm?". Vì vậy, hãy đảm bảo rằng team của bạn có thể hiểu bao quát chính xác được tất cả các chức năng của phần mềm.
  
  Thông thường, tùy và dự án và khách hàng mà đội dự án có thể tự thống nhất và đưa ra phương án xử lý hợp lý nhất cho sản phẩm. Tuy nhiên có những phần mềm đặc thù mà yêu cầu của khách hàng cũng không bình thường như các ứng dụng khác. Vì vậy chúng ta cần làm rõ yêu cầu của khách hàng.
  
  Ví dụ: chức năng Signup thông thường sẽ lưu thông tin đăng nhập email là duy nhất trong DB, tuy nhiên có ứng dụng lại không yêu cầu vậy. User có thể đăng ký bằng SNS với email A thành công, sau đó cũng có thể đăng ký bằng user ID với email A. Nghĩa là sẽ có 2 tài khoản cùng email A nhưng login service khác nhau thì vẫn hợp lệ.

• Xem xét tài liệu đặc tả yêu cầu một cách cẩn thận : nếu bạn quan sát các thuật ngữ được sử dụng trong thông số kỹ thuật dẫn đến sự mơ hồ thì hãy hỏi các bên liên quan để làm rõ. Bạn có thể kiểm tra các thuật ngữ mơ hồ, chung chung được sử dụng trong SRS như: usually, sometimes, some, mostly, most, may be, v.v.

• Kiểm tra các điều khoản được sử dụng như một danh sách nhưng không được đề cập rõ ràng hoặc không đề cập đầy đủ như danh sách đưa ra, v.v., Ví dụ trong spec của 1 màn hình có liệt kê 20 item, đánh số từ 1 đến 20 nhưng ở trang mô tả chi tiết thì lại thiếu mô tả cho item 15.

• Kiểm tra xem tất cả các thuộc tính được xem xét trong SRS như tính chính xác, bảo mật, khả năng bảo trì, v.v.

• Đừng giả sử bất kỳ yêu cầu nào: nếu bất kỳ yêu cầu nào không rõ ràng thì bạn nên đưa ra các truy vấn. Đôi khi tùy vào mục đích của sản phẩm mà khách hàng sẽ có những spec khác so với suy nghĩ thông thường của mình.
  
  Ví dụ: nếu một trường đầu vào chấp nhận số tiền lớn hơn 10 và nhỏ hơn 100. Vì vậy, ở đây bạn có thể hỏi về việc liệu có hỗ trợ các dấu thập phân cho trường này không, nếu có thì là làm tròn đến số thập phân thứ mấy.
  
  Đội dự án & Khách hàng

• Nếu yêu cầu được giải thích với đoạn văn lớn thì hãy ngắt nhỏ đoạn văn trong câu nhỏ và đưa ra một hình ảnh hoặc biểu đồ tổng hợp để dễ hình dung và hiểu rõ hơn về kịch bản.
  
  Ví dụ với quy trình mua 1 sản phẩm cần phải qua các trạng thái bắt buộc từ Đã xác nhận mua hàng -> Chờ lấy hàng -> Đang vận chuyển -> Đã nhận hàng -> Đánh giá sản phẩm. Nhìn vào đây chúng ta có thể hiểu cơ bản luồng hoạt động chính của một chức năng.

• Nếu có bất kỳ thông số kỹ thuật không rõ ràng, hãy đảm bảo rằng tất cả các truy vấn sẽ được làm rõ từ Project Manager càng sớm càng tốt.
  Q&A

• Nếu có bất kỳ phép tính nào liên quan để có được các giá trị cụ thể, thì hãy đảm bảo rằng bạn xem lại phép tính với các bộ dữ liệu đầu vào khác nhau (nghĩ đến việc chuyển các điều kiện giá trị biên.)
  Ví dụ bạn cần kiểm tra có đúng tài khoản này đã quá gia hạn thanh toán trong 1 tháng, nếu quá hạn sẽ không sử dụng được một số chức năng nào đó. Vậy, bạn cần chỉnh sửa dữ liệu test như:
  

Ngày hiện tại = 20/7
Ngày thanh toán cuối cùng 19/6
Như vậy đã quá hạn, và tài khoản sẽ hạn chế 1 số chức năng.

• Kiểm tra yêu cầu tham số hiệu suất ( Performance parameters) được xem xét trong tài liệu SRS, nếu có thì bạn có thể yêu cầu các thôn tin về thời gian, tính sẵn sàng, tốc độ, thời gian phục hồi, v.v. Ngoài ra có một số tham số khác như token

• Nếu bản chất mô-đun lớn và phức tạp hơn một chút thì hãy chia mô-đun thành các tính năng của nó và kiểm tra các kịch bản thử nghiệm xung quanh tính năng. Bạn cũng có thể chia nhỏ test scenarios thành các test cases nếu test scenarios vẫn còn phức tạp quá.

• Đảm bảo rằng tất cả các câu hỏi / truy vấn / vấn đề đang chờ xử lý phải được theo dõi thường xuyên. Luôn chắc chắn và đảm bảo rằng câu hỏi đó trả lời từ người quản lý sản phẩm ví dụ nhưu khách hàng, PM, BrSE.

• Khi nhận được xác nhận từ họ, sau đó đảm bảo rằng lịch sử sửa đổi được duy trì.

• Khi tất cả các câu hỏi đã được trả lời thỏa đáng và tài liệu đặc tả yêu cầu được cập nhật và bây giờ nếu có bất kỳ yêu cầu thay đổi nào được đưa ra thì bạn nên đưa ra các truy vấn về các khu vực bị ảnh hưởng. Như ví dụ trên:

Nếu quá hạn thanh toán, tài khoản sẽ không sử dụng được một số chức năng nào đó.

Think outside the box

Vậy các chức năng đó là gì, hãy làm rõ thêm về vấn đề này với người quản lý sản phẩm nha. Tuy nhiên, tùy vào từng khách hàng hay dự án, chúng ta cũng cần thống nhất cách trao đổi sao cho hiệu quả nhất. Có dự án Q&A nhiều khách hàng đánh giá cao vì chúng ta phát hiện ra nhiều vấn đề mà họ chưa nghĩ đến. Nhưng cũng có dự án chúng ta hỏi quá lắt nhắt hoặc bị lặp câu hỏi thì khách hàng sẽ đánh giá mình đọc hiểu tài liệu đại khái. Vì vậy nên tổng hợp những vùng ảnh hưởng hay nhưng chức năng tương tự thì có xử lý cùng 1 kiểu hay không. Như vậy cũng tiết kiệm thời gian và khách hàng không cảm thấy bị phiền phức quá nhiều, mình cũng được đánh giá cao hơn về cách làm việc.

Trong bài viết này, chúng ta đã đề cập đến các đặc điểm để đo lường yêu cầu. Tổng hợp lại bao gồm:

• Yêu cầu phải rõ ràng và mọi điểm cần đề cập cụ thể.
• Yêu cầu phải được hoàn thành, không có bất kỳ sự không nhất quán.
• Yêu cầu phải có thể kiểm tra được và mọi yêu cầu có thể kiểm tra thì nên có một số tiêu chí để đánh giá lại yêu cầu đó liệu có phù hợp nhất chưa.
• Yêu cầu phải được đo lường và nó có thể được đo lường với các tiêu chuẩn / điều khoản cụ thể.
  Đảm bảo rằng bất kỳ sự mơ hồ nào trong yêu cầu phải được xác định sớm trong giai đoạn SDLC vì nó sẽ giảm được chi phí để khắc phục lỗi cho các giai đoạn sau. Vì vậy bạn nên trao đổi nhiều hơn với các bên liên quan để làm rõ yêu cầu trước khi bắt đầu giai đoạn thiết kế và thực hiện.

https://www.softwaretestinghelp.com/rview-srs-document-and-create-test-scenarios-software-testing-training-course-day-2/ http://www.softwaretestingclass.com/guidelines-to-review-software-requirements-specification-srs-document-the-complete-checklist/ https://www.bmc.com/blogs/software-requirements-specification-how-to-write-srs-with-examples/