Xem mẫu
- Đặ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
1
Đinh Tiến Sỹ 09520257
- 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: 8
Hiểu rõ ràng yêu cầu cuối cùng
- 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
needs tuyến tính.
Sẽ có vòng lặp tại các bước.
Analysis
Thể hiện chi tiết hóa yêu
Specification
cầu giúp đỡ rất nhiều cho
đặc tả.
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 đề Analysis
Specification
Mục tiêu: để hiểu được yêu cầu, hạn chế
Validation
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 13
Trở thành cố vấn
- 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 Analysis
Specification
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. Validation
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ả
15
yêu cầu phần mềm
- Đặ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
16
Dễ điều chỉnh
- 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
nguon tai.lieu . vn
