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

Quá trình thu thập thông tin (elicitation) đóng vai trò quan trọng trong quá trình phát triển yêu cầu. Nó liên kết chặt chẽ với các hoạt động khác như phân tích, xác định yêu cầu và xác minh. Elicitation không chỉ là một bước đầu tiên mà còn là một quá trình liên tục được lặp lại trong suốt quá trình phát triển yêu cầu. Mục đích của nó là thu thập thông tin chính xác và đầy đủ về yêu cầu của khách hàng, sau đó sử dụng thông tin đó để xác định và xác minh yêu cầu. Quá trình này không chỉ diễn ra một lần mà còn được lặp lại nhiều lần trong suốt quá trình phát triển dự án để đảm bảo rằng yêu cầu được cập nhật và chính xác.

Kỹ thuật hiệu quả nhất để giải quyết mâu thuẫn giữa các bên liên quan là các buổi thảo luận ưu tiên. Các buổi thảo luận ưu tiên là một quá trình giúp các bên liên quan thống nhất và ưu tiên các yêu cầu quan trọng nhất. Điều này giúp giảm thiểu mâu thuẫn và tăng cường sự hiểu biết giữa các bên liên quan. Trong quá trình này, các bên liên quan sẽ thảo luận và đánh giá các yêu cầu, sau đó ưu tiên chúng dựa trên mức độ quan trọng và mức độ ảnh hưởng. Các buổi thảo luận ưu tiên giúp các bên liên quan đạt được sự đồng thuận và tăng cường sự hợp tác, từ đó giải quyết mâu thuẫn và đạt được mục tiêu chung.

Một trong những lợi ích của việc có một bộ quy tắc rõ ràng cho người ủng hộ sản phẩm là gì? Người ủng hộ sản phẩm đóng vai trò quan trọng trong việc thúc đẩy sự thành công của dự án. Họ giúp đảm bảo rằng dự án được thực hiện một cách hiệu quả và đạt được mục tiêu đề ra. Tuy nhiên, không phải lợi ích nào của việc có một bộ quy tắc rõ ràng cho người ủng hộ sản phẩm cũng chính xác. Một trong những lợi ích không chính xác là đảm bảo dự án sẽ luôn nằm trong ngân sách. Điều này không phải là một lợi ích của việc có một bộ quy tắc rõ ràng cho người ủng hộ sản phẩm. Thay vào đó, nó là một lợi ích của việc quản lý dự án một cách hiệu quả.

Trong phân tích yêu cầu, mục đích và cách sử dụng nhân vật (persona) được mô tả như sau. Hai lựa chọn dưới đây là đúng.

Hoạt động tổ chức và chia sẻ ghi chú thuộc về việc chuẩn bị cho việc thu thập thông tin. Khi bạn chuẩn bị cho việc thu thập thông tin, bạn cần phải tổ chức và sắp xếp các ghi chú của mình để dễ dàng truy cập và sử dụng. Điều này giúp bạn có thể thu thập thông tin một cách hiệu quả và chính xác hơn. Việc tổ chức và chia sẻ ghi chú cũng giúp bạn có thể dễ dàng chia sẻ thông tin với các thành viên khác trong nhóm, từ đó giúp việc thu thập thông tin trở nên nhanh chóng và hiệu quả hơn.

Elicitation trong kỹ thuật yêu cầu (requirements engineering) là quá trình thu thập thông tin về yêu cầu của người dùng hoặc các bên liên quan (stakeholders). Quá trình này nhằm mục đích xác định rõ những gì người dùng mong muốn và cần có trong hệ thống hoặc sản phẩm. Elicitation thường bao gồm các hoạt động như phỏng vấn, quan sát, phân tích dữ liệu và các phương pháp khác để thu thập thông tin về yêu cầu của người dùng. Quá trình này rất quan trọng vì nó giúp đảm bảo rằng hệ thống hoặc sản phẩm đáp ứng được nhu cầu và mong muốn của người dùng.

Đáp án đúng: "Collaborate with multiple business analysts and product champions to gather comprehensive requirements.". Với dự án phức tạp, một product owner khó nắm hết nhu cầu của mọi nhóm người dùng, nên cách làm được khuyến nghị là chia sẻ công việc khơi gợi yêu cầu: nhiều chuyên viên phân tích nghiệp vụ (business analyst) cùng các product champion, tức người đại diện cho từng lớp người dùng (user class), thu thập và làm rõ yêu cầu, còn product owner vẫn giữ quyền ra quyết định và ưu tiên. "Replace the product owner with a more knowledgeable individual." không giải quyết gốc vấn đề vì độ phức tạp vượt khả năng của bất kỳ một cá nhân nào. "Simplify the project to reduce complexity." là cắt phạm vi, chỉ hợp lý khi phía nghiệp vụ đồng ý thu hẹp mục tiêu, còn câu hỏi là làm sao hiểu đủ yêu cầu. "Delegate all decision-making to the development team." khiến yêu cầu do người không đại diện cho người dùng quyết định, dễ làm sai nhu cầu thật.

Đáp án đúng: "Creating a checklist of required documents and systems.". Khơi gợi độc lập (independent elicitation) là khi chuyên viên phân tích tự nghiên cứu tài liệu, hệ thống hiện có, báo cáo, quy trình mà không cần các bên liên quan có mặt; để chắc chắn không sót nguồn nào, trọng tâm là lập danh sách kiểm (checklist) mọi tài liệu và hệ thống cần có rồi đối chiếu. Phương án "Assigning a team member to gather all necessary materials." là một bước thực hiện, nhưng không có danh sách thì người đó cũng không biết phải gom những gì. Phương án "Setting up a shared repository for document access." giúp lưu và truy cập tài liệu, phục vụ sau khi đã biết cần tài liệu nào chứ không đảm bảo đủ. Phương án "Scheduling regular audits to ensure document availability." là kiểm tra định kỳ về sau, tốn công và vẫn cần một danh sách làm chuẩn để kiểm.

Đáp án đúng: "There are matters that should be, but are not, elicited through the elicitation process. They exist, but they are not realized.". Yêu cầu ngầm (implicit requirements) là những điều người dùng mong đợi nhưng không nói ra; khi cả người dùng lẫn người phân tích đều không nhận ra chúng tồn tại thì chúng là ẩn số không biết (unknown unknowns): có thật, đáng lẽ phải khơi gợi được, nhưng chưa ai ý thức về chúng. Phương án "customers should always be required to spell out their unknown unknowns" sai vì không thể bắt khách hàng nêu điều chính họ không biết. Phương án "cannot be known and therefore we can not make them explicit requirements" sai vì qua khơi gợi kỹ, bản mẫu, rà soát, ẩn số vẫn có thể lộ ra và được viết thành yêu cầu tường minh. Phương án "They help us reveal both known unknowns and more unknown unknowns." sai vì yêu cầu ngầm không phải công cụ phát hiện, chúng là thứ cần được phát hiện.

Hoạt động thu thập yêu cầu (requirements elicitation) là bước quan trọng trong quy trình phát triển phần mềm. Để chuẩn bị cho hoạt động này, chúng ta cần thực hiện một số bước quan trọng. Trong các lựa chọn dưới đây, có một lựa chọn không thuộc về việc chuẩn bị cho hoạt động thu thập yêu cầu. Lựa chọn đó là "Prepare resource:". Điều này có nghĩa là việc chuẩn bị nguồn lực không phải là một bước quan trọng trong việc chuẩn bị cho hoạt động thu thập yêu cầu. Thay vào đó, chúng ta cần quyết định phạm vi và chương trình thu thập yêu cầu, chuẩn bị các câu hỏi và mô hình thử nghiệm, và lưu giữ các vấn đề mở.

Khi muốn giải quyết mâu thuẫn về yêu cầu giữa các khách hàng doanh nghiệp, cách tiếp cận phù hợp nhất là dựa trên mục tiêu kinh doanh. Điều này có nghĩa là việc giải quyết mâu thuẫn sẽ được quyết định dựa trên những mục tiêu và mục đích kinh doanh của công ty, chứ không phải dựa trên sở thích cá nhân hoặc ưu tiên của một nhóm người cụ thể. Điều này giúp đảm bảo rằng quyết định được đưa ra là có lợi cho công ty và phù hợp với chiến lược kinh doanh tổng thể. Ví dụ, nếu một khách hàng doanh nghiệp muốn yêu cầu một tính năng cụ thể nhưng đó không phải là ưu tiên cao nhất của công ty, thì quyết định sẽ được đưa ra dựa trên mục tiêu kinh doanh và lợi ích của công ty, chứ không phải dựa trên yêu cầu của khách hàng.

Khi trả lời câu hỏi này, chúng ta cần hiểu rằng yêu cầu CJ (CJ Requirements) là những yêu cầu không được đáp ứng trong quá trình thu thập thông tin (elicitation) mà không liên quan đến dự án phần mềm. Điều này có nghĩa là nếu yêu cầu CJ không được đáp ứng, dự án phần mềm không nên được hoàn thành. Vì vậy, câu trả lời đúng là 'False', vì nếu yêu cầu CJ không được đáp ứng, dự án phần mềm vẫn có thể được hoàn thành nhưng có thể không đáp ứng được các yêu cầu của dự án.

Trong quá trình thu thập yêu cầu (elicitation) có thể xảy ra tình trạng bỏ sót các yêu cầu quan trọng. Điều này có thể dẫn đến việc dự án phần mềm không đáp ứng được nhu cầu của người dùng. Vì vậy, việc xác định và thu thập đầy đủ các yêu cầu là rất quan trọng trong suốt quá trình phát triển phần mềm. Nếu các yêu cầu quan trọng bị bỏ sót, dự án phần mềm có thể không thể hoàn thành đúng như kế hoạch.

Để xác định liệu bạn đã hoàn thành yêu cầu thu thập thông tin (requirements elicitation) hay chưa, bạn cần xem xét các dấu hiệu sau. Một dấu hiệu tốt là khi các yêu cầu mới được đề xuất đều có mức độ ưu tiên cao. Tuy nhiên, điều này không phải lúc nào cũng đúng. Một dấu hiệu khác là khi các nhà phát triển và kiểm thử viên đánh giá yêu cầu cho một khu vực cụ thể và không có nhiều câu hỏi được đặt ra. Điều này cho thấy yêu cầu đã được rõ ràng và đầy đủ. Một dấu hiệu khác nữa là khi các tính năng mới được đề xuất, yêu cầu của người dùng hoặc yêu cầu chức năng đều được coi là nằm trong phạm vi dự án. Điều này cho thấy yêu cầu đã được thu thập đầy đủ và chính xác. Cuối cùng, nếu người dùng không đưa ra các vấn đề mới mà chưa được đề cập trong các cuộc thảo luận trước đó, thì cũng có thể coi là một dấu hiệu tốt.

Khi thực hiện yêu cầu thu thập thông tin (requirements elicitation), có nhiều kỹ thuật được sử dụng để thu thập thông tin từ khách hàng hoặc người liên quan. Trong số các kỹ thuật này, có một số kỹ thuật không phù hợp hoặc không cần thiết. Kỹ thuật 'Fill all of the team roles' không phải là một kỹ thuật thu thập thông tin, mà là một kỹ thuật xây dựng đội ngũ. Nó liên quan đến việc đảm bảo rằng các thành viên trong đội ngũ có đủ kỹ năng và vai trò để thực hiện công việc một cách hiệu quả. Tuy nhiên, nó không liên quan trực tiếp đến quá trình thu thập thông tin.

Để xác định các lớp người dùng của hệ thống phần mềm mới đang phát triển, chúng ta nên bắt đầu bằng cách hỏi người tài trợ dự án (project sponsor) về những người họ dự kiến sẽ sử dụng hệ thống. Sau đó, chúng ta có thể brainstorm để nghĩ ra càng nhiều lớp người dùng càng tốt. Việc này giúp đảm bảo rằng hệ thống được thiết kế để đáp ứng nhu cầu của tất cả các lớp người dùng.

Đáp án đúng: "Business requirements". Business requirements (yêu cầu nghiệp vụ) nêu lý do tổ chức làm dự án và lợi ích kinh doanh mong đợi, thường là mục tiêu đo được về tài chính hay vận hành; câu tiết kiệm X đô la mỗi năm tiền điện đang lãng phí là đúng loại mục tiêu tài chính của tổ chức. Dù chính khách hàng nói ra, nó không mô tả việc người dùng cần làm, nên không phải yêu cầu người dùng. "User requirements" sai vì yêu cầu người dùng mô tả nhiệm vụ người dùng thực hiện với hệ thống, ví dụ theo dõi mức tiêu thụ điện của từng thiết bị. "Business rules" sai vì quy tắc nghiệp vụ là chính sách, quy định, công thức tính áp lên hoạt động, không phải mục tiêu lợi ích. "Quality attributes" sai vì thuộc tính chất lượng mô tả hệ thống tốt đến mức nào như hiệu năng, khả dụng, không phải số tiền tiết kiệm. "Solution ideas" sai vì phát biểu không đề xuất cách giải nào, như thay thiết bị hay lắp cảm biến, mà chỉ nêu kết quả kinh doanh cần đạt.

Đáp án đúng: "Draft straw man models". Khi chuẩn bị phỏng vấn trong hoạt động khơi gợi yêu cầu, người phân tích nên phác sẵn straw man model (mô hình nháp để người khác góp ý), như một sơ đồ quy trình hay danh sách tính năng thô; người được phỏng vấn thường dễ chỉ ra chỗ sai trong một bản nháp cụ thể hơn là trả lời câu hỏi trừu tượng từ trang giấy trắng. Phương án "Avoid preparing questions" sai vì chuẩn bị bộ câu hỏi giúp buổi phỏng vấn đi đúng mục tiêu và không bỏ sót chủ đề. Phương án "Focus only on UI design" sai vì phỏng vấn cần tìm hiểu mục tiêu, nhiệm vụ, quy tắc nghiệp vụ và yêu cầu chất lượng, giao diện chỉ là một phần nhỏ. Phương án "Skip meeting stakeholders" đi ngược bản chất phỏng vấn, vốn là trao đổi trực tiếp với bên liên quan.

Đáp án đúng: "Focus groups". Nhóm tập trung (focus group) tập hợp một nhóm người dùng đại diện, thường cho từng lớp người dùng, để thảo luận có điều phối về nhu cầu và kỳ vọng; với dự án lớn có rất nhiều người dùng, kỹ thuật khơi gợi này thu được quan điểm của số đông một cách hiệu quả hơn so với làm việc từng người. "Observation" là quan sát người dùng làm việc thật, rất tốt để hiểu quy trình ngầm nhưng tốn thời gian và chỉ phủ được ít người. "Brainstorming sessions" nhằm sinh nhiều ý tưởng mới, phù hợp khi tìm giải pháp chứ không nhằm thu thập nhu cầu đại diện của đông đảo bên liên quan. "Stakeholder interviews" là phỏng vấn một-một, cho thông tin sâu nhưng khó mở rộng khi số bên liên quan quá lớn, nên thường dùng cho người chủ chốt.

Đáp án đúng: "A User Representative is a real individual from the user base who participates directly in the development process, while a User Persona is a fictional composite based on real data.". Người đại diện người dùng (user representative, như product champion) là một người thật thuộc một nhóm người dùng, tham gia trực tiếp để cung cấp và thẩm định yêu cầu thay mặt nhóm đó; chân dung người dùng (persona) là nhân vật hư cấu tổng hợp từ dữ liệu thật, dùng khi không tiếp cận được người dùng thật. Phương án "used only in testing, while a User Persona is used solely" sai vì cả hai đều phục vụ khơi gợi và thẩm định suốt dự án. Phương án "are exactly the same" sai vì một bên là người thật, một bên là nhân vật giả định. Phương án "employed to document technical requirements" sai vì người đại diện không viết yêu cầu kỹ thuật và persona không chỉ dùng thiết kế giao diện. Phương án "represents one individual only, while a User Persona represents an entire organization" sai vì người đại diện nói thay cả một nhóm người dùng, còn persona đại diện cho một nhóm người dùng chứ không phải cả tổ chức.