Đề cương chi tiết phân tích yêu cầu phần mềm

Đề cương ôn thi cuối kì học phần phần tích yêu cầu phần mềm.

Mục lục CHƯƠNG I TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM VÀ QUY TRÌNH Các quan điể m khác đinh ngḥia về yêu cầ u phầ n mề m Đinh ngḥia ̃ chuẩn theo IEEE or slide Hãy nêu chất yêu cầu phần mềm Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng  Bản chất Bản chất yêu cầu phần mềm mâu thuẫn Sự mâu thuẫn thể ý niệm yêu cầu phần mềm xuất phát từ khách hàng từ người sử dụng • Các yêu cầu phần mềm xuất phát từ người sử dụng người phát triển phần mềm thông thường trừu tượng, mức cao • Ngược lại yêu cầu phần mềm mô tả từ người phát triển người sử dụng lại mức thấp, chi tiết người sử dụng hiểu hết Vì mâu thuẫn nên IEEE 1997 đưa định nghĩa yêu cầu phần mềm nhìn từ góc độ người sử dụng người phát triển, yêu cầu cần đúc kết thành văn để thống bên Định nghĩa IEEE: • Điều kiện hay khả sản phẩm phần mềm cần thiết cho người sử dụng để giải vấn đề để giải mục tiêu (1) • Điều kện hay khả cần phải thỏa mãn cần có hệ thống thành phần hệ thống nhằm đáp ứng hợp đồng, tiêu chuẩn đặc tả tài liệu khác.(2) • Văn thể điều kiện khả thể (1) (2)  Định nghĩa từ khách hàng Định nghĩa IEEE yêu cầu phần mềm từ phía khách hàng: • Điều kiện hay khả sản phẩm phần mềm cần thiết cho người sử dụng để giải vấn đề để giải mục tiêu (1) Hãy nêu thói quen tốt thói quen không tốt công nghệ học yêu cầu phần mềm  Thói quen tốt: • Luôn hỏi lại người dùng chưa hiểu hết yêu cầu họ • Không khảo sát yêu cầu với loại người sử dụng, mà phải bao quát tất người sử dụng • Đánh dấu điểm chưa rõ đặc tả: Đôi thiếu số thông tin yêu cầu phần mềm, cần thảo luận với người sử dụng để hiểu chi tiết Tất chỗ đc đánh đấu TBD( Tobe determined) => Tất TBD phải đc giải trước bắt đầu trình phân tích xây dựng phần mềm  Thói quen không tốt: • Tự nghĩ yêu cầu người dùng, hay tự cho người dùng phần mềm • Người sử dụng chuyên viên lĩnh vực nên có thói quen nghĩ tất phân tích viên đề chuyên gia lĩnh vực => Đưa yêu cầu ngắn gọn mà ko miêu tả kỹ lưỡng chúng Nêu các thuôc tính chất lương của yêu cầu phần mề m Quan ̣ giữa các thuôc tính chất lương Nêu các phương pháp phân loai yêu cầ u phầ n mềm Phân tích đăc điể m của từng phân loai Mô tả Quy trình công nghệ học yêu cầu phần mềm (Requirement Engineering Process) Quy trình công nghệ học phần mềm chia thành giai đoạn: Phát triển yêu cầu Quản lý yêu cầu Trong Phát triển yêu cầu chia làm giai đoạn nhỏ hơn: Phát yêu cầu, Phân tích yêu cầu, Đặc tả yêu cầu kiểm thử yêu cầu - Trong Phát triển yêu cầu chia làm giai đoạn nhỏ hơn: Phát yêu cầu Phân tích yêu cầu Đặc tả yêu cầu Kiểm thử yêu cầu - Quản lý yêu cầu hiểu :”thiết lập trì thoả thuận với khách hàng yêu cầu dự án phần mềm” (CMU/SEI 1995) Quản lý yêu cầu gồm bước sau Xác định giới hạn yêu cầu phần mềm (Requirement baseline) Duyệt giới hạn phần mềm Quản lý thay đổi yêu cầu phần mềm Quy trình phát triển thể hình vẽ sau: Mô tả quy trình sau: Maketing Customer Managerment lấy yêu cầu từ khách hàng, sau yêu cầu tổng hợp lại, phân tích, thỏa thuận với khách hàng, rà soát lại ( Đây trình phát triển yêu cầu ) Kết trình phát triển yêu cầu Baseline Requrirements Tài liệu chuyển chuẩn hóa làm mốc cho trình thay đổi ( gọi phiên sở 1.0) Phiên sở 1.0 gửi cho khách hàng, phận MCM lại tiếp tục đàn phán với khách hàng sở phiên này, yêu cầu thay đổi tổng hợp, xử lý cập nhập lại Baseline Requirements Với thay đổi cập nhập lại gồm : thay đổi gì, người thay đổi, thay đổi ảnh hưởng đến hệ thống, đề phòng Tất thông tin chuẩn hóa thành phiên 1.1 Bây phiên 1.1 lấy làm sở Quy trình tiếp tục có thống từ khách hàng đội phát triển Nêu vai trò của từng tác nhân yêu cầu phần mề m Ảnh hưởng của các tác nhân đến các thuôc tính chất lương yêu cầ u phần mềm CHƯƠNG II PHÁT HIỆN, TỔNG HỢP VÀ PHÂN TÍCH CÁC YÊU CẦU PHẦN MỀM CHƯƠNG III ĐẶC TẢ CÁC YÊU CẦU PHẦN MỀM Trình bày quy trình, kỹ thuật nội dung cần hoàn thành xác định nhiệm vụ phạm vi phần mềm Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi dự án Phạm vi dự án hàm của: • Chức cần có để đáp ứng nhu cầu người dùng • Tài nguyên sẵn sàng cho dự án • Thời gian cần có để thực dự án Phạm vi dự án - Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers, nhân viên đảm bảo chất lượng Nếu thời gian đủ dài, kết công việc tăng lên, không tăng tỷ lệ với tài nguyên đầu tư thêm Hiệu tổng thể dự án mà bị giảm sút Thêm tài nguyên chí làm chậm dự án cần phải đào tạo hỗ trợ cho nhân mới, làm giảm suất dự án Nhằm mục đích phân tích phạm vi, ta coi tài nguyên không đổi suốt dự án - Thời gian, thay đổi tài nguyên sẵn có không đủ để hoàn thành chức mong muốn Để phân tích phạm vi, ta coi thời gian yếu tố cố định Chức tổng thể bị giới hạn thời gian (cố định) tài nguyên (cũng cố định), phạm vi khả thi hình chữ nhật màu trắng Nếu hiệu đòi hỏi phải bổ sung đặc tính hệ thống với tài nguyên thời gian sẵn có dự án có phạm vi khả thi Thông thường công nghiệp, dự án dự án vượt phạm vi Nêu các phương pháp để phát hiên yêu cầu phần mềm và nguồn gốc yêu cầ u phần mềm So sánh đánh giá các kỹ thuât phát hiên yêu cầ u phần mềm  Phương pháp vấn  Phương pháp bảng hỏi  Phương pháp quan sát  Phương pháp nghiên cứu tài liệu phần mềm tương ứng or slide Trình bày quy trình thực (các bước), đặc điểm kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (Interviewing customers and domain experts) Đặt câu hỏi chất vấn đề người dùng Để giải vấn đề này, cần sử dụng câu hỏi: - Người sử dụng ai? - Khách hàng ai? - Nhu cầu họ có khác không? - Trong trường hợp tìm thấy giải pháp cho vấn đề này? Nội dung vấn thực theo mẫu sau: - Thiết lập tiểu sử người dùng hay khách hàng - Đi vào vấn đề - Tìm hiểu môi trường người dùng - Tóm tắt lại thu - Phân tích đầu vào vấn đề khách hàng - Đi vào giải pháp (nếu thích hợp) - Đi vào hội - Đi vào đáng tin cậy, hiệu nhu cầu hỗ trợ - Những yêu cầu khác - Bao quát lại - Tổng kết phân tích Những điểm cần lưu ý tiến hành vấn: - Chuẩn bị trước nội dung cần vấn Xem lại câu hỏi trước tiến hành vấn - Trước vấn nên tìm hiểu tảng bên liên quan công ty vấn - Ghi lại câu trả lời trình vấn (Không cố gắng lấy thông tin lúc này) - Tham khảo mẫu trình vấn để đảm bảo đặt câu hỏi Trình bày quy trình thực (các bước), đặc điểm kỹ thuật phương pháp xác định yêu cầu phần mềm Bảng hỏi (Questionnaires) Quy trình thực kỹ thuật xác định yêu cầu phần mềm hội thảo - Chuẩn bị Hội thảo o Quảng bá nội dung o Đảm bảo bên liên quan tham dự o Chuẩn bị hậu cần tốt o Khởi động vật chất (warm-up materials): gửi material trước hội thảo để chuẩn bị tham dự để tăng hiệu hội thảo Có loại warm-up materials: ♣ Thông tin cụ thể dự án Trong bao gồm phác thảo tài liệu yêu cầu, liệt kê tính đề nghị, vấn với người dùng tiềm năng, báo cáo phân tích xu hướng, thư từ khách hàng, báo cáo lỗi hệ thống hành, thị quản lý mới, liệu marketing mới… ♣ Chuẩn bị cách suy nghĩ vượt khỏi giới hạn - Chuẩn bị vai trò cho facilitator (vai trò người dẫn chương trình hay người chủ tọa): o Đó người bên ngoài, có kinh nghiệm.xử lý quản lý yêu cầu o Là thành viên nhóm đạt thành tựu định - Lên lịch trình Hội thảo - Chạy chương trình o Các vấn đề phương pháp thương mại o Brainstorming o Sự trình bày việc tiếp theo: sau Hội thảo, facilitator ghi lại kết thu Sau đó, facilitator kết thúc nhiệm vụ chuyển sang cho nhóm phát triển Trình bày quy trình thực (các bước), đặc điểm kỹ thuật phương pháp Nghiên cứu tài liệu Hệ thống phần mềm tương tự (Study of documents and software systems) Các thông tin mang lại  Các vấn đề tồn đọng hệ thống  Các hội tiếp cận nhu cầu  Phương hướng tiếp cận tác động đến yêu cầu HTTT  Lí tồn hệ thống hành  Tìm tên vị trí cá nhân có liên quan tới hệ thống Giúp cho việc giao tiếp, liên lạc mục tiêu  Dữ liệu cấu trúc, quy tắc xử lí liệu Những hạn chế  Thiếu tài liệu  Tài liệu hết hạn  Các tài liệu nguồn cung cấp thông tin không đúng, trùng lặp Trình bày quy trình thực (các bước), đặc điểm kỹ thuật phương pháp xác định yêu cầu phần mềm Brainstorming Brainstorming gồm có pha: - Nêu ý tưởng: Mục đích đưa nhiều ý tưởng tốt, mục đích bề rộng, chưa cần có chiều sâu - Thâu tóm lại ý tưởng: Phân tích ý tưởng đưa ra, chọn lọc, tổ chức, đánh giá, mở rộng theo chiều sâu, tinh chỉnh chúng lại thành ý tưởng thích hợp Kỹ thuật có lợi ích sau: • Khuyến khích thành viên tham gia • Cho phép thành viên tranh luận với ý kiến đề xuất • Người điều phối thư ký trì hội thảo không bị gián đoạn • Diễn nhanh chóng • Đưa giải pháp khả thi cho vấn đề • Khuyến khích ý tưởng, suy nghĩ sáng tạo, độc đáo Quy định: Trình bày quy trình thực (các bước), đặc điểm kỹ thuật phương pháp xác định yêu cầu phần mềm Prototyping Prototyping phương pháp xác định yêu cầu phần mềm cách đưa mẫu thử Người phát triển dựa vào yêu cầu khảo sát để đưa sản phẩm ban đầu phác thảo công nghệ khác với công nghệ sử dụng Sau có trao đổi với người sử dụng, từ tìm yêu cầu cách cụ thể, rõ ràng hơn, đặc biệt yêu cầu có tính “mờ” Việc tạo mẫu thử sử dụng nhiều lần nhiều phần giai đoạn khác Các mẫu thử tạo có khả tái sử dụng, mẫu thử sau phát triển liên tiếp nên mẫu thử trước.(Mô hình tiến hóa) Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm thực thi riêng lẻ hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng khách hàng hiểu cặn kẽ yêu cầu hệ thống Với mục đích phân tích yêu cầu ta chon xây dựng mẫu thử : throwaway, horizontal, user interface (Nếu muốn nói cụ thể loại người đọc sách Managing Requirement Software chương 13 nhe) Để xây dựng mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát yêu cầu hệ thống, tiến hành trao đổi đàm phán với khách hàng Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử Dựa vào yêu cầu khảo sát tạo mẫu tro đổi với người sử dụng, với khách hàng, để phát cụ thể yêu cầu đặc biệt yêu cầu có tính “mờ” Tiến hành phát triển theo mẫu thử phê duyệt, sau bước tiếp tục tạo mẫu thử sử dụng mẫu thử có từ trước Nêu các phương pháp phân nhóm yêu cầu phần mề m Muc đích của phân nhóm Đánh giá kết quả phân nhóm 10 Nêu các phương pháp mô hình hó a các yêu cầ u phầ n mề m 11 Trình bày bước (quy trình) Phân tích yêu cầu phần mềm Nêu kỹ thuật áp dụng Phân tích yêu cầu phần mềm Sau thu thập thông tin yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân tích yêu cầu Mục đích việc phân tích để xác yêu cầu có dư thừa, mức độ quan trọng yêu cầu -Từ yêu cầu phần mềm, ta xác định biếu đồ use case -Xác định hoạt động nghiệp vụ với điểm bắt đầu kết thúc Trong chu trình này, ta cần xác định đối tượng tham gia, luồng thông tin điều khiển chu trình -Xác định vấn đề môi trường hoạt động phần mềm -Thực hiền kết nối yêu cầu nghiệp vụ yêu cầu người sử dụng -Mô ta cụ thể xác điều kiện thuận lợi thực yêu cầu Các kỹ thuật áp dụng Phân tích yêu cầu phần mềm là: Mã giả (Pseudocode) Máy trạng thái hữu hạn (Finite state machines) Cây định (Decision trees) Cây định dạng đồ thị (Graphic decision trees) Biểu đồ hoạt động (Activity diagrams (flowcharts)) Mô hình thực thể liên kết (Entity relationship models) Phân tích hướng đối tượng (Object-oriented analysis) Phân tính cấu trúc (Structured analysis) Biểu đồ luồng liệu (Data flow Diagrams) 12 Trình bà y kỹ thuât thương lư ơng và thỏ a thuân yêu cầ u phần mềm Đánh giá quan ̣ giữa các tiêu chí "chất lương", "thời gian thưc hiên" thương lương ̣ 13 Mô tả ngắn gọn cấu trúc Tài liệu đặc tả yêu cầu phần mềm theo chuẩn IEEE830-1998 14 Nêu kỹ thuật gán nhãn yêu cầu phần mềm theo chuẩn IEEE830-1998 Nôi dung gồm có phần: Giới thiệu chung 1.1 Mục đích 1.2 Tài liệu thỏa thuận 1.3 Đối tượng đự định đề xuất đọc 1.4 Phạm vi dự án 1.5 Tài liệu tham khảo Mô tả hệ thống 2.1 Quan điểm sản phẩm 2.2 Đặc tính sản phẩm 2.3 Các lớp đặc điểm user 2.4 Môi trường hoạt động 2.5 Thiết kế hạn chế thực 2.6 Tài liệu người dung 2.7 Giả định phụ thuộc Tính hệ thống 3.1 Mô tả ưu tiên 3.2 Trình tự kích thích/phản hồi 3.3 Yêu cầu chức Yêu cầu giao diện bên 4.1 Giao diện người dung 4.2 Giao diện phần cứng 4.3 Giao diện phần mềm 4.4 Giao diện truyền thông Yêu cầu chức khác 5.1 Các yêu cầu hiệu suất 5.2 Các yêu cầu an toàn 5.3 Các yêu cầu bảo mật 5.4 Thuộc tính chất lượng phầm mềm Yêu cầu khác CHƯƠNG IV DUYỆT VÀ KIỂM SOÁT CÁC YÊU CẦU PHẦN MỀM Phân biệt hai khái niệm: Requirements Verification and Requirements Validation Làm rõ khác biệt khái niệm  Requirements Verification (Xác nhận): Kiểm tra xem sản phẩm khách hàng yêu cầu xây dựng không Đảm bảo phần mềm phát triển ( thay đổi) làm hài lòng tất bên liên quan thẩm định bên liên quan tới sản phẩm Kiểm tra tính quán đặc tả yêu cầu sản phẩm phần mềm phát triển ( thiết kế, thực hiện, ) đặc tả kĩ thuật Chiếm khoản 20% khối lượng công việc có vai trò quan trọng hiệu đôi lúc chiếm phần lớn hiệu chung có liên quan tới khách hàng - Validation điều kiện Đủ  Requirements Validation (Kiểm chứng) Kiểm tra xem việc xây dựng sản phẩm có thực không, có chạy xác không Phải đảm bảo bước trình xây dựng phần mềm mang đến sản phẩm phù hợp Kiểm tra đặc tả yêu cầu phần mềm yêu cầu mục tiêu bên liên quan - Chiếm 80% công việc, ảnh hưởng trực tiếp tới chất lượng sản phẩm - Verification điều kiện Cần Nêu các phương pháp xem xét lai yêu cầ u phầ n mề m Những tác nhân nào tham gia vào xem xét lai yêu cầ u phầ n mề m Trình bày kỹ thuật duyệt kiểm soát yêu cầu phần mềm Simple Check: Quy trình thực hiện, Khi áp dụng, tác nhân tham gia thực hiện, Các mẫu văn điển hình Quy trình thực hiện: Kiểm tra nguồ gốc yêu cầu phần mềm + Các yêu cầu phần mềm miêu tả phải với yêu cầu khách hàng + Theo dõ dấu vết mộ yêu cầu phần mềm (Tracing Requirement) Kiểm tra lại ma trận theo dõ yêu cầu phần mềm (Requirement Traceability Matrix) + Đảm bảo yêu cầu phần mềm phải xem xé, không xem xé thì phải có lí + Đảm bảo tất cả tài liệu đặc tả phải hợp lý Kiểm tra yêu cầu phần mềm trình bày tốt theo tiêu chí đã thảo luận, kiểm soát tính xác, tính không trùng lặp yêu cầu phần mềm Áp dụng tại: Các tài liệu yêu cầu phần mềm vừa lập xong Tác nhân tham gia: Người lập xong tài liệu yêu cầu phần mềm và kiểm tra lại Mẫu văn điển hình: + Tài liệu đặc tả yêu cầu phần mềm + Ma trận theo dõ yêu cầu phần mềm Trình bày kỹ thuật duyệt kiểm soát yêu cầu phần mềm Prototyping: Quy trình thực hiện, Khi áp dụng, tác nhân tham gia thực hiện, công cụ điển hình Là phương pháp tốt cho việc xác nhận người sử dụng hay khách hàng  Rất dễ để tiếp cận  Dễ dàng giúp bên liên quan phát vấn đề để giải  Phong phú đủ thể loại tư hệ thống nhỏ đến hệ thống vô lớn  Có xu hướng phát triển lớn Quá trình thực hiện:  Chọn thử nghiệm nguyên mẫu  Phát triển kịch thử nghiệm  Lập kế hoạch cẩn thận cần thiết để xây dựng mộ tập hợp kịch thử nghiệm cung cấp vùng hoạt độg rộg rãi cho yêu cầu  Ngườ sử dụng không nên sử dụng xung quanh hệ thống không bao giơ thực tính hệ thống quan trọng  Thực kịch thử nghiệm  Viết tài liệu cách sử dụng công cụ báo cáo vấn đề Trường hợp sử dụng: Sử dụng để lựa chọn kịch trường hợp sử dụng cho phiên gợi mở Nguyên liệu đánh giá :  Tài liệu nguồ  Danh sách kiểm tra  Tài liệu hỗ trợ  Thư mờ  Kế hoạch tổng thể  Issue/Defect Log  Thông tin liệu tóm tắt Trình bày kỹ thuật duyệt kiểm soát yêu cầu phần mềm Reviews and Inspections Quy trình thực hiện, Khi áp dụng, tác nhân tham gia thực hiện, Các công cụ điển hình Đồng bộ + Phương pháp tiếp cận truyền thống + Dựa cuộc họp Không đồng bộ + Tương đối + Thay họp mặt liên lạc thư điện tử Phương pháp đánh giá đồng Bước : Lên kế hoạch / tổng quan Lựa chọn ngườ đánh giá Phân công vai trò Phân phối tài liệụ Thảo liệu công việc đánh giá chung Leader:  Quản lý kiểm tra  Hành xử ngườ điều hành viên  Xác định / mờ ngườ đánh giá  Ngườ định vai trò  Phân phối tài liệu  Sắp xếp thờ gian, địa điểm gặp mặt Author:  Tạo tài liệu để đánh giá  Giúp trả lờ câu hỏi  Thườg không trực tiếp tham gia đánh giá  Chỉnh sửa tài liệu cần thiết Inspector / Reviewer:  Làm quen tài liệu thờ gian  Đánh giá tài liệu cho khiếm khuyết  Tìm kiếm khiếm khuyết (nếu có)  Sử dụng danh sách tài liệu hỗ trợ khác  Liên hệ sớm với lãnh đạo có vướng mắc việc đánh giá mộ lãng phí thờ gian Scibe / Recorder:  Ghi lại vấn đề nêu lên  Tốt điều hành viên hay ngườ đánh giá  Ghi lại thông tin rõ rang Bước 2: Chuẩn bị  Ngườ đánh giá làm quen với tài liệu đánh giá  Cần phải quen với tài liệu kịp thờ gian cho cuộ họp đánh giá Bước 3: Họp đánh giá, kiểm tra  Nhóm đánh giá cố gắng xác định khiếm khuyết  Các khiếm khuyết định vào thờ điểm  Cuộ hợp kéo dài giơ  Cách tiếp cận vòng tròn tiếp cận đọc (Reader approach)  Ngườ ghi chép ghi lại tất vấn đề + Vị trí xác định khiếm khuyết + Lý khiếm khuyết (trích dẫn yêu cầu danh sách kiểm tra) + Mức đô nghiêm trọng (Lớn, nhỏ) + Không ghi lại tên ngườ đánh giá khiếm khuyết + Cố gắng để hiển thị cho tất ngườ tham gia (tránh trùng lặp) Bước 4: Làm lại  Tác giả nhận ghi khiếm khuyết  Xác định khiếm khuyết thực sư “false positives”  Sửa chữa khiếm khuyết, cung cấp biện minh cho “false positives” Bước 5: Theo dõi  Lãnh đạo xác minh khiếm khuyết giải  Quyết định văn qua buổi đánh giá cần thêm buổi đánh giá khác Phương pháp đánh giá không đồng  Ưu điểm: Sức mạnh tổng hợp Giáo dục Dự kiến thời hạn Cạnh tranh Hạn chế tối đa “false positves”,  Nhược điểm:Chi phí (mất thờ gian sản xuất so với chi phí khiếm khuyết) Khó khăn lập trình thờ gian, địa điểm cho khách đánh giá diện rộg  Formal, Technical, Asynchronous Review Method (FTArm): Phương pháp đánh giá thức, kỹ thuật, không đồg bộ Phát triển Philip Johnson Đại học Hawaii + Giai đoạn : Chọn nhân tổ chức tài liệu + Giai đoạn 2: Định hướng ngườ tham gia tới nhiệm vụ giao + Giai đoạn 3: Đánh giá cá nhân + Giai đoạn 4: Xem xét hô sơ + Giai đoạn 5: Củng cố  Thông tin liên lạc không thực cuộ họp truyền thống + Email + Thông báo hộ đồg quản trị CHƯƠNG V CÁC KỸ THUẬT NÂNG CAO CHẤT LƯỢNG YÊU CẦU PHẦN MỀM Phân tích các thà nh phầ n ma trân vết yêu cầ u phầ n mề m Vai trò của ma trân ̣ theo dõi các thay đổ i yêu cầ u phầ n mề m Một điều rõ ràng rằng, thay đổi phần tấp yếu trình xây dựng yêu cầu phần mềm, thay đổi đến từ bên bên ngoài, quản lý thay đổi cần thiết 1.Thay đổi tránh , đặt kế hoạch cho 2.Vạch ranh giới cho yêu cầu 3.Thiết lập kênh đơn để điều khiển thay đổi 4.Sử dụng hệ thống điều khiển thay đổi để bắt thay đổi 5.Quản lý thay đổi cách phân cấp Thay đổi yêu cầu phần mềm có tính phân cấp, có nghĩa thay đổi yêu cầu mức kéo theo yêu cầu mức Do cần phải theo vết thay đổi, để biết thay đổi dẫn đến thay đổi nào, có thay đổi cần phải thông báo cho Kỹ thuật ma trận theo dõi yêu cầu phần mềm đạt mục đích Quá trình lập ma trận sau: (1)Xác định mối liên kết khả lập ma trận (2) Chọn dạng ma trận: tổng hợp hay chi tiết (3) Chọn chức năng/ yêu cầu cần theo dõi (3) Xác định phương pháp gán nhãn yêu cầu (4) Xác định nguồn thông tin yêu cầu phục vụ cho liênkết (5) Thông báo cho người tham gia liên kết (6) Kiểm soát liên kết trình phá triển phần mềm Phân tích vai trò tác nhân ảnh hưởng đến trình quản lý yêu cầu phần Mô tả ngắn gọn kỹ thuật quản lý yêu cầu phần mềm: Change Control (Kiểm soát thay đổi), Kiểm soát phiên (Version Control), Theo dõi trạng thái cầu phần mềm (Requirements status Tracking), Theo dõi vết yêu cầu (Requirements Tracing) Change Control (Kiểm soát thay đổi):  Đề xuất thay đổi  Phân tích tác động  Ra định  Cập nhật văn yêu cầu  Cập nhật kế hoạch  Đo lường biến động yêu cầu Kiểm soát phiên (Version Control):  Xác định sơ đồ xác định phiên  Xác định yêu cầu tài liệu phiên  Xác định phiên yêu cầu riêng Theo dõi trạng thái cầu phần mềm (Requirements status Tracking):  Xác định trạng thái yêu cầu  Ghi lại tình trạng yêu cầu  Báo cáo phân bố trạng thái tất yêu cầu Theo dõi vết yêu cầu (Requirements Tracing):  Xác định liên kết đến yêu cầu khác  Xác định liên kết đến yếu tố hệ thống khác Mô tả chất nội dung công việc Truy hồi (theo dõi vết) yêu cầu phần mềm Nêu phương pháp theo dõi vết yêu cầu phần mềm -Tính truy xuất nguồn gốc đề cập đến khả mô tả thực vòng đời yêu cầu, phía trước lẫn phía sau (tức từ nguồn gốc, thông qua phát triển đặc điểm kỹ thuật nó, triển khai sử dụng, thông qua tất giai đoạn sàng lọc liên tục lặp lại giai đoạn nào) " - Một đặc tả yêu cầu phần mềm theo dõi nguồn gốc Yêu cầu rõ ràng tạo điều kiện cho việc tham khảo Yêu cầu trình phát triển tương lai tài liệu nâng cao - Truy xuất nguồn cung cấp cho hỗ trợ thiết yếu việc hiểu mối quan hệ Tồn yêu cầu phần mềm, thiết kế, thực - Một liên kết mối quan hệ xác định thực thể Nêu số kỹ thuật quản lý thay đổi yêu cầu phần mềm Lý 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 định mình, môi trường bên thay đổi, hệ thống tồn Các tác nhân bên trong: không hỏi người câu hỏi thời gian suốt trình tập hợp yêu cầu ban đầu Chúng ta không tạo 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 theo chiều hướng tăng tiến Quá trình để quản lý thay đổi: 1.Đoán nhận thay đổi tất yếu, lên kế hoạch xử lý 2.Thiết lập ranh giới yêu cầu 3.Thiết lập kênh đơn để kiểm soát thay đổi 4.Sử dụng hệ điều khiển thay đổi để nắm bắt thay đổi 5.Quản lý thay đổi theo phân cấp Quản lý Cấu hình yêu cầu : Ngăn ngừa yêu cầu không hợp pháp phá hoại tiềm tàng hay yêu cầu thay đổi linh tinh Bảo đảm việc duyệt lại tài liệu yêu cầu 3.Làm thuận tiện việc lấy lại và/ xây dựng lại phiên trước tài liệu Hỗ trợ quản lý, tổ chức ranh giới “giải thoát kế hoạch” cho cải tiến cập nhập ngày tăng hệ thống 5.Ngăn chặn đồng thời việc cập nhật tài liệu hay xung đột không cho phép cập ... Phát yêu cầu, Phân tích yêu cầu, Đặc tả yêu cầu kiểm thử yêu cầu - Trong Phát triển yêu cầu chia làm giai đoạn nhỏ hơn: Phát yêu cầu Phân tích yêu cầu Đặc tả yêu cầu Kiểm thử yêu cầu - Quản lý yêu. .. trình) Phân tích yêu cầu phần mềm Nêu kỹ thuật áp dụng Phân tích yêu cầu phần mềm Sau thu thập thông tin yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân tích yêu cầu Mục đích việc phân tích để... nguồ gốc yêu cầu phần mềm + Các yêu cầu phần mềm miêu tả phải với yêu cầu khách hàng + Theo dõ dấu vết mộ yêu cầu phần mềm (Tracing Requirement) Kiểm tra lại ma trận theo dõ yêu cầu phần mềm (Requirement