Chương 4 Phân tích yêu cầu

1. Chương 4Phân tích yêu cầu Bộ Môn HTTT - Khoa CNTT - HUI

2. Nội dung • Phântíchyêucầulàgì • Quátrìnhphântíchyêucầu • Tìmkiếmcácyêucầucònthiếu • Phươngphápphântíchyêucầu • Prioritization and Ranking of Requirements • Quality Function Deployment (QFD) Method • Cáckỹ thuậtmôhìnhhóa • Môhìnhhóamụctiêu (Goal modelling) • Môhìnhhóaphântích (analysis modelling) • Tàiliệuđặctảyêucầuphầnmềm SRS Bộ Môn HTTT - Khoa CNTT - HUI

3. Địnhnghĩaphântíchyêucầu • Là quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc. • Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống. • Các mẫu hệ thống cũng có thể được phát triển để mô tả các yêu cầu. Bộ Môn HTTT - Khoa CNTT - HUI

4. Qui trìnhđểcócácchứcnăngcủahệthống Bộ Môn HTTT - Khoa CNTT - HUI

5. HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES) QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý • Định nghĩa tầm nhìn và phạm vi của dự án • Xác định các lớp người dùng • Xác định các đại diện thích hợp của mỗi lớp người dùng • Xác định người ra quyết định về yêu cầu và quy trình ra quyết định của họ • Chọn các kỹ thuật suy luận mà bạn sẽ dùng • Ứng dụng các kỹ thuật suy luận để phát triển các use cases và xếp thứ tựưu tiên các use cases đó cho từng phần của hệ thống BM HTTT Khoa CNTT - HUI

6. HƯỚNG DẪN SUY LUẬN YÊU CẦU(REQUIREMENTS ELICITATION GUIDELINES) QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý • Thu thập thông tin về các thuộc tính chất lượng và các yêu cầu phi chức năng khác từ người dùng. • Phác thảo các use cases từ các yêu cầu chức năng cần thiết • Ràxét các mô tả use-case và các yêu cầu chức năng • Phát triển các mô hình phân tích, nếu cần thiết, để làm sáng tỏ hiểu biếtcủa những người tham gia suy luận về các phần của yêu cầu Bộ Môn HTTT - Khoa CNTT - HUI

7. HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES) QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý • Phát triển và đánh giá các nguyên mẫu giao diện người dùng nhằm trựcquan hoá các yêu cầu chưa được hiểu kỹ • Phát triển các test cases dưới dạng ý tưởng từ các use cases • Sử dụng các test cases để kiểm tra các use cases, các yêu cầu chức năng, các mô hình phân tích, các nguyên mẫu • Lặp lại các bước từ 6 đến 13 trước khi thực hiện thiết kế và xây dựng từng phần của hệ thống BM HTTT Khoa CNTT - HUI

8. Nhiệmvụcủaphântíchyêucầu Trả lời được các câu hỏi sau: • Đầu vào của hệ thống là những gì • Các quá trình cần xử lý trong hệ thống, hay hệ thống phần mềm sẽ phải xử lý những cái gì • Đầu ra: kết quả xử lý của hệ thống là gì • Những ràng buộc trong hệ thống, mối quan hệ giữa đầu vào và đầu ra như thế nào Bộ Môn HTTT - Khoa CNTT - HUI

9. Nhiệmvụcủaphântíchyêucầu Trong quá trình phân tích cần lưu ý đến tính khả thi của dự án: • Khả thi về kinh tế: chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có: • Chi phí: • Mua sắm: thiết bị, vật tư (phần cứng), tư vấn, cài đặt thiết bị, quản lý và phục vụ,… • Chi phí cho khởi công: phần mềm phục vụ cho hệ thống, hệ thống liên lạc(truyền dữ liệu), nhân sự ban đầu, đào tạo, huấn luyện, cải tổ tổ chức cho phù hợp,… Bộ Môn HTTT - Khoa CNTT - HUI

10. Nhiệmvụcủaphântíchyêucầu • Chi phí: • Chi phí liên quan: chi phí nhân công phục vụ thu nhập dữ liệu, sửa đổi, cập nhập hệ thống, chuẩn bị tài liệu,… • Chi phí liên tục là tốn kém nhất gồm: bảo trì, thuê bao, khấu hao phần cứng, chi phí phục vụ cho vận hành,… Lợi nhuận do sử dụng hệ thống • Nhiệm vụ xử lý thông tin: giảm chi phí do xử lý tự động, tăng độ chính xác và kết quả tốt hơn, thời gian trả lời rút ngắn,… • Có được từ hệ thống: thu thập và lưu trữ dữ liệu tự động, đầy đủ, dữ liệu được chuẩn hóa, bảo đảm an toàn và an ninh dữ liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và tìm kiếm nhanh, kết nối và trao đổi diện rộng Bộ Môn HTTT - Khoa CNTT - HUI

11. Nhiệmvụcủaphântíchyêucầu • Khả thi về kỹ thuật: • Rủi ro xây dựng: các phần tử hệ thống (chức năng, hiệu suất) khi thiết kế và phân tích có tương đương hay không? • Có sẵn tài nguyên: có sẵn con người và tài nguyên cần thiết để phát triển hệ thống? • Công nghệ: các công nghệ liên quan cho việc phát triển hệ thống đã có sẵn hay chưa? Bộ Môn HTTT - Khoa CNTT - HUI

12. Nhiệmvụcủaphântíchyêucầu • Khả thi về hợp pháp: • Có sự xâm phạm, vi phạm hay khó khăn nào gây ra khi xây dựng hệ thống hay không • Các phương án: đánh giá về phương án tiếp cận đế việc xây dựng hệ thống Bộ Môn HTTT - Khoa CNTT - HUI

13. Mộtsố lỗikhithuthậpyêucầu • Cố gắng sắp xếp các yêu cầu thu thập được từ hàng tá người dùng sẽ rất khó khăn nếu không có 1 sơ đồ có cấu trúc như use case. • Thu thập yêu cầu từ 1 số ít các đại diện hay từ các khách hàng ồn ào hay cho ý kiến có thể gây rắc rối như: • Bỏ qua các yêu cầu quan trọng từ các loại người dùng khác • Quá chú trọng đến những yêu cầu không tiêu biểu cho nhu cầu của đa số người dùng. • Cách cân bằng tốt nhất: quan tâm đến 1 vài product champion, họ đại diện cho các loại người dùng. Bộ Môn HTTT - Khoa CNTT - HUI

14. Một số lỗi khi thu thập yêu cầu • Trong lúc phân tích yêu cầu, có thể phát hiện thấy phạm vi dự án xác định không đúng • Nếu quá lớn: cần thu thập thêm nhiều yêu cầu để xác định vừa đủ nghiệp vu và nhu cầu khách hàng • Nếu quá nhỏ: khách hàng có thể có các nhu cầu cũng quan trọng nhưng hiện nằm ngoài phạm vi đã xác định của dự án. Việc phân tích sẽ dẫn đến phải chỉnh sửa lại product vision hay project scope. Bộ Môn HTTT - Khoa CNTT - HUI

15. Phát hiện các yêu cầu còn thiếu • Phân rã các yêu cầu mức cao đủ chi tiết để phát hiện chính xác cái gì đang được yêu cầu. • Phải bảo đảm là tất cả các lớp người dùng đều cung cấp dữ liệu. Phải bảo đảm là mỗi use case có ít nhất 1 actor. • Tìm hiểu các yêu cầu hệ thống, use cases, event-response lists, và business rules được chuyển thành yêu cầu chức năng để bảo đảm analyst đã suy dẫn được tất cả chức năng cần thiết. • Kiểm tra cac giá trị biên cho các yều cầu còn thiếu đang được xác định Bộ Môn HTTT - Khoa CNTT - HUI

16. Phát hiện các yêu cầu còn thiếu Ví dụ: Giả sử có 2 yêu cầu như sau: • “If the price of the order is less than $100, the shipping charge is $5.95” • “If the price the order is more than $100, the shipping charge is 5 percent of the total price” Phí chuyển hàng cho 1 hóa đơn có trị giá chính xác 100 là gì? Vẫn chưa xác định được và được xem như 1 yêu cầu còn thiếu Bộ Môn HTTT - Khoa CNTT - HUI

17. Finding Missing Requirements • Biểu diễn thông tin của mọ̣i yêu cầu theo nhiều cách. • Tập hợp các yêu cầu với toán tử Boolean logic (ANDs, ORs, and NOTs) thường không đầy đủ. • Nếu tổ hợp các điều kiện logic mà không có yêu cầu nào tương ứng, developer phải suy nghĩ xem hệ thống nên làm gì Bộ Môn HTTT - Khoa CNTT - HUI

18. Ma trận CRUD • Là 1 cách để tìm yêu cầu bị thiếu. • Viết tắt của Create, Read, Update, and Delete. • Ma trận CRUD cho sự tương quan giữa các action của hệ thống với các thực thể dữ liệu giúp ta biết được mỗi data item được tạo, đọc, cập nhật, xóa ở đâu và như thế nào. Bộ Môn HTTT - Khoa CNTT - HUI

19. Ma trận CRUDL cho hệ thống theo dõi hóa chất Bộ Môn HTTT - Khoa CNTT - HUI CRUDL (Create, Read, Update, Delete, List) Có thể rút ra các suy luận gì từ ma trận trên khi nói đến thực thể Requester ???

20. Ví dụ ma trận CRUDL • Sau khi tạo ma trận CRUDL, cần kiểm tra xem: • Có ký tự nào trong 5 ký tự CRUDL không xuất hiện trong 1 cột nào đó không? • Ví dụ: một cột không có ký tự C  đối tượng được cập nhật mà không bao giờ được tạo ra? Nếu vậy chúng được tạo ra từ đâu? Bộ Môn HTTT - Khoa CNTT - HUI

21. Ví dụ ma trận CRUDL • Cột Requester không chứa D, không có use case nào có thể xóa Requester. Ba khả năng xảy ra: • Deleting a Requester is not an expected function of the Chemical Tracking System. • We are missing a use case that deletes a Requester. • The "Edit Requesters" use case is incorrect. Bộ Môn HTTT - Khoa CNTT - HUI

22. Khi nào thì kết thúc việc thu thập yêu cầu? • Nếu người dùng không thể nghĩ ra thêm 1 use case nào khác. • Nếu người dùng đề nghị các use case mới nhưng thực tế chúng có thể được suy diễn các use case khác. • Nếu người dùng lặp lại các vấn đề đã được xét đến trong các lần thảo luận trước đó. • Nếu các tính chất, yêu cầu người dùng, yêu cầu chức năng mới được đề nghị nằm ngoài phạm vi dự án. Bộ Môn HTTT - Khoa CNTT - HUI

23. Khi nào thì kết thúc việc thu thập yêu cầu? • Nếu các yêu cầu mới được đề nghị có độ ưu tiên thấp. • Nếu người dùng đưa ra các khả năng có thể đôi khi xuất hiện trong sản phẩm. • Tạo một checklist của các miền chức năng chung. Ví dụ checklist bao gồm error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. So sánh định kỳ danh sách này với các chức năng đã xác định của hệ thống. Nếu không tìm thấy lỗ hổng (gap) nào có nghĩa là chúng ta đã phân tích xong. Bộ Môn HTTT - Khoa CNTT - HUI

24. Requirements Elicitation Methods Bộ Môn HTTT - Khoa CNTT - HUI

25. Prioritization and Ranking of Requirements • Prioritization là gán mức độ quan trọng cho yêu cầu bắng cách dùng tag hay label. • Priorities thường được xác định ngay khi bắt đầu dự án, bằng cách xếp loại bằng số hay cụm từ, e.g., 1 có nghĩa là quan trọng nhất và 5 là ít quan trọng nhất. • Ranking là gán 1 thứ tự duy nhất cho mỗi yêu cầu trong 1 nhóm, sao cho không có 2 yêu cầu nào có cùng thứ tự (rank) Bộ Môn HTTT - Khoa CNTT - HUI

26. Prioritization and Ranking of Requirements • Khi cần phải quyết định tính năng cần có trong sản phẩm sẽ phát hành, thì nên dùng kỹ thuật ranking, trong khi đó kỹ thuật prioritization hầu như được dùng khi xác định phạm vi ban đầu của hệ thống. Bộ Môn HTTT - Khoa CNTT - HUI

27. Prioritization and Ranking of Requirements • Khi phân phối bảng câu hỏi (questionnaires ) hay phiếu điều tra (survey) cho khách hàng thường luôn có câu hỏi là nên chọn độ ưu tiên nào cho 1 tính năng nào đó của hệ thống , e.g., more likely to buy the product, no difference, less likely to buy the product. • Một vấn đề chung hay xảy ra khi để khách hàng đánh giá yêu cầu với 3 mức ưu tiên là “high,” “medium,” hay “low” thì một số khách hàng sẽ luôn gán độ ưu tiên là high cho mọi yêu cầu. Bộ Môn HTTT - Khoa CNTT - HUI

28. Các kỹ thuật Prioritization • “Analytic Hierarchy Process” (AHP) • “planning game,” or PG, Bộ Môn HTTT - Khoa CNTT - HUI

29. “Analytic Hierarchy Process” (AHP)(hay pairwise ranking) • Để xếp loại yêu cầu, Stakeholder hay analyst tìm 2 yêu cầu, so sánh chúng và đánh giá chúng để tìm ra cái nào quan trọng hơn. Quy trình này sẽ lập lại cho đến khi tất cả yêu cầu được xếp loại. • Phương pháp này chỉ thích hợp cho những tập hợp yêu cầu không quá lớn. • Vì các stakeholder khác nhau có thể xếp loại yêu cầu rất khác nhau, nên tạo công thức để hợp nhất các tập yêu cầu được đánh giá khác nhau  nên hạn chế các yêu cầu của stakeholder hay các tính năng của sản phẩm. Bộ Môn HTTT - Khoa CNTT - HUI

30. “Planning game” (PG) • Các yêu cầu của stakeholder, các tính năng hay yêu cầu của sản phẩm được phân chia thành 3 tập hợp theo tiêu chuần Kano: • “needed for the system to function,” • “add real value,” • “nice to have but not necessary.” • Thực hiện 1 phân tích rủi ro không chính thức để xác định mức độ thực thi, sau đó quyết định xem nên chọn features hay requirements nào để thực thi. Bộ Môn HTTT - Khoa CNTT - HUI

31. Đặc tính của ranking • Việc xếp loại đánh giá phải dựa vào thực tế, e.g., chi phí và rủi ro luôn có liên quan với nhau. • Một số ngành công nghiệp, có 1 số yêu tố như mối nguy hiểm cho người dùng và công nghệ mới cần phải được khảo sát cùng nhau. Bộ Môn HTTT - Khoa CNTT - HUI

32. Đặc tính của ranking • Ví dụ: kỹ thuật mới cho việc đóng mở cửa sổ của xe hơi dùng cảm biến ánh sáng thay vì dùng công tắc vật lý như trước đây có chi phí thấp được khách hàng đánh giá rất cao, nhưng khi phân tích mối nguy hiểm (hazard analysis ) thì thấy rằng không bảo đảm an toàn, có thể làm cho trẻ con bị thương khi cửa sổ đột ngột mở ra, do đó kỹ thuật này đã không được đưa vào mô hình xe hơi trong năm kế tiếp. Bộ Môn HTTT - Khoa CNTT - HUI

33. Prioritization and ranking • Prioritization : Việc xác định độ ưu tiên ban đầu cho các yêu cầu của stakeholder nên được thực hiện càng sớm càng tốt trong chu kỳ phát triển sản phẩm. • Ranking: Việc xếp loại đánh giá được thực hiện ngay khi các yêu cầu đã thu thập khá đủ như về chi phí, tài nguyên … Bộ Môn HTTT - Khoa CNTT - HUI

34. Quality Function Deployment (QFD) Method • Mục đích: Để tích hợp các nhu cầu của người dùng vào thiết kế sản phẩm. • Trình tự thực hiện: • Tìm ra nhu cầu khách hàng từ những người dù nói ra hay không nói ra, từ những lời nói mập mờ không đầy đủ. • Phát hiện ra các đặc tính “tích cực” làm phấn chấn khách hàng. • Chuyển các đặc tính này thành các đặc tính thiết kế và hành động có thể chuyển giao. • Xây dựng và phân phối sản phẩm/dịch vụ có chất lượng bằng cách tập trung vào các chức năng nghiệp vụ hướng tới mục tiêu chung – thỏa mãn khách hàng. Bộ Môn HTTT - Khoa CNTT - HUI

35. Quality Function Deployment (QFD) Method • Six Sigma là gì? • Assignment 17?? • QFD is often part of a Six Sigma program Bộ Môn HTTT - Khoa CNTT - HUI

36. Process Modeling Technique • Kỹ thuật mô hình hóa quy trình (model driven) phù hợp cho cả elicitation và analysis. • Data flow diagrams (DFDs) • Use case analysis (use case = business process) Bộ Môn HTTT - Khoa CNTT - HUI

37. Data flow diagrams (DFDs) • Được sử dụng trong 1 thời gian dài • Tập trung vào dòng dữ liệu và cấu trúc dữ liệu hơn là vào dịch vụ (services). Bộ Môn HTTT - Khoa CNTT - HUI

38. Bộ Môn HTTT - Khoa CNTT - HUI

39. Bộ Môn HTTT - Khoa CNTT - HUI

40. Use case analysis • Dùng để chỉ ra quy trình nghiệp vụ và mối quan hệ giữa hệ thống và thế giới bên ngoài. • Có thể dùng ngôn ngữ tự nhiên hay bảng biểu để mô tả use case. Bộ Môn HTTT - Khoa CNTT - HUI

41. Use case analysis • Một use case mô tả một dãy các tương tác giữa một hệ thống và một “actor” bênngoài, kết quả là actor hoàn thành một tác vụ (tasks) cho ai đó. • Một actor là mộtngười, một ứng dụng phần mềm khác, một thiết bị phần cứng, một thực thể khácnào đó tương tác với hệ thống để đạt được một mục đích nào đó. Còn được gọi là user role. • VD:use case “Đề nghị một hoá chất” của CTS bao hàm một actor gọi là “Requester” (Người đề xuất). Không có lớp người dùng nào trong CTS gọi là“Requester” cả, cả lớp người dùng các nhà hoá học và lớp người dùng nhân viênkho đều có thể đóng vai trò Requester. Bộ Môn HTTT - Khoa CNTT - HUI

42. USE CASES VÀ KỊCH BẢN SỬ DỤNG (USE CASES AND USAGE SCENARIOS) • Một use case có thể bao hàm một số các tác vụ (tasks) liên kết logic với nhau và một số chuỗi công việc tương tác lẫn nhau để hoàn thành các tác vụ này. • Use case là phương pháp nổi bật trong hướng OO, là tâm điểm của tiến trình RUP. • Use case chuyển hướng việc phát triển yêu cầu thành việc thảo luận xem người dùng cần hoàn thành cái gì (what), ngược lại với phương pháp truyền thống hỏi người dùng muốn hệ thống làm cái gì. • Mục tiêu của phương pháp use case là mô tả tất cả các nhiệm vụ mà người dùng sẽ cần thực thi với hệ thống. Bộ Môn HTTT - Khoa CNTT - HUI

43. USE CASES VÀ KỊCH BẢN SỬ DỤNG (USE CASES AND USAGE SCENARIOS) • Use case là một tập hợp các kịch bản (scenario) thông thường có liên quan nhau. • Một kịch bản được gọi là một tiến trình chuẩn (normal course) của các sự kiện nối tiếp nhau tạo nên use case, nó cũng được gọi là tiến trình chính (main course), tiến trình cơsở (basiccourse), luồng chuẩn (normal flow), hay là “đường yên lành” (happy path). • Tiến trình chuẩn được mô tả bằng cách liệt kê một dãy đối thoại (dialogue elements)hoặc dãy tương tác giữa actor và hệ thống. Bộ Môn HTTT - Khoa CNTT - HUI

44. Bộ Môn HTTT - Khoa CNTT - HUI

45. Bộ Môn HTTT - Khoa CNTT - HUI

46. Use case của hệ thống theo dõi hóa chất Bộ Môn HTTT - Khoa CNTT - HUI

47. Mô tả Use case “request a chemical” Bộ Môn HTTT - Khoa CNTT - HUI

48. Mô tả Use case “request a chemical” Bộ Môn HTTT - Khoa CNTT - HUI

49. Use case vàyêucầuchứcnăng • Không phải yêu cầu chức năng nào cũng được đưa vào UseCase • Khi đặc tả UC nên xác nhận yêu cầu chức năng nào cho phép người dùng hoàn thành mỗi UC • Kiểm tra xem trong tài liệu đặc tả yêu cầu (SRS) đã bao gồm các yêu cầu chức năng được mô tả trong các UC chưa Bộ Môn HTTT - Khoa CNTT - HUI

50. Use case vàyêucầuchứcnăng • Các kịch bản khác trong use case được mô tả là các tiến trình thay thế (alternativecourses). • Các tiến trình thay thế cũng nhằm hoàn thành tác vụ (tasks) nhưng chúngđược dùng để thay thế tiến trình chuẩn khi một số điều kiện xảy ra khiến không thểthực hiện được tiến trình chuẩn. • Tiến trình chuẩn có thể tách thành một tiến trìnhthay thế tại một điểm quyết định nào đó trên dãy đối thoại (dialogue sequence), và nhập lại vào tiến trình chuẩn sau Bộ Môn HTTT - Khoa CNTT - HUI