Lý do thay đổi yêu cầu phần mềm
. Các tác nhân bên ngoài: thay đổi vấn đề, người sử dụng thay đổi quyết định của mình, môi trường bên ngoài thay đổi, hệ thống mới tồn tại.
. Các tác nhân bên trong: chúng ta đã không hỏi những người đúng các câu hỏi đúng tại thời gian đúng trong suốt quá trình tập hợp yêu cầu ban đầu. Chúng ta đã không tạo ra một tiến trình thực hành để giúp đỡ việc quản lý thay đổi yêu cầu mà thông thường xảy ra theo chiều hướng tăng tiến.
Quá trình để quản lý thay đổi:
1.Đoán nhận những thay đổi tất yếu, và lên kế hoạch xử lý nó.. 2.Thiết lập ranh giới các yêu cầu.
3.Thiết lập một kênh đơn để kiểm soát sự thay đổi..
4.Sử dụng một hệ điều khiển thay đổi để nắm bắt những thay đổi.. 5.Quản lý sự thay đổi theo phân cấp.
Quản lý Cấu hình các yêu cầu :
1. Ngăn ngừa những yêu cầu không hợp pháp và các phá hoại tiềm tàng hay những yêu cầu thay đổi linh tinh.
2. Bảo đảm việc duyệt lại những tài liệu về yêu cầu.
3.Làm thuận tiện việc lấy lại và/ hoặc xây dựng lại những phiên bản trước của tài liệu.
4. Hỗ trợ quản lý, tổ chức ranh giới “giải thoát kế hoạch” cho những cải tiến hoặc cập nhập ngày càng tăng của hệ thống.
5.Ngăn chặn đồng thời việc cập nhật tài liệu hay xung đột và không cho phép cập nhập những tài liệu khác nhau cùng lúc.
Các câu từ 37- 39 không chắc chắn:
Tớ không chắc chắn về 3 câu hỏi của thầy: Phân biệt 3 câu hỏi? Thầy hỏi chỉ tập trung vào phần Requirements trong EA, hay việc ứng dụng EA vào đặc tả, mô hình , phân tích yêu cầu người dùng nói chung ( tức Usecases + Requirements )
Có 2 hướng:
• Nêu cả Requirements và Usecases: Khá phù hợp cho câu 38 ( Nếu dựa trên câu 32). Nếu trả lời tóm tắt thì khó tạo khác biệt giữa 3 câu. Còn nói chi tiết thì khá dài và mất công.
• Chỉ tập trung chi tiết phần Requirement: trình bày ở dưới.