21

Trong quy trình phát triển phần mềm, giai đoạn đầu tiên vô cùng quan trọng cần làm là phân tích tài liệu đặc tả. Đây cũng là giai đoạn chúng ta sẽ đưa ra rất nhiều câu hỏi với khách hàng nhằm đảm bảo việc hiểu rõ tài liệu đặc tả. Vậy làm thế nào để phân tích được requirement một cách hiệu quả? hỏi thế nào ngắn gọn nhưng khách hàng vẫn có thể hiểu được và tiết kiệm thời gian trả lời cho khách hàng? Trong bài viết này mình sẽ chia sẻ với các bạn một số kinh nghiệm của bản thân về cách phân tích yêu cầu và Q&A với khách hàng một cách hiệu quả.

1. Software requirement là gì?

1.1 Định nghĩa

Trước tiên chúng ta cần hiểu software requirement là gì? Hiểu một cách đơn giản software requirement là tài liệu miêu tả những yêu cầu của khách hàng về sản phẩm phần mềm, những hành vi của đối tượng trong sản phẩm đó, đó là những yêu cầu về chức năng hoặc phi chức năng mà sản phẩm phần mềm cần đáp ứng được.

1.2 Một số loại software requirement

2. Tại sao phân tích requirement cẩn thận lại quan trọng?

2.1 Ví dụ

Để trả lời được câu hỏi này, trước tiên hãy cũng mình phân tích một ví dụ dưới đây cho việc phân tích requirement sơ sài nhé:

Từ hình ảnh trên có thể thấy, phân tích requirement sơ sài dẫn tới việc sản phẩm cuối cùng không đáp ứng được yêu cầu khách hàng, số tiền phải trả cho việc phát triển dự án là rất lớn. Do đó, khi phân tích requirement cần phân tích một cách cẩn thận, rõ ràng và chi tiết.

2.2 Lợi ích của việc phân tích requirement cẩn thận

Có thể bạn quan tâm

Thế nào là một Requirement tốt?

Thuật toán chuỗi Fibonacci △

3. Phân tích requirement như thế nào cho hiệu quả?

3.1 Hiểu overview về dự án

Khi bắt đầu tham gia một dự án, trước hết cần có cái nhìn khái quát về dự án như khách hàng là ai? sản phẩm phần mềm làm về lĩnh vực gì? ngữ cảnh? nghiệp vụ chung.

3.2 Tìm hiểu về nghiệp vụ, các chứng năng chính

Các thành viên trong dự án cần tìm hiểu và phân tích các yêu cầu về chức năng của phần mềm:

3.3 Tìm hiểu các yêu cầu khác

Bên cạnh các yêu cầu về chức năng, thành viên trong dự án cũng cần tìm hiểu về các yêu cầu liên quan đến giao diện, cơ sở dữ liệu, các yêu cầu phi chức năng …

4. Q&A file là gì? Nên đưa ra câu hỏi như thế nào?

Trong quá trình nghiên cứu yêu cầu khách hàng, chắc chắn sẽ có rất nhiều câu hỏi phát sinh cần được giải đáp. Bạn không thể chạy đi chạy lại hỏi khách hàng luôn tục, và việc quản lý lưu lại các câu hỏi và câu trả lời đó như thế nào cũng là một việc bạn cần quan tâm. Đó là lý do vì sao chúng ta cần phải có tài liệu Q&A cho dự án.

4.1 Q&A file

Q&A là từ viết tắt của Question and Answer (hỏi và trả lời), thường được viết dưới dạng tệp excel. Tệp này bao gồm tất cả các câu hỏi trong dự án, đặc biệt là các câu hỏi về tài liệu yêu cầu của khách hàng về sản phẩm phần mềm.

Khi nghiên cứu yêu cầu của sản phầm phần mềm, nếu có câu hỏi gì thì đều nên viết vào file Q&A. File này cũng được coi là một nhật ký quan trọng.

4.2 Q&A file mẫu

Mỗi tổ chức, công ty đều có mẫu file Q&A riêng. Tuy nhiên, tựu chung lại thì đều có những thành phần dưới đây:

4.3 Gợi ý các câu hỏi tiếng anh sử dụng để hỏi khách hàng

Do đặc thù dự án hiện nay thường sử dụng ngôn ngữ tiếng anh, một số bạn cũng khá bối rối khi sử dụng ngôn ngữ này để hỏi đáp với khách hàng. Do đó, mình gợi ý một số câu hỏi tiếng anh bên dưới.

Để đặt câu hỏi một cách dễ hiểu, ngắn gọn và tiết kiệm thời gian trả lời cho khách hàng, chúng ta nên đặt câu hỏi dưới dạng câu hỏi lựa chọn (multiple choice) và dạng câu hỏi nghi vấn (Yes/No question) để khách hàng chỉ cần trả lời Yes/No là đủ.

Một điều chú ý khi hỏi khách hàng là không nên khỏi khách hàng muốn gì, cũng không nên hỏi khách hàng giải thích ý nghĩa trình bày trong requirement. Thay vào đó, chúng ta nên đưa ra ý hiểu của mình và hỏi khách hàng xác nhận lại ý hiểu đó.

  1. Yes/No question
  1. Multiple choice questionI have below case with 2 expected behavior:….Tôi có trường hợp bên dưới với 2 kết quả mong đợi như sau: (….giải thích trường hợp ở đây...):

    Expected result 1:… / Kết quả mong đợi 1

    Expected result 2:…/ Kết quả mong đợi 2

    Could you please share me your expected result. If you have better option, please let me know.

    Ông chọn kết quả mong đợi nào? Nếu ông có lựa chọn khác hay hơn, làm ơn hãy cho tôi biết.

5. Quản lý những yêu cầu được thay đổi

5.1 Tại sao có yêu cầu thay đổi

Trong quá trình làm dự án, nếu có sự bất hợp lý trong tài liệu yêu cầu, QA và các thành viên khác trong đội dự án cũng có thể thảo luận với khách hàng để thay đổi yêu cầu cho phù hợp. Những yêu cầu thay đổi có thể đến từ đội dự án hoặc từ khách hàng. Những thay đổi đó có thể là thay đổi về giao diện, thay đổi về nghiệp vụ hoặc cấu trúc dữ liệu.

5.2 Quy trình yêu cầu thay đổi và quản lý các thay đổi

  1. Đưa ra yêu cầu thay đổiTrước tiên, khách hàng hoặc đội dự án (Lập trình viên, kiểm thử viên, nhóm trưởng…) đưa ra các yêu cầu thay đổi.
  2. Phân tích yêu cầu thay đổiĐội dự án cần phân tích những yêu cầu thay đổi đó, phần nghiệp vụ…thay đổi này có khả năng ảnh hưởng đến những chức năng nào? ước lượng effort bỏ ra để thay đổi, liệu có ảnh hưởng đến thời gian release sản phẩm hay không?…
  3. Đưa ra quyết định thay đổi hay khôngDựa trên những phân tích trên, khách hàng sẽ là người quyết định có nên thay đổi hay không.
  4. Thực hiện các thay đổiSau khi khách hàng quyết định thay đổi, đội dự án sẽ bắt tay vào thực hiện thay đổi đó (coding, testing…)

Trên đây, mình đã chia sẻ với các bạn một số kinh nghiệm của bản thân về cách phân tích yêu cầu, cách Q&A với khách hàng một cách hiệu quả và quy trình thực hiện các yêu cầu thay đổi. Hi vọng bài viết này sẽ hữu ích đối với các bạn.

Nguồn: Sưu tầm từ internet via Viblo

Link nội dung: https://diendanxaydung.net.vn/qa-la-gi-a51414.html