Bài giảng Công nghệ phần mềm - Bài 2: Xác định yêu cầu - Lê Nguyễn Tuấn Thành

Công nghệ Phần mềm 
Xác định Yêu cầu 
Giảng viên: Lê Nguyễn Tuấn Thành 
Email: thanhlnt@tlu.edu.vn 
Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT 
Trường Đại Học Thủy Lợi 
Nội dung 
2 
 Yêu cầu Phần mềm 
 Quy trình Kỹ thuật tạo Yêu cầu 
Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007” 
1. Yêu cầu Phần mềm 
(Software Requirements) 
3 
Mục tiêu 
4 
 Giới thiệu khái niệm về Yêu cầu người dùng và Yêu cầu 
hệ thống 
 Miêu tả Yêu cầu chức năng và Yêu cầu phi chức năng 
 Giải thích cách những yêu cầu phần mềm được tổ chức 
trong một tài liệu yêu cầu 
Những chủ đề được đề cập 
(Topics covered) 
5 
 Yêu cầu người dùng và Yêu cầu hệ thống 
 Yêu cầu chức năng và Yêu cầu phi chức năng 
 Tài liệu yêu cầu phần mềm 
Yêu cầu là gì? 
(Requirement?) 
6 
 Yêu cầu có thể là: 
 phát biểu trừu tượng ở mức cao về một dịch vụ 
hoặc 
 một rằng buộc hệ thống đến một đặc tả chức 
năng toán học cụ thể 
Phân biệt: Yêu cầu và Thiết kế 
(Requirements and Design) 
7 
 Về nguyên tắc, yêu cầu nên phát biểu về CÁI (what) mà 
hệ thống nên làm, còn thiết kế nên miêu tả CÁCH (how) 
hệ thống làm điều đó 
 Trong thực tế, yêu cầu và thiết kế là không thể tách rời 
Sự đầy đủ và nhất quán của yêu cầu 
(Requirements completeness & consistency) 
8 
 Về nguyên tắc, những yêu cầu nên phải hoàn thiện và 
nhất quán 
 Hoàn thiện 
 Yêu cầu nên bao gồm miêu tả về tất cả các phương tiện, khía 
cạnh cần thiết 
 Nhất quán 
 Không nên có xung đột (conflicts) hoặc mâu thuẫn 
(contradictions) trong những yêu cầu 
 Trên thực tế, không thể tạo ra một tài liệu yêu cầu hoàn 
thiện và nhất quán 
Case study: Hệ thống LIBSYS 
9 
 Một hệ thống quản lý thư viện cung cấp một giao diện 
đơn cho một số lượng cơ sở dữ liệu bài báo trong 
những thư viện khác nhau, 
 Người dùng có thể tìm kiếm, tải về hoặc in những bài 
báo này cho mục đích học tập cá nhân 
Phân loại Yêu cầu 
10 
•Yêu cầu người dùng 
•Yêu cầu hệ thống 
•Yêu cầu chức năng 
•Yêu cầu phi chức năng 
Yêu cầu Người dùng vs Hệ thống 
11 
 Yêu cầu người dùng 
 Những phát biểu bằng ngôn ngữ tự nhiên cộng với sơ đồ 
(diagram) về những dịch vụ hệ thống sẽ cung cấp và những 
rằng buộc vận hành của nó. 
 Được viết cho/bởi khách hàng. 
 Yêu cầu hệ thống 
 Một tài liệu có cấu trúc đưa ra những mô tả chi tiết về 
chức năng hệ thống, dịch vụ và rằng buộc vận hành. 
 Được dự định là một cơ sở để thiết kế hệ thống 
 Có thể được định nghĩa hoặc minh hoạ sử dụng mô hình 
hệ thống (system models) 
VD: Yêu cầu Người dùng và Hệ thống 
12 
 Yêu cầu người dùng 
 Phần mềm phải cung cấp một cách thức để biểu diễn và truy cập 
những tệp bên ngoài được tạo bởi những công cụ khác 
 Đặc tả những yêu cầu hệ thống 
1. Người dùng nên được cung cấp các phương tiện (facilities) để 
định nghĩa kiểu của những tệp tin ngoài (external files) 
2. Mỗi kiểu tệp tin ngoài nên có một công cụ đi kèm có thể áp dụng 
cho kiểu tệp tin đó 
3. Mỗi kiểu tệp tin ngoài nên được biểu diễn bằng một biểu tượng 
cụ thể (specific icon) trên màn hình của người dùng 
4. Các phương tiện nên được cung cấp cho biểu tượng biểu diễn 
một kiểu tệp tin ngoài được định nghĩa bởi người dùng 
5. Khi người dùng chọn một biểu tượng biểu diễn tệp tin ngoài, hiệu 
ứng của việc lựa chọn đó là sử dụng công cụ liên kết với kiểu tệp 
ngoài đó cho tệp tin được biểu diễn bởi công cụ lựa chọn 
13 
Insulin Pump / Phần mềm kiểm soát / SRS / 3.3.2 
Chức năng Tính liều insulin: Mức đường an toàn 
Miêu tả Tính toán lượng insulin được cung cấp khi mức đường đo được hiện tại 
nằm trong vùng an toàn giữa 3 và 7 đơn vị. 
Đầu vào Lượng đường đọc được hiện tại (r2), hai lượng đường ở lần đọc trước (r0 
và r1) 
Nguồn Lượng đường đọc từ cảm biến. Những lần đọc khác từ bộ nhớ. 
Đầu ra Compdose - liều lượng insulin được cung cấp 
Miêu tả Vòng điều khiển chính 
Hành động CompDose có giá trị 0 nếu mức đường ổn định hoặc giảm xuống hoặc 
nếu mức độ đang tăng lên nhưng tỷ lệ tăng đang giảm. Nếu mức độ đang 
tăng và tỷ lệ tăng lại đang tăng lên, thì CompDose được tính bằng cách 
chia sự khác biệt giữa mức đường hiện tại và mức trước đó cho 4 và làm 
tròn kết quả. Nếu kết quả, được làm tròn bằng 0, thì CompDose được đặt 
ở liều tối thiểu có thể được phân phối. 
Yêu cầu Hai lần đọc trước đó để có thể tính tỷ lệ thay đổi của mức đường. 
Điều kiện trước Túi insulin chứa ít nhất một liều đơn tối đa cho phép của insulin 
Điều kiện sau r0 được thay thế bởi r1 sau đó r1 được thay thế bằng r2 
Ảnh hưởng phụ Không có 
Đối tượng của những kiểu yêu cầu 
14 
Yêu cầu người dùng 
(User requirements) 
• Nhà quản lý phía khách hàng (Client managers) 
• Người dùng cuối của hệ thống (System end-users) 
• Kỹ sư phía khách hàng (Client engineers) 
• Nhà quản lý phía nhà thầu (Contractor managers) 
• Kỹ sư hệ thống (System architects) 
Yêu cầu hệ thống 
(System requirements) 
• Người dùng cuối của hệ thống (System end-users) 
• Kỹ sư phía khách hàng (Client engineers) 
• Kỹ sư hệ thống (System architects) 
• Lập trình viên phần mềm (Software developers) 
Đặc tả thiết kế phần 
mềm 
(Software design 
specification) 
• Kỹ sư phía khách hàng (Client engineers) [có thể] 
• Kỹ sư hệ thống (System architects) 
• Lập trình viên phần mềm (Software developers) 
Yêu cầu Chức năng vs Phi chức năng 
(Functional and non-functional requirements) 
15 
 Yêu cầu chức năng 
 Những tuyên bố (statements) về dịch vụ hệ thống nên cung 
cấp, cách hệ thống nên phản ứng với những đầu vào cụ thể 
và cách hệ thống nên hành xử trong những tình huống cụ 
thể 
 Yêu cầu phi chức năng 
 Những rằng buộc trên những dịch vụ hoặc chức năng 
được cung cấp bởi hệ thống như rằng buộc về thời gian, 
rằng buộc về tiến trình phát triển, về các chuẩn,  
Yêu cầu chức năng 
(Functional requirements) 
16 
 Mô tả chức năng hoặc dịch vụ hệ thống 
 Phụ thuộc vào kiểu phần mềm, mong muốn của người 
dùng và kiểu của hệ thống nơi mà phần mềm được sử 
dụng 
 Những yêu cầu chức năng người dùng có thể là những 
tuyên bố (statements) ở mức cao về điều mà hệ thống 
nên làm 
 Những yêu cầu chức năng hệ thống nên miêu tả chi tiết 
dịch vụ hệ thống 
Ví dụ: 
Yêu cầu chức năng của LIBSYS 
17 
 Người dùng có thể tìm kiếm tất cả các bộ cơ sở dữ liệu 
ban đầu hoặc chỉ chọn một tập con trong đó 
 Hệ thống sẽ cung cấp chế độ hiển thị thích hợp cho 
người dùng để đọc tài liệu trong kho tài liệu 
 Mỗi đơn hàng sẽ được cấp một định danh duy nhất 
(ORDER_ID) mà người dùng sẽ sử dụng để sao chép 
vào khu vực lưu trữ dài hạn của tài khoản đó 
Yêu cầu phi chức năng 
(Non-functional requirements) 
18 
 Định nghĩa những thuộc tính và rằng buộc, ví dụ: độ tin 
cậy, thời gian phản ứng, yêu cầu lưu trữ. Những rằng 
buộc là khả năng thiết bị vào/ra (I/O), những biểu diễn 
hệ thống,  
 Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu 
chức năng. Nếu những yêu cầu này không được đáp ứng, 
hệ thống có thể sẽ vô dụng (useless) 
Phân loại Yêu cầu phi chức năng 
(Non-functional classifications) 
19 
 Yêu cầu sản phẩm (product requirements) 
 Những yêu cầu xác định rằng sản phẩm được phân phối phải 
hoạt động theo một cách cụ thể, ví dụ: tốc độ chạy (execution 
speed), độ tin cậy (reliability), v.v. 
 Yêu cầu tổ chức (organizational requirements) 
 Những yêu cầu là hệ quả của những chính sách (policies) và 
thủ tục (procedures) tổ chức, ví dụ: những tiêu chuẩn quy trình 
được sử dụng, phương pháp thiết kế, v.v. 
 Yêu cầu bên ngoài (external requirements) 
 Những yêu cầu phát sinh từ những yếu tố bên ngoài tác động 
lên hệ thống, ví dụ: yêu cầu về khả năng tương tác 
(interoperability) với các hệ thống khác, yêu cầu pháp lý 
(legislative), tính văn hóa, đạo đức, v.v. 
Ví dụ: 
Yêu cầu phi chức năng 
20 
 Yêu cầu sản phẩm (product requirement) 
 8.1 Giao diện người dùng cho LIBSYS sẽ được triển khai dưới 
dạng HTML đơn thuần mà không có frame hoặc Java applet 
 Yêu cầu tổ chức (organizational requirement) 
 9.3.2 Tiến trình phát triển hệ thống và những tài liệu chuyển 
giao (deliverable documents) phải phù hợp với tiến trình và 
sản phẩm được định nghĩa trong XYZCo-SP-STAN-95. 
 Yêu cầu bên ngoài (external requirement) 
 7.6.5 Hệ thống sẽ không tiết lộ bất kỳ thông tin về khách 
hàng ngoài tên và số tham chiếu của họ cho người vận hành 
hệ thống 
Phân biệt: 
Yêu cầu và Mục tiêu 
21 
 Yêu cầu là một cái gì đó có thể kiểm tra được 
 Mục tiêu là một đặc trưng khái quát hơn mà hệ thống 
phải thể hiện 
 Một ý định chung của người dùng, ví dụ tính dễ sử dụng, thân 
thiện với người dùng (nhưng đây không phải là một thuộc tính 
khách quan) 
 Mục tiêu hữu ích cho các nhà phát triển do chúng biểu đạt ý 
định của người dùng hệ thống 
Ví dụ: 
Mục tiêu và Yêu cầu 
22 
 Mục tiêu hệ thống 
 Hệ thống nên dễ sử dụng cho những người dùng kinh nghiệm 
và nên được tổ chức theo cách sao cho những lỗi người dùng 
được tối giản hóa 
 Yêu cầu phi chức năng có thể xác thực 
 Người dùng có kinh nghiệm có thể sử dụng tất cả chức năng 
hệ thống sau 2 giờ huấn luyện. 
 Sau thời gian huấn luyện này, số lượng trung bình lỗi được tạo 
ra bởi người dùng kinh nghiệm sẽ không quá 2 lỗi một ngày. 
Những độ đo cho Yêu cầu 
(Requirements measures) 
23 
Thuộc tính (property) Số đo (measure) 
Tốc độ 
(speed) 
Số giao dịch được xử lý / giây 
Số người dùng / thời gian đáp ứng sự kiện 
Thời gian làm tươi màn hình 
Kích thước 
(size) 
Mbytes 
Số lượng ROM chips 
Tính dễ sử dụng 
(ease of use) 
Thời gian huấn luyện 
Số lượng khung trợ giúp 
Độ tin cậy 
(reliability) 
Thời gian trung bình mà hệ thống lỗi (failure) 
Xác suất của trạng thái không sẵn sàng (unavailability) 
Tỷ lệ xuất hiện lỗi (failure occurrence) 
Tính sẵn sàng (availability) 
Độ vững mạnh 
(robustness) 
Thời gian khởi động sau khi có lỗi 
Phần trăm sự kiện gây ra lỗi 
Xác suất hư hỏng dữ liệu (data corruption) khi có lỗi 
Tính di động 
(portability) 
Phần trăm những phát biểu phụ thuộc mục tiêu 
Số lượng hệ thống mục tiêu (target systems) 
Xung đột yêu cầu 
24 
 Xung đột giữa những yêu cầu phi chức năng là phổ biến 
trong những hệ thống phức tạp 
 Ví dụ: Hệ thống tàu vũ trụ 
 Tối giản hóa trọng lượng, do đó số lượng vi xử lý (chip) trong 
hệ thống nên được tối giản hóa, 
 Tối giản hóa việc tiêu thụ điện năng (power consumption), 
những vi xử lý tiêu thụ điện năng thấp nên được sử dụng 
 Tuy nhiên, sử dụng vi xử lý điện năng thấp nghĩa là phải sử 
dụng số lượng nhiều hơn. 
 Đâu là yêu cầu quan trọng hơn? 
Nhắc lại: 
Yêu cầu người dùng 
25 
 Nên miêu tả những yêu cầu chức năng và phi chức năng 
theo cách mà chúng có thể được hiểu bởi người dùng 
hệ thống, những người không có kiến thức kỹ thuật chi 
tiết 
 Yêu cầu người dùng được định nghĩa sử dụng ngôn 
ngữ tự nhiên, các bảng và biểu đồ mà có thể được 
hiểu bởi tất cả người dùng 
Hướng dẫn viết yêu cầu 
(Guidelines for writing requirements) 
26 
 Tìm ra một định dạng chuẩn và sử dụng nó cho tất 
cả các yêu cầu. 
 Sử dụng ngôn ngữ một cách nhất quán. Sử dụng cho các 
yêu cầu bắt buộc, nên sử dụng cho các yêu cầu mong 
muốn. 
 Sử dụng văn bản được làm nổi bật để xác định 
những phần quan trọng của yêu cầu. 
 Tránh sử dụng thuật ngữ máy tính 
Vấn đề của Đặc tả Ngôn ngữ tự nhiên 
(Problems with NL specification) 
27 
 Sự mơ hồ (Ambiguity) 
 Người đọc và người viết yêu cầu phải phiên dịch những 
từ giống nhau theo cùng một cách. 
 Ngôn ngữ tự nhiên là không rõ ràng vì vậy điều này rất 
khó khăn. 
 Quá linh hoạt (Over-flexibility) 
 Những phát biểu tương tự có thể được nói bằng một số 
cách khác nhau trong đặc tả. 
 Thiếu tính mô-đun hóa 
 Cơ cấu ngôn ngữ tự nhiên không phù hợp để cấu trúc 
những yêu cầu hệ thống 
Những thay thế cho Đặc tả bằng NNTN 
28 
Ký hiệu 
(notation) 
Miêu tả 
(description) 
Ngôn ngữ tự 
nhiên được 
cấu trúc 
Cách tiếp cận này phụ thuộc vào việc định nghĩa các hình thức hoặc 
khuôn mẫu chuẩn để diễn tả đặc tả yêu cầu. 
Ngôn ngữ mô 
tả thiết kế 
Cách tiếp cận này sử dụng một ngôn ngữ như một ngôn ngữ lập trình 
nhưng với nhiều tính năng trừu tượng hơn để chỉ định các yêu cầu 
bằng cách định nghĩa một mô hình hoạt động của hệ thống. Cách tiếp 
cận này bây giờ không được sử dụng rộng rãi mặc dù nó có thể hữu ích 
cho các đặc tả giao diện. 
Ký hiệu đồ 
hoạ 
Một ngôn ngữ đồ họa, bổ sung bằng các chú thích văn bản, được sử 
dụng để định nghĩa các yêu cầu chức năng cho hệ thống. Một ví dụ ban 
đầu của một ngôn ngữ đồ họa như thế là SADT. Bây giờ, những mô tả 
use-case sử dụng và biểu đồ trình tự thường được sử dụng. 
Đặc tả toán 
học 
Đây là những ký hiệu dựa trên các khái niệm toán học như các máy 
hoặc tập hữu hạn trạng thái. Những đặc tả rõ ràng này làm giảm các 
tham số giữa khách hàng và nhà thầu về chức năng của hệ thống. Tuy 
nhiên, hầu hết khách hàng không hiểu những đặc tả hình thức và miễn 
cưỡng chấp nhận nó như một hợp đồng hệ thống. 
Đặc tả ngôn ngữ được cấu trúc 
(Structured language specifications) 
29 
 Sự tự do của người viết yêu cầu bị giới hạn bởi một 
khuôn mẫu được định nghĩa trước cho các yêu cầu. 
 Tất cả các yêu cầu được viết theo một cách chuẩn. 
 Thuật ngữ (terminology) sử dụng trong mô tả có thể bị 
hạn chế. 
 Ưu điểm là hầu hết các biểu cảm của ngôn ngữ tự 
nhiên được duy trì nhưng một mức độ đồng nhất bị 
bắt buộc trong đặc tả. 
Đặc tả dựa trên biểu mẫu 
(Form-based specifications) 
30 
 Sự định nghĩa của chức năng hoặc thực thể. 
 Sự mô tả về đầu vào và nguồn gốc của chúng. 
 Sự mô tả về đầu ra và nơi chúng đến. 
 Sự chỉ dẫn của các thực thể khác được yêu cầu. 
 Những điều kiện trước và sau (nếu thích hợp). 
 Những ảnh hưởng phụ (nếu có) của chức năng. 
Đặc tả nút dựa trên biểu mẫu 
(Form-based node specification) 
31 
Insulin Pump / Phần mềm kiểm soát / SRS / 3.3.2 
Chức năng Tính liều insulin: Mức đường an toàn 
Miêu tả Tính toán lượng insulin được cung cấp khi mức đường đo được hiện tại nằm trong 
vùng an toàn giữa 3 và 7 đơn vị. 
Đầu vào Lượng đường đọc được hiện tại (r2), hai lượng đường ở lần đọc trước (r0 và r1) 
Nguồn Lượng đường đọc từ cảm biến. Những lần đọc khác từ bộ nhớ. 
Đầu ra Compdose - liều lượng insulin được cung cấp 
Miêu tả Vòng điều khiển chính 
Hành động CompDose có giá trị 0 nếu mức đường ổn định hoặc giảm xuống hoặc nếu mức 
độ đang tăng lên nhưng tỷ lệ tăng đang giảm. Nếu mức độ đang tăng và tỷ lệ tăng 
lại đang tăng lên, thì CompDose được tính bằng cách chia sự khác biệt giữa mức 
đường hiện tại và mức trước đó cho 4 và làm tròn kết quả. Nếu kết quả, được làm 
tròn bằng 0, thì CompDose được đặt ở liều tối thiểu có thể được phân phối. 
Yêu cầu Hai lần đọc trước đó để có thể tính tỷ lệ thay đổi của mức đường. 
Điều kiện trước Túi insulin chứa ít nhất một liều đơn tối đa cho phép của insulin 
Điều kiện sau r0 được thay thế bởi r1 sau đó r1 được thay thế bằng r2 
Ảnh hưởng phụ Không có 
Đặc tả dạng bảng 
(Tabular specification) 
32 
 Được sử dụng để bổ sung cho ngôn ngữ tự nhiên. 
 Đặc biệt hữu ích khi phải định nghĩa một số các 
phương án thay thế có thể cho hành động 
Ví dụ: 
Đặc tả dạng bảng 
33 
Điều kiện Hành động 
Mức đường đang rơi 
xuống (r2 <r1) ... Feasibility studies) 
50 
 Một nghiên cứu khả thi quyết định xem hệ thống 
được đề xuất có đáng giá hay không 
 Đây là một nghiên cứu ngắn để tập trung kiểm tra: 
 Liệu hệ thống đóng góp vào các mục tiêu của công ty? 
 Liệu hệ thống có thể được kỹ nghệ hóa sử dụng công 
nghệ hiện tại và trong phạm vi ngân sách? 
 Liệu hệ thống có thể được tích hợp với các hệ thống khác 
đang được sử dụng? 
Thực hiện nghiên cứu khả thi 
(Feasibility study implementation) 
51 
 Dựa trên đánh giá thông tin (những gì được yêu 
cầu), thu thập thông tin và viết báo cáo 
 Đặt câu hỏi cho những người trong công ty 
 Điều gì xảy ra nếu hệ thống này không được thực thi? 
 Những vấn đề của quy trình hiện tại là gì? 
 Hệ thống được đề xuất sẽ giúp đỡ như thế nào? 
 Những vấn đề của tích hợp là gì? 
 Công nghệ mới có cần thiết không? Những kỹ năng nào? 
 Các phương tiện gì phải được hỗ trợ bởi hệ thống đề 
xuất? 
2. Khai phá và phân tích yêu cầu 
(Requirements elicitation and analysis) 
52 
 Liên quan đến nhân viên kỹ thuật làm việc với khách 
hàng để tìm hiểu về các lĩnh vực ứng dụng, các dịch 
vụ mà hệ thống nên cung cấp và những rằng buộc 
hoạt động của hệ thống. 
 Có thể liên quan đến người dùng cuối, nhà quản lý, 
kỹ sư tham gia bảo trì, chuyên gia về lĩnh vực đó, tổ 
chức công đoàn, v.v. Đây là gọi các bên liên quan 
(stakeholders) 
Khai phá yêu cầu 
(Requirements discovery) 
53 
 Là quá trình thu thập thông tin về những hệ thống đề 
xuất và hiện có, sau đó đưa ra các yêu cầu người 
dùng và yêu cầu hệ thống từ các thông tin này. 
 Nguồn thông tin bao gồm tài liệu, các bên liên quan 
đến hệ thống và các đặc tả của các hệ thống tương 
tự. 
Bên liên quan trong hệ thống ATM 
(ATM stakeholders) 
54 
 Khách hàng ngân hàng (Bank customers) 
 Đại diện của các ngân hàng khác (Representatives of 
other banks) 
 Quản lý ngân hàng (Bank managers) 
 Nhân viên tính toán (Counter staff) 
 Quản trị viên cơ sở dữ liệu (Database administrators) 
 Quản lý an ninh (Security managers) 
 Bộ phận quảng cáo (Marketing department) 
 Kỹ sư bảo trì phần cứng và phần mềm (Hardware and 
software maintenance engineers) 
 Người điều hành ngân hàng (Banking regulators) 
Khó khăn trong phân tích yêu cầu 
(Problems of requirements analysis) 
55 
 Các bên liên quan không biết mình thực sự muốn gì 
 Các bên liên quan phát biểu yêu cầu theo thuật ngữ 
riêng của họ 
 Các bên liên quan khác nhau có thể có các yêu cầu 
xung đột. 
 Các yếu tố về tổ chức và chính trị có thể ảnh hưởng 
đến yêu cầu hệ thống. 
 Các yêu cầu thay đổi trong quá trình phân tích. Các 
bên liên quan mới có thể xuất hiện và môi trường 
kinh doanh thay đổi. 
2.1. Quan điểm 
(Viewpoints) 
56 
 Quan điểm là một cách cấu trúc các yêu cầu để biểu 
diễn những khía cạnh khác nhau của các bên liên 
quan. 
 Các bên liên quan có thể được phân loại dựa trên 
các quan điểm khác nhau. 
 Sự phân tích đa góc độ này rất quan trọng khi không 
có cách nào chính xác để phân tích các yêu cầu hệ 
thống. 
Các kiểu quan điểm 
(Types of viewpoint) 
57 
 Quan điểm tương tác (Interactor viewpoints) 
 Con người hoặc các hệ thống khác tương tác trực tiếp với hệ 
thống. 
 Trong máy ATM, cơ sở dữ liệu khách hàng và tài khoản là 
những quan điểm tương tác. 
 Quan điểm gián tiếp (Indirect viewpoints) 
 Các bên liên quan tự họ không sử dụng hệ thống nhưng 
ảnh hưởng đến các yêu cầu. 
 Trong máy ATM, nhân viên quản lý và an ninh là những quan 
điểm gián tiếp. 
 Quan điểm miền (Domain viewpoints) 
 Đặc điểm và rằng buộc về miền ảnh hưởng đến những yêu 
cầu. 
 Trong máy ATM, một ví dụ là tiêu chuẩn cho truyền thông liên 
ngân hàng. 
Nhận dạng quan điểm 
(Viewpoint identification) 
58 
 Nhận dạng quan điểm sử dụng 
 Nhà cung cấp và người nhận của dịch vụ hệ thống; 
 Các hệ thống tương tác trực tiếp với hệ thống đang cần 
xác định; 
 Các quy định và tiêu chuẩn (regulations and standards); 
 Nguồn của các yêu cầu kinh doanh và phi chức năng; 
 Các kỹ sư phải phát triển và bảo trì hệ thống; 
 Quảng cáo và quan điểm kinh doanh khác. 
Phân cấp quan điểm của LIBSYS 
(LIBSYS viewpoint hierarchy) 
59 
2.2. Chất vấn 
(Interviewing) 
60 
 Trong cuộc chất vấn chính thức hoặc không chính 
thức, nhóm tạo yêu cầu sẽ đặt câu hỏi cho các bên 
liên quan về hệ thống mà họ sử dụng và hệ thống sẽ 
được phát triển. 
 Có hai kiểu chất vấn 
 Chất vấn kín, khi mà một tập các câu hỏi định nghĩa trước 
sẽ được trả lời. 
 Chất vấn mở khi không có chương trình nghị sự được 
xác định trước và một loạt vấn đề được đề cập với các 
bên liên quan. 
Thực hành Chất vấn 
(Interviews in practice) 
61 
 Thông thường kết hợp giữa chất vấn đóng và 
chất vấn mở. 
 Chất vấn là tốt để có được sự hiểu biết tổng thể 
về những gì các bên liên quan làm và cách mà 
họ có thể tương tác với hệ thống. 
Người chất vấn hiệu quả 
(Effective interviewers) 
62 
 Người chất vấn nên có một đầu óc cởi mở, sẵn sàng 
lắng nghe các bên liên quan và không nên có những 
ý tưởng ban đầu về các yêu cầu. 
 Người chất vấn nên nhắc người được chất vấn bằng 
một câu hỏi hay một đề nghị và không nên chỉ đơn 
giản là mong đợi họ phản hồi một câu hỏi kiểu như 
'Bạn muốn điều gì'. 
2.3. Kịch bản 
(Scenarios) 
63 
 Kịch bản là những ví dụ thực tế trong cuộc sống về 
cách một hệ thống có thể được sử dụng. 
 Kịch bản nên bao gồm: 
 Một mô tả về tình trạng ban đầu; 
 Một mô tả về luồng bình thường của các sự kiện; 
 Một mô tả về điều gì có thể khiến sai sót xảy ra; 
 Thông tin về các hoạt động đồng thời khác; 
 Một mô tả về trạng thái khi kịch bản kết thúc. 
Kịch bản của LIBSYS (1/2) 
(LIBSYS scenario) 
64 
 Giả định ban đầu: Người dùng đã đăng nhập vào hệ thống LIBSYS và đã 
tìm thấy tạp chí chứa bản sao của bài báo. 
 Bình thường: Người dùng chọn bài báo để sao chép. Sau đó, anh/chị ấy sẽ 
được hệ thống nhắc để cung cấp thông tin đăng ký cho tạp chí hoặc chỉ ra 
cách họ sẽ trả tiền cho bài báo. Những phương thức thanh toán thay thế là 
bằng thẻ tín dụng hoặc bằng cách trích dẫn số tài khoản của tổ chức. 
 Sau đó, người dùng sẽ được yêu cầu điền vào một mẫu bản quyền để lưu 
giữ chi tiết của giao dịch và sau đó họ gửi mẫu này vào hệ thống LIBSYS. 
 Mẫu bản quyền được kiểm tra, và nếu OK, phiên bản PDF của bài báo sẽ 
được tải xuống khu vực làm việc LIBSYS trên máy tính của người dùng và 
người dùng được thông báo rằng bài báo đã có sẵn. Người dùng được yêu 
cầu chọn một máy in và một bản sao của bài báo sẽ được in ra. Nếu bài báo 
đã được gắn cờ 'chỉ in' thì nó sẽ bị xóa khỏi hệ thống của người dùng khi 
người dùng đã xác nhận rằng việc in đã hoàn tất. 
Kịch bản của LIBSYS (2/2) 
(LIBSYS scenario) 
65 
 Điều có thể khiến sai sót xảy ra: Người dùng có thể không điền đúng trong 
mẫu bản quyền. Trong trường hợp này, mẫu đó phải được đưa lại cho 
người dùng để chỉnh sửa. Nếu mẫu đó được gửi lại mà vẫn không chính xác 
thì yêu cầu của người dùng về bài báo bị từ chối. 
 Việc thanh toán có thể bị hệ thống từ chối. Yêu cầu của người dùng về bài 
báo bị từ chối. Bài báo có thể tải xuống không thành công. Hãy thử lại cho 
đến khi thành công hoặc khi người dùng chấm dứt phiên làm việc. Có thể 
không in được bài báo. Nếu bài báo không được gắn cờ 'chỉ in' thì nó sẽ 
được giữ trong không gian làm việc của LIBSYS. Nếu không, bài báo sẽ bị 
xóa và tài khoản của người dùng được cộng thêm chi phí của bài báo. 
 Các hoạt động khác: Tải đồng thời các bài báo khác. 
 Trạng thái hệ thống khi hoàn thành: Người dùng đăng nhập. Bài báo tải 
về đã bị xóa khỏi không gian làm việc của LIBSYS nếu nó đã được gán cờ 
là chỉ in (print-only) 
Những trường hợp sử dụng 
(Use cases) 
66 
 Use-case là một kỹ thuật dựa trên kịch bản trong 
UML giúp xác định các tác nhân trong một tương tác 
và mô tả chính tương tác đó. 
 Một tập hợp các use-case nên mô tả tất cả các 
tương tác có thể với hệ thống. 
 Sơ đồ trình tự (sequence diagram) có thể được sử 
dụng để thêm chi tiết cho use-case bằng cách hiển 
thị trình tự xử lý sự kiện trong hệ thống. 
Use-case cho việc in bài báo 
(Article printing use-case) 
67 
Các use-case của LIBSYS 
(LIBSYS use cases) 
68 
Sơ đồ trình tự cho in bài báo 
(Sequence diagram for article printing) 
69 
4. Xác thực yêu cầu 
(Requirements validation) 
70 
 Liên quan đến việc chứng minh rằng các yêu cầu sẽ 
định nghĩa một hệ thống mà khách hàng thực sự 
muốn. 
 Chi phí của một lỗi yêu cầu là cao vì thế xác thực yêu 
cầu là rất quan trọng 
 Sửa một lỗi yêu cầu sau khi phát hành có thể mất chi phí 
lên đến 100 lần so với sửa một lỗi cài đặt. 
Kiểm tra yêu cầu 
(Requirements checking) 
71 
 Tính hiệu lực (validity). 
 Hệ thống có cung cấp các chức năng hỗ trợ tốt nhất nhu cầu 
của khách hàng không? 
 Tính nhất quán (consistency). 
 Có bất kỳ yêu cầu xung đột nào không? 
 Tính hoàn thiện (completeness). 
 Có phải tất cả các chức năng mà khách hàng yêu cầu đã được 
cài đặt? 
 Tính hiện thực (realism). 
 Các yêu cầu có thể được thực hiện với ngân sách và công 
nghệ sẵn có không? 
 Khả năng kiểm chứng (verifiability). 
 Các yêu cầu có thể được kiểm tra không? 
Những kỹ thuật xác thực yêu cầu 
(Requirements validation techniques) 
72 
 Đánh giá lại yêu cầu (Requirements reviews) 
 Phân tích thủ công có hệ thống của các yêu cầu 
 Tạo nguyên mẫu (Prototyping) 
 Sử dụng một mô hình có thể thực thi của hệ thống để 
kiểm tra các yêu cầu 
 Tạo các trường hợp thử nghiệm (Test-case generation) 
 Phát triển những bài kiểm tra cho các yêu cầu 
Đánh giá lại yêu cầu 
(Requirements reviews) 
73 
 Việc đánh giá lại thường xuyên nên được tổ chức 
trong lúc định nghĩa các yêu cầu đang được xây 
dựng 
 Cả nhân viên khách hàng và nhà thầu đều nên tham 
gia vào việc đánh giá lại 
 Việc đánh giá lại có thể chính thức (với những tài 
liệu đã hoàn thành) hoặc không chính thức. Viêc 
giao tiếp tốt giữa các nhà phát triển, khách hàng và 
người dùng có thể giải quyết các vấn đề ở giai đoạn 
đầu 
Kiểm tra việc đánh giá lại 
(Review checks) 
74 
 Khả năng kiểm chứng (Verifiability). 
 Liệu yêu cầu có thể kiểm thử được trong thực tế không? 
 Tính hiểu (Comprehensibility). 
 Liệu yêu cầu có được hiểu đúng không? 
 Khả năng truy vết (Traceability). 
 Liệu nguồn gốc của yêu cầu có được phát biểu rõ ràng? 
 Khả năng thích nghi (Adaptability). 
 Liệu yêu cầu có thể được thay đổi mà không ảnh hưởng 
lớn tới các yêu cầu khác không? 
Quản lý yêu cầu 
(Requirements management) 
75 
 Quản lý yêu cầu là quá trình quản lý sự thay đổi yêu 
cầu trong quá trình kỹ thuật tạo yêu cầu và phát triển 
hệ thống. 
 Yêu cầu khó tránh khỏi việc không đầy đủ và không 
nhất quán 
 Các yêu cầu mới xuất hiện trong quá trình khi nhu cầu 
kinh doanh thay đổi và sự hiểu biết tốt hơn về hệ thống 
được phát triển; 
 Các quan điểm khác nhau có những yêu cầu khác nhau 
và điều này thường mâu thuẫn (contradictory). 
Thay đổi yêu cầu 
(Requirements change) 
76 
 Mức độ ưu tiên của các yêu cầu từ các quan điểm 
khác nhau thay đổi trong quá trình phát triển. 
 Khách hàng hệ thống có thể xác định các yêu cầu từ 
quan điểm kinh doanh mà mâu thuẫn với những yêu 
cầu người dùng cuối. 
 Môi trường kinh doanh và kỹ thuật của hệ thống thay 
đổi trong quá trình phát triển. 
Tiến hóa yêu cầu 
(Requirements evolution) 
77 
Yêu cầu ổn định và không ổn định 
(Enduring and volatile requirements) 
78 
 Yêu cầu ổn định (Enduring requirements). 
 Yêu cầu ổn định bắt nguồn từ hoạt động cốt lõi của tổ 
chức khách hàng. 
 VD: Một bệnh viện sẽ luôn luôn có bác sĩ, y tá, v.v. Có thể 
được bắt nguồn từ các mô hình miền. 
 Yêu cầu không ổn định (Volatile requirements). 
 Yêu cầu thay đổi trong quá trình phát triển hoặc khi hệ 
thống đi vào sử dụng. 
 VD: Trong một bệnh viện, yêu cầu bắt nguồn từ chính 
sách chăm sóc sức khoẻ 
Phân loại yêu cầu 
(Requirements classification) 
79 
Kiểu yêu cầu Miêu tả 
Yêu cầu có thể 
thay đổi 
(Mutable 
requirements) 
Những yêu cầu thay đổi do sự thay đổi của môi trường mà 
công ty đang hoạt động. Ví dụ, trong các hệ thống bệnh 
viện, quỹ kinh phí chăm sóc bệnh nhân có thể thay đổi và 
do đó cần phải thu thập thông tin điều trị khác nhau. 
Yêu cầu khẩn cấp 
(Emergent 
requirements) 
Những yêu cầu nổi lên khi sự hiểu biết của khách hàng về hệ 
thống phát triển trong quá trình phát triển hệ thống. Quá trình 
thiết kế có thể bộc lộ các yêu cầu khẩn cấp mới. 
Yêu cầu hệ quả 
(Consequential 
requirements) 
Những yêu cầu là kết quả từ sự giới thiệu của hệ thống 
máy tính. Giới thiệu hệ thống máy tính có thể thay đổi quy 
trình của tổ chức và mở ra những cách làm việc mới để tạo 
ra các yêu cầu hệ thống mới 
Yêu cầu tương 
thích 
(Compatibility 
requirements) 
Những yêu cầu phụ thuộc vào các hệ thống hoặc quá trình 
kinh doanh cụ thể trong một công ty. Khi điều này thay đổi 
này, những yêu cầu tương thích trên hệ thống được ủy thác 
hoặc phân phối cũng có thể phải tiến hóa theo. 
Lập kế hoạch quản lý yêu cầu 
(Requirements management planning) 
80 
 Trong quá trình kỹ thuật tạo yêu cầu, bạn phải lên kế 
hoạch cho những việc sau: 
 Nhận dạng yêu cầu (Requirements identification) 
 Cách những yêu cầu được nhận dạng riêng biệt; 
 Quy trình quản lý thay đổi 
 Quá trình tiếp theo khi phân tích yêu cầu thay đổi; 
 Chính sách truy xuất nguồn gốc (Traceability policies) 
 Số lượng thông tin về các mối quan hệ yêu cầu được duy trì; 
 Công cụ hỗ trợ CASE 
 Công cụ hỗ trợ cần thiết để giúp quản lý sự thay đổi yêu cầu; 
Khả năng truy vết 
(Traceability) 
81 
 Khả năng truy vết liên quan đến các mối quan hệ 
giữa các yêu cầu, nguồn gốc của chúng và thiết kế 
hệ thống 
 Khả năng truy vết nguồn (Source traceability) 
 Liên kết những yêu cầu với các bên liên quan đã đề xuất 
các yêu cầu này; 
 Khả năng truy vết yêu cầu (Requirements traceability) 
 Liên kết giữa các yêu cầu phụ thuộc; 
 Khả năng truy vết thiết kế (Design traceability) 
 Liên kết những yêu cầu với thiết kế; 
Ma trận truy vết 
(Traceability matrix) 
82 
Tóm tắt những điểm chính (1/2) 
(Key points) 
83 
 Quy trình kỹ thuật tạo yêu cầu bao gồm: nghiên cứu 
khả thi, khai phá và phân tích yêu cầu, đặc tả yêu 
cầu và quản lý yêu cầu. 
 Khai phá và phân tích yêu cầu là quá trình lặp liên 
quan đến hiểu biết miền, thu thập yêu cầu, phân 
loại, cấu trúc, ưu tiên và xác thực. 
 Hệ thống có nhiều bên liên quan với các yêu cầu khác 
nhau. 
Tóm tắt những điểm chính (2/2) 
(Key points) 
84 
 Các yếu tố xã hội và tổ chức ảnh hưởng đến các 
yêu cầu hệ thống. 
 Xác thực yêu cầu liên quan đến việc kiểm tra: tính 
hợp lệ, tính nhất quán, tính đầy đủ, tính hiện 
thực và khả năng kiểm chứng. 
 Những thay đổi kinh doanh chắc chắn dẫn đến thay 
đổi yêu cầu. 
 Quản lý yêu cầu bao gồm lập kế hoạch và quản lý 
thay đổi. 
Tài liệu Tham khảo 
85 
 Giáo trình chính: Software Engineering, Ian 
Sommerville, 8th Edition, 2007 
 Tham khảo: 
 Object-Oriented Software Engineering Practical Software 
Development using UML and Java, Lloseng.com, 
Lethbridge/Laganièr, 2001 
 Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm, 
Phạm Thị Quỳnh