Bài giảng Thu nhận yêu cầu - Chương 4: Phân tích yêu cầu có cấu trúc gồm 8 phần cung cấp cho người học các kiến thức: Phân tích yêu cầu là gì, quá trình phân tích yêu cầu, tìm kiếm các yêu cầu còn thiếu, phương pháp phân tích yêu cầu, prioritization and Ranking of Requirements, quality Function Deployment (QFD) Method, các kỹ thuật mô hình hóa, tài liệu đặc tả yêu cầu phần mềm SRS. Mời các bạn tham khảo.
Phân tich yêu câu Bô Môn HTTT - Khoa CNTT HUI Chương • • • • • • • Phân tích u cầu Q trình phân tích u cầu Tìm kiếm u cầu còn thiếu Phương pháp phân tích yêu cầu Prioritization and Ranking of Requirements Quality Function Deployment (QFD) Method Các kỹ thuật mô hình hóa • Mơ hình hóa mục tiêu (Goal modelling) • Mô hình hóa phân tích (analysis modelling) • Tài liệu đặc tả yêu cầu phần mềm SRS Bô Môn HTTT - Khoa CNTT HUI Nơi dung • Là q trình suy ḷn u cầu hệ thống thơng qua quan sát hệ thống tại, thảo luận với người sử dụng, phân tích cơng việc • Việc có thể liên quan với việc tạo hay nhiều mơ hình khác Nó giúp phân tích viên hiểu biết hệ thống • Các mẫu hệ thống có thể phát triển để mô tả yêu cầu Bô Môn HTTT - Khoa CNTT - HUI Định nghĩa phân tich yêu câu Bô Môn HTTT - Khoa CNTT - HUI Qui trình để có chức hệ thống QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 1.Định nghĩa tầm nhìn phạm vi dự án 2.Xác định lớp người dùng 3.Xác định đại diện thích hợp lớp người dùng 4.Xác định người quyết định yêu cầu quy trình quyết định họ 5.Chọn kỹ thuật suy luận mà bạn dùng 6.Ứng dụng kỹ thuật suy luận để phát triển use cases xếp thứ tự ưu tiên use cases đó cho phần hệ thống BM HTTT Khoa CNTT - HUI 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 Ý 7.Thu thập thơng tin thuộc tính chất lượng yêu cầu phi chức khác từ người dùng 8.Phác thảo use cases từ yêu cầu chức cần thiết 9.Rà xét mô tả use-case yêu cầu chức 10.Phát triển mơ hình phân tích, nếu cần thiết, để làm sáng tỏ hiểu biết người tham gia suy luận phần yêu cầu Bô Môn HTTT - Khoa CNTT - HUI 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 Ý 11.Phát triển đánh giá nguyên mẫu giao diện người dùng nhằm trực quan hoá yêu cầu chưa hiểu kỹ 12.Phát triển test cases dạng ý tưởng từ use cases 13.Sử dụng test cases để kiểm tra use cases, u cầu chức năng, mơ hình phân tích, nguyên mẫu 14.Lặp lại bước từ đến 13 trước thực thiết kế xây dựng phần hệ thống BM HTTT Khoa CNTT - HUI HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES) Trả lời câu hỏi sau: •Đầu vào hệ thống •Các q trình cần xử lý hệ thống, hay hệ thống phần mềm phải xử lý •Đầu ra: kết xử lý hệ thống •Những ràng buộc hệ thống, mối quan hệ đầu vào đầu thế Bô Môn HTTT - Khoa CNTT - HUI Nhiệm vụ phân tich yêu câu Nhiệm vụ phân tich yêu câu •Khả thi 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ý 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 liệu), nhân 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 Trong trình phân tích cần lưu ý đến tính khả thi dự án: Nhiệm vụ phân tich yêu câu • Chi phí: • Chi phí liên quan: chi phí nhân công phục vụ thu nhập liệu, sửa đổi, cập • Chi phí liên tục tốn 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 sử dụng hệ thống • Nhiệm vụ xử lý thơng tin: giảm chi phí xử lý tự đông, tăng đô chính xác kết tốt hơn, thời gian trả lời rút ngắn,… • Có từ hệ thống: thu thập lưu trữ liệu tự đông, đầy đủ, liệu chuẩn hóa, bảo đảm an toàn an ninh liệu, tương thích chuyển Bô Môn HTTT - Khoa CNTT - HUI nhập hệ thống, chuẩn bị tài liệu,… đổi bô phận, truy cập tìm kiếm nhanh, kết nối trao đổi diện rông 10 • Trái với Throwaway Prototype, evolutionary prototype cung cấp tảng cấu trúc vững chắc để xây dựng sản phẩm tăng, tiến dần yêu cầu nên rõ ràng theo thời gian • Evolution prototype thành phần mơ hình phát triển phần mềm dạng xoắn ốc chu trình phát triển phần mềm hướng đối tượng Bô Môn HTTT - Khoa CNTT - HUI Evolutionary Prototypes 11 • Evolutionary prototype phải xây dựng có mã chương trình từ đầu, nhiều thời gian throwaway prototype hai mô chức hệ thống • Evolution prototype phải thiết kế cho phát triển mở rộng sau này, vậy developers phải ý đến kiến trúc SW Bô Môn HTTT - Khoa CNTT - HUI Evolutionary Prototypes 11 Bô Môn HTTT - Khoa CNTT - HUI Evolutionary Prototypes 11 Bô Môn HTTT - Khoa CNTT - HUI So sánh Prototypes 11 • Paper prototype cách đơn giản, nhanh, rẻ kỹ thuật thấp • Thường dùng cho vòng lặp trình thiết kế, phác họa tay giấy • Designer phác thảo ý tưởng giấy không bận tâm đến việc control xuất xác đâu trơng thế • A preson plays the role of the computer while a user walks through an evaluation scenario The user can judge whether that is indeed the expected response and whether the item displayed contains the correct elements Bô Môn HTTT - Khoa CNTT - HUI Paper Prototypes 11 • Có nhiều cơng cụ thích hợp cho việc xây dựng election throwaway prototype: • Programming language such as: MS Visual Basic, IBM VisualAge Smaltalk, and Inprise Delphi • Scripting language as Perl, Python, and Rexx • Commercial prototyping tool kits, screen painters, and graphical user interface builders • Drawing tools such as microsoft Visio and Microsoft PowerPoint Bô Môn HTTT - Khoa CNTT - HUI Electronic Prototypes 11 • Để đánh giá hiệu horizontal prototypes nên tạo kịch (script) trước để hướng dẫn người dùng thực bước đặt câu hỏi thu thập thơng tin như: • Does the prototype implement the functionality in the way you expected? • Is any functionality missing? • Can you thing of any error condition that the prototype doesn’t address? • Are any unnecessary functions present? • How logical and complete does the navigation seem to you? • Were any tasks overly complex? Bơ Môn HTTT - Khoa CNTT - HUI Đánh giá Prototypes 11 • Phải đảm bảo chọn người đánh giá, nên bao gồm đại diện người dùng thành thạo kinh nghiệm • Quan sát người dùng lúc họ làm việc với prototype tốt chỉ đơn giản hỏi họ nghĩ prototype Có thể phát nhiều điều từ quan sát Bô Môn HTTT - Khoa CNTT - HUI Đánh giá Prototypes 11 • Yêu cầu người đánh giá chia sẻ suy nghĩ họ làm việc với prototype, có thể phát yêu cầu còn thiếu Nên tạo môi trường thân thiện để người đánh giá tự trình bày ý kiến họ • Lưu trữ lại kết đánh giá prototype • Với horizontal prototype: dùng thông tin để điều chỉnh lại yêu cầu SRS • Với verticak prototype: nên xem xét mâu thuẫn SRS prototype Bô Môn HTTT - Khoa CNTT - HUI Đánh giá Prototypes 12 • The biggest risk is that a stateholder will see a running prototype and conclude that the product is nearly completed • Đùng ngại việc phải giao sản phẩm “chưa hoàn chỉnh” mà bỏ qua việc tạo prototype Phải xác định rõ với xem prototype nó sản phẩm cuối Bô Môn HTTT - Khoa CNTT - HUI Các rủi ro phương pháp Prototyping 12 • Cách khắc phục: • Dùng paper prototype • DÙng công cụ prototype khác hẳn với công cụ dùng để phát triển phần mềm, tránh áp lực người đánh giá”kết thúc sớm bàn giao” • Để prototype trơng có vẻ nháp, không cần trau chuốt Bô Môn HTTT - Khoa CNTT - HUI Các rủi ro phương pháp Prototyping 12 • Người dùng q trọng đến hình thức, giao diện thế hoạt động sao, quên tập trung vào yêu cầu hệ thống • Người dùng nghĩ việc thực thi sản phẩm cuối giống việc thực thi prototype • Ví dụ: nếu người dùng thấy prototype đáp ứng tức truy vấn DB mô phỏng, họ có thể nghĩ thực thi sản phẩm phần mềm nhanh tương tự với CSDL phân tán cực lớn Bô Môn HTTT - Khoa CNTT - HUI Các rủi ro phương pháp Prototyping 12 • Các hoạt động làm prototype có thể nhiều công sức thời gian đội phát triển Và hết thời gian, có họ phát hành prototype sản phẩm cuối, vội vã đưa sản phẩm không dự định Do just enough prototype to test the hypothesis, answer the questions, and refine your understending of the requirements Bô Môn HTTT - Khoa CNTT - HUI Các rủi ro phương pháp Prototyping 12 • Nên đưa nhiệm vụ prototyping vào kế hoạch, lập lịch biểu tài nguyên để phát triển, đánh giá chỉnh sửa prototype • Xác định mục đích prototype trước bắt đầu • Nên lập kế hoạch cho nhiều prototype Hiếm có kết lần thử • Tạo throwaway prototypes thật nhanh rẻ • Khơng nên đưa việc kiểm tra liệu đầu vào, quản lý lỗi, mã hóa liệu…vào throwaway prototype Bô Môn HTTT - Khoa CNTT - HUI Prototyping Success Factors 12 • Sử dụng liệu hợp lý prototype screen display and reports Người đánh giá không còn ý đến liệu tập trung vào việc xem xét hoạt động hệ thống • Đừng mong đợi prototype có thể thay thế hoàn toàn SRS Những chức thu thập từ prototype nên ghi chép lại SRS Các hình khơng thể đưa định nghĩa chi tiết liệu tiêu chuẩn đánh giá, mối quan hệ liệu,… Bô Môn HTTT - Khoa CNTT - HUI Prototyping Success Factors 12 ... Môn HTTT - Khoa CNTT - HUI • Use case tập hợp kịch (scenario) thông thường có liên quan 43 44 Bô Môn HTTT - Khoa CNTT - HUI 45 Bô Môn HTTT - Khoa CNTT - HUI Bô Môn HTTT - Khoa CNTT - HUI Use... Bơ Mơn HTTT - Khoa CNTT - HUI Khi nao kêt thuc việc thu thâp yêu câu? 23 Bô Môn HTTT - Khoa CNTT HUI Requirements Elicitation Methods 24 • Prioritization gán mức độ quan trọng cho yêu cầu bắng... dùng Bô Môn HTTT - Khoa CNTT - HUI Môt số lôi thu thâp yêu âugắng sắp xếp yêu cầu thu thập từ hàng •cCố 13 phạm vi dự án xác định khơng • Nếu quá lớn: cần thu thập thêm nhiều yêu cầu để xác