Giáo trình Kỹ nghệ phần mềm - Bài 4: Yêu cầu phần mềm

u yêu cầu có thể được diễn đạt cùng một lúc
Ví dụ yêu cầu của LIBSYS
4.5 LIBSYS phải cung cấp một hệ thống kế toán tài
chính để ghi nhận tất cả các khoản thanh toán của
người sử dụng. Người quản lý hệ thống có thể cấu
hình hệ thống này sao cho khách hàng thường
xuyên có thể nhận được một tỷ lệ giảm giá.
Ví dụ yêu cầu kẻ ô
2.6 Tiện ích kẻ ô (Grid facilities) Để hỗ trợ việc định vị các
thực thể trong một sơ đồ, người sử dụng có thể bật chế
độ kẻ ô theo centimet hoặc inch thông qua một lựa chọn
trong bảng điểu khiển. Ban đầu chế độ kẻ ô được tắt. Việc
kẻ ô có thể được bật lên hoặc tắt đi bất kỳ lúc nào trong
quá trình chỉnh sửa và có thể chuyển đổi giữa hai hệ
thống inch và centimet bất kỳ lúc nào. Một chức năng kẻ
ô sẽ được cung cấp để tự động điều chỉnh sơ đồ cho vừa
màn hình nhưng số đường kẻ sẽ được giảm để tránh phải
lấp đầy sơ đồ nhỏ với các đường kẻ.
Các vấn đề với ví dụ yêu cầu
• Yêu cầu CSDL gồm cả thông tin chi tiết và thông tin khái 
niệm
– Mô tả khái niệm của một hệ thống kế toán tài chính được phát 
triển trong LIBSYS;
– Tuy nhiên, nó cũng gồm các chi tiết để người quản lý có thể cấu 
hình hệ thống này – điều này là không cần thiết ở cấp độ này
• Yêu cầu kẻ ô xen lẫn ba loại yêu cầu
– Yêu cầu chức năng khái niệm (cần có kẻ ô);
– Yêu cầu phi chức năng (đơn vị kẻ ô);
– Yêu cầu giao diện phi chức năng (bật/tắt kẻ ô).
Diễn đạt có cấu trúc
2.6.1 Tiện ích kẻ ô
Chương trình sẽ cung cấp một tiện ích kẻ ô trong đó một ma trận các
đường ngang và dọc sẽ làm nền của cửa sổ soạn thảo. Các dòng kẻ
này là thụ động và việc dóng hàng là trách nhiệm của người sử dụng.
Lý giải: Việc kẻ ô giúp người sử dụng tạo một sơ đồ ngăn nắp và
khoảng cách giữa các thực thể được hợp lý. Mặc dù kẻ ô chủ động
trong đó các thực thể được tự động khớp với dòng kẻ có thể hữu
ích hơn, việc định vị nhiều khi khó chính xác. Nên tốt nhất để
người sử dụng quyết định vị trí của các thực thể.
Đặc tả: ECLIPSE/WS/Tools/DE/FS Section 5.6
Nguồn: Ray Wilson, Glasgow Office
Hướng dẫn viết yêu cầu
• Đưa ra một chuẩn về khuôn dạng và áp dụng cho
tất cả các yêu cầu. 
• Sử dụng ngôn ngữ theo một cách nhất quán. 
– Dùng tử “phải” cho các yêu cầu bắt buộc, “nên” cho
các yêu cầu mong muốn.
• Dùng màu sắc để nhấn mạnh các phần quan trọng
của tài liệu.
• Tránh sử dụng thuật ngữ máy tính
Yêu cầu hệ thống
• Là đặc tả chi tiết hơn yêu cầu người sử dụng về 
chức năng, dịch vụ và ràng buộc của hệ thống.
• Làm cơ sở để thiết kế hệ thống
• Có thể dùng làm một phần của hợp đồng
• Yêu cầu hệ thống có thể được mô tả, minh họa 
bằng các mô hình hệ thống (Chương 8)
Yêu cầu và thiết kế
• Về lý thuyết, yêu cầu nói lên hệ thống phải làm gì 
và thiết kế mô tả làm thế nào để làm điều đó
• Trên thực tế, yêu cầu và thiết kế không thể tách rời 
nhau
–Một kiến trúc hệ thống có thể được thiết kế để cấu 
trúc các yêu cầu;
– Hệ thống có thể tương tác với hệ thống sinh yêu cầu 
thiết kế khác;
– Việc sử dụng một thiết kế cụ thể có thể là yêu cầu lĩnh 
vực
Vấn đề đặc tả bằng ngôn ngữ tự nhiên
• Mơ hồ
– Người đọc và người viết phải dịch các từ theo cùng 
một cách. Ngôn ngữ tự nhiên bản thân là mơ hồ nên 
việc cùng hiểu như nhau rất khó.
• Quá linh động
– Cùng một điều nhưng có nhiều cách diễn đạt trong tài 
liệu đặc tả
• Thiếu tính module
– Các cấu trúc của ngôn ngữ tự nhiên không đủ để cấu 
trúc các yêu cầu hệ thống
Đặc tả khác bằng ngôn ngữ tự nhiên
Ký pháp Mô tả
Ngôn ngữ tự
nhiên có cấu trúc
Dựa trên các mẫu và chuẩn để diễn tả đặc tả yêu cầu.
Ngôn ngữ mô tả
thiết kế
Sử dung ngôn ngữ giống ngôn ngữ lập trình nhưng ở mức trừu
tượng cao hơn để đặc tả yêu cầu bằng các mô hình hoạt động của
hệ thống. Hiện nay cách này chỉ dùng cho đặc tả giao diện.
Ký pháp đồ họa Sử dung ngôn ngữ đồ họa kèm theo chú thích văn bản để mô tả yêu
cầu chức năng của hệ thống. Các biểu đồ ca sử dụng và tuần tự
đang được sử dụng phố biến.
Đặc tả toán học Sử dụng các ký pháp dựa trên các khái niệm toán học như máy
trang thái, tập hợp để đặc tả nhằm giảm nhập nhằng và mơ hồ gây
tranh cãi giữa khách hàng và người thực hiện về các chức năng hệ
thống.
Đặc tả ngôn ngữ có cấu trúc
• Hạn chế bớt sự tùy tiện của người viết yêu cầu 
bằng các mẫu yêu cầu
• Tất cả các yêu cầu được viết theo một cách thống 
nhất
• Có thể hạn chế thuật ngữ sử dụng trong mô tả
• Ưu điểm là vẫn sử dụng ngôn ngữ tự nhiên nhưng 
có dự đồng nhất trong đặc tả.
Đặc tả bằng biểu mẫu
• Định nghĩa của chức năng hoặc thực thể
• Mô tả đầu vào và chúng đến từ đâu
• Mô tả đầu ra và nơi chúng sẽ đến
• Chỉ ra các thực thể cần thiết khác
• Tiền và hậu điều kiện (nếu phù hợp)
• Các hiệu ứng phụ (nếu có) của chức năng
Ví dụ đặc tả bằng biểu mẫu
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is
in the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose – the dose in insulin to be delivered
Destination Main control loop
Action CompDose is zero if the sugar level is stable or falling or if the level is increasing but the
rate of increase is decreasing. If the level is increasing and the rate of increase is
increasing, ...
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
Đặc tả bằng bảng
• Thường dùng đê bổ sung cho ngôn ngữ tự nhiên
• Rất hữu ích khi ta phải chỉ ra một số lựa chọn các 
hoạt động khác nhau.
Ví dụ đặc tả bằng bảng
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and CompDose = 0
rate of increase decreasing 
((r2-r1)<(r1-r0))
Sugar level increasing and 
rate of increase stable or 
increasing. ((r2-r1) ≥ (r1-r0))
CompDose = round ((r2-r1)/4)
If rounded result = 0 then 
CompDose = MinimumDose
Các mô hình đồ họa
• Mô hình đồ họa hữu ích nhất
– Khi ta cần thể hiện các trạng thái thay đổi như thế nào 
hoặc
– Khi ta cần mô tả một dãy các hành động
• Xem Chương 8 về các mô hình đồ họa khác
Sơ đồ tuần tự
• Mô tả một dãy các sự kiện xảy ra khi người sử 
dụng tương tác với hệ thống
• Đọc từ trên xuống và xem thứ tự của các hành 
động xảy ra
• Rút tiến từ máy ATM
– Kiểm tra thẻ;
– Xử lý yêu cầu;
– Hoàn thành giao dịch.
Sơ đồ tuần tự của việc rút tiền trên ATM
Đặc tả giao diện
• Hầu hết các hệ thống phải hoạt động cùng với các 
hệ thống khác và giao diện phải được chỉ ra như là 
một phần của yêu cầu.
• Ba kiểu giao diện có thể xác định
– Giao diện thủ tục;
– Cấu trúc dữ liệu sẽ được trao đổi;
– Biễu diễn dữ liệu.
• Tốt nhất là dùng khác ký pháp hình thức (toán) để 
đặc tả giao diện
Mô tả giao diện bằng PDL
• PDL = Program Design Language
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
Tài liệu yêu cầu
• Tài liệu yêu cầu là phát biểu chính thức về những 
gì được yêu cầu đến người phát triển hệ thống
• Cần có cả một định nghĩa về yêu cầu người sử 
dụng và một đặc tả về yêu cầu hệ thống
• Nó KHÔNG phải là một tài liệu thiết kế. Nó tập 
trung vào hệ thống phải làm CÁI GÌ, thay vì phải 
làm NHƯ THẾ NÀO.
Người dùng tài liệu yêu cầu
Khách hàng
Chỉ ra yêu cầu và đọc kiểm tra chúng đúng là
cái họ cần; Cũng là người chỉ ra các thay đổi
với yêu cầu.
Quản lý Sử dụng tài liệu yêu cầu để mời thầu hoặc
lập kế hoạch phát triển hệ thống.
Kỹ sư hệ thống Sử dụng yêu cầu để hiểu hệ thống chuẩn bị
được phát triển.
Kiểm thử viên Sử dụng yêu cầu để kiểm thử hệ thống.
Kỹ sư bảo trì Sử dụng yêu cầu để hiểu hệ thống và quan
hệ giữa các thành phần của nó.
Chuẩn yêu cầu IEEE
• Định nghĩa một cấu trúc tổng quát cho một tài liệu 
yêu cầu nhưng cần cụ thể hóa để áp dụng cho mỗi 
hệ thống cụ thể.
– Giới thiệu.
–Mô tả chung.
– Yêu cầu cụ thể.
– Phụ lục.
– Chỉ mục.
Cấu trúc tài liệu yêu cầu
1. Lời nói đầu
2. Giới thiệu
3. Thuật ngữ
4. Định nghĩa yêu cầu người sử dụng
5. Kiến trúc hệ thống
6. Đặc tả yêu cầu hệ thống
7. Mô hình hệ thống
8. Tiến hóa hệ thống
9. Phụ mục
10. Chỉ mục
Các điểm chính
• Yêu cầu xác định hệ thống phải làm gì và các ràng buộc khi 
xây dựng và vận hành
• Các yêu cầu chức năng xác định các dịch vụ hệ thống phải 
cung cấp
• Các yêu cầu phi chức năng ràng buộc hệ thống đang được 
phát triển và qui trình phát triển
• Yêu cầu người sử dụng là phát biểu ở mức cao về những 
gì hệ thống phải làm. Yêu cầu người sử dụng cần được 
viết bằng ngôn ngữ tự nhiên, bảng biểu, và sơ đồ.
Các điểm chính
• Yêu cầu hệ thống dùng để mô tả các chức năng hệ 
thống cần cung cấp.
• Tài liệu yêu cầu phần mềm là thỏa thuận đã đạt 
được về yêu cầu hệ thống.
• Chuẩn IEEE là một điểm bắt đầu tốt để xác định 
các chuẩn yêu cầu cụ thể và chi tiết hơn.
Bài tập về nhà
• Chọn và trả lời 5 câu hỏi trong sách
– Cuối Chương 6, Software Engineering.
• Chọn một công cụ quản lý yêu cầu và viết các yêu 
cầu cho bài tập lớn
• 
px
• 
Nộp bài tập trên trang web môn học
• Nộp bài tập về nhà các có trong slide các bài giảng 
1-4 lên trang web môn học.
– Tên file:
• Nguyen_Thi_An_1.zip
Chuẩn bị cho các tuần tiếp theo
• Nghỉ hai tuần lên lớp
– Các nhóm tập trung làm bài tập lớn
• Tự đọc thêm Chương 7: Các qui trình kỹ nghệ yêu 
cầu
• Xem dần trước các Chương 8,11,14,17,18,23,32
– Dùng slide tiếng Anh
• 
8/Presentations/index.html