Kỹ thuật yêu cầu

1
Chương 3
Kỹ thuật yêu cầu
(Requirement Engineering)
2
Nội dung
1. Kỹ thuật yêu cầu là gì
2. Xác định yêu cầu hệ thống là gì
3. Các loại yêu cầu hệ thống
4. Quy trình RE
3
1. Kỹ thuật yêu cầu là gì
(Requirement Engineering)
•
Ta dùng Requirement Engineering thay cho Requirement
Analysis
•
RE là quá trình lặp bao gồm 3 hoạt động:
–
Rút ra yêu cầu từ thực tế (Elicitation)
–
Đặc tả yêu cầu (Specification)
–
Xác thực (Validation)
•
Kết quả của quá trình RE là những đặc tả về hệ thống phần
mềm
4
2. Yêu cầu (Requirement ) là gì?
Requirements described the “what” of a system,
not the “how”

Mô tả cái gì cần cho hệ thống
Mô tả cái gì cần cho hệ thống
5
Yêu cầu phần mềm
•
Phản ánh sự hiểu biết lẫn nhau về vấn đề giữa người phân tích
và khách hàng
•
Nền tảng để xây dựng hợp đồng
•
Là sự chuẩn bị cho giai đoạn tiếp theo (giai đoạn phân tích)
•
Là tài liệu để kiểm tra hệ thống khi được phát hành
6
Input/ Output của xác định yêu cầu
•
Input:
–
Các yêu cầu từ khách hàng (Problem statement prepared by
the customers)
•
Output:
–
Tài liệu đặc tả yêu cầu ( Software requirements specification
– SRS)
7
Mức độ mô tả yêu cầu
•
Yêu cầu người dùng:
–

Chủ yếu dành cho người dùng
–
Viết bằng ngôn ngữ tự nhiên và biểu đồ
–
Mô tả dịch vụ và ràng buộc hoạt động
•
Yêu cầu hệ thống:
–
Tài liệu có cấu trúc mô tả chức năng, dịch vụ và ràng buộc
hoạt động của hệ thống
–
Có thể là một phần của hợp đồng
8
Người đọc
9
3. Các loại yêu cầu hệ thống
•
Các yêu cầu của hệ thống phần mềm thường được chia thành ba
loại:
–
Yêu cầu chức năng
–
Yêu cầu phi chức năng
–
Yêu cầu miền ứng dụng
•
Thực tế khó phân biệt ba loại yêu cầu này một cách rõ ràng.
10
03/12/13 10
Yêu cầu chức năng

•
Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các
chức năng hoặc các dịch vụ của hệ thống một cách chi tiết.
•
Đặc điểm của yêu cầu chức năng:
–
Tính mập mờ, không rõ ràng của các yêu cầu:
•
Vấn đề này xảy ra khi các yêu cầu không được xác định
một cách cẩn thận.
–
Tính hoàn thiện và nhất quán:
•
Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết
và không có sự xung đột hoặc đối ngược giữa các yêu
cầu.
11
Ví dụ
•
Trong hệ thống quản lý thư viện:
–
Người dùng được cấp tài khoản riêng
–
Người dùng có thể tìm kiếm; download; in các bài báo
–
Người dùng có thể được cấp một vùng riêng để lưu dữ liệu
12
03/12/13 12
Yêu cầu phi chức năng
•

Yêu cầu phi chức năng không đề cập trực tiếp tới các chức
năng cụ thể của hệ thống.
•
Yêu cầu phi chức năng thường định nghĩa các thuộc tính như:
–
độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ …
–
các ràng buộc của hệ thống (khả năng của thiết bị vào/ra,
giao diện …)
•
Một số yêu cầu phi chức năng còn có liên quan đến quy trình
xây dựng hệ thống (các chuẩn được sử dụng, các công cụ
CASE, ngôn ngữ lập trình …)
•
Các yêu cầu phi chức năng có thể hạn chế những yêu cầu chức
năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ
không sử dụng được.
13
3 yêu cầu phi chức năng cơ bản
•
Yêu cầu về sản phẩm:
–
Hiệu năng
–
Khả năng sử dụng
–
Độ tin cậy … của sản phẩm
•
Yêu cầu về mặt tổ chức:
–

Cơ cấu tổ chức; Chính sách của tổ chức
–
Thời gian bàn giao
–
Tương thích với hệ thống cũ
•
Yêu cầu ngoài:
–
Do các tác nhân ngoài hệ thống
–
Tính pháp lý
–
Tính riêng tư
14
03/12/13 14
Lý do xuất hiện yêu cầu phi chức năng
•
Yêu cầu của người sử dụng
•
Ràng buộc về ngân sách
•
Các chính sách của tổ chức sử dụng hệ thống
•
Yêu cầu tương thích giữa phần cứng và phần mềm
•
Các tác nhân ngoài khác
15
15
Ví dụ về yêu cầu phi chức năng
•

Xác định các yêu cầu phi chức năng của Hệ thống đặt vé tàu
trước
–
Yêu cầu về sản phẩm: phải xây dựng website
–
Yêu cầu về mặt tổ chức: mạng máy tính nối tất cả các trạm
xe lửa với nhau.
–
Yêu cầu ngoài: Hệ thống phải bảo mật
16
03/12/13 16
Ví dụ về yêu cầu phi chức năng
•
Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được
của Hệ thống đặt vé tàu trước
–
Mục tiêu của hệ thống là dễ sử dụng đối với nhân viên cũng
như hành khách và được tổ chức để sao cho tối thiểu hoá
được lỗi.
–
Các yêu cầu phi chức năng có thể thẩm định được: Những
người nhân viên sử dụng có kinh nghiệm có thể sử dụng
được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập
huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra
bởi người sử dụng là không quá hai lỗi một ngày.
17
03/12/13 17
Yêu cầu miền ứng dụng
•
Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của

hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng
dụng.
•
Nó có thể là yêu cầu chức năng hoặc phi chức năng.
•
Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể hệ
thống sẽ không làm việc được.
•
Một số vấn đề liên quan đến yêu cầu miền ứng dụng:
–
Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới
ngôn ngữ của lĩnh vực ứng dụng.
–
Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng
họ không biết cách xây dựng những yêu cầu miền ứng dụng
một cách rõ ràng, mang tính kỹ thuật.
18
Một số ràng buộc
•
Ràng buộc trước sau
•
Ràng buộc cấu trúc
•
Ràng buộc suy diễn
•
Ràng buộc thời gian
Môn học loại cơ sở phải học
trước môn học loại chuyên
ngành
Điểm giữa kỳ <4 thì thi lại, nếu thi

lại <4 thì học lại, nếu >=4 thì
được thi cuối kỳ
Dựa vào luật
Lương kỳ 1 phải trả trước ngày 5
hàng tháng
Khi người dùng nhấn Enter thì
chỉ trong 2 giây thì hệ thống phải
hồi đáp
19
4. Quy trình RE
•
Thu thập yêu cầu (Requirement Elicitation)
•
Phân tích yêu cầu (Requirement Analysis)
•
Tạo tài liệu đặc tả yêu cầu (Requirement Documentation)
•
Đánh giá yêu cầu (Requirement Review)
20
21
Bước 1: Thu thập yêu cầu
(Requirement Elicitation)
•
Mục đích
•
Nội dung cần thu thập
•
Những khó khăn
•
Các kỹ thuật

22
Mục đích
•
Tiếp cận với nghiệp vụ, chuyên môn, môi trường hoạt động của
hệ thống
•
Tìm hiểu các chức năng, nhiệm vụ và cung cách hoạt động của
hệ thống
•
Chỉ ra những chỗ hợp lý cần được kế thừa, những chỗ bất hợp
lý cần khắc phục
23
Nội dung cần thu thập
•
Đánh giá tính khả thi về nghiệp vụ và kỹ thuật của hệ thống
•
Nhận biết xem ai sẽ giúp xác định yêu cầu và hiểu biết thực
chất của tổ chức
–
Operation manager, product manager
–
Makerting people
–
Internal/external customer
–
End-users
–
Consultant
–
Product engineer, Software engineer

•
Xác định môi trường kỹ thuật
•
Nhận biết các ràng buộc nghiệp vụ (domain constraint)
24
Những khó khăn thường gặp
1. Khó khăn về phạm vi (Problems of scope): đường biên hệ
thống thường mập mờ, hay khách hàng chỉ nhắm đến các yếu tố
kỹ thuật hơn là mục tiêu tổng thể của hệ thống
2. Khó khăn về hiểu biết khách hàng: khách hàng không biết họ
cần gì, có ý kiến trái ngược nhau về hệ thống cần xây dựng, ít
hiểu biết về kỹ thuật, thời gian giao tiếp với kỹ sư hệ thống
thường rất hạn chế.
3. Khó khăn về tính ổn định: yêu cầu thường thay đổi theo thời
gian
25
Các kỹ thuật thu thập yêu cầu
•
Các kỹ thuật thu thập yêu cầu:
–
Phỏng vấn (Interview)
•
Chọn lựa stakeholder để phỏng vấn
–
Phiếu điều tra (questionnaire)
–
Thu thập tài liệu : biểu mẫu, báo cáo, thống kê, số liệu,…
–
Phiên họp động não ( brainstorm session): kỹ thuật thảo luận nhóm
giúp tìm ra nhanh chóng những ý tưởng mới

–
Sử dụng kịch bản (scenario) để phát hiện các yêu cầu của hệ thống.
•
Tạo các kịch bản (scenario) để giúp khách hàng/người dùng xác định tốt
hơn các yêu cầu chính của hệ thống
•
Một tập hợp các use case sẽ mô tả tất cả các tương tác có thể trong hệ
thống.