Đặc tả yêu cầu phần mềm
1
GVHD: PGS.TS Vũ Thanh Nguyên SVTH: Trịnh Hồng Trường – 09520326 Đinh Tiến Sỹ 09520257
Tại sao phải đặc tả yêu cầu phần mềm?
Vấ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 nhỏ : tiếp cận với yêu cầu phần
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
Đối với các dự án lớn: việc tiếp cận mà không có đặc
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
3
Đầu ra: đặc tả chi tiết hệ thống trong tương lai
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
4
Không thể sinh ra tự động
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
....
5
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.
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.
nhiều về phần mềm.
Người dùng cần sự tiện lợi nhưng không hiểu biết
không hiểu được những vấn đề chuyên ngành của
người dùng.
6
Nhà phát triển thực hiện phần mềm nhưng có thể sẽ
Mục đích
Tài liệu đặc tả yêu cầu phần mềm:
và nhà cung cấp.
Là cầu nối cho khoảng cách giao tiếp giữa khách hàng
mà cả hai đều có thể hiểu.
7
Đặc tả mong muốn của người dùng ở một phạm trù
Sự cần thiết của đặc tả
Giúp người dùng hiêu được thực sự muốn gì
muốn gì
Người dùng không phải bao giờ cũng biết họ thực sự
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
Xác nhận “Phần mềm thỏa mãn đặc tả”
Cần thiết
Đặc tả tốt cho ra phần mềm tốt
cùng.
Đặc tả yêu cầu bị lỗi sẽ thể hiện ra ở phần mềm cuối
nhất.
Để đạt được chất lượng tốt nhất cần có một đặc tả tốt
khuyết.
9
Đặc tả khiếm khuyết sẽ cho ra phần mềm khiếm
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
riêng từng vấn đề.
Chia vấn đề thành nhiều phần nhỏ và giải quyết
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
Analysis
Phân tích vấn đề
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
13
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
Phân tích vấn đề
Một vài vấn đề:
Thu thập thông tin cần thiết
chất cần thiết của phần mềm
Tương tác với người dùng để hình thành những tính
Quản lý thông tin
Bảo đảm việc hoàn thành phần mềm
14
Bảo đảm nhất quán
...
Analysis
Đặc tả yêu cầu
Specification
Kết quả cuối cùng của việc đặc tả yêu cầu là
Validation
đặ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:
hình chỉ chú ý đến cầu trúc bên trong
Vì nó chú ý đến thể hiện bên ngoài, còn các mô
15
yêu cầu phần mềm
Xử lý lỗi, hạn chế, ... Đều được rõ ràng trong đặc tả
Đặ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
16
Dễ theo dõi
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ế
17
Giao diện
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
18
Cần thể hiện rõ yêu cầu của đầu vào
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.
19
Yêu cầu cấu hình
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
20
Độ tin cậy, khả năng chịu lỗi, yêu cầu sao lưu.
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
21
Đại từ “thân thiện” cần được tránh
Analysis
Xác nhận đặc tả
Specification
Rất nhiều lỗi đọc hiểu
Validation
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
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
24
Prototyping...
Phương pháp thường dùng: SSAD, OOA,
Tổng kết
Đặc tả:
kế.
Phải bao gồm chức năng, thi hành, giao diện, và thiết
Sử dụng ngôn ngữ tự nhiên
25
Kiểm lại và xác nhận
Cám ơn
26
