Bài giảng Kỹ thuật phần mềm - Phần 3: Phương pháp xác định yêu cầu người dùng

9/13/2011
1
PHẦN III: 
PHƯƠNG PHÁP XÁC ĐỊNH 
YÊU CẦU NGƯỜI DÙNG
I. Tổng quan về yêu cầu phần mềm
II. Quy trình xác định yêu cầu phần mềm
III. Công cụ và phương pháp đặc tả yêu cầu
phần mềm
IV. Nguyên lý phân tích yêu cầu sử dụng
1
1. Khái niệm
• Các đặc tính của hệ thống hay sản phẩm do 
khách hàng - người sử dụng phần mềm - nêu 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
Lĩnh vực ứng
dụng 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
Bài toán của
khách hàng
cần giải quyết
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
2
9/13/2011
2
Tại sao cần phải đặt ra yêu 
cầu phần mềm ?
• 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ọ, 
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ý
3
2. Phân loại
• 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
– Các yêu cầu ngoài chức năng
– Các ràng buộc khác
4
9/13/2011
3
II. 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 
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 
management)
5
Ví dụ: Quy trình xác định yêu cầu
phần mềm hướng đối tượng
Application
Domain 
Objects
SubSystems 
class...
class...
class...
Implementat
ion Domain 
Objects
Source
Code
Test 
Cases
? 
Expressed in 
Terms Of
Structured By
Implemented
By
Realized By Verified 
By
System
Design
Object
Design
Implemen-
tation
Testing
class....? 
Requirements
Elicitation
Use Case
Model
Requirements
Analysis
Or textual requirements
6
9/13/2011
4
1. Phát hiện yêu cầu phần mềm
• Đá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á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)
7
1. Phát hiện yêu cầu phần mềm
• 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.
• 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
• 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.
8
9/13/2011
5
Đầu ra của bước 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 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
• Các nguyên mẫu xây dựng, phát triển hay sử 
dụng 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
2. Phân tích các yêu cầu PM và
thương lượng với khách hàng
S
o
ft
w
a
re
E
n
g
in
e
e
ri
n
g
G
ro
u
p
C
u
s
to
m
e
r 
G
ro
u
p
10
9/13/2011
6
2. Phân tích các yêu cầu PM 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 các nhóm liên quan 
• 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
• 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ầm mềm để xác định 
chúng 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
11
2. Phân tích các yêu cầu PM và
thương lượng với khách hàng
• Thẩm định các rủi ro có thể xảy ra với từng yêu
cầu phần mềm
• Đá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
• 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
12
9/13/2011
7
3. Đặc tả yêu cầu phần mềm
• Đặ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
• 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
– Đặ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 đồ.
• Tiêu chí đánh giá chất lượng của hồ sơ đặc tả:
– Tính rõ ràng, chính xác
– Tính phù hợp
– Tính đầy đủ, hoàn thiện
13
Ví dụ: Các yêu cầu về hồ sơ đặc tả
• Đặ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 
• Dùng như công cụ tham khảo cho bảo trì 
• Sự ghi chép cẩn thận về vòng đời của HT, nghĩa 
là dự đoán các thay đổi
• Các đáp ứng với các sự cố không mong đợi
14
9/13/2011
8
3.1. Các thành phần của hồ sơ đặc tả
• Đặ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, 
– 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 tả mô tả hay đặc tả phi chức năng (Descriptive 
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,
• 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.
15
Đặc tả chức năng
• 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 cài đặt
– Ví dụ: The watch system must display the time based 
on its location
• 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),
– Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự
nhiên.
16
9/13/2011
9
Đặc tả phi chức năng và ràng buộc
• 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, 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ớ, 
• The response time must be less than 1 second
• 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, chuẩn tài liệu, 
• The implementation language must be COBOL
– Các yêu cầu từ bên ngoài
• Must interface to the dispatcher system written in 1956.
• 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
17
3.2. Tài liệu yêu cầu
• Tài liệu về yêu cầu là các phát biểu chính thức về 
cái được yêu cầu bởi các nhà phát triển HT 
• Nó bao gồm cả 2 phần: định nghĩa và đặc tả yêu 
cầu
• 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) 
18
9/13/2011
10
Nội dung cần có của tài liệu yêu cầu
Use the requirements to
develop validation tests for
the system
Use the requirements
document to plan a bid for
the system and to plan the
system development process
Use the requirements to
understand what system is to
be developed
System test
engineers
Managers
System engineers
Specify the requirements and
read them to check that they
meet their needs. They
specify changes to the
requirements
System customers
Use the requirements to help
understand the system and
the relationships between its
parts
System
maintenance
engineers
19
III. Phương pháp và công cụ
đặc tả yêu cầu phần mềm
• Biểu đồ phân cấp chức năng - WBS 
(work break down structure)
• Biểu đồ luồng dữ liệu – DFD (data flow 
diagram)
• Máy trạng thái – FSM (Finite state 
machine)
• Sơ đồ thực thể liên kết – ERD (entity 
relation diagram)
20
9/13/2011
11
1. Đặc tả chức năng với DFD
• 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:
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
21
Ví dụ: mô tả biểu thức toán học bằng
DFD
+
*
* +
b
a
a d
c
(a+b)*(c+a*d)-e*(a+b)
22
9/13/2011
12
Ví dụ đặc tả các chức năng của thư 
viện qua DFD
Có
sách
Tìm theo
chủ đề
Yêu cầu từ người mượn
Kho sách
Danh sách tác giả
Danh sách tên sách
Danh sách chủ đề
Chủ đề yêu cầu Đưa ra 
Tên sách
Danh sách người mượn
Thông tin 
về sách
Sách
Chủ đề
Tên tác giả
Tên sách
Liệt kê các tên sách
liên quan đến chủ đề
Tên sách;
Tên người mượn
Sách
Tên sách, tác giả
Tên người mượn
23
Các hạn chế của DFD
• Ý nghĩa của các ký pháp sử dụng được xác định
bởi các định danh lựa chọn của NSD
• 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
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
. . .
Endif
24
9/13/2011
13
Các hạn chế của DFD
• Trong DFD không xác
định rõ các hướng thực
hiện (control aspects)
• 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.
• Chức năng D có thể cần
cả A, B và 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
A
B
C
D
F
E
25
Các hạn chế của DFD
• DFD không xác định sự đồng bộ giữa các chức 
năng / mô-đun
– A xử lý dữ liệu và B được hưởng (nhận) các kết quả 
được xử lý từ A
– 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
A B
26
9/13/2011
14
2. Đặc tả trạng thái với FSM - Finite 
State Machines 
• FSM chứa
– 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
– Các chức năng chuyển tiếp
•
ON OFF
High pressure alarm
High temp. alarm
Restart
δ : Q x I Q
27
Ví dụ: thư viện
• Xét các giao dịch:
– Mượn sách / Trả sách
– Thêm đầu sách / Loại bỏ đầu sách
– Liệt kê danh sách các đầu sách theo tên tác giả hay theo
chủ đề
– 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ả, . . .
28
9/13/2011
15
Đặc tả các yêu cầu đặc biệt của thư 
viện
• Độ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ộ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 đó, . . .
29
Đặc tả các đối tượng trong thư viện
• Các đối tượng:
– Tên sách
– Mã quyển
– Nhân viên phục vụ
– Người mượn
• 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
30
9/13/2011
16
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: 
– (AV) Available: được phép mượn, 
– (CO) - (BR): đã mượn (Check Out; Borrow), 
– (L): Last, 
– (R): Remove
CO AV BR
L R
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ả, . . .31
3. Đặ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
• ER Model
– Thực thể
– Quan hệ
– Thuộc tính
• Biểu đồ thực thể
32
9/13/2011
17
Thực thể
• 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
• Thực thể có thể có mối quan hệ: 
– person owns car
• Thực thể có các thuộc tính
Person Owns Car
33
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
– đặ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
Car
Ford
Blue
ID
Automobile 
Company
Ford
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.
34
9/13/2011
18
Quan hệ
• Chỉ ra mối liên quan gữa các đối tượng dữ liệu
Bookstore Orders Books
1 N
 Cardinality : chỉ ra định lượng của mối quan hệ
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ệ
Customer
Is 
provided
with
Repair Action
1 N
35
Ví dụ: ERD mô tả thư viện
Area
Title
Author
Deals 
with
Written
by
Belongs to Copy
holds
Was 
held 
by
Borrower
state
1 M
N N
N
Text
1
limit
36
9/13/2011
19
4. Thế nào là một đặc tả tốt? 
• Dễ hiểu với người dùng
• Có ít điề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)
• 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, . . .
37
1. Mô hình hóa dữ liệu
• Xác định các đối tượng dữ liệu
• Xác định các đặc tính của các đối
tượng dữ liệu
• Thiết lập các mối quan hệ giữa các đối
tượng dữ liệu
38
9/13/2011
20
2. Mô hình hóa các chức năng
• Xác định các chức năng chuyển đổi đối
tượng dữ liệu
• Chỉ ra luồng dữ liệu đi qua hệ thống
như thế nào
• Biểu diễn bộ phận sản sinh dữ liệu và
bộ phận tiêu thụ dữ liệu
39
3. Mô hình hóa hành vi
– Chỉ ra các trạng thái (states) khác nhau của 
hệ thống
– Đặc tả các hiện tượng (events) làm hệ 
thống thay đổi trạng thái
40
9/13/2011
21
4. Phân mảnh các mô hình
• Tinh lọc từng mô hình để biểu diễn các
mức trừu tượng thấp hơn
• Lọc đối tượng dữ liệu
• 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
41
5. Bản chất
• 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
42