Phân tích Yêu cầu Phần mềm

• Bài giảng này trình bày về phân tích yêu cầu phần mềm, bao gồm thu thập, phân tích và làm rõ yêu cầu.
• Mục tiêu là xác định các bên liên quan, thu thập yêu cầu từ họ và xác định các đặc trưng (FEAT) cho các yêu cầu hiện có.
• Nội dung bao gồm vai trò của thu thập, phân tích yêu cầu trong dự án phát triển phần mềm, các kỹ thuật thu thập yêu cầu và xác định các FEAT từ các yêu cầu hiện có.

Kỹ Nghệ Yêu Cầu (Requirements Engineering - RE)

• RE là tập hợp các hoạt động liên quan đến việc xác định và truyền đạt mục tiêu của hệ thống phần mềm trong lĩnh vực nó được sử dụng.
• RE là cầu nối giữa nhu cầu thực tế của người dùng, khách hàng và các bên liên quan khác với hệ thống phần mềm.
• Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án.
• Phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu - RE.

Tỷ Lệ Thành Công và Thất Bại của Dự Án Phần Mềm

• Theo thống kê của Standish Group năm 1994 và 1998, tỷ lệ thành công của các dự án phần mềm tại Mỹ lần lượt là 16% và 26%.
• Những yếu tố hàng đầu dẫn đến thành công là sự tham gia của người dùng, sự hỗ trợ của quản lý cấp cao và các yêu cầu được nêu rõ.
• Yếu tố hàng đầu dẫn đến thất bại bao gồm thiếu sự tham gia của người dùng, các yêu cầu và đặc tả không đầy đủ và các yêu cầu, đặc tả thay đổi.

Các Nguyên Nhân Thất Bại của Dự Án Phần Mềm (Theo Standish Group)

• Yêu cầu không hoàn chỉnh.
• Thiếu sự hợp tác của người dùng.
• Thiếu tài nguyên.
• Mong muốn phi thực tế.
• Thiếu hỗ trợ pháp lý.
• Thay đổi yêu cầu và đặc tả.
• Thiếu hoạch định.
• Hệ thống không còn cần thiết.

Hậu Quả của Sai Sót trong Yêu Cầu

• Lỗi yêu cầu có thể gây tốn kém nếu không được phát hiện và sửa chữa sớm.
• Báo cáo của Bochm và Papaccio (1988) cho thấy chi phí phát hiện lỗi tăng lên theo từng giai đoạn phát triển phần mềm, từ phân tích yêu cầu đến triển khai hệ thống.
• Cần dành thời gian để tìm hiểu kỹ vấn đề và thu thập yêu cầu chính xác trong giai đoạn đầu.

Thu Thập và Xác Định Yêu Cầu

• Đây là khâu kỹ thuật đầu tiên trong quy trình phát triển phần mềm.
• Bên phát triển và khách hàng phối hợp thực hiện.
• Mục tiêu là tìm hiểu xem cần làm gì để giải quyết bài toán.

Phân Tích Yêu Cầu

• Là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra.
• Để phân tích đúng cần định nghĩa rõ "vấn đề", phải xác định:
  • Vấn đề nào cần được giải quyết (phạm vi).
  • Vấn đề ở đâu (ngữ cảnh).
  • Vấn đề của ai (đối tác).
  • Tại sao cần giải quyết (mục tiêu).
  • Hệ thống phần mềm sẽ hỗ trợ như thế nào (kịch bản).
  • Khi nào cần giải quyết (ràng buộc).
  • Điều gì ngăn chặn việc giải quyết (tính khả thi và rủi ro).
• Nhà phân tích phải là chuyên gia trong phạm vi vấn đề, nhanh chóng khoanh vùng và đặt câu hỏi.

Các Thành Phần Cần Làm Rõ Khi Thu Thập Yêu Cầu

• Ranh giới (phạm vi của vấn đề).
• Đối tác (xác định những người làm chủ vấn đề).
• Mục tiêu (định nghĩa các tiêu chuẩn thành công).
• Kịch bản (sử dụng các ví dụ cụ thể để hiểu vấn đề).

Các Hoạt Động Trong Tiến Trình Thu Thập, Quản Lý và Làm Rõ Yêu Cầu:

• Hiểu phạm vi vấn đề.
• Thu thập yêu cầu.
• Phân loại.
• Giải quyết mâu thuẫn.
• Sắp xếp thứ tự ưu tiên.
• Kiểm tra, kiểm chứng các yêu cầu.

Vai Trò của Nhà Phân Tích

• Chuyển các ý tưởng thành các đặc tả yêu cầu.
• Có quan hệ truyền thông với các stakeholder, giúp họ tìm thấy sự khác nhau giữa cái họ muốn và cái họ thực sự cần.
• Thu thập, phân tích, ghi chép và kiểm tra nhu cầu của các stakeholder.
• Là cầu nối giữa cộng đồng khách hàng và đội phát triển phần mềm.
• Đóng vai trò trung tâm trong việc thu thập và phổ biến thông tin.

Các Nguồn Bổ Sung Yêu Cầu (Theo Mô Hình Volere)

• Mong muốn và nhu cầu của các bên liên quan.
• Các mô hình nghiệp vụ.
• Tổ chức và hệ thống hiện tại.
• Mô hình tình huống hiện tại.
• Các tài liệu hiện có.
• Các loại yêu cầu được đề xuất.
• Các yêu cầu có thể tái sử dụng.
• Các mẫu yêu cầu.
• Thư viện tái sử dụng.

Các Khó Khăn Khi Thu Thập Yêu Cầu

• Kiến thức về lĩnh vực (hiếm khi có biểu mẫu rõ ràng, phân tán qua nhiều nguồn, kiến thức mâu thuẫn).
• Kiến thức về ẩn ý (khó mô tả công việc thường làm).
• Thiếu quan sát (quan sát có thể khác với cách làm).
• Thiên vị (người ta không rảnh/ không muốn nói, hoặc thiên vị về tính thuyết phục, quan sát, nhận thức, ký pháp).

Các Kỹ Thuật Thu Thập Yêu Cầu

• Phỏng vấn (đối thoại riêng lẻ với stakeholder).
• Bản câu hỏi thăm dò (gửi đến một tập hợp lớn hơn các stakeholder).
• Hội thảo (các stakeholder tập hợp để tập trung thảo luận).
• Thẻ sự kiện (sử dụng công cụ đồ họa, trực quan để minh họa hành vi hệ thống).
• Phân vai (mỗi thành viên trong nhóm được gán một vai, thường là một trong các người dùng cuối).
• Các phiên làm việc tập trung (story boarding - trình bày các ý tưởng trong phiên tập trung ngắn).
• Sử dụng các biểu đồ quan hệ.
• Mẫu thử (phát triển một mẫu thử để có sự phản hồi).
• Các ca sử dụng (sự tương tác giữa người dùng và hệ thống được trình bày như một chuỗi các bước).
• Phân tích các tài liệu hiện có.
• Quan sát và minh họa nhiệm vụ (xem người dùng thực hiện nhiệm vụ cụ thể).
• Phân tích các hệ thống đang tồn tại.

Phỏng Vấn

• Là một trong những phương pháp suy luận yêu cầu phổ biến nhất.
• Phương pháp phỏng vấn một nhóm các stakeholder đã được lựa chọn
• Cung cấp cơ hội để phát triển thêm các câu hỏi phụ thuộc vào câu trả lời nhận được.
• Là cách tốt để thu thập các yêu cầu về khả năng sử dụng, độ tin cậy, hiệu năng và khả năng hỗ trợ của hệ thống.
• Lưu ý: Cần xác định rõ nhóm stakeholder, chuẩn bị trước câu hỏi, phát biểu lại câu trả lời, không gợi ý câu trả lời, không hỏi nhiều câu trong một câu, không hỏi về các chi tiết cài đặt, không dùng câu hỏi phức tạp, không hỏi câu tiếp theo khi chưa trả lời xong câu trước, hỏi thêm nếu câu trả lời không rõ ràng, không ngắt lời khi người dùng đi lệch hướng và cần nắm bắt mọi yêu cầu.

Bản Câu Hỏi Thăm Dò

• Bản câu hỏi thăm dò là hữu ích nhất nếu có thể hỏi nhiều stakeholder các câu hỏi tương tự và chúng ta không mong đợi sinh thêm các câu hỏi.
• Áp dụng được với nhiều đối tượng thuộc các nhóm Stakeholder hơn so với phỏng vấn trực tiếp và hội thảo.
• Tuy nhiên, do các bản câu hỏi thăm dò quá cấu trúc và không tác động lẫn nhau, chúng ta có ít sự giám sát về các kết quả thu được.
• Lợi ích của bản câu hỏi thăm dò là chúng có thể được gửi qua email.

Hội Thảo Yêu Cầu

• Stakeholder được lựa chọn gặp gỡ nhóm dự án
• Thảo luận tập trung trong một khoảng thời gian. Người phân tích hệ thống đóng vai trò là người điều hành cuộc hội thảo.
• Cung cấp cơ hội để áp dụng các kỹ thuật suy luận yêu cầu khác nhau.
• Mục đích có thể là thu thập các yêu cầu mới hoặc xét duyệt, phân loại và đánh thứ tự ưu tiên cho các yêu cầu đang tồn tại.

Phân Vai

• Các thành viên trong nhóm được gán cho các vai trò liên quan đến hệ thống được xây dựng.
• Các vai trò này thường là người dùng hệ thống hoặc các tác nhân khác tương tác với hệ thống.

Các Phiên Làm Việc Tập Trung

• Những người tham gia tập hợp lại trong thời gian ngắn.
• Người chỉ đạo thông báo mục đích của phiên
• Các yêu cầu mới có thể sinh ra liên quan đến một số phần của hệ thống hoặc liên quan đến việc giải quyết vấn đề
• Mỗi người tham gia cung cấp một số ý kiến và các ý kiến không được phép bình phẩm.
• Sau khi mọi ý kiến đã được viết, chọn ngẫu nhiên hoặc tạo sự kết hợp các ý kiến này.
• Việc các yêu cầu và các thiết kế (giải pháp cho vấn đề) được thảo luận cùng thời điểm là khá thường xuyên

Phân Tích Các Tài Liệu Hiện Có

• Các yêu cầu có thể được trích rút từ các tài liệu.
• Để phân tích, đọc tài liệu và đánh dấu các câu hình thành nên một yêu cầu.

Quan Sát Và Mô Phỏng Nhiệm Vụ

• Người sử dụng không thể phát biểu bằng từ ngữ các chi tiết về nhiệm vụ của họ, người dùng có thể mô phỏng nhiệm vụ, trong khi người phân tích ghi chú và tạo các quan sát về cách mà nhiệm vụ này được thực hiện.
• Nhà phân tích viên có thể hỏi người dùng một nhiệm vụ cụ thể, và người dùng có thể minh họa để giải thích.

Mục Tiêu của Thu Thập Yêu Cầu

• Xác định đầy đủ và chính xác các stakeholders.
• Lựa chọn phương pháp thu thập các yêu cầu đối với từng nhóm stakeholder.
• Thu thập các yêu cầu và đưa vào báo cáo.

Xác Định Các FEAT (Đặc Trưng) từ Yêu Cầu Hiện Có

• Các Feat được bắt nguồn từ yêu cầu của các bên liên quan và cần được truy vết nguồn gốc.
• Các yêu cầu thu thập từ các bên liên quan không nhất thiết phải có các thuộc tính của một yêu cầu tốt. Việc lấy các Feat từ các yêu cầu của các bên liên quan sẽ tạo cơ hội để loại bỏ/ sửa chữa các yêu cầu chưa tốt.

Các Kỹ Thuật Xác Định Các FEAT

• Sao chép (nếu yêu cầu gốc không cần thay đổi).
• Phân tách (chia yêu cầu phức tạp thành các yêu cầu đơn giản hơn).
• Làm rõ ràng, dễ hiểu (diễn giải yêu cầu mập mờ).
• Kết hợp (gộp các yêu cầu dư thừa).
• Loại bỏ (xóa các yêu cầu không khả thi, không cần thiết).
• Sửa chữa (sửa lỗi chính tả, ngữ pháp).
• Thêm chi tiết (làm rõ yêu cầu, đặc biệt là để có thể kiểm thử).
• Thống nhất (sử dụng từ vựng thống nhất).
• Làm cho đầy đủ (thêm thông tin để hoàn thiện yêu cầu).
• Khái quát hóa (làm cho yêu cầu trừu tượng hơn).