- Thu thập yêu cầu là quá trình xác định, thu thập và phân tích các yêu cầu của các bên liên quan (stakeholders) để hiểu rõ mục tiêu, nhu cầu và mong muốn của dự án.
- Là giai đoạn nền tảng, giúp xác định phạm vi, mục tiêu và các yếu tố quan trọng khác để đảm bảo dự án thành công.
Mục tiêu chính của Requirements Gathering
Là tạo ra một tài liệu yêu cầu chi tiết và rõ ràng, thường được gọi là Đặc tả Yêu cầu (Requirements Specification). Tài liệu này sẽ đóng vai trò quan trọng cho toàn bộ đội ngũ phát triển, giúp họ hiểu được:
- Mục tiêu của dự án: Dự án được tạo ra để giải quyết vấn đề gì?, xác định ai là người dùng/khách hàng và họ cần gì.
- Chức năng cần có: Sản phẩm hoặc hệ thống cần làm được những gì?
- Giới hạn và điều kiện: Các yêu cầu phi chức năng (non-functional requirements) như hiệu suất, bảo mật, và khả năng sử dụng.
- Đảm bảo tất cả các bên liên quan có cùng nhận thức về phạm vi và mục tiêu.
Phương pháp thu thập yêu cầu phổ biến
- Phỏng vấn. Đây là một trong những phương pháp hiệu quả nhất nhưng cũng tốn kém nhất. Thực hiện phỏng vấn cho phép bạn quan sát người mình đang nói chuyện, đánh giá mức độ hiểu biết của họ và nắm bắt các tín hiệu phi ngôn ngữ. Tuy nhiên, phương pháp này đòi hỏi kỹ năng giao tiếp tốt và có thể tốn thời gian cũng như chi phí.
- Khảo sát. Khảo sát là một cách hiệu quả về mặt chi phí để thu thập thông tin từ lượng lớn đối tượng. Chúng dễ dàng phân phối và không đòi hỏi nhiều thời gian của người trả lời. Tuy nhiên, khảo sát cũng có những hạn chế. Chúng thường gặp khó khăn với các câu hỏi mở và thiếu tính cá nhân như một cuộc phỏng vấn.
- Động não. Một buổi động não có thể là một công cụ mạnh mẽ để tạo ra ý tưởng. Tuy nhiên, nó có thể gây khó khăn cho những người tham gia hướng nội, những người có thể cảm thấy không thoải mái khi chia sẻ ý tưởng trong môi trường nhóm. Để giảm thiểu điều này, hãy cân nhắc sử dụng các buổi hội thảo có người hướng dẫn để hướng dẫn quá trình và đảm bảo tiếng nói của mọi người đều được lắng nghe.
- So sánh chuẩn. Điều này bao gồm việc so sánh dự án của bạn với các tiêu chuẩn ngành hoặc đối thủ cạnh tranh để xác định các lĩnh vực cần cải thiện hoặc đổi mới. So sánh chuẩn có thể cung cấp những hiểu biết giá trị về những gì đang hiệu quả trên thị trường.
- Tạo mẫu. Việc tạo mẫu cho phép các bên liên quan tương tác với phiên bản sơ bộ của sản phẩm. Phương pháp thực hành này có thể giúp làm rõ các yêu cầu và xác định các vấn đề tiềm ẩn ngay từ đầu quá trình phát triển.
- Quan sát. Việc quan sát người dùng trong môi trường tự nhiên của họ có thể cung cấp những hiểu biết sâu sắc về cách họ tương tác với các hệ thống hoặc quy trình hiện tại. Kỹ thuật này đặc biệt hữu ích để xác định những nhu cầu hoặc vấn đề chưa được nói ra mà người dùng có thể chưa nói rõ.
- Phân tích tài liệu. Phân tích tài liệu hiện có, chẳng hạn như kế hoạch dự án trước đây, hướng dẫn sử dụng hoặc hướng dẫn quy định, có thể khám phá các yêu cầu thiết yếu và tránh bỏ sót các khía cạnh quan trọng của dự án.
Tầm quan trọng của Requirements Gathering
Nếu quá trình Thu thập Yêu cầu được không thực hiện không, dự án sẽ gặp phải nhiều rủi ro:
- Sản phẩm không đáp ứng nhu cầu: Dẫn đến việc phải làm lại (rework), tốn kém thời gian và chi phí.
- Thay đổi liên tục: Yêu cầu thay đổi thường xuyên trong quá trình phát triển, làm gián đoạn tiến độ.
- Mâu thuẫn giữa các bên: Thiếu sự thống nhất giữa các bên liên quan do yêu cầu không rõ ràng.
Những sai lầm phổ biến thường gặp ở giai đoạn này
- Không xác định đầy đủ các bên liên quan (Stakeholders)
Sai lầm lớn nhất là chỉ làm việc với một vài người quản lý cấp cao mà bỏ qua những người trực tiếp sử dụng sản phẩm hoặc các bộ phận liên quan. Điều này dẫn đến việc bỏ sót những yêu cầu quan trọng và tạo ra một sản phẩm không thực sự hữu ích trong thực tế.
Hậu quả: Các yêu cầu không đầy đủ, không chính xác, dẫn đến việc sản phẩm cuối cùng không đáp ứng được nhu cầu thực tế của người dùng cuối.
- Yêu cầu không rõ ràng và mơ hồ
Đây là vấn đề muôn thuở. Thay vì yêu cầu cụ thể, BA thường nhận được những câu nói chung chung như “Hệ thống cần phải dễ sử dụng” hay “Phần mềm cần hoạt động nhanh”. Những yêu cầu mơ hồ này khiến đội ngũ phát triển khó hiểu và dễ dẫn đến sự sai lệch so với mong đợi ban đầu.
Hậu quả: Đội ngũ kỹ thuật phải đoán ý, sản phẩm được phát triển không đúng với mong muốn, gây lãng phí thời gian và chi phí để chỉnh sửa.
- Không ưu tiên các yêu cầu
Việc thu thập được hàng trăm yêu cầu mà không sắp xếp theo mức độ ưu tiên sẽ khiến đội ngũ phát triển không biết nên làm gì trước. Mọi thứ đều được coi là quan trọng, dẫn đến tình trạng làm việc không hiệu quả và dễ bị quá tải.
Hậu quả: Dự án có thể không hoàn thành các tính năng cốt lõi đúng hạn, hoặc tệ hơn là tốn thời gian vào những tính năng không mang lại nhiều giá trị.
- Thiếu tài liệu hóa hoặc tài liệu không đầy đủ
Cho dù có một buổi thảo luận hiệu quả, nếu không được tài liệu hóa một cách chi tiết và có hệ thống, các yêu cầu sẽ dễ dàng bị quên hoặc hiểu sai. Tài liệu không đầy đủ làm cho quá trình bàn giao công việc và kiểm thử trở nên khó khăn.
Hậu quả: Gây ra sự hiểu lầm giữa các bộ phận, các thành viên mới tham gia dự án khó nắm bắt thông tin và quá trình kiểm thử không có cơ sở rõ ràng để đối chiếu.
- Giả định thay vì đặt câu hỏi
Một BA giỏi không bao giờ giả định. Sai lầm phổ biến là dựa vào kinh nghiệm hoặc các dự án tương tự để tự phỏng đoán nhu cầu của khách hàng, thay vì đặt câu hỏi, lắng nghe và xác nhận.
Hậu quả: Sản phẩm có thể đáp ứng được các yêu cầu mà BA giả định nhưng lại bỏ qua các nhu cầu thực tế và độc đáo của khách hàng.
- Bỏ qua các yêu cầu phi chức năng (Non-functional requirements)
Yêu cầu phi chức năng, như hiệu suất, bảo mật, khả năng mở rộng, thường bị xem nhẹ trong giai đoạn đầu. Tuy nhiên, chúng lại quyết định đến chất lượng và khả năng tồn tại lâu dài của sản phẩm.
Hậu quả: Hệ thống có thể hoạt động đúng chức năng nhưng lại chậm, dễ bị tấn công hoặc khó nâng cấp khi cần thiết.
Bài viết khác
Notion
Là một ứng dụng quản lý công việc đa năng, hỗ trợ người dùng trong việc ghi chú, theo dõi nhiệm vụ, quản lý dự án, xây dựng wiki và lưu trữ cơ sở dữ liệu trong cùng một nền tảng. Là một ứng dụng viết ghi chú, nhưng nếu biết cách sử dụng, […]
Security Testing
Hay còn gọi là Kiểm thử bảo mật, là một trong những phần quan trọng trong phát triển phần mềm, nhằm đảm bảo các hệ thống và ứng dụng trong một tổ chức không có bất kỳ sơ hở nào có thể gây ra các tổn thất về an toàn bảo mật. Kiểm thử bảo […]
Non-Functional Testing
Hay còn gọi là Kiểm thử phi chức năng, là kỹ thuật kiểm thử tập trung vào việc đánh giá các khía cạnh phi chức năng của hệ thống. Nó kiểm tra các tham số không được kiểm tra trong Function Testing (kiểm thử chức năng), chẳng hạn như hiệu suất, khả năng sử dụng, […]
Unit Testing
Hay còn gọi là Kiểm thử đơn vị, là một loại kiểm thử phần mềm tập trung vào việc kiểm tra các thành phần hoặc “đơn vị” nhỏ nhất và riêng biệt của mã nguồn. Một đơn vị có thể là một hàm (function), một phương thức (method), một lớp (class) hoặc một module. Mục […]
Smoke Testing
Hay còn gọi là Kiểm thử khói, là một loại kiểm thử phần mềm nhanh chóng, tập trung vào việc xác minh các chức năng cốt lõi và quan trọng nhất của ứng dụng có hoạt động ổn định hay không. Mục đích chính là để kiểm tra xem bản dựng (build) mới của phần […]
Functional Testing
Hay còn gọi là kiểm thử chức năng, là kỹ thuật kiểm tra phần mềm dựa trên từng chức năng để đảm bảo hệ thống đáp ứng đúng yêu cầu đã đặt ra. Đây là dạng kiểm thử hộp đen, trong đó tester không cần quan tâm đến mã nguồn mà chỉ so sánh chức […]
Khoá học lập trình game con rắn cho trẻ em 
