Đặc tả yêu cầu phần mềm

Click to edit Master title style Click to edit Master text styles Second level Third level Fourth level Fifth level 9/23/2013 ‹#› Đặc tả yêu cầu phần mềm GVHD: PGS.TS Vũ Thanh Nguyên SVTH: Trịnh Hồng Trường – 09520326 Đinh Tiến Sỹ - 09520257 1 Tại sao phải đặc tả yêu cầu phần mềm? Vấn đề: Đối với các dự án nhỏ : tiếp cận với yêu cầu phần mềm dễ dàng vì cấu trúc dự án không phức tạp. Đối với các dự án lớn: việc tiếp cận mà không có đặc tả là rất khó. Vì cấu trúc và yêu cầu phần mềm cực kì phức tạp 2 Tại sao phải đặc tả? Yêu cầu: Đầu vào: những yêu cầu người dùng đặt ra Đầu ra: đặc tả chi tiết hệ thống trong tương lai 3 Thách thức Đặc tả yêu cầu phần mềm: Cần phải có tương tác người dùng Không thể sinh ra tự động 4 Nền tảng Hiểu được yêu cầu phần mềm là rất khó Hình tượng hóa hệ thống trong tương lai rất khó Khả năng của hệ thống không rõ ràng Yêu cầu thay đổi theo thời gian .... Thực tế cho thấy việc đưa ra một đặc tả yêu cầu phần mềm là cần thiết. 5 Mục đích của tài liệu đặc tả? Tài liệu đặc tả được hình thành giữa người dùng và nhà cung cấp. Người dùng cần sự tiện lợi nhưng không hiểu biết nhiều về phần mềm. Nhà phát triển thực hiện phần mềm nhưng có thể sẽ không hiểu được những vấn đề chuyên ngành của người dùng. 6 Mục đích Tài liệu đặc tả yêu cầu phần mềm: Là cầu nối cho khoảng cách giao tiếp giữa khách hàng và nhà cung cấp. Đặc tả mong muốn của người dùng ở một phạm trù mà cả hai đều có thể hiểu. 7 Sự cần thiết của đặc tả Giúp người dùng hiêu được thực sự muốn gì Người dùng không phải bao giờ cũng biết họ thực sự muốn gì Cần đánh giá khả năng và hiểu rõ tiềm lực Quá trình phân tích giúp yêu cầu rõ ràng hơn. Đặc tả được xem như một chứng nhận cho sản phẩm cuối cùng: Hiểu rõ ràng yêu cầu cuối cùng Xác nhận “Phần mềm thỏa mãn đặc tả” 8 Cần thiết Đặc tả tốt cho ra phần mềm tốt Đặc tả yêu cầu bị lỗi sẽ thể hiện ra ở phần mềm cuối cùng. Để đạt được chất lượng tốt nhất cần có một đặc tả tốt nhất. Đặc tả khiếm khuyết sẽ cho ra phần mềm khiếm khuyết. 9 Quá trình đặc tả Hoạt động chính: Phân tích yêu cầu/ vấn đề. Đặc tả yêu cầu. Xác nhận đặc tả. Trong đó bước phân tích đầu tiên chính là bước quan trọng nhất và khó khăn nhất. 10 Quá trình đặc tả Quá trình này không tuyến tính. Sẽ có vòng lặp tại các bước. Thể hiện chi tiết hóa yêu cầu giúp đỡ rất nhiều cho đặc tả. needs Analysis Specification Validation 11 Quá trình đặc tả Chia để trị là chiến thuật cơ bản Chia vấn đề thành nhiều phần nhỏ và giải quyết riêng từng vấn đề. Một lượng lớn thông tin sinh ra Tổ chức lại để dễ dàng quản lý. Các kỹ thuật như data flow diagram, object diagram, ... Được sử dụng cho việc phân tích. 12 Phân tích vấn đề Mục tiêu: để hiểu được yêu cầu, hạn chế của phần mềm Vấn đề liên quan: Nói chuyện với khách hàng Đọc hướng dẫn sử dụng Học tập hệ thống hiện tại Hướng dẫn người dùng Trở thành cố vấn Analysis Specification Validation 13 Phân tích vấn đề Một vài vấn đề: Thu thập thông tin cần thiết Tương tác với người dùng để hình thành những tính chất cần thiết của phần mềm Quản lý thông tin Bảo đảm việc hoàn thành phần mềm Bảo đảm nhất quán ... 14 Đặc tả yêu cầu Kết quả cuối cùng của việc đặc tả yêu cầu là đặc tả yêu cầu phần mềm. Tại sao không phải mô hình DFD, OO, ... Mà lại là đặc tả yêu cầu phần mềm: Vì nó chú ý đến thể hiện bên ngoài, còn các mô hình chỉ chú ý đến cầu trúc bên trong Xử lý lỗi, hạn chế, ... Đều được rõ ràng trong đặc tả yêu cầu phần mềm Analysis Specification Validation 15 Đặc điểm của một đặc tả yêu cầu phần mềm Chính xác Hoàn thiện Rõ ràng Nhất quán Kiểm chứng Dễ theo dõi Dễ điều chỉnh 16 Thành phần của một đặc tả Một đặc tả yêu cầu phần mềm cần thể hiện yêu cầu về: Chức năng Thi hành Hạn chế về thiết kế Giao diện 17 Yêu cầu chức năng Thể hiện tất cả các chức năng mà hệ thống hỗ trợ Kết quả tương ứng với đầu vào và mối liện hệ giữa chúng Tất cả các hành động của hệ thống Cần thể hiện rõ yêu cầu của đầu vào 18 Yêu cầu thi hành Những hạn chế của việc thi hành (chạy hệ thống). Thời gian phản hồi của hệ thống với yêu cầu. Yêu cầu cấu hình 19 Hạn chế thiết kế Các yếu tố hạn chế khách hàng lựa chọn trong môi trường làm việc thực tế Ví dụ: Hạn chế của phần cứng Bảo mật Độ tin cậy, khả năng chịu lỗi, yêu cầu sao lưu. 20 Giao diện Tất cả những tương tác giữa phần mềm với người dùng Giao diện người dùng rất quan trọng Đại từ “thân thiện” cần được tránh 21 Xác nhận đặc tả Rất nhiều lỗi đọc hiểu Có thể có lỗi cấu trúc Sẽ tốn rất nhiều tài nguyên để khắc phục lỗi Ở bước này cần khắc phục càng nhiều lỗi của đặc tả càng tốt Analysis Specification Validation 22 Kiểm tra đặc tả Đặc tả được kiểm lại bằng một nhóm người Gồm: tác giả, người dùng, người phát triển, khách hàng Tiến trình: kiểm tra theo từng giai đoạn Hiệu quả: Bước này có thể tìm thấy 40~80% lỗi và khắc phục kịp thời 23 Tổng kết Một đặc tả tốt sẽ cho một phần mềm tốt Giai đoạn yêu cầu có 3 giai đoạn con: Phân tích, đặc tả và xác nhận Phân tích: Cho các vấn đề và mô hình hóa Phương pháp thường dùng: SSAD, OOA, Prototyping... 24 Tổng kết Đặc tả: Phải bao gồm chức năng, thi hành, giao diện, và thiết kế. Sử dụng ngôn ngữ tự nhiên Kiểm lại và xác nhận 25 Cám ơn 26