CHƯƠNG 2. PHÂN TÍCH YÊU CẦU PHẦN MỀM
2.1. Khái niệm
2.2. Nội dung phân tích
2.3. Tài liệu đặc tả yêu cầu
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
34
2.1. Khái niệm
§ Quá trình tìm kiếm, phân tích, kiểm tra, tư liệu hoá các dịch vụ và
các ràng buộc của hệ thống được gọi
là kỹ nghệ yêu cầu
(Requirements Engineering - RE).
§ Kỹ nghệ yêu cầu có thể hiểu là việc phân tích yêu cầu một cách có
hệ thống.
§ Kỹ nghệ yêu cầu là khâu kỹ thuật đầu tiên trong quá trình xây dựng
hệ thống/phần mềm.
35
2.1. Khái niệm
§ Yêu cầu (requirement) có nhiều mức:
—Một mô tả trừu tượng về một dịch vụ rằng hệ thống phải chịu một ràng buộc nào đó
§ Các yêu cầu có thể phục vụ các nhiệm vụ:
—Một đặc tả chi tiết toán học về một chức năng.
—Cơ sở để thương lượng một hợp đồng
• Khi đó phải được viết một cách trừu tượng cần giải nghĩa thêm
—Cơ sở để viết hợp đồng
• Khi đó phải được định nghĩa chi tiết
36
—Làm tư liệu đầu vào cho việc thiết kế và triển khai
2.1. Khái niệm
§ Yêu cầu người dùng - User requirements
thống cung cấp và các ràng buộc về vận hành.
— Các phát biểu bằng ngôn ngữ tự nhiên cộng với các sơ đồ về các dịch vụ mà hệ
§ Yêu cầu hệ thống – System requirements
— Được viết cho khách hàng.
hệ thống cùng với các ràng buộc về vận hành.
— Một tài liệu có cấu trúc bao gồm các mô tả chi tiết về các chức năng và dịch vụ của
37
— Định nghĩa cái gì cần được cài đặt
37
• Có thể là một phần của một hợp đồng giữa khách hàng và người nhận thầu.
2.1. Khái niệm
§ Đặc tả yêu cầu (phần mềm): Software Requirements Specification
(SRS)
— Bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các
yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác.
cấp và các ràng buộc để xây dựng và vận hành hệ thống.
— Tài liệu đặc tả yêu cầu là bản mô tả chi tiết các dịch vụ mà hệ thống cung
— Đủ chi tiết làm cơ sở cho việc thiết kế và triển khai.
38
— Dành cho nhà phát triển.
2.1. Khái niệm
§ Yêu cầu từ nghiệp vụ:
hay các dịch vụ mà hệ thống/phần mềm cần cung cấp.
— Các yêu cầu chức năng (Functional requirements): Mô tả các chức năng
buộc đặt lên dịch vụ và quá trình phát triển hệ thống (về chất lượng, về môi
trường, chuẩn sử dụng, qui trình phát triển,…)
— Các yêu cầu phi chức năng (Non-Functional requirements): Mô tả các ràng
đặt ra từ miền ứng dụng, phản ánh những đặc trưng miền đó.
39
— Các yêu cầu miền/lĩnh vực ngoài (Domain requirements) : Những yêu cầu
2.1. Khái niệm
§ Các yêu cầu chức năng:
— Mô tả chức năng hay dịch vụ của hệ thống — Chúng phụ thuộc vào:
• Loại phần mềm sẽ được xây dựng • Sự mong muốn của khách hàng • Loại hệ thống mà phần mềm trợ giúp
— Mức độ các yêu cầu
40
• Trừu tượng: hệ thống làm gì? • Chi tiết: nhiệm vụ cụ thể của hệ thống cần thực hiện
2.1. Khái niệm
§ Các yêu cầu chức năng:
— Ví dụ:
liệu hoặc tên tài liệu
• Người sử dụng có thể tìm kiếm tài liệu dựa trên các từ khóa có trong tài
(.txt), PDF, Word, Excel,…
• Hệ thống phải đọc được các định dạng khác nhau của tài liệu: văn bản
41
• Hệ thống cần cung cấp phương tiện hiển thị dễ dàng các tài liệu từ CSDL
2.1. Khái niệm
§ Yêu cầu phi chức năng quy định các tính chất và ràng buộc
§ Yêu cầu phi chức năng có thể quan trọng hơn cả các yêu cầu chức
năng vì nếu không thỏa mãn các yêu cầu này thì hệ thống vô dụng.
(tính dễ dùng).
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
42
— Ví dụ: Sau 2 ngày đào tạo, nhân viên có thể nhập được 20 đơn hàng trong 1h
2.1. Khái niệm
§ Yêu cầu phi chức năng:
cách hành xử của sản phẩm cần bàn giao
— Yêu cầu sản phẩm (Product requirements): Các yêu cầu quy định về
từ các chính sách và quy trình của tổ chức của khách hàng cũng như nhóm
phát triển
— Yêu cầu tổ chức (Organisational requirements ): Các yêu cầu xuất phát
nhân tố bên ngoài hệ thống và quy trình phát triển nó
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
43
— Yêu cầu bên ngoài (External requirements ): Các yêu cầu nảy sinh từ các
2.1. Khái niệm
§ Yêu cầu phi chức năng:
— Yêu cầu về sản phẩm
• Chỉ sử dụng tối đa 256 MB bộ nhớ • Giao diện người dùng của LIBSYS cần được cài đặt dạng HTML đơn giản không chứa frame hay Java applet
Tiến trình phải đáp ứng chuẩn DO178
— Yêu cầu về tổ chức
định tại XYZCo -SP-STAN-95
• • Quy trình phát triển hệ thống và các tài liệu bàn giao cần tuân theo chuẩn quy trình và sản phẩm được qui
— Yêu cầu bên ngoài
trừ tên và số tham chiếu (reference number) của khách hàng
44
• Hệ thống sẽ không để lộ thông tin cá nhân của các khách hàng cho các nhân viên vận hành hệ thống, ngoại
2.1. Khái niệm
§ Xung đột giữa các yêu cầu phi chức năng khác nhau là chuyện thường gặp
trong các hệ thống phức tạp.
§ Một số yêu cầu phi chức năng có thể khó mà phát biểu được chính xác, và
việc kiểm định các yêu cầu phi chức năng không chính xác có thể khó
khăn.
§ Các yêu cầu phi chức năng kiểm định/ đo được (verifiable): sử dụng một
phép đo để kiểm định.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
45
— Tính dễ sử dụng.
2.1. Khái niệm
§ Các phép đo yêu cầu phi chức năng
hình.
— Tốc độ: Giao dịch được xử lý /giây; thời gian phản hồi; thời gian làm mới màn
ra lỗi.
— Kích thước: Mb; số lượng bộ nhớ trong. — Dễ dùng: Thời gian huấn luyện/ đào tạo; Số trang trợ giúp. — Độ tin cậy: Thời gian trung bình xảy ra lỗi; Xác suất không khả dụng; Tần suất xảy
Xác suất xảy ra hỏng hóc dữ liệu do lỗi.
— Độ bền: Thời gian khởi động sau khi hỏng; Tỉ lệ phần trăm các sự cố gây ra lỗi;
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
46
— …
2.1. Khái niệm
§ Yêu cầu miền:
mô tả các đặc điểm và tính chất hệ thống phản ánh miền ứng dụng đó.
— Các yêu cầu miền xuất phát từ miền ứng dụng (application domain), chúng
yêu cầu đã có hoặc định nghĩa các tính toán cụ thể.
— Các yêu cầu miền có thể là các yêu cầu chức năng mới, các ràng buộc về các
động được.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
47
— Nếu các yêu cầu miền không được thỏa mãn, hệ thống có thể không hoạt
2.1. Khái niệm
§ Ví dụ: yêu cầu miền của hệ thống thư viện:
này cần dựa vào chuẩn Z 39. 50.
— Cần có một chuẩn giao diện người dùng cho tất cả các cơ sở dữ liệu, chuẩn
được. Tùy theo các yêu cầu của người dùng, các tài liệu này sẽ được in tại
chỗ tại máy chủ của hệ thống rồi chuyển bằng tay tới người dùng hoặc được
in tại một máy in trong mạng.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
48
— Do các hạn chế về bản quyền, một số tài liệu phải được xóa ngay khi nhận
2.1. Khái niệm
§ Yêu cầu miền:
dụng è Thường khó hiểu đối với các kĩ sư phần mềm.
— Mức độ hiểu được: Các yêu cầu được diễn đạt bằng ngôn ngữ của miền ứng
yêu cầu miền đến mức họ không nghĩ đến việc diễn đạt các yêu cầu miền
một cách tường minh.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
49
— Ẩn ý : Các chuyên gia trong ngành hiểu rõ về lĩnh vực đang nói đến trong
2.2. Nội dung phân tích
§ Đánh giá ưu nhược điểm của hệ thống cũ – system as is (phân tích quy trình
nghiệp vụ trong tổ chức)
§ Xác định yêu cầu cụ thể cho hệ thống mới - system to be
— Thiếu sót; Kém hiệu lực, quá tải; Tốn phí cao, lãng phí
dựng hệ thống mới gồm phần mềm mới, …); Khắc phục yếu kém của hệ
thống hiện tại; Khả năng mở rộng.
§ Xác định và mô tả chi tiết yêu cầu cho phần mềm mới - software to be
50
— Phạm vi; Nhân lực sử dụng (điều khiển hệ thống); Tài chính (chi phí xây
Mục tiêu
§ Hiểu yêu cầu
§ Mô tả yêu cầu theo cách mà khách hàng có thể hiểu được. Đảm bảo
rằng khách hàng hiểu bản mô tả yêu cầu.
§ Mô tả yêu cầu theo cách mà đội phát triển (những người thiết kế,
lập trình, kiểm thử, và cài đặt hệ thống) có thể hiểu được.
51
Các bước thực hiện
1. Mô hình hóa quy trình nghiệp vụ (business process modelling) 2. Nghiên cứu khả thi (feasibility study) 3. Khám phá yêu cầu (requirements elicitation ) 4. Phân tích yêu cầu (requirements analysis) 5. Đặc tả yêu cầu (requirements specification) 6. Thẩm định yêu cầu (requirements validation)
52
Mô hình hoá quy trình nghiệp vụ
§ Hiểu quy trình nghiệp vụ hiện tại
§ Xác định trạng thái hiện tại của các quy trình
§ Đánh giá ưu điểm và hạn chế của quy trình hiện tại
§ Thiết kế quy trình nghiệp vụ mới
§ Đề xuất giải pháp CNTT để giải quyết nhu cầu nghiệp vụ mang lại
các giá trị cho các bên liên quan (phần mềm mới)
53
Nghiên cứu khả thi
§ Nhằm trả lời câu hỏi:
§ Nội dung nghiên cứu khả thi tập trung để trả lời các câu hỏi:
— Có nên phát triển hệ thống hay không?
— Hệ thống được xây dựng sẽ giúp ích gì cho tổ chức?
— Hệ thống sử dụng công nghệ nào, kinh phí bao nhiêu, thời gian bao nhiêu?
54
— Hệ thống cần phải tích hợp với hệ thống nào đang sử dụng?
Nghiên cứu khả thi
§ Khả thi về nghiệp vụ § Khả thi về kinh tế § Khả thi về kỹ thuật, công nghệ § Khả thi về pháp luật
55
Khám phá, thu thập yêu cầu
• Nhân viên kỹ thuật làm việc với khách để hiểu về miền ứng dụng, nắm bắt mong
muốn của khách hàng về hệ thống mới: các dịch vụ mà hệ thống cung cấp và các
ràng buộc khi vận hành các dịch vụ.
56
Khám phá, thu thập yêu cầu
§ Khó khăn khi thực hiện
lộn giữa yêu cầu và mong muốn
— Khách hàng thương mơ hồ về yêu cầu, không biết rõ mình muốn gì, dễ lẫn
đổi,…
57
— Họ thể hiện yêu cầu theo thuật ngữ riêng — Khách hàng đa dạng, các yêu cầu có thể mâu thuẫn nhau — Những yếu tố tổ chức và chính sách có thể ảnh hưởng đến yêu cầu — Yêu cầu thương mang tính đặc thù, khó hiểu, khó có chuẩn chung. — Các yêu cầu thay đổi trong quá trình phân tích: môi trường nghiệp vụ thay
Khám phá, thu thập yêu cầu
§ Khó khăn khi thực hiện
dựng để phục vụ công việc của họ è Người phát triển phải sẵn sàng, kiên trì
theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính
năng cần thiết”.
— Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây
nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý.
58
— Khách hàng rất hay thay đổi các đòi hỏi của mình è Người phát triển cần
Khám phá, thu thập yêu cầu
§ Hiểu nghiệp vụ, hiểu miền ứng dụng
§ Nắm bắt mong muốn của người dùng về hệ thống mới
- Các dịch vụ hệ thống cần cung cấp
§ Xây dựng các mô hình phân tích để làm rõ các yêu cầu trên
- Các ràng buộc đặt lên hệ thống
- Mô hình khung cảnh
- Mô hình chức năng
59
- Mô hình dữ liệu
Khám phá, thu thập yêu cầu
§ Các phương pháp khám phá, thu thập yêu cầu
1. Nghiên cứu tài liệu
2. Quan sát
Phỏng vấn
3.
4. Điều tra bằng bảng hỏi
60
5. Họp, làm việc nhóm, tổ chức hội thảo
Khám phá, thu thập yêu cầu
§ Tùy vào đặc điểm của hệ thống, tổ chức để
lựa chọn phương pháp phù hợp
§ Có thể kết hợp nhiều phương pháp để đạt
được mục tiêu
§ Sử dụng bản mẫu (prototype) để hỗ trợ
61
Phân tích yêu cầu
§ Đánh giá rủi ro § Đánh giá tính khả thi § Xếp thứ tự ưu tiên § Xem xét và loại bỏ mâu thuẫn giữa các yêu cầu § Phân nhóm yêu cầu
62
Đặc tả yêu cầu
§ Là quá trình xây dựng/viết tài liệu mô tả yêu cầu
và khách hàng không có kiến thức về kỹ thuật hiểu
được.
— Các yêu cầu của người dùng phải được người dùng cuối
thể bao gồm nhiều thông tin kỹ thuật hơn.
— Yêu cầu hệ thống là những yêu cầu chi tiết hơn và có
hệ thống
è Do đó, điều quan trọng là chúng phải đầy đủ nhất
có thể.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
63
— Các yêu cầu có thể là một phần của hợp đồng phát triển
Thẩm định yêu cầu
Liên quan đến việc kiểm tra tính đúng đắn, tính đầy đủ, tính nhất quán, tính hiện thực và kiểm tra được của yêu cầu. Cụ thể trả lời được các câu hỏi: § Còn nhu cầu nào của người dùng chưa kể đến? § Có mâu thuẩn gì giữa các yêu cầu? § Chức năng, ràng buộc gì chưa kể? § Có thực hiện được không? § Có thể kiểm tra nó như thế nào?
64
Thẩm định yêu cầu
§ Các kỹ thuật thẩm định yêu cầu:
— Xem xét lại yêu cầu:
• Phân tích một cách có hệ thống
• Lấy ý kiến khách hàng
• Tiến hành thường xuyên
— Làm bản mẫu
Sử dụng mô hình khả dụng
•
• Kiểm tra tính thực hiện được
65
— Tạo ca kiểm thử (test case)
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực
hiện bởi đội phát triển hệ thống.
§ Tài liệu đặc tả yêu cầu nên bao gồm cả các định nghĩa về yêu cầu của người sử
dụng và đặc tả yêu cầu hệ thống.
§ Tài liệu đặc tả yêu cầu không phải là tài liệu thiết kế hệ thống. Nó chỉ thiết lập
những gì hệ thống phải làm, chứ không phải mô tả rõ làm như thế nào.
66
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Thông tin trong tài liệu yêu cầu phụ thuộc vào loại hệ thống và cách
tiếp cận phát triển được sử dụng.
§ Các hệ thống được phát triển dần dần sẽ có ít chi tiết hơn trong tài
liệu yêu cầu.
§ Các tiêu chuẩn về tài liệu yêu cầu (ví dụ: Tiêu chuẩn IEEE) được áp
dụng cho các đặc tả yêu cầu của các dự án phát triển hệ thống lớn.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
67
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Tài liệu đặc tả tốt cần:
— Dễ hiểu với người dùng
— Có ít câu nhập nhằng
— Có ít quy ước khi mô tả, có thể tạo đơn giản
— Với phong cách từ trên xuống (topdown)
chương trình và giao diện dễ làm, đảm bảo tính nhất quán.
68
— Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Ngôn ngữ viết tài liệu
— Ngôn ngữ tự nhiên
— Ví dụ: Chức năng kiểm tra chính tả
• Định ra yêu cầu: Thông báo lỗi chính tả của văn bản
• Đặc tả:
• Các lỗi chính tả được gạch đỏ bên dưới
• Lỗi soạn thảo được gạch xanh bên dưới
• Lỗi chính tả : Từ đơn không có trong từ điển
69
• Lỗi soạn thảo: Thừa dấu cách; Không viết hoa đầu câu
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Ngôn ngữ tự nhiên
— Mù mờ đa nghĩa
— Quá linh động
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
70
— Thiếu tính mô đun hoá
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Các lựa chọn khác:
bằng toán học
§ Ví dụ
— Ngôn ngữ tự nhiên có cấu trúc — Ký hiệu đồ hoạ: Mô hình — Ngôn ngữ mô tả thiết kế, đặc tả
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
71
— Đặc tả theo form — Đặc tả bằng bảng
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Ví dụ:
72
— Đặc tả bằng mô hình ( sơ đồ )
2.3. Tài liệu yêu cầu /Tài liệu đặc tả yêu cầu
§ Ví dụ:
73
— Ngôn ngữ mô tả thiết kế (PDL: Program Design Language)
Mẫu tài liệu yêu cầu
§ Ví dụ tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE:
1.1. Mục đích của tài liệu yêu cầu 1.2. Phạm vi của sản phẩm 1.3. Các định nghĩa, từ viết tắt 1.4. Các tham chiếu 1.5. Tổng quan về tài liệu yêu cầu
— 1. Giới thiệu
• • • • •
2.1. Giới thiệu chung về sản phẩm 2.2. Các chức năng của sản phẩm 2.3. Đặc điểm của người sử dụng 2.4. Các ràng buộc 2.5. Giả thiết và các phụ thuộc
— 2. Mô tả chung
• • • • •
74
— 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng dụng và giao diện. — 4. Phụ lục — 5. Chỉ mục
