Bài giảng Nhập môn công nghệ phần mềm - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)
Chương 5: Kỹ nghệ yêu cầu phần
mềm (Requirement Engineering)
• 1. Tổng quan về yêu cầu phần mềm
NHẬP MÔN
• 2. Quy trình xác định yêu cầu phần mềm
CÔNG NGHỆ PHẦN MỀM
(INTRODUCTION TO SOFTWARE
ENGINEERING)
• 3. Phương pháp và công cụ đặc tả yêu cầu
phần mềm
• 4. Nguyên lý phân tích yêu cầu sử dụng
1
2
1
2
Mục đích xác định yêu cầu phần mềm
Khái niệm
• Các đặc tính của hệ thống hay sản phẩm do
• 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 dựng để phục vụ
công việc của họ.
• Cho nên chúng ta 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 rất hay thay đổi các đòi hỏi của
mình, chúng ta nắm bắt được các thay đổi đó
và sửa đổi các mô tả một cách hợp lý
khách hàng - người sử dụng PM - đặt ra à Xác
định được phần mềm đáp ứng được các yêu cầu và mong
muốn của khách hàng - người sử dụng phần mềm
Bài toán của khách
Lĩnh vực ứng dụng
hàng cần giải quyết
của hệ thống/sản
phẩm
Nhu cầu và ràng buộc
của những người có
quyền lợi và nghĩa vụ
liên quan đến hệ thống
/sản phẩm
Ngữ cảnh nghiệp vụ: tương tác
của hệ thông/sản phẩm và đóng
góp về mặc nghiệp vụ của hệ
thống
3
4
Phân loại yêu cầu
2. Quy trình xác định yêu cầu PM
• Phát hiện các yêu cầu phần mềm (Requirements
• Theo 4 thành phần của phần mềm:
– Các yêu cầu về phần mềm (Software)
– Các yêu cầu về phần cứng (Hardware)
– Các yêu cầu về dữ liệu (Data)
– Các yêu cầu về con người (People, Users)
• Theo cách đặc tả phần mềm
– Các yêu cầu chức năng
elicitation)
• Phân tích các yêu cầu phần mềm và thương lượng với
khách hàng (Requirements analysis and negotiation)
• Đặc tả các yêu cầu phần mềm (Requirements
specification)
• Mô hình hóa hệ thống (System modeling)
• Kiểm tra tính hợp lý của các yêu cầu phần mềm
(Requirements validation)
• Quản trị các yêu cầu phần mềm (Requirements
– Các yêu cầu ngoài chức năng
– Các ràng buộc khác
management)
5
6
5
6
Phát hiện yêu cầu phần mềm
Quy trình xác định yêu cầu PM (tiếp)
Xây dựng
mộnguyên mẫu
(prototype)
• Đánh giá tính khả thi về kỹ thuật và nghiệp vụ
của phần mềm định phát triển
• Tìm kiếm các nhân sự (chuyên gia, người
sử dụng) có những hiểu biết sâu sắc nhất,
chi tiết nhất về hệ thống giúp chúng ta xác
định yêu cầu phần mềm
Xáđịnh
yêu cầu
Phát triển
đặc điểm kỹ thuật
Xem
duyệt
Vấn đề
• Xác định môi trường kỹ thuật trong đó sẽ
triển khai phần mềm
• Xác định các ràng buộc về lĩnh vực ứng dụng
của phần mềm (giới hạn về chức năng/hiệu
năng phần mềm)
Tạra
mhình
phân tích
Last Update8-07
Dept. of SE, 2002
SE-III.7
8
Đầu ra của bước phát hiện yêu cầu
phần mềm
Phát hiện yêu cầu phần mềm
• Bảng kê (statement) các đòi hỏi và chức năng khả thi
• Xác định các phương pháp sử dụng để phát hiện
các yêu cầu phần mềm: phỏng vấn, làm việc
nhóm, các buổi họp, gặp gỡ đối tác, v.v.
của phần mềm
• Bảng kê phạm vi ứng dụng của phần mềm
• Mô tả môi trường kỹ thuật của phần mềm
• Bảng kê tập hợp các kịch bản sử dụng của phần mềm
• Thu hút sự tham gia của nhiều chuyên gia, khách
hàng để chúng ta có được các quan điểm xem xét
phần mềm khác nhau từ phía khách hàng
• Các nguyên mẫu xây dựng, phát triển hay sử dụng
• Xác định các yêu cầu còn nhập nhằng để làm mẫu
thử
• Thiết kế các kịch bản sử dụng của phần mềm để
giúp khách hàng định rõ các yêu cầu chính.
trong phần mềm (nếu có)
• Danh sách nhân sự tham gia vào quá trình phát hiện
các yêu cầu phần mềm - kể cả các nhân sự từ phía công
ty- khách hàng
9
10
9
10
Phân tích các yêu cầu PM và
thương lượng với khách hàng
Phân tích các yêu cầu phần mềm và
thương lượng với khách hàng
Phân tích
Cần
thiết ?
Nhất quán +
đầy đủ ?
Khả
thi ?
Yêu cầu không cần
thiết
Yêu cầu không đầy đủ,
yêu cầu mâu thuẫn
Yêu cầu không khả
thi
Thương lượng
Thảo luận
về các
yêu cầu
Đặt thứ tự ưu
ên cho các yêu
cầu
Nhất trí
về các
yêu cầu
11
12
Phân tích các yêu cầu phần mềm và
thương lượng với khách hàng
Phân tích các yêu cầu phần mềm và
thương lượng với khách hàng
• Phân loại các yêu cầu phần mềm và sắp xếp chúng theo
• Thẩm định các rủi ro có thể xảy ra với từng yêu
các nhóm liên quan
cầu phần mềm
• Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan
hệ của nó với các yêu cầu phần mềm khác
• Đánh giá thô (tương đối) về giá thành và thời gian
thực hiện của từng yêu cầu phần mềm trong giá
thành sản phẩm phần mềm và thời gian thực
hiện phần mềm
• Thẩm định từng yêu cầu phần mềm theo các tính chất:
phù hợp, đầy đủ, rõ ràng, không trùng lặp
• Phân cấp các yêu cầu phần mềm theo dựa trên nhu cầu
và đòi hỏi khách hàng / người sử dụng
• Thẩm định từng yêu cầu phần mềm để xác định:
• Giải quyết tất cả các bất đồng về yêu cầu phần
mềm với khách hàng / người sử dụng trên cơ sở
thảo luận và thương lượng các yêu cầu đề ra
– Các yêu cầu PM có khả năng thực hiện được trong môi
trường kỹ thuật hay không
– Có khả năng kiểm định các yêu cầu phần mềm hay không
13
14
13
14
Đặc tả yêu cầu phần mềm
Ví dụ: Các yêu cầu về hồ sơ đặc tả
• Đặc tả các yêu cầu phần mềm: xây dựng các tài liệu đặc tả, trong đó
có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học
hình thức (a formal mathematical model), tập hợp các kịch bản sử
dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên
• Đặc tả hành vi bên ngoài của HT
• Đặc tả các ràng buộc về cài đặt
• Dễ thay đổi
• Phương pháp đặc tả:
– Đặc tả phi hình thức (Informal specifications): viết bằng ngôn ngữ tự
nhiên
• Dùng như công cụ tham khảo cho bảo trì
– Đặc tả hình thức (Formal specifications): viết bằng tập các ký pháp có
các quy định về cú pháp (syntax) và ngữ nghĩa (sematic) rất chặt chẽ,
thí dụ ký pháp đồ họa dùng các lưu đồ.
• Sự ghi chép cẩn thận về vòng đời của HT,
• Tiêu chí đánh giá chất lượng của hồ sơ đặc tả:
nghĩa là dự đoán các thay đổi
– Tính rõ ràng, chính xác
– Tính phù hợp
– Tính đầy đủ, hoàn thiện
• Các đáp ứng với các sự cố không mong đợi
15
16
Các thành phần của hồ sơ đặc tả
Đặc tả chức năng
• Đặc tả vận hành hay đặc tả chức năng (Operational specifications):
mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng:
– Các dịch vụ mà hệ thống phải cung cấp
• Miêu tả các chức năng của hệ thống, phụ thuộc vào
kiểu phần mềm và mong đợi của người dùng
– Tương tác giữa phần mềm và môi trường, độc lập với việc
– Hệ thống sẽ phản ứng với đầu vào cụ thể ra sao
– Hành vi của hệ thống trong các tình huống đặc biệt.
cài đặt
– Ví dụ: Hệ thống đồng hồ phải hiển thị thời gian dựa trên vị
• Đặc tả mô tả hay đặc tả phi chức năng (Descriptive
trí của nó
specifications): đặc tả các đặc tính, đặc trưng của phần mềm:
– Các ràng buộc về các dịch vụ hay các chức năng hệ thống cung
cấp như thời gian, ràng buộc về các quá trình phát triển, các
chuẩn,…
• Các công cụ đặc tả tiêu biểu:
– Biểu đồ luồng dữ liệu (Data Flow Diagrams)
– Máy trạng thái hữu hạn (Finite State Machines)
– Mạng Petri (Petri nets),…
• Ngoài ra còn có yêu cầu về lĩnh vực, bắt nguồn từ lĩnh vực
của ứng dụng hệ thống và các đặc trưng của lĩnh vực này.
– Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự
nhiên.
17
18
17
18
Đặc tả phi chức năng và ràng buộc
Tài liệu yêu cầu
•
Yêu cầu phi chức năng: Định nghĩa các khía cạnh sử dụng phần mềm,
• Tài liệu về yêu cầu là các phát biểu chính thức
không liên quan trực tiếp tới các hành vi chức năng:
–
Các tính chất của hệ thống như độ tin cậy, thời gian trả lời, dung lượng bộ
nhớ, …
về cái được yêu cầu bởi các nhà phát triển HT
•
Thời gian trả lời phải nhỏ hơn 1 giây
• Nó bao gồm cả 2 phần: định nghĩa và đặc tả
•
•
Ràng buộc: do khách hàng hay môi trường thực thi phần mềm đặt ra
–
Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành,
yêu cầu
chuẩn tài liệu, …
•
Ngôn ngữ cài đặt phải là COBOL
Các yêu cầu từ bên ngoài
Phải giao tiếp với hệ thống điều phối được viết vào năm 1956.
–
• Nó không phải là tài liệu thiết kế. Tốt hơn có
thể nó chỉ là 1 tập các cái mà HT phải làm hơn
là HT phải làm thế nào (PT chứ không phải là
TK)
•
Thường sử dụng các công cụ
–
–
–
Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)
Đặc tả Logic (Logic Specifications)
Đặc tả đại số (Algebraic Specifications)
à
Khó phát biểu chính xác, Rất khó kiểm tra
19
20
3. Phương pháp và công cụ đặc tả yêu
cầu phần mềm
Nội dung cần có của tài liệu yêu cầu
Xác định các yêu cầu, đọc hiểu để kiểm tra
Khách hàng hệ thống
xem có đúng với nhu cầu hay không. Họ xác
định các thay đổi về yêu cầu.
• Biểu đồ phân cấp chức năng - WBS (work
break down structure)
Sử dụng tài liệu về yêu cầu để lên kế hoạch
đấu thầu cho hệ thống và lên kế hoạch cho
quá trình phát triển hệ thống
• Biểu đồ luồng dữ liệu – DFD (data flow
Nhà quản lý
diagram)
Sử dụng yêu cầu để hiểu về hệ thống sẽ phát
triển
• Máy trạng thái – FSM (Finite state machine)
Kỹ sư hệ thống
• Sơ đồ thực thể liên kết – ERD (entity relation
Sử dụng yêu cầu để phát triển các trường hợp
kiểm thử cho hệ thống
Kỹ sư kiểm thử hệ thống
diagram)
Sử dụng yêu cầu để hiểu về hệ thống và mối
iên hệ giữa các phấn khác nhau của hệ thống
Kỹ sư bảo trì hệ thống
21
22
21
22
Ví dụ: mô tả biểu thức toán học bằng
Đặc tả chức năng với DFD
DFD
(a+b)*(c+a*d)-e*(a+b)
• Hệ thống (System): tập hợp các dữ liệu (data) được xử
lý bằng các chức năng tương ứng (functions)
• Các ký pháp sử dụng:
b
c
a
d
a
Thể hiện các chức năng (functions)
Thể hiện luồng dữ liệu
Kho dữ liệu
+
*
*
+
Vào ra dữ liệu và tương tác giữa
hệ thống và người sử dụng
23
24
Ví dụ đặc tả các chức năng của thư
Các hạn chế của DFD
viện qua DFD
Yêu cầu từ người mượn
• Ý nghĩa của các ký pháp sử dụng được xác định
Tên sách, tác giả
Tên người mượn
Sách
bởi các định danh lựa chọn của NSD
Kho sách
• Ví dụ: DFD của chức năng tìm kiếm sách:
If NSD nhập vào cả tên tác giả và tiêu đề sách Then
tìm kiếm sách tương ứng, không có thì thông báo lỗi
Elseif chỉ nhập tên tác giả Then
Sách
Tên tác giả
Có
sách
Thông tin
về sách
Danh sách tác giả
Tên sách
Tên sách;
Tên người mượn
Danh sách tên sách
Danh sách người mượn
hiển thị danh sách các sách tương ứng với
tên tác giả đã nhập và yêu cầu NSD lựa chọn sách
Elseif chỉ nhập tiêu đề sách Then
. . .
Danh sách chủ đề
Liệt kê các tên sách
liên quan đến chủ đề
Tìm theo
chủ đề
Chủ đề
Chủ đề yêu cầu
Đưa ra
Tên sách
Endif
25
26
25
26
Các hạn chế của DFD
Các hạn chế của DFD
•
•
•
•
•
Chức năng D có thể cần cả A, B và
•
Trong DFD không xác định rõ các
hướng thực hiện (control aspects)
• DFD không xác định sự đồng bộ giữa các chức
C
Chức năng D có thể chỉ cần một
trong A, B và C để thực hiện
Chức năng D có thể kết xuất kết
quả cho một trong E và F
Chức năng D có thể kết xuất kết
quả chung cho cả E và F
Chức năng D có thể kết xuất kết
quả riêng cho cả E và F
năng / mô-đun
– A xử lý dữ liệu và B được hưởng (nhận) các kết
A
E
quả được xử lý từ A
B
C
D
F
– A và B là các chức năng không đồng bộ
(asynchronous activities) vì thế cần có buffer để
ngăn chặn tình trang mất dữ liệu
•
Biểu đồ DFD này không chỉ rõ đầu
vào là gì để thực hiện chức năng
D và đầu ra là gì sau khi thực hiện
chức năng D.
A
B
27
28
Đặc tả trạng thái với FSM - Finite
State Machines
Ví dụ: quản lý thư viện
• FSM chứa
• Xét các giao dịch:
– Tập hữu hạn các trạng thái Q
– Tập hữu hạn các đầu vào I
– Mượn sách / Trả sách
– Thêm đầu sách / Loại bỏ đầu sách
– Các chức năng chuyển tiếp
– Liệt kê danh sách các đầu sách theo tên tác giả
δ : Q x I à Q
hay theo chủ đề
•
Báo động áp lực cao
– Tìm kiếm sách theo các yêu cầu của người mượn
– Tìm kiếm sách quá hạn trả, . . .
Báo động nhiệt độ cao
ON
OFF
Khởi động lại
29
30
29
30
Đặc tả yêu cầu
Đặc tả các đối tượng
• Các đối tượng:
– Tên sách
• Độc giả không được mượn quá một số lượng
sách nhất định, trong một thời gian nhất định
– Mã quyển
– Nhân viên phục vụ
– Người mượn
• Một số sách không được mượn về
• Một số người không được mượn một số loại
sách nào đó, . . .
• Cần có:
– tập hợp (danh sách) các tiêu đề sách
– danh sách các tác giả cho từng quyển sách,
– danh sách các chủ đề liên quan của các quyển sách
31
32
Đặc tả dữ liệu với
Mô hình thực thể liên kết -ERD
• Mô hình khái niệm cho phép đặc tả các yêu
cầu logic của hệ thống, thường được sử dụng
trong các hệ thống dữ liệu lớn
FSM đặc tả trạng thái
• Ta có tập hợp các sách (mỗi đầu sách có thể có
nhiều quyển sách trong thư viện).
• Mỗi quyển sách có thể có 1 trong 5 trạng thái
sau:
• ER Model
– Thực thể
– Quan hệ
– (AV) Available: được phép mượn,
– (CO) - (BR): đã mượn (Check Out; Borrow),
– (L): Last,
CO
AV
BR
– Thuộc tính
– (R): Remove
• Biểu đồ thực thể
L
R
33
34
Có thể có hạn chế về số sách được mượn cho 1 nhóm độc giả hoặc mọi độc giả, . . .
33
34
Thực thể
Thuộc tính
• Tính chất của một thực thể hoặc một đối
tượng dữ liệu
• Thực thể : tập hợp các thông tin liên quan cần
được xử lý trong phần mềm
– đặt tên cho 1 mẫu (instance) của đối tượng dữ liệu
– mô tả mẫu (instance)
– tạo liên kết (reference) đến các mẫu khác
• Thực thể có thể có mối quan hệ:
– người sở hữu ôtô
Ford
Người
sở hữu
Ôtô
Automobile
Company
Blue
Car
Ford
ID
• Thực thể có các thuộc tính
Tập các thuộc tính của 1 đối tượng dữ liệu được xác định thông
qua ngữ cảnh của bài toán.
35
36
Quan hệ
Ví dụ: ERD mô tả thư viện
Area
• Chỉ ra mối liên quan gữa các đối tượng dữ liệu
N
1
N
Deals
with
Bookstore
Books
Orders
Copy
state
Belongs to
1
N
N
Ø Cardinality : chỉ ra định lượng của mối quan hệ
Title
1:1 one-to-one 1:N one-to-many M:N many-to-many
Ø Modality : 0 – có thể có, có thể không có quan hệ
1 – bắt buộc có quan hệ
Was
held
by
Text
holds
Written
by
1
M
Is
Author
1
N
Borrower
Customer
Repair Action
provided
with
limit
37
38
37
38
So sánh
FSM
Thế nào là một đặc tả tốt?
DFD
ERD
• Dễ hiểu với người dùng
• Có ít điều nhập nhằng
Đơn giản, dễ hiểu.
Có thể phức tạp với số
lượng trạng thái lớn
Đơn giản, dễ hiểu
Mô tả trạng thái của thực
thể
• 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)
Mô tả luồng dữ liệu
Mô tả trừu tượng cơ sở
dữ liệu
Xác định rõ hướng thực
Không xác định rõ hướng hiện
thực hiện
Không xác định rõ hướng
thực hiện
• Dễ triển khai cho những pha sau của vòng đời:
thiết kế hệ thống và thiết kế chương trình và
giao diện dễ làm, đảm bảo tính nhất quán, . . .
Thể hiện tốt tính song
song và tuần tự
Không thể hiện tính tuần
tự hay song song của tiến
trình
Không thể hiện tính tuần
tự hay song song
39
40
2.1
D Customer 1
Master
Order
Thế nào là một đặc tả tốt?
Customer
Verify
Customer
Need to
establish
Valid
Khách hàng mới
2.2
D Inventory 2
Master
Order
Notify
Update
2.4
Mặt hàng
Đặt hàng
Customer
Verify
Item
Hệ thống
Hoá đơn
Kho hàng
Phiếu hàng
Khách hàng
đặt hàng
Update
Commit
Thông báo
chuyển hàng
Avail
Valid
Item
2.3
D Shipping 4
Taxes
Check
Available
Tax
2.5
Ord D Inventory 2
Master
Back
Order
3
Create
Order
D Back
Order
Pending Order
41
42
41
42
4. Nguyên lý phân tích yêu cầu sử
dụng
Mô hình hóa các chức năng
Mô hình hóa dữ liệu
• Xác định các chức năng chuyển đổi đối tượng
dữ liệu
• Xác định các đối tượng dữ liệu
• Chỉ ra luồng dữ liệu đi qua hệ thống như thế
• Xác định các đặc tính của các đối tượng dữ
nào
liệu
• Biểu diễn bộ phận sản sinh dữ liệu và bộ phận
• Thiết lập các mối quan hệ giữa các đối tượng
tiêu thụ dữ liệu
dữ liệu
43
44
Mô hình hóa hành vi
Phân mảnh các mô hình
• Chỉ ra các trạng thái (states) khác nhau của hệ
• Tinh lọc từng mô hình để biểu diễn các mức
thống
trừu tượng thấp hơn
• Đặc tả các hiện tượng (events) làm hệ thống
• Lọc đối tượng dữ liệu
thay đổi trạng thái
• Tạo ra phân cấp chức năng
• Biểu diễn hành vi (behavior) ở các mức chi tiết
khác nhau
45
46
45
46
Bản chất của việc phân tích
• Hãy bắt đầu bằng cách tập trung vào bản chất
của vấn đề chứ không xem xét những chi tiết
cài đặt
47
12 trang
19740
Free
Bạn đang xem tài liệu "Bài giảng Nhập môn công nghệ phần mềm - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_nhap_mon_cong_nghe_phan_mem_chuong_6_ky_nghe_yeu_c.pdf
