Câu hỏi: SWR302 - Phần 4: Đại diện người dùng và khơi gợi yêu cầu

Theo gợi ý của Karl Wiegers và Joy Beatty trong cuốn sách Software Requirements, phiên bản thứ ba: Kỹ thuật thu thập yêu cầu (requirements elicitation) ít hữu ích nhất khi dự án của bạn là phát triển ứng dụng mới là gì? Để trả lời câu hỏi này, chúng ta cần xem xét kỹ lưỡng từng kỹ thuật thu thập yêu cầu. Các kỹ thuật thu thập yêu cầu bao gồm phỏng vấn (interviews), hội thảo (workshops), quan sát (observations) và phân tích giao diện hệ thống (system interface analysis). Trong khi các kỹ thuật khác đều hữu ích trong việc thu thập yêu cầu cho dự án mới, phỏng vấn lại không phải là lựa chọn tốt nhất. Điều này là vì phỏng vấn thường tập trung vào việc thu thập thông tin từ các chuyên gia và người dùng đã có kinh nghiệm, trong khi dự án mới thường cần thu thập thông tin từ các chuyên gia và người dùng mới.

Khi chuẩn bị cho quá trình thu thập yêu cầu (elicitation) trên dự án của mình, bước đầu tiên quan trọng là quyết định phạm vi và chương trình thu thập yêu cầu (decide on elicitation scope and agenda). Điều này giúp bạn xác định rõ những gì cần thu thập, ai sẽ tham gia vào quá trình thu thập, và mục tiêu của quá trình thu thập yêu cầu. Bằng cách quyết định phạm vi và chương trình thu thập yêu cầu, bạn có thể đảm bảo rằng quá trình thu thập yêu cầu được thực hiện một cách hiệu quả và đạt được mục tiêu mong muốn. Ngoài ra, quyết định phạm vi và chương trình thu thập yêu cầu cũng giúp bạn tránh được những sai sót và nhầm lẫn trong quá trình thu thập yêu cầu.

Khi phát hiện ra bất kỳ xung đột nào trong kỹ thuật quản lý yêu cầu, rất quan trọng phải bắt đầu giải quyết xung đột càng sớm càng tốt. Việc thu thập thông tin có thể diễn ra sau đó. Điều này giúp đảm bảo rằng các yêu cầu được thống nhất và rõ ràng, giảm thiểu khả năng xảy ra xung đột trong tương lai. Việc giải quyết xung đột sớm cũng giúp tiết kiệm thời gian và nguồn lực trong quá trình phát triển sản phẩm.

Trong quá trình thu thập yêu cầu, việc có một bản kế hoạch họp và gửi trước cho các thành viên tham gia có thể mang lại nhiều lợi ích. Điều này giúp tạo ra một quá trình phỏng vấn có cấu trúc và cho phép mọi người chuẩn bị trước. Khi có một bản kế hoạch họp rõ ràng, các thành viên tham gia sẽ biết rõ mục tiêu và nội dung cần thảo luận, từ đó có thể chuẩn bị các ý tưởng và câu hỏi phù hợp. Điều này giúp tăng cường hiệu quả của cuộc họp và đảm bảo rằng mọi người đều có cơ hội thể hiện ý kiến của mình. Ngoài ra, việc có một bản kế hoạch họp cũng giúp tránh được những cuộc thảo luận không liên quan và đảm bảo rằng cuộc họp được tiến hành một cách chuyên nghiệp.

Kỹ thuật Workshop là một phương pháp thu thập yêu cầu hiệu quả trong quy trình thu thập yêu cầu. Để thực hiện một Workshop thành công, cần có một số bước quan trọng. Đầu tiên, cần lên kế hoạch một chương trình (Plan an agenda), đặt thời gian giới hạn cho các cuộc thảo luận (Time box discussions), đảm bảo có đủ số lượng thành viên tham gia nhưng chỉ bao gồm các bên liên quan quan trọng (Keep the team small but include the right stakeholders), giữ cho tất cả mọi người đều tham gia và tập trung (Keep everyone engaged), chuẩn bị các câu hỏi và mô hình giả (Prepare questions and straw man models ahead of time). Tuy nhiên, một số kỹ thuật không thuộc về phương pháp Workshop, chẳng hạn như 'Fill all of the team roles' (Điền đầy đủ các vai trò của đội ngũ), tức là cố gắng mời đủ mọi người tham gia mà không cần xem xét kỹ lưỡng về vai trò và tính cần thiết của họ.

Để phân loại người dùng, chúng ta có thể dựa vào nhiều yếu tố khác nhau. Trong số các lựa chọn trên, có một số yếu tố không phải là phương pháp phân loại người dùng hợp lý. Đầu tiên, chúng ta có thể dựa vào quyền truy cập hoặc cấp độ bảo mật của người dùng (ví dụ: người dùng thường, người dùng khách, người dùng quản trị viên). Điều này giúp chúng ta phân loại người dùng dựa vào mức độ truy cập và quyền lực của họ. Thứ hai, chúng ta có thể dựa vào các nhiệm vụ mà người dùng thực hiện trong quá trình hoạt động kinh doanh của họ. Điều này giúp chúng ta phân loại người dùng dựa vào vai trò và chức năng của họ. Thứ ba, chúng ta có thể dựa vào tần suất người dùng sử dụng sản phẩm. Điều này giúp chúng ta phân loại người dùng dựa vào mức độ sử dụng và độ trung thành của họ. Cuối cùng, chúng ta có thể dựa vào các lớp người dùng khác nhau cho sản phẩm của mình. Điều này giúp chúng ta phân loại người dùng dựa vào nhu cầu và mục tiêu của họ. Tuy nhiên, một yếu tố không phải là phương pháp phân loại người dùng hợp lý là dựa vào các tính năng mà người dùng sử dụng. Điều này không giúp chúng ta phân loại người dùng một cách hiệu quả và chính xác.

Một mục tiêu của một phân loại yêu cầu là giúp tổ chức dữ liệu vào các lớp. Điều này giúp chúng ta nghĩ về các lớp mà chúng ta có thể bỏ qua nếu không có phân loại. Ví dụ, khi phân loại yêu cầu cho một hệ thống quản lý thư viện, chúng ta có thể tạo các lớp như 'sách', 'nhân viên', 'khách hàng'. Việc phân loại này giúp chúng ta xác định rõ các yêu cầu của hệ thống và tránh bỏ qua các yêu cầu quan trọng. Ngoài ra, phân loại yêu cầu cũng giúp chúng ta dễ dàng tìm kiếm và truy cập các yêu cầu đã được xác định.

Để tìm được giọng nói của người dùng, chúng ta cần thực hiện các bước sau. Trước hết, chúng ta phải xác định được các lớp người dùng khác nhau cho sản phẩm của mình. Sau đó, chúng ta cần chọn và làm việc với các cá nhân đại diện cho mỗi lớp người dùng và các nhóm liên quan khác. Tiếp theo, chúng ta cần thống nhất về người quyết định yêu cầu cho dự án của mình. Cuối cùng, chúng ta cần hiểu được các nhiệm vụ mà người dùng thực hiện trong quá trình hoạt động kinh doanh của họ. Tuy nhiên, không phải tất cả các lựa chọn đều là bước trong quá trình tìm kiếm giọng nói của người dùng. Lựa chọn không phải bước trong quá trình này là 'Các nhiệm vụ họ thực hiện trong quá trình hoạt động kinh doanh của họ'.

Trong kỹ thuật yêu cầu, việc tập trung vào những người quan trọng nhất trong tổ chức là một chiến lược hiệu quả. Điều này có nghĩa là bạn nên ưu tiên những người có ảnh hưởng lớn đến quyết định và quá trình thực hiện dự án. Họ có thể cung cấp thông tin chi tiết và chính xác về yêu cầu của dự án, giúp bạn hiểu rõ hơn về nhu cầu của khách hàng và tổ chức. Bằng cách tập trung vào những người quan trọng nhất, bạn có thể thu thập được thông tin chất lượng cao và đảm bảo rằng dự án được thực hiện đúng hướng.

Trong quy trình quản lý yêu cầu, việc giải quyết xung đột là một phần quan trọng. Khi phát hiện ra bất kỳ xung đột nào, việc giải quyết xung đột càng sớm càng tốt là rất quan trọng. Điều này giúp tránh được những vấn đề phức tạp và tốn thời gian sau này. Elicitation của thông tin có thể diễn ra sau khi giải quyết xung đột, nhưng việc giải quyết xung đột phải được ưu tiên. Việc giải quyết xung đột sớm giúp đảm bảo rằng các yêu cầu được rõ ràng, chính xác và không mâu thuẫn với nhau. Điều này giúp cho quá trình phát triển sản phẩm trở nên hiệu quả hơn và giảm thiểu các vấn đề phát sinh trong tương lai.

Xác định các bên liên quan (stakeholders) là một bước quan trọng khi thu thập yêu cầu cho một hệ thống phần mềm. Điều này giúp bạn hiểu rõ ai đang tham gia vào dự án, ai sẽ bị ảnh hưởng bởi kết quả dự án và ai có thể ảnh hưởng đến kết quả dự án. Việc xác định các bên liên quan giúp bạn có thể thu thập yêu cầu chính xác và đầy đủ, từ đó đảm bảo rằng hệ thống phần mềm đáp ứng được nhu cầu và kỳ vọng của các bên liên quan. Ngoài ra, việc xác định các bên liên quan cũng giúp bạn có thể dự đoán và giải quyết các vấn đề có thể xảy ra trong quá trình thực hiện dự án.

Để viết được câu hỏi điều tra hiệu quả, cần bắt đầu bằng việc hỏi những câu hỏi mở (open-ended questions) ngay từ đầu. Những câu hỏi này cho phép người tham gia trả lời một cách tự do và chi tiết, giúp thu thập được thông tin đầy đủ và có ý nghĩa. Câu hỏi mở thường bắt đầu bằng từ như 'Bạn nghĩ gì về', 'Bạn cảm thấy thế nào khi', 'Bạn nghĩ rằng', v.v. Điều này giúp người tham gia có thể thể hiện quan điểm và ý kiến của mình một cách tự nhiên và chân thực. Ngoài ra, câu hỏi mở cũng giúp nhà điều tra có thể thu thập được thông tin sâu sắc và chi tiết hơn, giúp cho việc phân tích và tổng hợp dữ liệu trở nên dễ dàng hơn.

Elicitation là một quá trình hợp tác và phân tích bao gồm các hoạt động để thu thập, khám phá, trích xuất và thu thập yêu cầu. Quá trình này nhằm mục đích thu thập thông tin cần thiết từ khách hàng hoặc người sử dụng để xác định các yêu cầu của hệ thống hoặc sản phẩm. Elicitation thường bao gồm các hoạt động như thu thập yêu cầu, xác định yêu cầu và phân tích yêu cầu. Trong quá trình này, người tham gia sẽ thảo luận và chia sẻ ý tưởng để thu thập thông tin cần thiết. Quá trình này rất quan trọng vì nó giúp đảm bảo rằng các yêu cầu được thu thập chính xác và đầy đủ.

Khi tham gia vào nhiều đại diện người dùng khác nhau thay vì chỉ dựa vào một đại diện duy nhất, chúng ta có thể đảm bảo được một cái nhìn toàn diện hơn về nhu cầu đa dạng của người dùng. Điều này giúp chúng ta hiểu rõ hơn về những mong muốn và kỳ vọng của người dùng, từ đó có thể thiết kế và phát triển sản phẩm hoặc giải pháp phù hợp hơn với nhu cầu của họ. Ngoài ra, việc tham gia vào nhiều đại diện người dùng còn giúp chúng ta nhận ra và giải quyết được những rủi ro tiềm ẩn mà chúng ta có thể bỏ qua nếu chỉ dựa vào một đại diện duy nhất.

Đáp án đúng gồm hai ý: "They gather requirements from other members of the user classes they represent and reconcile inconsistencies." và "They serve as the primary interface between members of a single user class and the project’s business analyst.". Product champion (người đại diện sản phẩm) là người dùng chủ chốt được chọn để đại diện cho một user class (nhóm người dùng); họ là đầu mối chính giữa nhóm người dùng đó và người phân tích nghiệp vụ, thu thập yêu cầu từ những người dùng khác trong nhóm và hoà giải những ý kiến mâu thuẫn trước khi đưa cho nhóm dự án. "They implement the coding standards." sai vì tiêu chuẩn lập trình là việc của lập trình viên, product champion đứng ở phía người dùng. "They write requirements documents." không phải vai trò định nghĩa của họ: viết tài liệu yêu cầu chính thức là trách nhiệm của người phân tích nghiệp vụ, product champion chỉ cung cấp thông tin, góp ý và review.

Một đại diện được chỉ định của một lớp người dùng cụ thể cung cấp các yêu cầu người dùng cho nhóm mà họ đại diện. Người đại diện này đóng vai trò quan trọng trong việc xác định và ưu tiên các yêu cầu của nhóm, đảm bảo rằng các yêu cầu này được thực hiện một cách hiệu quả và phù hợp với mục tiêu của nhóm. Họ cũng phải có khả năng giao tiếp và làm việc hiệu quả với các thành viên khác trong nhóm, cũng như với các bên liên quan khác.

Đáp án đúng gồm ba ý: "Users repeat issues they already covered in previous discussions.", "Suggested new features, user requirements, or functional requirements are all deemed to be out of scope." và "Proposed new requirements are all low priority.". Không có thời điểm tuyệt đối cho biết khơi gợi (elicitation) đã xong, nên người phân tích dựa vào tín hiệu: người dùng chỉ nhắc lại điều đã nói, ý mới đều nằm ngoài phạm vi, yêu cầu mới đề xuất đều ưu tiên thấp; tất cả cho thấy nguồn yêu cầu mới có giá trị đã cạn. Phương án "Developers and testers who review the requirements for an area raise many questions." sai vì đây là tín hiệu ngược lại: nhiều câu hỏi chứng tỏ yêu cầu ở mảng đó còn mơ hồ hoặc thiếu, cần khơi gợi tiếp; tín hiệu hoàn tất là khi lập trình viên và kiểm thử viên đọc yêu cầu mà chỉ còn ít câu hỏi.

Trong quá trình quan sát thụ động cho việc thu thập thông tin về nhiệm vụ, người quan sát sẽ không tham gia vào quá trình mà họ đang quan sát. Họ sẽ không hỏi bất kỳ câu hỏi nào, cũng không can thiệp vào quá trình đó. Thay vào đó, họ sẽ chỉ quan sát và ghi lại các hành động của người dùng mà không gây ảnh hưởng đến quá trình đó. Điều này giúp người quan sát có thể thu thập thông tin chính xác và khách quan về cách người dùng thực hiện các nhiệm vụ.

Đáp án đúng: "The persona must be representative of their user class". Persona (chân dung người dùng) là một nhân vật được dựng lên để đại diện cho một lớp người dùng (user class), có tên, mục tiêu, thói quen và bối cảnh; nó giúp nhóm khơi gợi và thiết kế nghĩ cụ thể về người sẽ dùng sản phẩm, nên điều quan trọng nhất là các đặc điểm của nó phản ánh đúng lớp người dùng đó. Phương án "The persona must be a real person" sai vì persona thường là nhân vật hư cấu tổng hợp từ nhiều người thật, dựa trên một cá nhân cụ thể dễ làm lệch đặc điểm chung. Phương án "The persona must be rich" sai vì dù hiểu là giàu có hay giàu chi tiết, đó không phải tiêu chí chính; chi tiết chỉ có ích khi phục vụ tính đại diện. Phương án "The persona must be beautiful" sai vì ngoại hình không liên quan tới nhu cầu và hành vi người dùng.

Đáp án đúng: "Training courses". Elicitation (khơi gợi yêu cầu) là hoạt động tìm ra yêu cầu từ bên liên quan và các nguồn khác; kỹ thuật phổ biến gồm phỏng vấn, hội thảo, nhóm tập trung, quan sát, bảng hỏi, phân tích tài liệu, phân tích giao diện hệ thống. Khoá đào tạo là để truyền kiến thức cho người học, dòng thông tin đi ngược chiều với khơi gợi, nên không phải kỹ thuật khơi gợi. "Interviews" là kỹ thuật khơi gợi cơ bản nhất, BA hỏi trực tiếp từng người hay nhóm nhỏ để hiểu nhu cầu. "Focus groups" là kỹ thuật khơi gợi, tập hợp một nhóm người dùng đại diện để lấy ý kiến về nhu cầu, sở thích, kỳ vọng với sản phẩm. "Observations" là kỹ thuật khơi gợi, BA quan sát người dùng làm việc thực tế để thấy những bước họ không kể ra khi phỏng vấn. Ba kỹ thuật này đều đúng là khơi gợi nên không được chọn trong câu hỏi phủ định.