Phân tích và quản lí yêu cầu phần mềm

Phân tích quản lí yêu cầu phần mềm Xếp hạng ưu tiên Kiểm tra hợp lệ References: C1.Ebook +John Vu (CMU) Độ ưu tiên & thẩm định  Kỹ sư phải chịu ràng buộc thời gian, chi phí chất lượng, khơng thể thực tất yêu cầu  Các yêu cầu phải đánh độ ưu tiền thẩm định để chắn giống với yêu cầu khách hàng  Thẩm định u cầu khó nhóm lập trình phải giải cho thỏa mản tất loại người dùng  Các hoạt động đòi hỏ việc giao tiếp thường xuyên cụ thể nhóm phát triển loại người dùng Requirement Development Các ràng buộc  Với thời gian tài nguyên giới hạn, đội ngũ phát triển phải cung cấp sản phẩm thỏa mãn tất loại người sử dụng:     Các yêu cầu Chi phí giới hạn Lịch làm việc cố định Các ràng buộc khác  Bằng cách đội ngũ phát triển xây dựng hệ thống phù hợp với mục tiêu kinh doanh hài lòng tất loại người dùng?  Trả lời: thực yêu cầu có độ ưu tiên trước, loại bỏ trì hỗn u cầu có độ ưu tiên thấp Requirement Development Kỹ thuật xác định độ ưu tiên  Xem xét tất yêu cầu với stakeholders định độ ưu tiên cách chọn (Đông ý, Không) để xác định:  Must have (Essential - High)  Should have (Desirable- Medium)  Nice to have (Optional - Low)  Must Have: Khơng có u cầu (chức năng), hệ thống khơng phải nghiệp vụ khơng thể giải  Should Have: tính quan trọng để phân biệt hệ thống hệ thống tương tự  Nice to Have: tính tăng cường hệ thống không đáng kể Requirement Development Hoạt động  Thảo luận nhóm (10 phút):  Liệt kê yêu cầu đề tài (đồ án)  Xác định tầm quan trọng yêu cầu:  Must have  Should have  Nice to have Requirement Development Kỹ thuật xác định độ ưu tiên  Độ ưu tiên yêu cầu dựa Important Urgent Important Not Important Urgent High Priority Don't these! Not Urgent Medium Priority Low Priority Requirement Development Kỹ thuật xác định độ ưu tiên  Ước lượng giá trị chi phí yêu cầu  Ưu tiên yêu cầu có giá trị cao tổng giá trị sản phẩm mà chi phí thấp  Các stakeholders ước lượng lợi ích yêu cầu khoáng từ đến (9 cao nhất)  Đội ngũ phát triển ước lượng chi phí thực yêu cầu sử dụng giá trị  Đội ngũ phát triển ước lượng rủi ro thực yêu cầu Requirement Development Kỹ thuật xác định độ ưu tiên  value % (cost % * cost weight) + (risk % * risk weight)  Các thành viên tham gia việc xác định độ ưu tiên bao gồm:  Quản lý dự án điều khiển chính, giải xung đột cần thiết  Đại diện khách hàng cung cấp lợi ích giá trị  Đại diện nhóm phát triển cung cấp thơng tin chi phí rủi ro Requirement Development Thẩm định yêu cầu  Xem xét yêu cầu  Kiểm thử yêu cầu Requirement Development Xem xét u cầu  Khơng thức  A peer deskcheck, bạn mời đồng nghiệp kiểm lại kết bạn  A passaround, bạn mời số đồng nghiệp kiểm lại kết bạn  A walkthrough, tác giả mô tả chờ phản hồi sản phẩm Requirement Development 10 Xem xét yêu cầu  Chính thức – Kiểm tra Requirement Development 11 Kiểm thử yêu cầu  Thiết kế test cases giúp tìm vấn đề mà không cần phải thực thi cụ thể (Beizer 1990)  Nếu bạn bắt đầu phát triển test case sớm u cầu bạn tìm vấn đề sửa chữa với chi phi rẻ Requirement Development 12 Kiểm thử yêu cầu Requirement Development 13 Hoạt động  Thiết kế test case cho use case quan trọng đề tài (đồ án)  Dữ liệu mẫu Requirement Development 14 Thẩm định yêu cầu Thẩm định với Stakeholders  Xác định rõ ràng yêu cầu đáp ứng nhu cầu họ Thẩm định với quản lý:  Để yêu cầu phù hợp với mục đích mục tiêu kinh doanh  Đôi cần stakeholders tham dự Thẩm định với đội ngũ phát triển:  Đề làm rõ số thuộc tính tìm lỗi Requirement Development 15 Thẩm định với Stakeholders  Danh sách yêu cầu xếp với tiêu chí      Ưu tiên Chi phí Rủi ro Biến động Phụ thuộc (quan hệ với yêu cầu khác)  Stakeholders thay đổi thứ tự ưu tiên  Nếu có thể, giải mâu thuẫn yêu cầu stakeholders khác  Các yêu cầu đầy đủ thông qua sở để xác định thay đổi tương lai Requirement Development 16 Thẩm định với quản lý  Đảm bảo yêu cầu đám ứng nhu cầu kinh doanh  Đảm bảo yêu cầu phù hợp với mục đích mục tiêu kinh doanh  Xác minh “nghiệp vụ thực tế” yêu cầu  Tất yêu cầu phải viết thành văn rõ ràng Requirement Development 17 Thẩm định QA  Quality Assurance xem xét yêu cầu:  Xác định thứ không tuân theo chuẩn  Đảm bảo yêu cầu viết theo mẫu hướng dẫn  Đảm bảo yêu cầu viết thành văn rõ ràng đầy đủ  Đảm bảo yêu cầu sử dụng 'intended readership'  Kiểm tra trước thông qua/xác nhận Requirement Development 18 Yêu cầu chấp nhận  Đặc tả yêu cầu tốt khi:  Viết thành văn  Rõ ràng xúc tích  Dễ hiểu  Có thể kiểm thử  Có thể sử dụng  Có thể theo dõi/theo vết  Có thể kiểm chứng Requirement Development 19 Một số câu hỏi kiểm thử          Các yêu cầu hoàn chỉnh chưa? Tất yêu cầu xác định chưa? Các yêu rõ ràng có độ ưu tiên phù hợp chưa? Các yêu cầu có mâu thuẫn khơng? Tất u cầu có giải đầy đủ điều kiện chưa? Tất yêu cầu có giải đầy đủ điều kiện biên chưa? Các u cầu có khả thi khơng? (tồn giải pháp) Các yêu cầu thực ràng buộc biết? Are the requirements sufficient? (i.e., they could be sent to software development team and have a reasonable probability of implementing the product that was desired) Requirement Development 20 Một số câu hỏi kiểm thử           Các trạng thái yêu cầu rõ ràng chưa? Tập hợp yêu cầu có giống với nghiệp vụ stakeholder cần không? Mối quan hệ yêu cầu có xác khơng? Xem xét u cầu chức phi chức chưa? Yêu cầu xác rõ ràng chưa? Yêu cầu đơn giản thực chưa? Yêu cầu kiểm chứng/kiểm thử khơng? u cầu có xác khơng? Các u cầu có thuộc phạm vị dự án không? Câu mang nghĩa nhất? Requirement Development 21 Một số câu hỏi kiểm thử          Yêu cầu đáp ứng stakeholders khơng? u cầu có cần đủ khơng? u cầu hiểu khơng? (khơng cần phải phân tích nghĩa từ) u cầu có giải thích khơng? Các stakeholders có giải thích u cầu giống khơng? u cầu có mâu thuẫn với u cầu khác khơng? u cầu có chứa sai sót thực tế khơng? u cầu có khả thi với cơng nghệ khơng? u cầu có phù hợp với thời gian chi phí định không? Requirement Development 22 ... thái yêu cầu rõ ràng chưa? Tập hợp yêu cầu có giống với nghiệp vụ stakeholder cần khơng? Mối quan hệ u cầu có xác không? Xem xét yêu cầu chức phi chức chưa? Yêu cầu xác rõ ràng chưa? Yêu cầu đơn... mẫu Requirement Development 14 Thẩm định yêu cầu Thẩm định với Stakeholders  Xác định rõ ràng yêu cầu đáp ứng nhu cầu họ Thẩm định với quản lý:  Để yêu cầu phù hợp với mục đích mục tiêu kinh... stakeholders khác  Các yêu cầu đầy đủ thông qua sở để xác định thay đổi tương lai Requirement Development 16 Thẩm định với quản lý  Đảm bảo yêu cầu đám ứng nhu cầu kinh doanh  Đảm bảo yêu cầu phù hợp