Bài giảng Công nghệ phần mềm - Yêu cầu phần mềm

g workspace của LIBSYS. Nếu không, xóa tài liệu và hoàn lại chi phí cho người dùng. Other activities: Song song download các tài liệu khác nhau. System state on completion: Người dùng đang ở trạng thái đăng nhập. Nếu tài liệu có gắn cờ 'print-only' thì nó đã bị xóa khỏi LIBSYS workspace. Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Use case Ca sử dụng (use-case) là một kĩ thuật kiểu kịch bản bằng ngôn ngữ UML Chỉ rõ các actor trong một tương tác và Mô tả chính tương tác đó. Một bộ ca sử dụng có thể mô tả được tất cả các tương tác có thể đối với hệ thống. Có thể dùng các sơ đồ tuần tự (sequence diagram) để bổ sung chi tiết cho các ca sử dụng Minh họa chuỗi xử lý sự kiện. Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville use-case in tài liệu In tài liệu Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville LIBSYS use case Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Article printing Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Print article sequence Ca sử dụng – Use case Use case: Là một tập các kịch bản tương tác giữa một hoặc vài actor với hệ thống nhằm thực hiện một mục tiêu chung Sơ đồ use case (đồ họa) Sơ đồ mô tả tổng quan các ca sử dụng của một hệ thống và ai dùng chức năng nào Mô tả chi tiết use case (văn bản) Mô tả chi tiết tương tác giữa người dùng và hệ thống trong một tập các kịch bản * Ví dụ Use Case: Travel Agency use case list available flights Tên: list available flights Mô tả: người dùng xem danh sách các chuyến bay có thể đặt Actor: người dùng Kịch bản chính: người dùng nhập thông tin về thành phố cần đến, ngày đi và ngày đến hệ thống cung cấp một danh sách các chuyến bay phù hợp kèm theo giá vé và booking number Kịch bản phụ: 1a. Dữ liệu vào không đúng 2. Hệ thống báo lỗi và kết thúc, use case quay lại từ đầu 2.a. Không có chuyến bay nào phù hợp 	3. Use case quay lại từ đầu Ghi chú: Dữ liệu vào là đúng nếu tên thành phố đúng, ngày đi và ngày đến là các ngày hợp lệ, ngày đi sớm hơn ngày đến, ngày đến muộn hơn thời điểm hiện tại ít nhất 2 ngày, và ngày đi không muộn hơn một năm kể từ hiện tại * Ví dụ Use Case: Travel Agency use case list available flights người dùng nhập thông tin về thành phố cần đến, ngày đi và ngày đến hệ thống cung cấp một danh sách các chuyến bay phù hợp kèm theo giá vé và booking number 1a. Dữ liệu vào không đúng 2. Hệ thống báo lỗi và kết thúc, use case quay lại từ đầu 2.a. Không có chuyến bay nào phù hợp 	3. Use case quay lại từ đầu * 1 2 1a 2a 3 Sơ đồ Use case * Các loại sơ đồ use case Business use case Một phần của tài liệu yêu cầu người dùng Mô tả chức năng từ góc nhìn của người dùng System use case Một phần của tài liệu kĩ thuật của đội phát triển Mang tính kĩ thuật và chi tiết hơn Tập trung vào mô tả những gì cần cài đặt * Yêu cầu chức năng của TravelAgency: các business use case * Yêu cầu chức năng của TravelAgency: System use case, phần 1: manage trip * Yêu cầu chức năng của TravelAgency: System use case, phần 2: plan trip * Yêu cầu chức năng của TravelAgency: System use case, phần 3: manage flights * Yêu cầu chức năng của TravelAgency: System use case, phần 4: manage hotels * Mẫu tài liệu mô tả use case Mẫu dùng cho môn học này Tên: tên của use case Mô tả: Mô tả ngắn gọn của use case – mục tiêu của ca sử dụng Actor: một hoặc vài actor – nhân tố tương tác với hệ thống Tiền điều kiện: các điều kiện hệ thống cần thỏa mãn để use case có thể hoạt động Kịch bản chính: Mô tả chuỗi tương tác chính giữa actor và hệ thống Chú ý! Chỉ nên mô tả hệ thống từ góc nhìn của người sử dụng Các kịch bản phụ: Có thể chứa các kịch bản thất bại Ghi chú: Dùng cho tất cả những gì cần thiết nhưng lại không phù hợp với các thể loại trên * Travel Agency. Mô tả chi tiết use case: list available flights Tên: list available flights Mô tả: người dùng xem danh sách các chuyến bay có thể đặt Actor: người dùng Kịch bản chính: người dùng nhập thông tin về thành phố cần đến, ngày đi và ngày đến hệ thống cung cấp một danh sách các chuyến bay phù hợp kèm theo giá vé và booking number Kịch bản phụ: 1a. Dữ liệu vào không đúng 2. Hệ thống báo lỗi và kết thúc, use case quay lại từ đầu 2.a. Không có chuyến bay nào phù hợp 	3. Use case quay lại từ đầu Ghi chú: Dữ liệu vào là đúng nếu tên thành phố đúng, ngày đi và ngày đến là các ngày hợp lệ, ngày đi sớm hơn ngày đến, ngày đến muộn hơn thời điểm hiện tại ít nhất 2 ngày, và ngày đi không muộn hơn một năm kể từ hiện tại * Kịch bản Tương tác giữa một actor và hệ thống Người dùng tác động vào hệ thống Hệ thống phản ứng Các hiệu ứng quan trọng đối với người dùng / người dùng thấy Hoạt động bên trong của hệ thống không phải là một phần của tương tác * Travel Agency. Mô tả chi tiết use case: cancel trip Tên: cancel trip Mô tả: người dùng hủy một chuyến đi đã đặt Actor: người dùng Tiền điều kiện: Chuyến đi đã được đặt chỗ Ngày đầu tiên của thời gian đặt phòng khách sạn hoặc chuyến bay phải muộn hơn thời điểm hiện tại ít nhất 1 ngày. Kịch bản chính: Người dùng chọn chuyến đi để hủy Hệ thống thông báo chi phí của việc hủy chuyến đi Chuyến đi được chọn sẽ bị hủy sau khi người dùng khẳng định việc hủy * Travel Agency. Mô tả chi tiết use case: plan trip Use case này chứa (include) các use case khác Tên: plan trip Mô tả: người dùng lập kế hoạch một chuyến đi bao gồm khách sạn và các chuyến bay Actor: người dùng Kịch bản chính: Lặp đi lặp lại hoạt động bất kì trong danh sách sau cho đến khi xong 	1. list available flights (use case) 	2. add flight to trip (use case) 	3. list available hotels (use case) 	4. add hotel to trip (use case) 	5. list trip (use case) 	6. delete hotel from trip (use case) 	7. delete flight from tip (use case) * Travel Agency. Mô tả chi tiết use case: save trip Tên: save trip Mô tả: người dùng đặt tên cho chuyến đi hiện hành và lưu lại cho sử dụng sau này Actor: người dùng Tiền điều kiện: chuyến đi hiện hành không rỗng Kịch bản chính: 	1. Người dùng nhập tên cho chuyến đi Các kịch bản phụ: 	1: tên nhập không hợp lệ 	2: thông báo cho người dùng và kết thúc use case 	1: tên trùng với tên của một chuyến khác 	2: hỏi người dùng xem có nên ghi đè lên chuyến đã ghi lần trước hay không 	3a: nếu người dùng đồng ý, ghi đè lên chuyến cũ 	3b: nếu người dùng không đồng ý, kết thúc use case * Use case và ranh giới hệ thống Use case và actor được xác định tùy theo ranh giới hệ thống * List flights Search for fights FRONT END BACK END TRAVEL AGENCY Biên hệ thống: TravelAgency Biên hệ thống: Front End List flights TRAVEL AGENCY List flights FRONT END BACK END Người dùng Người dùng Người dùng Nội dung chính Yêu cầu phần mềm là gì? Tầm quan trọng của yêu cầu phần mềm trong quá trình phát triển phần mềm Kĩ nghệ yêu cầu Nghiên cứu khả thi Thu thập và phân tích yêu cầu Làm tài liệu yêu cầu Thẩm định yêu cầu * Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Thẩm định yêu cầu (Requirement validation) quan tâm đến việc chứng tỏ rằng các yêu cầu định nghĩa được hệ thống mà khách hàng thực sự muốn. Chi phí của lỗi yêu cầu cao đến mức công đoạn thẩm định rất quan trọng Việc sửa một lỗi yêu cầu sau khi đã bàn giao phần mềm có thể tốn kém gấp 100 lần chi phí cho việc sửa một lỗi cài đặt. Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Các tiêu chí cho thẩm định Hiệu lực – Validity Hệ thống có cung cấp những chức năng phục vụ tốt nhất yêu cầu của khách hàng hay không? Nhất quán – Consistency Có những yêu cầu nào xung đột nhau không? Đầy đủ – Completeness Có đủ các chức năng mà khách hàng đòi hỏi hay không? Thực tế – Realism Có thể cài đặt các yêu cầu trong phạm vi công nghệ và ngân sách cho phép hay không? Kiểm định được – Verifiability Có cách kiểm tra các yêu cầu xem chúng đã được thỏa mãn chưa hay không? Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Kĩ thuật thẩm định yêu cầu Duyệt yêu cầu – Requirements reviews Đọc và phân tích lại một cách có hệ thống (không dùng chương trình tự động). Phiên bản thử nghiệm – Prototyping Dùng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu (Chương 17) Tạo các ca kiểm thử (test case) Viết các test dành cho các yêu cầu để kiểm tra khả năng kiểm thử được. Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Quản lý yêu cầu Yêu cầu phần mềm luôn luôn thay đổi! Môi trường doanh nghiệp và kĩ thuật thay đổi Phần cứng mới  giao diện mới. Luật thay đổi, nhu cầu doanh nghiệp thay đổi  thay đổi chức năng Khách hàng, người sử dụng thay đổi Thay đổi chức năng Xung đột giữa các yêu cầu mới nảy sinh, và giữa yêu cầu mới với yêu cầu cũ Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Quản lý yêu cầu Để quản lý yêu cầu, cần xác định Định danh yêu cầu: Mỗi yêu cầu có định danh riêng để tiện cho việc tham chiếu giữa các yêu cầu và lần vết Quy trình quản lý thay đổi: các hoạt động đánh giá ảnh hưởng và chi phí của thay đổi Chính sách lần vết: cách ghi lại và lưu trữ quan hệ giữa các yêu cầu và giữa mỗi yêu cầu với thiết kế tương ứng với nó Công cụ hỗ trợ: hỗ trợ thực hiện các công việc trên một cách có hiệu quả. CASE tool, spreadsheet, cơ sở dữ liệu.... Quản lý thay đổi Xác định vấn đề Phân tích vấn đề, đặc tả thay đổi Phân tích thay đổi & đánh giá chi phí Thực hiện thay đổi Yêu cầu đã chỉnh sửa Trần Minh Châu dịch từ nguyên bản Software Engineering 8th Ed. của Ian Sommerville Quản lý thay đổi yêu cầu Nên áp dụng cho tất cả các thay đổi được đề xuất đối với bộ yêu cầu. Các giai đoạn chính Phân tích vấn đề: Thảo luận về vấn đề của các yêu cầu và đề xuất thay đổi; Bổ sung chi tiết; Chốt lại những điểm sẽ thay đổi. Phân tích thay đổi và đánh giá chi phí. Đánh giá hiệu ứng của thay đổi đối với các yêu cầu khác; Ra quyết định có thực hiện thay đổi hay không. Thực hiện thay đổi. Cập nhật tài liệu yêu cầu và các tài liệu khác để thực hiện thay đổi đã xét. Bài tập lớn Thu thập và phân tích yêu cầu *