Bài giảng Công nghệ phần mềm: Phân tích và đặc tả yêu cầu - Lê Thị Mỹ Hạnh

1Phân tích và đặc tả yêu cầu
Lê Thị Mỹ Hạnh
Khoa Công nghệ Thông tin
Trường Đại học Bách khoa, Đà Nẵng
NỘI DUNG
„ Đại cương về phân tích và đặc tả
„ Nền tảng của phân tích
„ Phân tích và nắm bắt yêu cầu
„ Đặc tả yêu cầu
„ Thẩm định yêu cầu
„ Một số phương pháp và công cụ hỗ trợ
2Phân tích và đặc tả
„ Xác định và phân tích yêu cầu là khâu kỹ
thuật đầu tiên của quá trình phát triển phần 
mềm.
„ Xác định các chức năng/dịch vụ mà khách hàng 
yêu cầu từ hệ thống
„ Các ràng buộc mà hệ thống được phát triển và
vận hành.
„ Là sự phối hợp của nhà phát triển và khách 
hàng.
„ Quyết định chất lượng phần mềm đạt được 
và chi phí bỏ ra.
Phân tích và đặc tả
‰Mục đích: Đặc tả yêu cầu phần mềm 
‰Cơ sở cho việc mời thầu (cần có giải 
thích)
‰cơ sở để ký kết hợp đồng (cần đầy 
đủ chi tiết)
‰Làm tư liệu phục vụ thiết kế và triển 
khai (cần đầy đủ , chính xác, không 
mâu thuẫn)
3Yêu cầu là gì?
‰ Các yêu cầu là các mô tả từ mức trừu tượng rất 
cao đến một đặc ta rất chi tiết về dịch vụ mà hệ
thống cần cung cấp cũng như các ràng buộc lên sự
phát triển và họat động của nó.
‰ Yêu cầu là:
‰ Năng lực của phần mềm mà người sử dụng cần để giải quyết 
vấn đề đặt ra nhằm đạt được mục đích xác định
‰ Năng lực của phần mềm cần có nhằm thỏa mãn một hợp 
đồng, một chuẩn, một đặc tả.
Bài toán
•Hiểu vấn đề
•Chi tiết hóa
•Biểu diễn lại Đặc tả
Vai trò
„ Có vai trò đặc biệt quan trọng trong 
tiến trình phát triển phần mềm.
4Phân loại yêu cầu
„ Yêu cầu người dùng
„ Diễn đạt bằng ngôn ngữ tự nhiên và sơ đồ
„ Nêu rõ dịch vụ hệ thống cung cấp và các ràng 
buộc trong hoạt động của nó.
„ Yêu cầu hệ thống
„ Mô tả đủ chi tiết về các dịch vụ hệ thống
„ Như một hợp đồng giữa khách hàng và nhà thầu
„ Đặc tả phần mềm
„ Mô tả chi tiết về phần mềm làm cơ sở cho thiết kế
và cài đặt
„ Dành cho người phát triển
Đối tượng đọc yêu cầu
Ö Yêu cầu viết ra cần đáp ứng được tất cả
các đối tượng này.
5Các loại yêu cầu
„ Các yêu cầu chức năng
„ Mô tả các chức năng hay các dịch vụ mà hệ thống 
phần mềm cần cung cấp.
„ Các yêu cầu phi chức năng
„ Mô tả các ràng buộc đặt lên dịch vụ và quá trình 
phát triển hệ thống (về chất lượng, về môi trường, 
chuẩn sử dụng, qui trình phát triển..)
„ Các yêu cầu miền/lĩnh vực
„ Những yêu cầu đặt ra từ miền ứng dụng, phản 
ánh đặc trưng của miền đó.
Yêu cầu chức năng
„ Mô tả chức năng hay các dịch vụ của hệ thống
„ Chúng phụ thuộc vào:
„ Loại phần mềm sẽ được xây dựng
„ Sự mong muốn của khách hàng
„ Loại hệ thống mà phần mềm trợ giúp
„ Mức độ các yêu cầu
„ Trừu tượng: hệ thống làm gì
„ Chi tiết: dịch vụ cụ thể hệ thống thực hiện 
6Yêu cầu chức năng
„ Ví dụ
„ Người sử dụng có thể tìm kiếm tài liệu dựa trên từ
khóa có trong tài liệu hoặc tên tài liệu
„ Hệ thống cần cug cấp cho người sử dụng phương 
tiện hiển thị dễ dàng các tài liệu từ CSDL
„ Hệ thống phải đọc được các dịnh dạng khác nhau 
của tài liệu: text, doc, pdf, ppt, bảng tính excel,..
Yêu cầu chức năng
„ Sự không chính xác của yêu cầu
„ Yêu cầu không được phát biểu chính xác
„ Yêu cầu nhập nhằng có thể được hiểu khác nhau giữa người 
sử dụng và người phát triển
„ Ví dụ: yêu cầu “hiển thị dễ dàng”
„ Người sử dụng: có thể hiển thị các loại tài liệ khác nhau
„ Người phát triển: cung cấp giao diện hiển thị tài liệu ở chế độ 
văn bản
„ Trên nguyên tắc yêu cầu phải thỏa mãn
„ Đầy đủ: yêu càu phải mô tả đầy đủ các chức năng cần thiết
„ Gắn bó: các yêu cầu không mâu thuẫn nhau
„ Thực tế không đơn giản để có các yêu cầu đầy dủ và
gắn bó
7Yêu cầu phi chức năng
„ Định nghĩa các tính chất và ràng buộc của hệ thống
„ Yêu cầu tiến trình
„ Phương pháp thiết kế
„ Ngôn ngữ lập trình
„ Công cụ sử dụng
„ Thời gian trả lời
„ Độ tin cậy
„ Yêu cầu về lưu trữ dữ liệu
„ Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu phi chức 
năng
„ Nếu yêu cầu phi chức năng không được đáp ứng hệ thống trở nên 
vô dụng
Yêu cầu phi chức năng
„ Yêu cầu về sản phẩm
„ Tốc độ, độ tin cậy, bộ nhớ cần, giao diện
„ Yêu cầu về tổ chức, tiến trình phát triển
„ Các chuẩn áp dụng, phương pháp thiết kế, 
ngôn ngữ lập trình, mô hình tiến trình,..
„ Yêu cầu từ bên ngoài
„ Về chi phí, về bản quyền, liên kết,..
8Các loại yêu cầu phi chức năng
Yêu cầu
Phi chức năng
Yêu cầu
Sản phẩm
Yêu cầu
về tổ chức
Yêu cầu
từ bên ngoài
Yêu cầu
Khả dụng
Yêu cầu
Hiệu quả
Yêu cầu
Tin cậy
Yêu cầu
Khả chuyển
Yêu cầu hoạt 
động bên trong
Yêu cầu
Đạo lý
Yêu cầu
Pháp lý
Yêu cầu 
chuyển giao
Yêu cầu
Triển khai
Yêu cầu 
về chuẩn
Yêu cầu
Cá nhân
Yêu cầu 
về an toàn
Yêu cầu
về hiệu năng
Yêu cầu 
không gian
Yêu cầu phi chức năng
„ Ví dụ
„ Yêu cầu về sản phẩm
„ Phần mềm chỉ nên yêu cầu tối đa 256 MB bộ nhớ
„ Yêu cầu vê tổ chức
„ Yêu cầu phải đáp ứng chuẩn DO178
„ Yêu cầu bên ngoài
„ Hệ thống không được để lộ thông tin cá nhân của 
khách hàng ra bên ngoài
9Yêu cầu người sử dụng 
(user requirements)
„ Nên mô tả
„ Yêu cầu chức năng
„ Yêu cầu phi chức năng
„ Dể hiểu đối với người sử dụng
„ Không có kiến thức chi tiết về kỹ thuật/tin học
„ Nên mô tả
„ Bằng ngôn ngữ tự nhiên
„ Biểu đồ, bảng biểu
Ngôn ngữ tự nhiên (NNTN)
„ Ưu điểm
„ Dễ hiểu
„ Dễ sử dụng
„ Hạn chế
„ Không rỏ ràng, thiếu chính xác
„ Nhập nhẵng
„ Lẫn lộn giữa yêu cầu chức năng và yêu cầu phi 
chức năng
„ Quá mềm dẻo
„ Có thể trình bày nhiều cách
10
Giải pháp thay thế cho NNTN 
„ Ngôn ngữ có cấu trúc
„ Sử dụng ngôn ngữ gần gũi với ngôn ngữ
lập trình
„ Các mô hình
„ Các ký hiệu đồ họa
„ Ký hiệu tóan học
„ Ngôn ngữ hình thức
Yêu cầu hệ thống
(System Requirements)
„ Là đặc tả chi tiết hơn yêu cầu người sử
dụng
„ Phục vụ cơ bản cho bước thiết kế
„ Có thể sử dụng làm một phần của hợp 
đồng
„ Có thể sử dụng các mô hình để mô tả
11
Tài liệu yêu cầu
„ Chỉ mô tả về chức năng (các hành vi bên 
ngòai) của hệ thống và các ràng buộc 
(WHAT)
„ Không mô tả về phương thức cài đặt (HOW) 
– không phải là tài liệu thiết kế
„ Phải dễ thay đổi
„ Khó xác định được đầy đủ, chính xác ngay
„ Phải qua nhiều bước xét duyệt lại
„ Sử dụng như là tài liệu tham khảo khi bảo trì
„ Đặc tả trả lời các sự kiện không mong đợi
Tài liệu yêu cầu
„ Khó khăn
„ Khách hàng chỉ có khái niệm mơ hồ
„ người phát triển phải chi tiết hóa thành các yêu 
cầu phần mềm có thể xây dựng được
„ Khách hàng rất hay thay đổi yêu cầu
„ người phát triển cần tỉnh táo để xác định đúng 
các yêu cầu
„ Các yêu cầu thường mang tính đặc thù
„ Khó hiểu, khó định nghĩa
„ Không có chuẩn biểu diễn
12
Tài liệu yêu cầu
„ Khó khăn
„ Hệ thống đa người sử dụng
„ Các yêu cầu đa dạng, mức ưu tiên khác nhau
„ Yêu cầu mâu thuẫn nhau
„ Người đặt hành khác người sử dụng thật sự
„ Không nắm vững yêu cầu
Cấu trúc của tài liệu yêu cầu
„ Giới thiệu
„ Thuật ngữ
„ Định nghĩa yêu cầu người sử dụng
„ Kiến trúc hệ thống
„ Đặc tả yêu cầu hệ thống
„ Mô hình hệ thống
„ Phát triển/thay đổi của hệ thống
„ Phụ lục
„ Chỉ mục
13
Định dạng của tài liệu yêu cầu
„ Theo chuẩn IEEE 830-1984
1. Giới thiệu
2. Mô tả chung
3. Yêu cầu chi tiết
Định dạng của tài liệu yêu cầu
1. Giới thiệu
1.1. Mục đích
1.2. Phạm vi
1.3. Định nghĩa (định nghĩa, từ viết tắt)
1.4. Tài liệu tham khảo
1.5. Mô tả cấu trúc tài liệu
14
Định dạng của tài liệu yêu cầu
2. Mô tả chung
2.1. Tổng quan về sản phẩm
2.2. Chức năng sản phẩm
2.3. Đối tượng người dùng
2.4. Ràng buộc tổng thể
2.5. Giả thiết và sự lệ thuộc
Định dạng của tài liệu yêu cầu
3. Yêu cầu chi tiết
3.1. Yêu cầu về chức năng
3.1.1. Chức năng 1
3.1.1.1. Giới thiệu
3.1.1.2. Dữ liệu vào
3.1.1.3. Xử lý
3.1.1.4. kết quả
3.1.2. Chức năng 2
3.1.n. Chức năng n
3.2. Yêu cầu về giao diện ngoài
3.2.1. Giao diện người dùng
3.2.2. Giao diện phân cứng
3.2.3. Giao diện phần mềm
3.2.4. Giao diện truyền thông
3.3. Yêu cầu hiệu suất
3.4 Ràng buộc thiết kế
3.5. Thuộc tính: - bảo mật
- bảo trì
3.6. Yêu cầu khác
Phụ lục
15
Các công đoạn phân tích và đặc tả
Phân tích bài tóan
Thu thập yêu cầu
Nghiên cứu khả thi Phân tích 
yêu cầu
Xác định
yêu cầu
Đặc tả
yêu cầu
Báo cáo 
khả thi Tài liệu mô 
tả hệ thống
Tài liệu định 
nghĩa yêu cầu
Tài liệu đặc
tả yêu cầuThẩm định
Tài liệu yêu cầu
Quá trình 
hình thành 
yêu cầu
Tiến trình phân tích yêu cầu
Hiểu miền 
ứng dụng
Thẩm định
yêu cầu
Phân loại
yêu cầu
Sắp xếp
ưu tiên
Đặc tả
yêu cầu
Thu thập 
yêu cầu
Giải quyết 
mâu thuẩn
Tài 
liệu 
mô 
tả
HT
16
Phân tích bài tóan
„ Mô tả nghiệp vụ
„ Mô tả các luồng nghiệp vụ, các xử lý và vai 
trò của con người trong hệ thống hiện tại
„ Hiểu được nghiệp vụ
„ Chủ yêu tập trung vào các miền cần tự 
động hoá
„ Hỗ trợ cho việc xác định các thay đổi và cải 
tiến yêu cầu trong hệ thống mới
Phân tích bài tóan
„ Mô tả hệ thống
„ Mô tả hệ thống đề xuất
„ Mô tả luồng thông tin giữa hệ thống đề xuất và 
môi trường của nó
„ Đáp ứng được các mô tả nghiệp vụ
„ Cải tiến nghiệp vụ hiện tại
„ Dựa trên mô tả nghiệp vụ hiện tại
17
Thu thập yêu cầu
„ Xác định tính khả thi của hệ thống
„ Kinh tế
„ Kỹ thuật
„ Vận hành
„ Xác định những người liên quan đến hệ
thống và những người sử dụng cuối
„ Xác định các ràng buộc khi sử dụng hệ
thống đề xuất
Thu thập yêu cầu
„ Xác định phương pháp thu thập yêu cầu
„ Phỏng vấn
„ Xác định các yêu cầu nhập nhằng
„ Có thể sử dụng kỹ thuật nguyên mẫu
„ Xác định các yêu cầu khác mà khách 
hàng không yêu cầu rỏ
„ Ví dụ: giao diện dễ sử dụng
18
Thu thập yêu cầu
„ Kết quả của bước thu thập yêu cầu
„ Phát biểu về sự cần thiết và tính khả thi
„ Giới hạn lĩnh vực/chức năng của phần 
mềm
„ Danh sách những người liên quan/sử dụng 
phần mềm
„ Mô tả môi trường sẽ vận hành phần mềm
„ Danh sách các yêu cầu phần mềm đề xuất
„ Các ràng buộc phần mềm đề xuất
Thu thập yêu cầu
„ Các kỹ thuật thu thập yêu cầu
„ Phỏng vấn
„ Thực hiện các cuộc họp/hội thảo
„ Chuẩn bị bảng câu hỏi điều tra
„ Chức năng mong đợi
„ Thời gian yêu cầu hoàn thành dự án
„ Kết quả một tiến trình nghiệp vụ
„ Quan sát họat động nghiệp vụ hiện tại
„ Đến nơi làm việc của khách hàng để khảo sát, quay 
phim,..
„ Tham khảo các chuyên gia trong lĩnh vực
„ Hiểu rỏ các nghiệp vụ chuyên môn phức tạp
19
Thu thập yêu cầu
„ Phỏng vấn
„ Hiểu rỏ nghiệp vụ hiện tại
„ Hiểu rỏ chi tiết yêu cầu
„ Hiểu rỏ mong muốn thực sự của khách hàng
„ Chuẩn bị
„ Lập danh sách đối tượng, hẹn gặp, lập kế hoạch, chuẩn bị câu 
hỏi, phương tiện,..
„ Câu hỏi
„ Câu hỏi đóng – mở
„ Câu hỏi ngắn gọn, tập trung vào chủ đề
„ Cách thức tiến hành
„ Theo nhóm, ít nhất hai người
„ Phân công hỏi và ghi chép
Nghiên cứu khả thi
„ Mục tiêu của nghiên cứu khả thi là đi đến kết 
luận:
„ Có nên phát triển hệ thống hay không?
„ Nội dung nghiên cứu khả thi tập trung vào 
những câu hỏi sau:
„ Hệ thống xây dựng sẽ giúp gì cho tổ chức?
„ Hệ thống xây dựng sử dụng công nghệ nào và kinh 
phí bao nhiêu?
„ Hệ thống cần tích hợp với hệ thống nào đang sử
dụng?
20
Nghiên cứu khả thi
„ Báo cáo khả thi được viết dựa trên thông tin, 
báo cáo thu thập được, những đánh giá ban 
đầu về hệ thống hiện tại và phác họa các 
phương án dự kiến.
„ Câu hỏi đặt ra cho người của tổ chức:
„ Cái gì xảy ra nếu hệ thống không được triển khai?
„ Những vấn đề gì đang đặt ra cần giải quyết?
„ Hệ thống được đề xuất giúp họ như thế nào?
„ Những tích hợp gì cần phải có?
„ Công nghệ mới gì, kỹ năng gì cần có?
„ Những tiện ích gì cần sự trợ giúp từ hệ thống?
Phân tích yêu cầu
Những khó khăn của phân tích
„ Khách hàng thường mơ hồ về các yêu cầu, không 
biết mình muốn cụ thể gì, dễ lẫn lộn giữa yêu cầu và
mong muốn.
„ Họ thể hiện yêu cầu theo thuật ngữ riêng
„ Khách hàng đa dạng có thể đưa ra các yêu cầu mâu 
thuẫn.
„ Những yếu tố tổ chức và chính sách có thể ảnh 
hưởng đến yêu cầu
„ Yêu cầu thường mang tính đặc thù, khó hiểu, khó có
chuẩn chung.
„ Các yêu cầu thay đổi trong quá trình phân tích: môi 
trường nghiệp vụ thay đổi,..
21
Phân tích yêu cầu
„ Đôi khi còn gọi là phát hiện yêu cầu.
„ Nhà kỹ thuật cùng với khách hàng (người 
dùng, kỹ sư, nhà quản lý, chuyên gia,..-người 
liên quan) làm rõ lĩnh vực ứng dụng, các dịch 
vụ mà hệ thống cần cung cấp và các ràng 
buộc trong họat động của nó.
„ Xây dựng các mô hình phân tích để làm rõ 
các yêu cầu miền.
Phân tích yêu cầu
„ Phân loại yêu cầu
„ Chức năng
„ Phi chức năng
„ Yêu cầu chức năng xuất phát từ các yêu cầu 
của khách hàng và nghiệp vụ trong hệ thống 
hiện tại
„ Yêu cầu phi chức năng thường không lộ rõ
„ Thường do người phát triển đề xuất
22
Phân tích yêu cầu
Mục tiêu, mong muốn và yêu cầu
„ Mục tiêu, mong muốn: là cái hướng tới.
„ Ví dụ: “Xây dựng giao diện thân thiện”
„ Yêu cầu: là cái cụ thể kiểm tra được
„ Ví dụ: “Giao diện đồ họa có các lệnh được chọn 
bằng menu”
„ Nhiệm vụ của người phân tích là các xác định 
đúng, đầy đủ và chính xác các yêu cầu.
Nguyên lý phân tích yêu cầu
Nguyên lý 1: Mô hình hóa miền thông tin
„ Phải hiểu và biểu diễn được miền thông tin 
(problem domain)
„ định danh dữ liệu (đối tượng, thực thể)
„ định nghĩa các thuộc tính
„ thiết lập các mối quan hệ giữa các dữ liệu
ÖTừ điển dữ liệu, mô hình thực thể mối quan 
hệ,mô hình khái niệm
23
Nguyên lý phân tích yêu cầu
Nguyên lý 2: Mô hình hóa chức năng
„ Bản chất của phần mềm là biến đổi thông tin
„ định danh các chức năng (biến đổi thông tin)
„ xác định cách thức dữ liệu (thông tin) di chuyển 
trong hệ thống (luồng dữ liệu)
„ xác định các tác nhân tạo dữ liệu (nguồn) và tác 
nhân tiêu thụ dữ liệu (đích)
ÖMô hình phân rã chức năng, mô hình luồng 
dữ liệu
Nguyên lý phân tích yêu cầu
Nguyên lý 3: Mô hình hóa hành vi
„ Phần mềm (hệ thống) có trạng thái (hành vi)
„ xác định các trạng thái của hệ thống
„ ví dụ: giao diện đồ họa, section trong ứng dụng web
„ xác định các dữ kiện làm thay đổi hành vi hệ
thống
„ ví dụ: bàn phím, chuột, các cổng thông tin...
ÖBiểu đồ trạng thái
24
Nguyên lý phân tích yêu cầu
Nguyên lý 4: Phân hoạch các mô hình
„ Làm mịn, phân hoạch và biểu diễn các 
mô hình ở các mức khác nhau
„ làm mịn các mô hình dữ liệu
„ tạo cây (mô hình) phân rã chức năng
„ biểu diễn hành vi ở các mức chi tiết khác 
nhau
ÖMô hình luồng dữ liệu các mức 1,2,3,..
Nguyên lý phân tích yêu cầu
Nguyên lý 5: Tìm hiểu vấn đề bản chất
„ Nhìn nhận bản chất của yêu cầu (làm 
gì, điều kiện gì,..)
„ Không quan tâm đến cách thức cài đặt 
(làm như thế nào)
25
Phân hoạch yêu cầu
Có thể phân hoạch yêu cầu theo hai cách
„ Phân loại theo đặc trưng:
„ Yêu cầu tương hỗ: chịu ảnh hưởng của môi trường
„ Yêu cầu nảy sinh:nhận ra trong quá trình phát triển
„ Yêu cầu hệ quả:là kết quả của việc áp dụng hệ thống dựa 
trên máy tính
„ Yêu cầu tương thích:phụ thuộc vào hệ khác hay tiến trình tổ
chức
„ Phân loại theo mức độ quan trọng: chính, phụ
Thẩm định yêu cầu
„ Thẩm định yêu cầu liên quan tới việc kiểm 
tra tính đúng đắn, tính đầy đủ, tính hiện 
thực và kiểm tra được của yêu cầu.
1. Thỏa mãn được nhu cầu của người dùng?
2. Yêu cầu không mâu thuẫn nhau?
3. Yêu cầu phải đầy đủ (chức năng, ràng buộc)?
4. Yêu cầu là hiện thực?
5. Yêu cầu có thể kiểm tra được?
26
Thẩm định yêu cầu
„ Thường xuyên thẩm định yêu cầu
„ Cả khách hàng và ngườ ... ngôn ngữ hình thức hoá
„ Đặc tả bằng công thức tóan học
33
Đặc tả hình thức hay không hình thức?
„ Đặc tả hình thức
„ Chính xác (toán học)
„ Hợp thức hóa hình thức (công cụ hóa)
„ công cụ trao đổi: khó đọc, khó hieu
„ khó sử dụng
„ Đặc tả không hình thức
„ Dễ hiểu, dễ sử dụng
„ Mềm dẻo
„ Thiếu sự chính xác
„ Không chặc chẽ, Nhập nhằng
Đặc tả phi hình thức
„ Ví dụ: chức năng kiểm tra lỗi chính tả
„ Yêu cầu: thông báo các lỗi chính tả khi duyệt
„ Đặc tả:
„ Các lỗi chính tả được gạch đỏ bên dưới
„ Các lỗi soạn thảo được gạch xanh bên dưới
„ Lỗi chính tả:
„ Từ đơn không có trong từ điển
„ Lỗi soạn thảo
„ Thừa dấu cách
„ Không viết hoa đầu câu
34
Ứng dụng đặc tả hình thức
„ ứng dụng trong các giai đoạn sớm của 
tiến trình phát triển
„ Hạn chế lỗi trong phát triển phần mềm
„ Ứng dụng chủ yếu trong phát triển các 
hệ thống “quan trọng” (critical system)
„ Hệ thống điều khiển
„ Hệ thống nhúng
„ Hệ thống thời gian thực
Các kỹ thuật đặc tả hình thức
„ Biểu đồ luồng dữ liệu
„ Biểu đồ thực thể kết hợp
„ Làm bản mẫu
„ Máy trạng thái hữu hạn
„ Mạng Petri
„ Điều kiện trước sau
„ Kiểu trừu tượng
„ Ngôn ngữ đặc tả Z
35
Biểu đồ phân rã chức năng
„ Function Decomposition Diagram – FDD
„ Xác định phạm vi của hệ thống
„ Phân hoạch chức năng
„ Tạo nền tảng cho thiết kế kiến trúc hệ
thống
Chức năng
Bán hàng
Liên kết
Nhận đơn Gửi đơn Gom, gửi hàng
Biểu đồ phân rã chức năng
„ Ví dụ: biểu diễn các chức năng của hệ
thống cửa hàng nước giai khát
Hệ quản lý cửa 
hàng
Bán hàng Kế toán Quản lý tồn 
kho
Quản lý nhập 
hàng
Quản lý 
xuất
Báo cáo 
tồn
Bán lẽ Quản lý đơn 
hàng
Quản công 
nợ
Chức năng
Quan hệ bao 
hàm
36
Biểu đồ dòng dữ liệu
„ Data Flow Diagram – DFD
„ Mô tả cách thức dữ liệu di chuyển và được xử lý, 
lưu trữ trong hệ thống
„ DFD dễ viết, dễ đọc, dễ hiểu được sử dụng phổ
biến
„ DFD được xây dựng từ các hình vẽ và các kí hiệu 
qui ước.
„ Có nhiều mức chi tiết khác nhau (phân tích có cấu 
trúc)
„ Có nhiều cách xây dựng DFD, thông dụng là 
phương pháp DeMarco-Yourdon, Gane Sarson và
Merise (pháp)
Biểu đồ dòng dữ liệu
„ Một số phương pháp vẽ DFD
37
Biểu đồ dòng dữ liệu
„ DFD – Các thành tố
„ Quá trình (Process)
„ Mô tả hoạt động (activities) hay phép biến đổi 
(Transform) một hoặc nhiều dòng dữ liệu vào (input) 
thành một hoặc nhiều dòng dữ liệu ra (output)
„ Quá trình không chỉ ra chi tiết logic hay thủ tục xử lý
„ Trong sơ đồ DFD, quá trình có thể là một người sử dụng 
hoặc máy tính xử lý
„ Ví dụ:
„ Nhận yêu cầu khách hàng
„ Thủ tục giao hàng
„ Thông báo
„ Xử lý điểm
1
Mô tả quá trình
Biểu đồ dòng dữ liệu
„ DFD – Các thành tố
„ Thực thể (Entity)
„ Xác định ranh giới, phạm trù hay phạm vi, ngữ cảnh của 
hệ thống đang xét
„ Cung cấp cái vào cho hệ thống và lấy cái ra từ hệ thống
„ Các thực thể có thể nằm bên trong hay bên ngoài, tạo 
thành các nguồn hay các đích cho hệ thống
„ Mỗi thực thể có thể là một người, tổ chức hoặc một hệ
thống khác tương tác với hệ thống đang xét
„ Ví dụ:
„ Khách hàng
„ Học viên
„ Giáo viên
Tên thực thể
38
Biểu đồ dòng dữ liệu
„ DFD – Các thành tố
„ Kho dữ liệu (data stores):
„ Chỗ chứa các thông tin được lưu theo thời gian, được xử
lý thủ công hay tự động
„ Đó là các tập tin, cơ sở dữ liệu hay bất cứ các hình thức 
lưu trữ dữ liệu nào (bảng biểu báo cáo, từ điển, hộp thư, 
danh bạ,..)
„ Ví dụ:
„ Hồ sơ học viên
„ Sổ nợ
„ Kết quả tuyển sinh
Tên kho dữ liệu
Biểu đồ dòng dữ liệu
„ DFD – Các thành tố
„ Dòng dữ liệu (Data flows)
„ Phương tiện luân chuyển thông tin thể hiện cái vào và
cái ra, thể hiện sự tương tác trong hệ thống
„ Có thể là báo cáo, biểu mẫu, vân bẳn, thư tín, thông 
điệp hay dữ liệu nói chung
„ Được tạo thành từ các vật mang thông tin (giấy, màn 
hình,..) có cùng bản chất
„ Đi từ tơi phát (nguồn) đến nơi nhận (đích)
„ Ví dụ:
„ Yêu cầu cho vay
„ Tra lời vay
„ Báo kết quả thi
Dữ liệu chuyển
39
Biểu đồ dòng dữ liệu
„ Ví dụ: DFD hệ thống mua bán hàng
Biểu đồ dòng dữ liệu
„ Ví dụ: DFD hệ thống tài chính cá nhân
40
Biểu đồ dòng dữ liệu
„ DFD – Các bước thực hiện
„ Phân rã chức năng hệ thống
„ Liệt kê các tác nhân, các khoản mục dữ
liệu
„ Vẽ DFD cho các mức
„ Làm mịn DFD cho các mức từ DFD ngữ
cảnh
Biểu đồ dòng dữ liệu
„ DFD – Một số nguyên tắc
„ Các tiến trình phải có luồng vào và luồng ra
„ Không có luồng dữ liệu giữa các tác nhân –
tác nhân, tác nhân – kho dữ liệu, kho dữ liệu 
– kho dữ liệu.
„ Luồng dữ liệu không quay lại nơi xuất phát
„ Làm mịn cần đảm bảo đầy đủ các yếu tố của 
bước trước (tác nhân, luồng dữ liệu, kho dữ
liệu).
41
Biểu đồ dòng dữ liệu
„ Các mức DFD
Biểu đồ thực thể quan hệ
„ ERD – Entity Relation Diagram
„ Phân tích dữ liệu độc lập với xử lý
„ Nghiên cứu miền thông tin
„ Tạo ra mô hình trừu tượng hướng khách 
hàng
„ Xác định mối liên hệ giữa các dữ liệu
42
Biểu đồ thực thể quan hệ
„ ER – khái niệm
„ Thực thể: 
„ Là các đối tượng thế giới thực mà
chúng ta muốn xử lý
„ Có thể là đối tượng thực hoặc trừu tượng
„ Thuộc tính: 
„ là các đặc điểm, tính chất của thực thể
„ Quan hệ: 
„ Mối liên hệ giữa các thực thể
„ Là thông tin cần lưu trữ, xử lý
„ Kế thừa: quan hệ thừa kế giữa các thực thể
Tên thực thể
Thuộc tính1
Thuộc tính 2
Biểu đồ thực thể quan hệ
„ ER – ví dụ
NGK
ĐĐHÀNG_NGK
ĐẶT
KHÁCH_HÀNG
LOẠI_NGKTHUỘC
CỦA
(0,n)
(1,n)
(1,1) (0,n)
(1,n)(1,1)
NGK(MA_NGK, TEN_NGK, HIEU, LOAI, DVTINH, DON_GIA)
ĐĐHANG_NGK(SO_DDH, NGAY_DAT, KHACH_HANG, NGAYGIAO, TRANG THAI)
CHITIET_DDH(MA_NGK, SO_DDH, SL_DAT, DONGIA_DAT)
43
Biểu đồ thực thể quan hệ
„ ER – Xác định thực thể quan hệ
„ Thực thể: 
„ Là các danh từ (trong câu mô tả các yêu cầu)
„ Có các thuộc tính khóa (xác định duy nhất)
„ Quan hệ
„ Hoạt động xảy ra giữa các thực thể
„ Có nghĩa với họat động của hệ thống
„ Là động từ
Biểu đồ thực thể quan hệ
„ ER – Các bước
„ Mô tả thực thể và sự liên kết giữa các thực 
thể
„ Mô tả thực thể và các mối quan hệ
„ Mô tả thực thể, các mối quan hệ và các 
thuộc tính
44
Từ điển dữ liệu
„ Phương pháp có tính hình thức để mô 
tả dữ liệu mà hệ thống xử lý
„ Ký pháp để mô tả các dữ liệu điều 
khiển và miền giá trị của chúng
„ Chứa đựng các thông tin về nơi (modul) 
và cách thức xử lý dữ liệu
„ Thường được tạo bằng các công cụ trợ
giúp
Từ điển dữ liệu
„ Các khoản mục từ điển dữ liệu
„ Tên (name): tên dữ liệu
„ Bí danh (alias):tên gọi khác của dữ liệu
„ Vị trí (where): tên các modul xử lý
„ Cách thức (how): vai trò của dữ liệu và
cách thức xử lý
„ Ký pháp (Description): ký pháp mô tả dữ
liệu
„ Format: Kiểu dữ liệu,giá trị mặc định,
45
Từ điển dữ liệu
„ Từ điển dữ liệu – ví dụ Integrated
office 
phone 
system
Telephone number System output
alphanumeric dataFormat:
telephone no. = [ local extension | outside no. | 0 ] 
outside no. = 9 + [ service code | domestic no. ] 
service code = [ 211 | 411 | 611 | 911 ] 
domestic no. = ( ( 0 ) + area code ) + local number 
area code = *three numeral designator*
Description:
Read_phone_number(input)
Display_phone_number(output)
Analyze_long_distance_calls (input)
Where/ How used:
Phone number, numberAliases:
Telephone numberName:
Bảng từ điển dữ liệu
Làm bản mẫu trong phân tích 
„ Trong nhiều trường hợp, mô hình chạy 
thử là phương pháp duy nhất để xác 
định yêu cầu
„ Phần mềm lớn, phức tạp ⇒ bản mẫu
(trực quan)
„ Bản mẫu phần mềm:phát triển yêu cầu
„ Bản mẫu phần cứng: kiểm tra thiết kế
46
Làm bản mẫu trong phân tích 
„ Các bước thực hiện
„ Bước 1: Đánh giá yêu cầu và xác định có nên làm 
bản mẫu không; độ phức tạp, chủng loại, khách 
hàng
„ Bước 2: Biểu diễn vắn tắt yêu cầu (yêu cầu chức 
năng, yêu cầu phi chức năng)
„ Bước 3: Thiết kế nhanh kiển trúc, cấu trúc dữ liệu
„ Bước 4: Phát triển, kiểm thử
„ Sử dụng các thành phần sẵn có
„ Dùng các ngôn ngữ bậc cao
„ Các thuật tóan dễ cài đặt
„ Bước 5: Người dùng đánh giá (bước quan trọng???)
„ Bước 6: Lặp lại bước2-5 cho đến khi đủ yêu cầu
Làm bản mẫu trong phân tích 
„ Ưu điểm
„ Loại bớt hiểu nhầm
„ Phát hiện thiếu hụt chức năng
„ Ví dụ: soạn thảo kéo theo kiểm tra chính tả
„ Phát hiện các điểm yếu
„ Khó sử dụng
„ Thao tác không an toàn
„ Kiểm tra tính khả thi, hữu ích
„ Có thể xây dựng được không
„ Có thực sự cần không
„ Làm cơ sở cho đặc tả: làm giống như thế này nhưng tốt hơn
„ Huấn luyện người sử dụng
„ Hỗ trợ kiểm thử (so sánh kết quả)
ÖLàm bản mẫu là kỹ thuật tránh rủi ro
47
Làm bản mẫu trong phân tích 
„ Nhược điểm
„ Các yêu cầu phi chức năng thường không 
được thể hiện đầy đủ
„ Làm tăng chi phí:cần phải ước lượng chi 
phí chính xác của bản mẫu
„ Các yêu cầu thay đổi quá nhanh làm bản 
mẫu trở nên vô nghĩa
„ Người dùng không sử dụng bản mẫu theo 
cách thông thường (kết quả đánh giá
không có giá trị)
Làm bản mẫu trong phân tích 
„ Ngôn ngữ làm bản mẫu
„ Java
„ Visual Basic
„ Prolog, Lisp, Python
„ Các ngôn ngữ script khác
„ Perl, PHP, shell script
48
Làm bản mẫu trong phân tích 
„ Bản mẫu giao diện/trực quan
„ Sử dụng các ngôn ngữ, công cụ trực quan
„ VB
„ Delphi, J Buider
„ FrontPage
„ Sử dụng lại một lượng lớn các thư viện sẵn 
có
„ Tính cấu trúc không cao, khó tích hợp kết 
quả của nhiều nhóm, khó bảo trì
Máy trạng thái hữu hạn
„ Finite State Machine
„ Mô tả các luồng điều khiển
„ Biểu diễn dạng đồ thị
„ Bao gồm:
„ Tập hợp các trạng thái S (các nút của đồ thị)
„ Tập hợp các dữ liệu vào I (các nhãn của các cung)
„ Tập hợp các chuyển tiếp T: S x I -> S (các cung có 
hướng của đồ thị)
„ Khi có một dữ liệu vào một trạng thái sẽ chuyển sang 
trạng thái khác
49
Máy trạng thái hữu hạn
ON
HOOK
OFF
HOOK DIALING
RINGING
BUSY
CONNECTED
Handset
lifted Handset 
replaced
Number
dialed
Number
dialed
Handset 
replaced
Handset 
replaced
Handset 
replaced
Handset 
replaced
Line 
in use
Last number
dialed
Caller
answers
Caller
hangs up
„ Ví dụ 1: 
Máy trạng thái hữu hạn
„ Ví dụ 2:
50
Máy trạng thái hữu hạn
„ Ví dụ 2:
Máy trạng thái hữu hạn
„ Ví dụ 2:
51
Máy trạng thái hữu hạn
„ Biểu diễn hệ thống phức tạp
„ Hạn chế khi đặc tả những hệ thống 
không đồng bộ
„ Các thành phần của hệ thống hoạt động 
song song hoặc cạnh tranh
Điều kiện trước/sau
(Pre/Post Condition)
„ Được dùng để đặc tả các hàm hoặc mô đun
„ Đặc tả các tính chất của dữ liệu trước và sau 
khi thực hiện hàm
„ Pre-condition: đặc tả các ràng buộc trên tham số
trước khi hàm được thực hiện
„ Post-condition: đặc tả các ràng buộc trên tham số
sau khi hàm được thực hiện
„ Có thể sử dụng ngôn ngữ phi hình thức, hình 
thức hoặc ngôn ngữ lập trình để đặc tả các 
điều kiện.
52
Điều kiện trước/sau
„ Ví dụ: đặc tả hàm tìm kiếm
Function search(a: danh sách phần tử kiểu K,
size: số phần tử của danh sách,
e: phần tử kiểu K,
result: kiểu Boolean)
pre ∀i, 1≤i≤size, a[i] ≤ a[i+1]
post result = (∃i, 1≤i≤size, a[i] = e)
Điều kiện trước/sau
„ Bài tập: đặc tả các hàm
„ Sắp xếp một danh sách số nguyên
„ Đảo ngược các phần tử của danh sách
„ Đếm số phần tử có giá trị e trong một danh sách số
nguyên
53
Kiểu trừu tượng
(Abstract type)
„ Mô tả dữ liệu và các thao tác trên dữ liệu đó ở một 
mức trừu tượng độc lập với cách cài đặt dữ liệu bởi 
ngôn ngữ lập trình
„ Đặc tả một kiểu trừu tượng gồm:
„ Tên của kiểu trừu tượng 
„ Dùng từ khóa sort
„ Khai báo các kiểu trừu tượng đã tồn tại được sử dụng
„ Dùng từ khóa import
„ Các thao tác trên kiểu trừu tượng
„ Dùng từ khóa operations
Kiểu trừu tượng
„ Ví dụ 1: đặc tả kiểu trừu tượng Boolean
„ Một thao tác không có tham số là một hằng số
„ một giá trị của kiểu trừu tượng được định 
nghĩa biểu diễn bởi kí tự “_”
54
Kiểu trừu tượng
„ Ví dụ 2: đặc tả kiểu trừu tượng Vector
Kiểu trừu tượng
„ Các thao tác trên kiểu trừu tượng chỉ được 
định nghĩa mà không chỉ ra ngữ nghĩa của nó
„ Tức là ý nghĩa của thao tác
„ Sử dụng các tiên đề để chỉ ra ngữ nghĩa của 
các thao tác
„ Sử dụng từ khóa axioms
„ Định nghĩa các ràng buộc mà một thao tác 
được định nghĩa
„ Sử dụng từ khóa precondition
55
Kiểu trừu tượng
„ Ví dụ 2: đặc tả kiểu trừu tượng Vector
Kiểu trừu tượng
„ Bài tập:
„ Đặc tả kiểu trừu tượng Cây nhị phân
„ Đặc tả kiểu trừu tượng Tập hợp
56
Kiểu trừu tượng
„ sort Circle
„ Import Integer, float
„ Operations
„ Init : Integer x Integer x float -> Circle
„ Unit_Circle: ->Circle
„ Bankinh: Circle -> float
„ Get_X: Circle -> Integer
„ Get_Y: Circle -> Integer
„ Zoom: Circle x float -> Circle
„ Tinh_tien:Circle x Integer x Integer -> Circle
Kiểu trừu tượng
„ axioms
„ Bankinh(Unit_Circle) = 1
„ Get_x(Unit_Circle) = Get_Y(Unit_Circle) = 0
„ Bankinh(Init(x, y, r)) = r
„ Get_X(Init(x, y, r)) = x
„ Get_Y(Init(x, y, r)) = y
„ C = Init(x,y,r) => Bankinh(Tinhtien(C, dx, dy)) = r
„ C = Init(x,y,r) => Get_X(Tinhtien(C, dx, dy)) = x + dx
„ C = Init(x,y,r) => Get_Y(Tinhtien(C, dx, dy)) = y + dy
„ C = Init(x,y,r) =>Bankinh(Zoom(C, dr)) = r + dr
„ C = Init(x,y,r) =>Get_X(Zoom(C, dr)) = x
„ C = Init(x,y,r) =>Get_Y(Zoom(C, dr)) = y
„ With
„ C: Circle ; x, y,dx, dy: integer; r, dr: float
57
Mạng Petri (Petri Nets)
„ Thích hợp để mô tả các hệ thống không 
đồng bộ với những họat động đồng thời
„ Mô tả luồng điều khiển của hệ thống
„ Đề xuất năm 1962 bởi Carl Adam
„ Có loại
„ Mạng Petri (cổ điển)
„ Mạng Petri mở rộng
Mạng Petri
„ Gồm các phần tử
„ Một tập hữu hạn các nút (O)
„ Một tập hữu hạn các chuyển tiếp (†)
„ Một tập hữu hạn các cung (→)
„ Các cung nối các nút với các chuyển tiếp hoặc 
ngược lại
„ Mỗi nút có thể chứa một hoặc nhiều thẻ
(z)
58
Mạng Petri
„ Ví dụ:
Mạng Petri
„ Mạng Petri được định nghĩa bởi sự đánh dấu các nút 
của nó
„ Việc đánh dấu các nút được tiến hành theo nguyên 
tắc sau:
„ Mỗi chuyển tiếp có các nút vào và các nút ra
„ Nếu tất cả các nút vào của một chuyển tiếp có ít nhất một 
thẻ, thì chuyển tiếp này có thể vượt qua được.
„ Nếu chuyển tiếp này được thực hiện thì tất cả các nút vào 
của chuyển tiếp sẽ bị lấy đi một thẻ, và một thẻ sẽ được 
thêm vào tất cả các nút ra của chuyển tiếp
„ Nếu chuyển tiếp là có thể vượt qua thì chọn chuyển tiếp nào 
cũng được
59
Mạng Petri
„ Ví dụ
Mạng Petri
„ Ví dụ
60
Mạng Petri
„ Ví dụ
Mạng Petri
„ Ví dụ 1: Mô tả hoạt động của đèn giao thông
61
Mạng Petri
„ Ví dụ 1: Mô tả hoạt động của 2 đèn giao thông
Mạng Petri
„ Ví dụ 1: Mô tả hoạt động an toàn của 2đèn giao thông
62
Mạng Petri
„ Ví dụ 1: Mô tả hoạt động an toàn của 2đèn giao thông
Mạng Petri
„ Ví dụ 2: Chu kì sống của con người
63
Mạng Petri
„ Ví dụ 3: Viết thư và đọc thư
Mạng Petri
„ Ví dụ 4:
„ Hệ thống cần mô tả bao gồm một nhà sản xuất, một nhà
tiêu thụ và môt kho hàng chỉ chứa được nhiều nhất hai sản 
phẩm
„ Nhà sản xuất có 2 trạng thái:
„ P1: đang sản xuất
„ P2: không sản xuất
„ Nhà tiêu thụ có 2 trạng thái:
„ C1: có sản phẩm để tiêu thụ
„ C2: không có sản phẩm để tiêu thụ
„ Kho hàng có 3 trạng thái
„ Chứa 0 sản phẩm
„ Chứa 1 sản phẩm
„ Chứa 2 sản phẩm
64
Mạng Petri
„ Ví dụ 4: mô tả tách rời mỗi thành phần
Mạng Petri
„ Ví dụ 4: Mô tả kết hợp các thành phần
65
So sánh các kỹ thuật đặc tả