Bài giảng Công nghệ phần mềm - Nguyễn Khắc Quốc - Chương 2: Phân tích và đặc tả yêu cầu

ác định yêu cầu nhưng nhiều khi không thích hợp
với đặc tả yêu cầu vì:
i) Không phải lúc nào người đọc và người viết đặc tả
bằng ngôn ngữ tự nhiên cũng hiểu các từ như nhau.
ii) Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu
liên quan đến nhau có thể được biểu diễn bằng các
hình thức hoàn toàn khác nhau và người phát triển
không nhận ra các mối liên quan này.
iii) Các yêu cầu khó được phân hoạch một cách hữu
hiệu do đó hiệu quả của việc đổi thay chỉ có thể xác
định được bằng cách kiểm tra tất cả các yêu cầu chứ
không phải một nhóm các yêu cầu liên quan.
2.4.2 Đặc tả yêu cầu (tt)
- Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục
được các hạn chế trên,
- Tuy nhiên đa số khách hàng lại không thông thạo
các ngôn ngữ này.
- Mỗi ngôn ngữ đặc tả hình thức thường chỉ phục vụ
cho một nhóm lĩnh vực riêng biệt và việc đặc tả hình
thức là một công việc tốn kém thời gian.
- Một cách tiếp cận là bên cạnh các đặc tả hình thức
người ta viết các chú giải bằng ngôn ngữ tự nhiên để
giúp khách hành dễ hiểu.
2.4.2 Đặc tả yêu cầu (tt)
- Một khi các yêu cầu đã được thiết lập thì cần thẩm
định xem chúng có thỏa mãn các nhu cầu của khách
hàng hay không.
- Nếu thẩm định không được tiến hành chặt chẽ thì
các sai sót có thể lan truyền sang các giai đoạn thiết
kế và mã hóa khiến cho việc sửa đổi hệ thống trở nên
rất tốn kém.
- Mục tiêu của thẩm định là kiểm tra xem yêu cầu mà
người phân tích xác định có thỏa mãn 4 yếu tố sau
không:
2.4.3 Thẩm định yêu cầu
1. Thỏa mãn nhu cầu của người dùng
2. Các yêu cầu không được mâu thuẫn nhau
3. Các yêu cầu phải đầy đủ
4. Các yêu cầu phải hiện thực.
2.4.3 Thẩm định yêu cầu (tt)
Đối với các hệ thống phức tạp, nhiều khi chúng ta
không nắm chắc được yêu cầu của khách hàng,
- Khó đánh giá được tính khả thi cũng như hiệu quả
của hệ thống.
- Một cách tiếp cận đối với trường hợp này là xây
dựng bản mẫu.
- Bản mẫu vừa được dùng để phân tích yêu cầu vừa
có thể tiến hóa thành sản phẩm cuối cùng.
2.5 Làm bản mẫu trong quá trình phân tích
-Bản mẫu phần mềm không phải nhằm vào việc thẩm
định thiết kế (thiết kế của nó thường là hoàn toàn khác
với hệ thống được phát triển cuối cùng),
- mà là để thẩm định yêu cầu của người sử dụng.
2.5 Làm bản mẫu trong quá trình phân tích
Bước 1: Đánh giá yêu cầu phần mềm và xác định phần
mềm cần xây dựng có xứng đáng để làm bản mẫu
không
- Ta có thể xác định một số nhân tố làm bản mẫu: lĩnh
vực ứng dụng, độ phức tạp ứng dụng, đặc trưng khách
hàng và đặc trưng dự án.
- Để đảm bảo tính tương tác giữa khách hàng với bản
mẫu, chúng ta cần đảm bảo các điều kiện:
1. Khách hàng phải cam kết dùng tài nguyên để đánh
giá và làm mịn bản mẫu (chi tiết hóa yêu cầu)
2. Khách hàng phải có khả năng đưa ra những quyết
định về yêu cầu một cách kịp thời
2.5.1 Các bước làm bản mẫu
Bước 2: Trước khi có thể bắt đầu xây dựng một bản
mẫu, người phân tích phải:
- biểu diễn miền thông tin và các lĩnh vực,
- hành vi và chức năng của vấn đề rồi xây dựng một
cách tiếp cận hợp lý tới việc phân hoạch.
- Có thể ứng dụng các nguyên lý phân tích nền tảng
(phân tích top-down) và các phương pháp phân tích yêu
cầu.
2.5.1 Các bước làm bản mẫu (tt)
Bước 3: Sau khi đã xét duyệt mô hình yêu cầu, phải tạo ra
một đặc tả thiết kế vắng tắt cho bản mẫu
-Việc thiết kế phải xuất hiện trước khi bắt đầu làm bản
mẫu.
- Tuy nhiên thiết kế tập trung chủ yếu vào các vấn đề thiết
kế dữ liệu và kiến trúc mức đỉnh chứ không tập trung vào
thiết kế thủ tục chi tiết.
2.5.1 Các bước làm bản mẫu (tt)
Bước 4: Phần mềm bản mẫu được tạo ra, kiểm thử và
làm mịn.
- Bản mẫu nên được xây dựng một cách nhanh chóng
và với một chi phí nhỏ.
- Một cách lý tưởng, bản mẫu nên được lắp ráp từ các
khối chức năng (thư viện...) đã có.
- Có thể dùng các ngôn ngữ bậc cao hay các công cụ
tự động để xây dựng bản mẫu.
2.5.1 Các bước làm bản mẫu (tt)
Bước 5: Khách hàng đánh giá và làm mịn yêu cầu
-Bước này là cốt lõi của cách tiếp cận làm bản mẫu.
- khách hàng có thể xem xét cách biểu diễn được cài
đặt cho yêu cầu phần mềm, gợi ý những thay đổi làm
cho phần mềm đáp ứng tốt hơn với các nhu cầu thực
tế.
Bước 6: Lặp lại các bước 4 và 5 cho tới khi tất cả các
yêu cầu đã được hình thức hóa đầy đủ hay cho tới khi
bản mẫu đã tiến hóa thành một phần mềm hoàn thiện.
2.5.1 Các bước làm bản mẫu (tt)
Bước 1: 
Đánh giá yêu cầu và xác 
định phần mềm
Bước 2:
Bắt đầu xây dựng một bản 
mẫu
Bước 3: 
Tạo ra một đặc tả thiết kế 
vắng tắt cho bản mẫu
Bước 4:
Phần mềm bản mẫu được 
tạo ra, kiểm thử và làm mịn
Bước 5: 
Khách hàng đánh giá và 
làm mịn yêu cầu
Bước 6: 
Lặp lại các bước 4 và 
5 cho tới khi tất cả các 
yêu cầu đã được hình 
thức hóa đầy đủ/ bản 
mẫu đã tiến hóa thành 
một phần mềm hoàn 
thiện.
2.5.1 Các bước làm bản mẫu (tt)
1. Sự hiểu lầm giữa những người phát triển phần mềm
và những người sử dụng phần mềm có thể được
nhận thấy rõ khi các chức năng của hệ thống được
trình diễn.
2. Sự thiếu hụt các dịch vụ người dùng có thể được phát
hiện.
3. Sự khó sử dụng hoặc sự nhầm lẫn các dịch vụ người
dùng có thể được thấy rõ và được sửa lại.
2.5.2 Lợi ích và hạn chế của phát triển bản mẫu
4. Đội ngũ phát triển phần mềm có thể tìm ra đựơc
các yêu cầu không đầy đủ hoặc không kiên định
khi họ phát triển bản mẫu.
5. Một hệ thống hoạt động được (mặc dầu là hạn
chế) là bằng chứng thuyết minh cho tính khả thi và
tính hữu ích của ứng dụng cho các nhà quản lý.
6. Bản mẫu đó được dùng làm cơ sở cho việc viết
đặc tả một sản phẩm.
2.5.2 Lợi ích và hạn chế của phát triển bản mẫu (tt)
Các lợi ích khác như:
1. Dùng để huấn luyện người sử dụng ngay từ trước khi
hệ thống được phân phối.
2. Dùng trong quá trình thử nghiệm hệ thống. Kết quả
khác nhau có nghĩa là có sai sót.
-Tạo bản mẫu là một kỹ thuật giảm bớt rủi ro.
- Một rủi ro lớn trong việc phát triển phần mềm là các sai
sót
- Việc tạo bản mẫu sẽ giảm bớt số các vấn đề của đặc
tả yêu cầu và giá cả tổng cộng của việc phát triển có thể
là thấp hơn nếu ta phát triển bản mẫu.
2.5.2 Lợi ích và hạn chế của phát triển bản mẫu (tt)
Một số hạn chế:
1. Để đơn giản hóa việc tạo bản mẫu người ta có thể bỏ
qua các yêu cầu phức tạp.
2. Các yêu cầu phi chức năng như độ tin cậy, độ an toàn
hay hiệu năng thường không được biểu thị đầy đủ trong
bản mẫu.
3. Do tính chưa hoàn thiện về chức năng/hiệu năng,
người dùng có thể không dùng bản mẫu như cách dùng
một hệ thống thực đang hoạt động.
 chất lượng đánh giá của khách hàng nhiều khi không
cao.
2.5.2 Lợi ích và hạn chế của phát triển bản mẫu (tt)
-Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu
phần mềm (Software Requirement Specification - SRS).
-Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm,
các chức năng cần có, đối tượng người sử dụng và các
ràng buộc khi vận hành sản phẩm.
Gồm các bước:
2.6 Định dạng đặc tả yêu cầu
1 Giới thiệu
1.1 Mục đích
1.2 Phạm vi
1.3 Định nghĩa
1.4 Tài liệu tham khảo
1.5 Mô tả chung về tài liệu
2 Mô tả chung
2.1 Tổng quan về sản phẩm
2.2 Chức năng sản phẩm
2.3 Đối tượng người dùng
2.6 Định dạng đặc tả yêu cầu (tt)
2.4 Ràng buộc tổng thể
2.5 Giả thiết và sự lệ thuộc
3 Yêu cầu chi tiết
3.1 Yêu cầu chức năng
3.1.1 Yêu cầu chức năng 1
3.1.1.1 Giới thiệu
3.1.1.2 Dữ liệu vào
3.1.1.3 Xử lý
3.1.1.4. Kết quả
3.1.2 Yêu cầu chức năng 2 ...
3.1.n Yêu cầu chức năng n
2.6 Định dạng đặc tả yêu cầu (tt)
3.2 Yêu cầu giao diện ngoài
3.2.1 Giao diện người dùng
3.2.2 Giao diện phần cứng
3.2.3 Giao diện phần mềm
3.2.4 Giao diện truyền thông
3.3 Yêu cầu hiệu suất
3.4 Ràng buộc thiết kế
3.5 Thuộc tính
3.5.1 Tính bảo mật, an toàn và khả năng phục hồi
3.5.2 Tính bảo trì
3.6 Các yêu cầu khác
2.6 Định dạng đặc tả yêu cầu (tt)
Tóm lại
* Quá trình phân tích:
- Phân tích phạm vi dự án
- Phân tích mở rộng yêu cầu nghiệp vụ
+ Xác định yêu cầu nghiệp vụ
+ Xác định yêu cầu chất lượng khách hàng
+ Phân tích cơ sở hạ tầng cơ sở hiện hành
+ Phân tích ảnh hưởng kỹ thuật
- Phân tích yêu cầu bảo mật
+ Xác định vai trò
+ Xác định môi trường bảo mật
+ Xác định ảnh hưởng bảo mật
+ Kế hoạch vận hành
+ Kế hoạch kiểm soát đăng nhập
+ Xác định mức độ yêu cầu bảo mật
+ Rà soát bảo mật hiện tại
Tóm lại (tt)
- Phân tích yêu cầu về tốc độ
- Phân tích yêu cầu vận hành
- Phân tích khả năng mở rộng yêu cầu
- Phân tích yếu tố con người
- Phân tích yêu cầu tích hợp
- Phân tích thực tiễn nghiệp vụ tồn tại
Tóm lại (tt)
Quá trình xác định yêu cầu:
Mục đích: Xác định chính xác các yêu cầu đặt ra
Kết quả:
+ Danh sách các công việc sẽ được thực hiện
+ Những mô tả chi tiết các công việc khi thực
hiện trong thế giới thực
Tóm lại (tt)
Yêu cầu
Yêu cầu chức năng Yêu cầu phi chức năng
Yêu cầu 
chức năng 
nghiệp vụ
Yêu cầu 
chức năng 
hệ thống
Liên quan 
đến người 
dùng
Liên quan 
đến kỹ sư 
tin học
Lưu trữ
Tra cứu
Tính toán
Kết xuất
Môi trường
Mô phỏng
Tự động
Phân quyền
Sao lưu
Tính tái sử dụng
Tính bảo trì
Tính tiến hóa
Tính tiện dụng
Tính hiệu quả
Tính tương thích
Tóm lại (tt)
- Phân tích và định rõ yêu cầu là bước kỹ thuật đầu tiên
trong tiến trình kỹ nghệ phần mềm.
- Tại bước này các phát biểu chung về phạm vi phần
mềm được làm mịn thành một bản đặc tả cụ thể để trở
thành nền tảng cho mọi hoạt động kỹ nghệ phần mềm
sau đó.
- Việc phân tích phải tập trung vào các miền thông tin,
chức năng và hành vi của vấn đề.
- Để hiểu rõ yêu cầu, người ta tạo ra mô hình, phân
hoạch vấn đề và tạo ra những biểu diễn mô tả cho bản
chất của yêu cầu rồi sau đó đi vào các chi tiết.
Kết chương
- Trong nhiều trường hợp, không thể nào đặc tả được
đầy đủ mọi vấn đề tại giai đoạn đầu.
- Việc làm bản mẫu thường giúp chỉ ra cách tiếp cận
khác để từ đó có thể làm mịn thêm yêu cầu.
- Để tiến hành đúng đắn việc làm bản mẫu, có thể cần
tới các công cụ và kỹ thuật đặc biệt.
- Kết quả của việc phân tích là tạo ra bản đặc tả các yêu
cầu phần mềm.
- Đặc tả cần được xét duyệt để đảm bảo rằng người phát
triển và khách hàng có cùng nhận biết về hệ thống cần
phát triển.
Kết chương