TRƯỜNG ĐẠI HỌC THUỶ LỢI

Khoa CNTT – BM Công nghệ phần mềm

PHÂN TÍCH YÊU CẦU PHẦN MỀM

Trần Thị Ngân

Email: ngantt@tlu.edu.vn
ĐT: 0989040454
TỔNG QUAN MÔN HỌC
 TỔNG QUAN MÔN HỌC
 Tên môn học: Phân tích yêu cầu phần mềm

 Mã số: CSE461

 Số tín chỉ: 3

 Số tiết: 30 tiết Lý Thuyết & 15 tiết TH

2
 TỔNG QUAN MÔN HỌC

Mục tiêu môn học:

 Sinh viên nắm được sự cần thiết của yêu cầu phần

mềm

 Hiểu được quá trình phân tích yêu cầu phần mềm

 Viết đặc tả phần mềm

2
 Nội dung môn học

• Tổng quan về yêu cầu phần mềm

• Lập kế hoạch quản lý yêu cầu

• Thu thập, phân tích, làm rõ yêu cầu

• Mô hình hóa yêu cầu

3
 Nội dung môn học

• Yêu cầu phi chức năng

• Đặc tả yêu cầu

• Sắp xếp yêu cầu theo thứ tự ưu tiên

3
 Tài liệu môn học
• Tài liệu chính: Bài giảng của giáo viên
• Tham khảo:
1. Peter Zielczynski, Requirements Management
Using IBM Rational RequisitePro, IBM Press,
ISBN: 0-321-38300-1, 2008.
2. Risk Lutowski, Software Requirements
encapsulation, quality, and Reuse, Auerbach
Publication, 2005.

4
 Tổng quan về yêu cầu phần mềm
- Yêu cầu cho 1 phần mềm cụ thể là tổng hợp những
yêu cầu từ nhiều đối tượng khác nhau về tổ chức,
mức độ chuyên môn và mức độ tham gia, tương tác
với phần mềm trong môi trường hoạt động của nó.
- Có thể kiểm chứng một cách riêng rẽ ở mức chức
năng(các yêu cầu chức năng) hoặc mức hệ thống
(các yêu cầu bổ sung)
- Cung cấp các chỉ số đánh giá độ ưu tiên về các mặt
khi cân nhắc về nguồn tài nguyên.
- Cung cấp các giá trị trạng thái để theo dõi tiến độ
của dự án.
 Tổng quan về yêu cầu phần mềm
 Cần xác định được đầu vào của hệ thống là gì
 Những quá trình cần xử lý trong hệ thống, hay
hệ thống phần mềm sẽ phải xử lý những gì.
 Xác định được đầu ra (kết quả xử lý) của hệ
thống là gì
 Những ràng buộc trong hệ thống, chủ yếu là
mối quan hệ giữa đầu vào và đầu ra như thế
nào
 Mục đích của phân tích yêu cầu
 Phát hiện và giải quyết xung đột giữa các
yêu cầu
 Tìm ra được những cái mà hệ thống phần
mềm phải có; những giới hạn của phần
mềm và cách phần mềm tương tác với tổ
chức và môi trường hoạt động của nó.
 Nghiên cứu các yêu cầu hệ thống để lấy
được các yêu cầu phần mềm.
 Phân loại yêu cầu

 Theo sản phẩm và tiến trình

 Theo chức năng

 Theo tính kiểm định

 Theo phạm vi đặc tả

Phân loại theo sản phẩm và tiến trình
 Yêu cầu sản phẩm: là những đòi hỏi hay
ràng buộc mà phần mềm phải thực hiện.
 Yêu cầu tiến trình: là những ràng buộc
liên quan đến việc phát triển phần mềm
đó(quy trình, đối tác kiểm thử, phân tích,
kĩ thuật sử dụng,...).
 Phân loại theo chức năng
 Yêu cầu chức năng: đặc tả các chức năng mà phần
mềm phải thực hiện.
 Yêu cầu phi chức năng: là các ràng buộc về giải pháp
và chất lượng(hiệu năng, việc bảo trì, độ an toàn, bảo
mật,...).
 Yêu cầu đặc tả các thuộc tính nổi bật: là các đặc tả
cho các thuộc tính phụ thuộc vào sự vận hành,… đặc
biệt là kiến trúc hệ thống. Các thuộc tính này không
thể xác định được cho từng thành phần đơn lẻ.
 Phân loại theo tính kiểm định

 Rõ ràng, định lượng và có thể kiểm định.

 Mơ hồ, không thể kiểm định

 Phân loại theo phạm vi đặc tả

 Yêu cầu hệ thống: đặc tả các cấu hình, cơ

sở hạ tầng, phần cứng, phần mềm, con
người, kỹ thuật,… của toàn bộ hệ thống.
 Yêu cầu phần mềm: đặc tả các chức năng,
giao diện,… của các module phần mềm.
Các nhân tố tham gia (Stakeholder)

 Khách hàng;
 Người dùng cuối;
 Những người phát triển (bảo trì);
 Những nhà sản xuất;
 Những người kiểm thử;
Các nhân tố tham gia (Stakeholder)

 Người đảm bảo chất lượng;

 Người quản trị Cơ sở dữ liệu;

 Người quản lý cấu hình;

 Những nhà cung cấp;

Các nhân tố tham gia (Stakeholder)

 Những nhà tiếp thị;

 Người quản lý;

 Các cơ quan quy định tính an toàn hệ

thống (Safety regulation agencies).

 Ví dụ

Xác định các thành phần tham gia vào

hệ thống Quản lý đào tạo Trường Đại
học Thuỷ lợi?
Kim tự tháp các yêu cầu
 Kim tự tháp các yêu cầu
 NEEDS : Yêu cầu được để xuất bởi Stakeholder
 FEATURES: Một dịch vụ được cung cấp bởi hệ thống.
Mục tiêu của một đặc trưng là để thỏa mãn một nhu cầu
Stakeholder.
 USE CASES : Một mô tả về hành vi của hệ thống
 SUPPLEMENTARY REQUIREMENT : yêu cầu khác
(thường là yêu cầu phi chức năng) và không thể được thể
hiện trong các use cases
 TEST CASES (ca kiểm thử): một đặc tả về các đầu vào
kiểm thử, các điều kiện thực thi, và các kết quả mong đợi.
 SCENARIOS: Một chuỗi hành động cụ thể; một đường cụ
thể qua một use case.
 Các đặc tính của một yêu cầu tốt

 Có thể hiểu

 Khả thi (hiện thực, có thể thực hiện)

 Cần thiết

 Độc lập với cài đặt (trừu tượng)

 Các đặc tính của một yêu cầu tốt

 Không mập mờ (Rõ ràng)

 Có thể kiểm thử (có thể thẩm định)

 Ngắn gọn, xúc tích, đơn giản

 Đúng đắn
TIẾN TRÌNH QUẢN LÝ CÁC YÊU CẦU

 Thiết lập bản kế hoạch quản lý

yêu cầu.
 Suy luận các yêu cầu.
 Phát triển tài liệu trực quan.
 Tạo các use case.
 Tiến trình quản lý các yêu cầu
 Đặc tả bổ sung.
 Tạo các test case từ các use case.
 Tạo các test case từ đặc tả bổ
sung.
 Thiết kế hệ thống.
 PHÂN BIỆT PHÂN TÍCH YÊU CẦU
VÀ PHÂN TÍCH THIẾT KẾ
 Yêu cầu: Trả lời câu hỏi What
What: Cái mà hệ thống nên làm
 Thiết kế: Trả lời câu hỏi How
How: Hệ thống làm điều đó như thế
nào.
QUY TRÌNH PHÂN TÍCH
VÀ QUẢN LÝ YÊU CẦU
 NGHIÊN CỨU KHẢ THI
 Khả thi về kinh tế: chi phí và lợi nhuận
 Khả thi về kỹ thuật: tài nguyên sẵn có, công
nghệ, …
 Khả thi về hợp pháp: có sự xâm phạm, vi phạm
hay khó khăn nào gây ra khi xây dựng hệ thống
hay không
 Các phương án: đánh giá về phương án tiếp cận
đến việc xây dựng hệ thống.
 PHÂN TÍCH YÊU CẦU
 Đầu vào của hệ thống là gì
 Những quá trình cần xử lý trong hệ thống, hay
hệ thống phần mềm sẽ phải xử lý những cái gì.
 Đầu ra: kết quả xử lý của hệ thống là gì
 Những ràng buộc trong hệ thống, chủ yếu là
mối quan hệ giữa đầu vào và đầu
ra như thế nào
 PHÂN TÍCH YÊU CẦU

Phân tích yêu cầu là quá trình suy luận

các yêu cầu hệ thống thông qua quan
sát hệ thống hiện tại, thảo luận với
những người sử dụng, phân tích công
việc.
 XÁC ĐỊNH YÊU CẦU
 Là mô tả trừu tượng các dịch vụ mà hệ thống
được mong đợi phải cung cấp và các ràng buộc
mà hệ thống phải tuân thủ khi vận hành.
 Chỉ có các đặc tả đặc điểm bên ngoài của hệ
thống mà không liên quan đến các đặc tính thiết
kế.
 Phải được viết sao cho người đọc có thể hiểu
được mà không cần một kiến thức chuyên môn
đặc biệt nào.
 ĐẶC TẢ YÊU CẦU

Dựa trên những yêu cầu của người sử dụng,

người phát triển đưa ra các đặc tả cho hệ thống
 Đầu ra của hệ thống là cái gì?
 Hệ thống sẽ phải làm cái gì để có kết quả
mong muốn, nghĩa là phải xử lý những cái gì?
 Những tài nguyên mà hệ thống yêu cầu là gì?
 TÀI LIỆU ĐẶC TẢ YÊU CẦU
(Requirements Specification document)
 Là tuyên bố chính thức về những gì
được yêu cầu của các nhà phát triển hệ
thống
 Nên bao gồm cả định nghĩa về các yêu cầu
người dùng và đặc tả của yêu cầu hệ thống
 Nên thiết lập về CÁI hệ thống nên
làm hơn là CÁCH hệ thống nên làm
 THẨM ĐỊNH YÊU CẦU
 Chứng tỏ rằng các yêu cầu định nghĩa được
hệ thống mà khách hàng thực sự muốn.
 Đảm bảo rằng người thực thi, người lập
trình hiểu được yêu cầu.
 Đảm bảo dễ hiểu, nhất quán và hoàn thiện
 Tài liệu yêu cầu có đảm bảo đầu ra là 1 phần
mềm hoàn chỉnh, đúng đắn.
 KHÓ KHĂN KHI PHÂN TÍCH,
NẮM BẮT YÊU CẦU

Những vấn đề từ phía người dùng:

 Người dùng không hiểu họ muốn gì,
 Yêu cầu của người dùng thay đổi
 Người dùng không hiểu về kỹ thuật,
 Người dùng không hiểu về quy trình phát triển
 KHÓ KHĂN KHI PHÂN TÍCH,
NẮM BẮT YÊU CẦU
Những vấn đề từ phía nhà phát triển:
 Nhà phát triển hướng yêu cầu của người dùng theo
một hệ thống hay mô hình sẵn có,
 Việc phân tích yêu cầu có thể do các lập trình viên
thực hiện,
 Ngôn ngữ của người dùng và nhà phát triển không
khớp nhau.
 KHÓ KHĂN KHI PHÂN TÍCH,
NẮM BẮT YÊU CẦU
Những vấn đề khác:
 Các yêu cầu thường khó định nghĩa và không theo một
tiêu chuẩn nào,
 Với các hệ thống thông tin lớn thì các yêu cầu thường
rất đa dạng và có các mức ưu tiên khác nhau, thậm chí
mâu thuẫn lẫn nhau.
 Người đặt hàng đôi khi là các nhà quản lý, không phải
là người dùng thực sự do đó việc đưa ra các yêu cầu
thường không sát với mong muốn thực sự, cần lấy
thêm yêu cầu từ các stakeholders khác.
 TÓM TẮT
 Phân tích và xác định yêu cầu là bước kỹ
thuật đầu tiên trong tiến trình xây dựng
phần mềm.
 PTYCPM gồm các phát biểu chung về
phạm vi phần mềm. Các yêu cầu về phần
mềm được thể hiện thành một bản đặc tả
cụ thể để trở thành nền tảng cho mọi
hoạt động sau đó.
 TÓM TẮT
 Việc phân tích phải tập trung vào các
miền thông tin, chức năng và hành vi của
vấn đề.
 Trong nhiều trường hợp, không thể nào
đặc tả được đầy đủ mọi vấn đề tại giai
đoạn đầu.
 TÓM TẮT
 Việc làm bản mẫu thường giúp chỉ ra
cách tiếp cận khác để từ đó có thể làm
mịn thêm yêu cầu. Việc này đôi khi cần
tới các công cụ và kỹ thuật đặc biệt
 TÓM TẮT

 Kết quả của việc phân tích là tạo ra bản

đặc tả các yêu cầu phần mềm.
 Đặc tả cần được xét duyệt để đảm bảo
rằng người phát triển và khách hàng có
cùng nhận biết về hệ thống cần phát
triển.
 TÓM TẮT
Vai trò của đặc tả các yêu cầu
 LẬP KẾ HOẠCH QUẢN LÝ YÊU CẦU
(REQUIREMENTS MANAGEMENT PLAN)
 NỘI DUNG

 Thời điểm lập kế hoạch quản lý yêu cầu

(RMP)

 Các quyết định được tư liệu hóa trong RMP

 Mẫu của bản kế hoạch quản lý yêu cầu

 THỜI ĐIỂM LẬP KẾ HOẠCH

 Ngay sau khi bắt đầu phát triển dự án, bản kế hoạch
quản lý các yêu cầu cần được xây dựng.

 Bản RMP có thể theo mẫu trong RequisitePro. Sử

dụng mẫu này, chúng ta cần tạo các quyết định được
nắm bắt trong RMP
 CÁC QUYẾT ĐỊNH ĐƯỢC TƯ LIỆU HÓA
TRONG RMP

 Công cụ quản lý yêu cầu (RM) có được sử dụng không?

 Các kiểu yêu cầu gì sẽ được lưu vết trong dự án?

 Các thuộc tính của các kiểu yêu cầu này là gì?

 Các yêu cầu sẽ được tạo ở đâu – chỉ trong CSDL hay
trong các tài liệu?
 CÁC QUYẾT ĐỊNH ĐƯỢC TƯ LIỆU HÓA
TRONG RMP

 Giữa các yêu cầu nào, ta cần triển khai các dấu vết?
 Các tài liệu nào được yêu cầu?
 Chúng ta sẽ tuân theo Tiến trình hợp nhất Rational
(RUP) hay phương pháp luận khác?
CÁC QUYẾT ĐỊNH ĐƯỢC TƯ LIỆU HÓA
TRONG RMP
 CÁC QUYẾT ĐỊNH ĐƯỢC TƯ LIỆU HÓA
TRONG RMP

 Toàn bộ Hệ thống sẽ chỉ được lưu trong một dự án

hay dàn trải ra nhiều dự án khác?
 Tiến trình đảm bảo rằng mọi yêu cầu đã được cài đặt
và được kiểm thử là gì?
 Những yêu cầu và những khung nhìn nào chúng ta
cần để sinh ra các báo cáo?
 CÔNG CỤ QUẢN LÝ YÊU CẦU (RM) CÓ ĐƯỢC SỬ
DỤNG KHÔNG

 Sử dụng công cụ quản lý yêu cầu tạo thuận lợi đáng kể

trong việc tạo và bảo trì các yêu cầu
 Cung cấp khả năng tự hiệu chỉnh yêu cầu theo dấu vết
 Mất chi phí để mua công cụ và mất thời gian để học
cách sử dụng chúng
 Việc so sánh lựa chọn các công cụ RM có thể tìm thấy ở
Website www.paper-review.com/tool/rms/read.php.
CÁC KIỂU YÊU CẦU GÌ SẼ ĐƯỢC LƯU DẤU VẾT
TRONG DỰ ÁN?
CÁC KIỂU YÊU CẦU GÌ SẼ ĐƯỢC LƯU DẤU VẾT
TRONG DỰ ÁN?

• Các yêu cầu Stakeholder (STRQ)

• Các đặc trưng (FEAT)
• Các Use Case (UC)
• Các yêu cầu bổ sung (SUPL)
CÁC THUỘC TÍNH CỦA CÁC KIỂU YÊU CẦU NÀY LÀ
GÌ?
CÁC THUỘC TÍNH CỦA CÁC KIỂU YÊU CẦU NÀY LÀ
GÌ?
 CÁC YÊU CẦU SẼ ĐƯỢC TẠO Ở ĐÂU – CHỈ
TRONG CSDL HAY TRONG CÁC TÀI LIỆU

Các yêu cầu có trong các tài liệu đem lại những lợi ích sau:
 Dễ truy cập hơn đến các yêu cầu bởi các thành viên trong nhóm,
những người mà không có sự truy cập đến CSDL yêu cầu.
 Có cơ hội để nhóm và tổ chức các yêu cầu.

 Trình bày chúng ở dạng dễ đọc hơn.

 Dễ thêm các chú thích và các giải thích.

 CÁC YÊU CẦU SẼ ĐƯỢC TẠO Ở ĐÂU – CHỈ
TRONG CSDL HAY TRONG CÁC TÀI LIỆU

Một lựa chọn để quản lý các yêu cầu trong các tài
liệu là sử dụng các báo cáo.

 Vì tính tự nhiên trong mô tả của chúng, các UC có

thể được kết hợp với các tài liệu – Một tài liệu/1 UC.

 Các đặc trưng được lưu trong tài liệu trực quan.
 Các yêu cầu bổ sung được lưu trong Bản đặc tả bổ
sung.
 GIỮA CÁC YÊU CẦU NÀO CHÚNG TA CẦN
TRIỂN KHAI CÁC DẤU VẾT?

Phụ thuộc và các

kiểu yêu cầu mà
chúng ta lựa chọn,
cây dấu vết có thể
khác nhau.
 CÁC TÀI LIỆU NÀO ĐƯỢC YÊU CẦU?

Tài liệu trực quan

 Các UC ,

 Bản đặc tả bổ sung

CHÚNG TA SẼ TUÂN THEO TIẾN TRÌNH HỢP NHẤT RATIONAL
(RUP) HAY PHƯƠNG PHÁP LUẬN KHÁC?

RUP ( Rational Unified Process ) là tiến trình phát triển

phần mềm lặp ngày càng trở nên thông dụng. Một số lợi
ích của việc sử dụng RUP:
Cách tiếp cận lặp, mọi rủi ro có thể phát hiện sớm
trong tiến trình.
Có thể sử dụng các mẫu tài liệu chuẩn.
Tích hợp với IBM RequisitePro và các công cụ
Rational khác.
NHỮNG YÊU CẦU VÀ NHỮNG KHUNG NHÌN NÀO CHÚNG
TA CẦN ĐỂ SINH RA CÁC BÁO CÁO?
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ YÊU CẦU

1. Introduction
2. Tools, Environment and Infrastructure
3. Documents and Requirement types
3.1. Documents
3.2. Requirement Types
3.3 Traceability
3.4 Requirement Attributes
3.5. Reports and Measures
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ YÊU CẦU
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
MẪU CỦA BẢN KẾ HOẠCH QUẢN
LÝ YÊU CẦU
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
 MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
Các thuộc tính của FEAT
 MẪU CỦA BẢN KẾ HOẠCH QUẢN
LÝ YÊU CẦU
Các thuộc tính của FEAT
 MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
Các thuộc tính của FEAT
 CÁC THUỘC TÍNH CỦA CÁC YÊU
CẦU
Các thuộc tính của FEAT
 CÁC THUỘC TÍNH CỦA CÁC YÊU
CẦU

 Các thuộc tính của STRQ: tương tự như FEAT

trừ Target Release
 Các thuộc tính của Use Case (UC): tương tự
như FEAT thêm thuộc tính Actor.
 Các thuộc tính của SUPL: tương tự như FEAT.
MẪU CỦA BẢN KẾ HOẠCH QUẢN LÝ
YÊU CẦU
 YÊU CẦU
1. Hoàn thành việc lập nhóm và chọn đề tài.
2. Xây dựng bản kế hoạch quản lý yêu cầu gồm
các phần:
- Xác định mục đích, phạm vi của đề tài
- Xác định công cụ sử dụng và các kiểu yêu cầu
- Xác định các nhân tố tham gia dự án phần mềm
của nhóm
- Xây dựng bảng liên lạc với các nhân tố chính
THU THẬP, PHÂN TÍCH,
LÀM RÕ YÊU CẦU
 NỘI DUNG
 Vai trò của thu thập, phân tích yêu cầu
trong dự án phát triển phần mềm

 Các kỹ thuật thu thập yêu cầu

 Xác định các FEAT từ các yêu cầu hiện có

ĐỊNH NGHĨA YÊU CẦU PHẦN MỀM
(REQUIREMENTS ENGINEERING)
CÁC NHÂN TỐ ẢNH HƯỞNG ĐẾN THÀNH CÔNG/THẤT
BẠI CỦA MỘT DỰ ÁN PHÁT TRIỂN PHẦN MỀM
NGUYÊN NHÂN THẤT BẠI CỦA MỘT DỰ
ÁN PHÁT TRIỂN PHẦN MỀM
HẬU QUẢ CỦA SAI SÓT
CÁC THÀNH PHẦN KHI THU THẬP YÊU CẦU
THU THẬP VÀ PHÂN TÍCH YÊU CẦU
THU THẬP VÀ PHÂN TÍCH YÊU CẦU
CÁC HOẠT ĐỘNG TRONG TIẾN TRÌNH
THU THẬP, QUẢN LÝ VÀ LÀM RÕ YÊU
CẦU

• Hiểu phạm vi vấn đề

• Thu thập yêu cầu

• Phân loại

• Giải quyết mâu thuẫn

• Sắp xếp thứ tự ưu tiên

• Kiểm tra, kiểm chứng các yêu cầu

CÁC HOẠT ĐỘNG TRONG TIẾN TRÌNH
THU THẬP, QUẢN LÝ VÀ LÀM RÕ YÊU
CẦU
VAI TRÒ CỦA NHÀ PHÂN TÍCH YÊU CẦU
KHÓ KHĂN KHI THU THẬP YÊU
CẦU
VÍ DỤ
ĐỌC TÀI LIỆU CƠ BẢN
 CÁC KỸ THUẬT THU THẬP, PHÂN TÍCH
YÊU CẦU
 Phỏng vấn (đối thoại riêng lẻ với stakeholder).
 Bản câu hỏi thăm dò (một tập các câu hỏi gửi đến
một tập hợp lớn hơn các stakeholder).
 Hội thảo (Workshop - các stakeholder tập hợp để
tập trung thảo luận).
 Thẻ sự kiện (sử dụng công cụ đồ họa, trực quan
để minh họa hành vi hệ thống).
 Phân vai (mỗi thành viên trong nhóm được gán
một vai, thường là một trong các người dùng
cuối).
 CÁC KỸ THUẬT THU THẬP, PHÂN TÍCH
YÊU CẦU
 Các phiên làm việc tập trung (story boarding -
trình bày các ý tưởng trong phiên tập trung
ngắn).
 Sử dụng các biểu đồ quan hệ.
 Mẫu thử (phát triển một mẫu thử để có sự phản
hồi).
 Các ca sử dụng (sự tương tác giữa người dùng và
hệ thống được trình bày như một chuỗi các bước).
 CÁC KỸ THUẬT THU THẬP, PHÂN TÍCH
YÊU CẦU
 Phân tích các tài liệu hiện có (trích rút thông tin từ
các tài liệu word, các email và các lưu ý).
 Quan sát và minh họa nhiệm vụ (xem người dùng
thực hiện nhiệm vụ cụ thể).
 Phân tích các hệ thống đang tồn tại (thu thập các
yêu cầu từ hệ thống bị thay thế hoặc từ các hệ
thống cạnh tranh đã được xây dựng).
Bảng các Stackholder và các phương pháp
suy luận yêu cầu được sử dụng
 PHỎNG VẤN (INTERVIEW)
 Là một trong các phương pháp suy luận yêu cầu
phổ biến nhất là phỏng vấn.
 Là phương pháp phỏng vấn một nhóm các
stakeholder đã được lựa chọn.
 Lợi ích của phương pháp này là tính tự nhiên
trong giao tiếp.
 PHỎNG VẤN
 Cung cấp cơ hội để phát triển thêm các câu hỏi phụ
thuộc vào các trả lời nhận được.
 Là cách tốt để thu thập các yêu cầu về khả năng sử
dụng, độ tin cậy, hiệu năng và khả năng hỗ trợ của
hệ thống. Khách hàng thường không phát biểu các
yêu cầu phi chức năng này trừ khi họ được hỏi
tường minh.
BẢN CÂU HỎI THĂM DÒ
(QUESTIONAIR)
 BẢN CÂU HỎI THĂM DÒ
(QUESTIONAIR)
 Bản câu hỏi thăm dò là hữu ích nhất nếu chúng
ta có thể hỏi nhiều stakeholder các câu hỏi
tương tự và chúng ta không mong đợi sinh thêm
các câu hỏi.
 Áp dụng được với nhiều đối tượng thuộc các
nhóm Stakeholder hơn so với phỏng vấn trực
tiếp và hội thảo.
 BẢN CÂU HỎI THĂM DÒ
(QUESTIONAIR)
 Tuy nhiên, do các bản câu hỏi thăm dò quá cấu trúc và
không tác động lẫn nhau, chúng ta có ít sự giám sát về
các kết quả thu được.
 Các câu hỏi nên rõ ràng và dễ trả lời vì không có cơ hội
để gạn lọc bất kỳ vấn đề gì hoặc những hiểu nhầm trừ
khi chúng ta tiếp tục hỏi stakeholder sử dụng một số kỹ
thuật khác.
 Lợi ích của bản câu hỏi thăm dò là chúng có thể được
gửi qua email.
HỘI THẢO YÊU CẦU
(WORKSHOP)
 HỘI THẢO YÊU CẦU
(WORKSHOP)
 Trong khi hội thảo các yêu cầu, nhóm stakeholder được
lựa chọn gặp gỡ nhóm dự án.
 Họ thảo luận tập trung trong một khoảng thời gian.
Người phân tích hệ thống tạo điều kiện thuận lợi cho
buổi hội họp.
 Hội thảo yêu cầu cung cấp cơ hội để áp dụng các kỹ
thuật suy luận yêu cầu khác nhau, như làm việc nhóm,
thẻ sự kiện, và phân vai.
 HỘI THẢO YÊU CẦU
(WORKSHOP)
 Mục đích của hội thảo có thể là thu thập các yêu cầu
mới hoặc xét duyệt, phân loại và đánh thứ tự ưu tiên
cho các yêu cầu đang tồn tại.
 Các kết quả của hội thảo các yêu cầu nên được tư liệu
hóa trong các tài liệu yêu cầu stakeholder.
 Trong dự án mẫu, một hội thảo được chỉ đạo bời phân
tích viên nghiệp vụ, người quản lý dự án, người phát
triển, người quản lý nội dung và quản trị hệ thống.
PHÂN VAI (ROLE PLAYING)
 PHÂN VAI (ROLE PLAYING)

 Các thành viên trong nhóm được gán cho các vai
trò liên quan đến hệ thống được xây dựng.
 Thông thường nhất, các vài trò thường là người
dùng hệ thống hoặc các tác nhân khác tương tác
với hệ thống
CÁC PHIÊN LÀM VIỆC TẬP TRUNG
 CÁC PHIÊN LÀM VIỆC TẬP TRUNG

 Trong các phiên làm việc tập trung, những người tham
gia tập hợp lại trong thời gian ngắn.
 Khi bắt đầu, người chỉ đạo thông báo mục đích của
phiên.
 Các yêu cầu mới có thể sinh ra liên quan đến một số
phần của hệ thống hoặc liên quan đến việc giải quyết
vấn đề, ví dụ như giải quyết một tập các yêu cầu mâu
thuẫn.
 CÁC PHIÊN LÀM VIỆC TẬP TRUNG

 Mỗi người tham gia cung cấp một số ý kiến và các ý kiến
không được phép bình phẩm.
 Sau khi mọi ý kiến đã được viết, chọn ngẫu nhiên hoặc
tạo sự kết hợp các ý kiến này.
 Chỉ khi mọi ý kiến đã được tư liệu hóa và nhóm phân
tích phân tích mọi ý tưởng, việc bình phẩm mới được
cho phép.
 CÁC PHIÊN LÀM VIỆC TẬP TRUNG

 Phương pháp này đặc biệt hữu ích khi một vấn đề cần
giải quyết – hoặc là một phần đáng kể của yêu cầu bị bỏ
sót, hoặc các yêu cầu là xung đột.
 Việc các yêu cầu và các thiết kế (giải pháp cho vấn đề)
được thảo luận cùng thời điểm là khá thường xuyên.
 PHÂN TÍCH CÁC TÀI LIỆU HIỆN CÓ
(Document, Email)

 Nhiều yêu cầu có thể được trích rút từ các tài liệu.
 Một kỹ thuật để phân tích tài liệu là đọc tài liệu và sử
dụng bút đánh dấu để đánh dấu các câu mà hình thành
lên môt yêu cầu.
 Với các tài liệu ở dạng điện tử, chúng ta có thể cắt và
dán các phần của văn bản vào tài liệu yêu cầu
Stakeholder, hoặc lưu trữ nó trong CSDL.
 QUAN SÁT VÀ MÔ PHỎNG NHIỆM VỤ
 Người sử dụng không thể phát biểu bằng từ ngữ các chi
tiết về nhiệm vụ của họ
 Quan sát nghiệp vụ: người dùng có thể mô phỏng
nhiệm vụ, trong khi người phân tích ghi chú và tạo các
quan sát về cách mà nhiệm vụ này được thực hiện.
 Mô phỏng nhiệm vụ phân tích viên có thể hỏi người
dùng một nhiệm vụ cụ thể, và người dùng có thể minh
họa để giải thích.
 MỘT SỐ CHÚ Ý

 Xác định đầy đủ và chính xác các

stakeholders
 Lựa chọn phương pháp thu thập các yêu
cầu đối với từng nhóm stakeholder
 Thu thập các yêu cầu và đưa vào báo cáo
 BÀI TẬP NHÓM

Dựa vào các kỹ thuật thu thập, phân

tích yêu cầu, hãy thu thập các yêu
cầu của dự án phần mềm mà nhóm
đăng ký.
KIM TỰ THÁP CÁC YÊU CẦU
CÁC CÁCH XÁC ĐỊNH CÁC FEAT
TỪ CÁC YÊU CẦU HIỆN CÓ
CÁC KỸ THUẬT XÁC ĐỊNH CÁC FEAT TỪ CÁC
YÊU CẦU HIỆN CÓ

Sao chép
Phân tách
Làm cho rõ ràng, dễ hiểu
Định tính chất
Kết hợp
CÁC KỸ THUẬT XÁC ĐỊNH CÁC FEAT TỪ CÁC
YÊU CẦU HIỆN CÓ

 Khái quát hóa

 Loại bỏ
 Làm cho đầy đủ
 Sửa chữa
 Thống nhất
 Thêm các chi tiết:
 XÁC ĐỊNH CÁC FEAT TỪ CÁC YÊU CẦU HIỆN CÓ

 Sao chép: Nếu không có các thay đổi được yêu cầu,
STRQ có thể được copy thành FEAT một các chính xác.
Các kiểu yêu cầu khác nhau áp dụng cho cùng một đoạn
văn bản là được phép. Tuy nhiên, nên tránh các yêu cầu
được phát biểu bởi cùng một đoạn văn bản. Trong
trường hợp này, các yêu cầu là dư thừa.
 Phân tách: Nếu các yêu cầu không nguyên tử, chúng ta
có thể tách nó thành 2 hoặc nhiều yêu cầu hơn.
 VÍ DỤ

STRQ1 Người dùng có thể hủy một yêu cầu đặt trước
khách sạn hoặc đặt trước xe ô tô
Trong trường hợp này, nhà phân tích quyết định không
phân tách nó mà giữ nguyên.
 FEAT1 Người dùng sẽ có thể hủy một yêu cầu đặt trước
khách sạn hoặc đặt trước xe ô tô
(Sao chép)
 VÍ DỤ

STRQ2 Hệ thống sẽ có điều hướng rõ ràng.

Yêu cầu này là mơ hồ và nó không đủ chính xác để có thể được kiểm
thử. Hai đặc trưng cụ thể hơn có thể được sinh ra từ nó:
FEAT21 Các tab riêng cần được xây dựng cho chức năng chính.
FEAT22 Trên mỗi trang có một nút gợi ý cho luồng mặc định.

(Phân tách)
 XÁC ĐỊNH CÁC FEAT TỪ CÁC YÊU CẦU HIỆN CÓ

 Làm cho rõ ràng, dễ hiểu: thanh lọc, hoặc giải thích có

thể áp dụng khi yêu cầu gốc không rõ ràng và mập mờ.
 Định tính chất: Chúng ta có thể đạt được chất lượng
bằng cách thêm các giới hạn hoặc các điều kiện cho yêu
cầu. Nó có thể giúp giải quyết các yêu cầu xung đột.
 VÍ DỤ
STRQ3 Đôi khi người dùng sẽ nhập mã sân bay, mà hệ thống sẽ
hiểu, nhưng đôi khi thành phố gần nhất có thể được chấp nhận, do
đó người dùng không cần biết mã sân bay, và nó sẽ vẫn được hiểu
bởi hệ thống.
Câu này là phức tạp và không rõ ràng. Chúng ta có thể thay thế nó
bởi một câu đơn giản hơn.
FEAT3 Hệ thống sẽ xác định sân bay dựa vào mã sân bay hoặc tên
thành phố.
 XÁC ĐỊNH CÁC FEAT TỪ CÁC YÊU CẦU HIỆN CÓ

 Kết hợp: Các yêu cầu dư thừa và chống chéo có thể

được kết hợp thành 1 yêu cầu.
 Khái quát hóa: Nếu yêu cầu không trừu tượng, nó chứa
một số chi tiết không cần thiết, chúng ta có thể áp dụng
phép khái quát hóa.
 Loại bỏ: Đôi khi một yêu cầu cần được xóa. Điều này có
thể xảy ra khi yêu cầu là không khả thi, không cần thiết,
không khớp với các yêu cầu khác.
 XÁC ĐỊNH CÁC FEAT TỪ CÁC YÊU CẦU HIỆN CÓ

 Làm cho đầy đủ: Nếu một tập các yêu cầu là không đầy
đủ, chúng ta cần thêm các yêu cầu ở giai đoạn này.
 Sửa chữa: sử dụng lại các từ ngữ để sửa các lỗi chính
tả, lỗi ngữ pháp, các dấu chấm câu, hoặc thay đổi một
phần của yêu cầu là không đúng.
 Thống nhất: Các yêu cầu mà sử dụng từ vựng không
khớp có thể được thống nhất.
 XÁC ĐỊNH CÁC FEAT TỪ CÁC YÊU CẦU HIỆN CÓ
 Thêm các chi tiết: Nếu yêu cầu không đủ chính xác, chúng ta có thể thêm các
chi tiết. Kỹ thuật này thường sử dụng để tạo các yêu cầu có khả năng kiểm
thử từ các yêu cầu không có thể kiểm thử
Ví dụ:
 STQR 4 Nếu người dùng đã mua vé một lần, sẽ không cần lặp lại thông
tin tương tự, như địa chỉ hoặc số thẻ tín dụng.
Trong yêu cầu này, chúng ta làm rõ bằng cách thêm „các giao dịch tương lai”.
FEAT 4 Nếu người dùng đã mua vé một lần, sẽ không cần lặp lại thông tin tương
tự (như địa chỉ hoặc số thẻ tín dụng) trong các giao dịch tương lai.
 BÀI TẬP

Dựa trên các yêu cầu thu thập được từ

các stakeholders, hãy xác định các đặc
trưng (FEAT).
MÔ HÌNH HÓA YÊU CẦU

1
 NỘI DUNG CHÍNH
 Các khái niệm cơ bản
 Các ngôn ngữ mô hình hóa
 Nguyên tắc mô hình hóa
 Mô hình quan hệ thực thể và UML
 Mô hình hoá tương tác
CÁC KHÁI NIỆM CƠ BẢN
 CÁC KHÁI NIỆM CƠ BẢN

 D – Đặc tính lĩnh vực: những thứ có thật trong

lĩnh vực ứng dụng dù chúng ta có thiết kế chúng
trong hệ thống hay không.

 R – Các yêu cầu: những thứ trong lĩnh vực ứng

dụng mà chúng ta mong muốn trở thành hiện
thực bằng cách đưa vào hệ thống.
 CÁC KHÁI NIỆM CƠ BẢN

S – Đặc tả: mô tả các hành vi chương trình cần

thực hiện để đáp ứng với các yêu cầu
C- Máy tính: Môi trường để hệ thống được vận
hành.
P – Chương trình: sản phẩm (hệ thống) mà dự án
phải đáp ứng
 VAI TRÒ CỦA MÔ HÌNH HÓA
TRONG PTYCPM

Hướng dẫn suy luận yêu cầu

Cung cấp sự đo lường cho quy trình
Giúp làm rõ các vấn đề
Kiểm tra sự thấu hiểu của nhà phân tích
yêu cầu về hệ thống
 Yêu cầu đối với các thành phần

Đặc tả (S) được cho trong thuộc tính của lĩnh vực

(D) thỏa mãn các yêu cầu (R)

Chương trình (P) thực hiện trên một máy tính (C)

cụ thể đáp ứng với đặc tả (S)

Yêu cầu đối với các thành phần

Chúng ta đã xem xét (và hiểu) tất cả các yêu

cầu (Requirements) quan trọng?

Chúng ta đã xem xét (và hiểu) tất cả các thuộc

tính lĩnh vực (Domain properties) liên quan?

HẠN CHẾ CỦA MÔ HÌNH HÓA

Hiện tượng trong mô hình lại không có trong

lĩnh vực ứng dụng.

Hiện tượng trong lĩnh vực ứng dụng lại không

được mô tả trong mô hình.

Ví dụ: Ngăn chặn truy cập trái phép
từ các máy tính
VÍ DỤ: BIỂU DIỄN THÔNG TIN
TÁC GIẢ
NGUYÊN TẮC MÔ HÌNH HÓA

 Trừu tượng hóa (Abstraction)

 Phân tách (Decomposition)
 Quy chiếu (Projection)
 Mô-đun hóa (Modularity)
 Mẫu (Patterns)
NGUYÊN TẮC MÔ HÌNH HÓA

 Trừu tượng hóa: Không đi vào chi tiết, chỉ tập

trung vào các nội dung chính (quan trọng)
 Phân tách: Phân chia vấn đề thành các phần
độc lập để khảo sát riêng biệt
 Quy chiếu: Phân chia các khía cạnh khác nhau
và mô tả chúng một cách riêng biệt
NGUYÊN TẮC MÔ HÌNH HÓA

 Mô-đun hóa: Lựa chọn các cấu trúc ổn định

theo thời gian để dễ định vị khi thay đổi

 Mẫu: Cấu trúc của một mô hình đã có và được

sử dụng (xuất hiện) trong nhiều ứng dụng khác

nhau
NGÔN NGỮ (KÝ PHÁP) MÔ HÌNH
HÓA

 Ngôn ngữ tự nhiên

 Ngôn ngữ (Ký pháp) bán hình thức

 Ngôn ngữ (Ký pháp) hình thức

 K Ý PHÁP MÔ HÌNH HÓA

 Ngôn ngữ tự nhiên:

- Diễn cảm và linh hoạt: hữu ích cho suy diễn và
lập các mô hình ký hiệu dễ đọc
- Khó để nắm bắt được các quan hệ mấu chốt
 KÝ PHÁPMÔ HÌNH HÓA

 Ký pháp bán hình thức (UML)

- Nắm được cấu trúc và một số ngữ nghĩa
- Có thể thực hiện (một số) hoạt động, kiểm tra tính

nhất quán, ảnh động,

- Gần như là trực quan – cho phép chuyển thông
tin một cách nhanh chóng đến các dạng đối tác
khác nhau
 CHỌN KÝ PHÁP CHO VIỆC
MÔ HÌNH HÓA
 Ký pháp hình thức
- Ngữ nghĩa chính xác, có thể suy luận
rộng: các mô hình dựa trên cơ sở toán
- Các mô hình rất chi tiết
 MÔ HÌNH THỰC THỂ QUAN HỆ
(ENTITY RELATIONSHIP MODELLING)
Các thành phần: Thực thể (Entities), Quan
hệ (Relationships), Thuộc tính (Attributes)
 THỰC THỂ
Thực thể (Entity): Là khái niệm mô tả một lớp
các đối tượng có đặc trưng chung mà chúng ta
cần quan tâm.
˜ Các thực thể là đối tượng cụ thể hoặc trừu
tượng: như Sinh viên, Khách hàng, …
˜ Trong sơ đồ thì thực thể thường được ký hiệu
là hình chữ nhật

Sinhvien khachhang
 THỰC THỂ YẾU

Thực thể yếu: X là thực thể yếu nếu sự tồn tại

của X phụ thuộc vào sự tồn tại của thực thể Y.

Được ký hiệu bằng hình chữ nhật kép

Ví dụ: Người nhà (người phụ thuộc) của nhân

viên trong công ty

 BẢN GHI

Bản ghi: là một đối tượng cụ thể của lớp các

˜

đối tượng đó.

Ví dụ: Sinh viên Nguyễn Văn Anh là đối tượng
cụ thể của thực thể Sinh viên

1
5
3
 THUỘC TÍNH (ATTRIBUTE)

- Là các tính chất, đặc điểm chung của lớp

đối tượng. Nó là một giá trị dùng để mô tả
một đặc trưng nào đó của một thực thể.
- Thuộc tính có thể là: đơn (singled, đa
trị/lặp (multiple-valued), suy diễn (derived
attribute), thuộc tính hợp thành…
KÝ HIỆU TRONG MÔ HÌNH ER
 CÁC QUAN HỆ
(RELATIONSHIPS)
- Các kết nối logic giữa hai hoặc nhiều thực thể:
Cư trú là một quan hệ có thể tồn tại giữa Thành
phố và Nhân viên
- Một thể hiện của một quan hệ là một thể hiện
n-tuple của thực thể: bộ 2 thành phần (Nam,
Cần Thơ), là một thể hiện trong quan hệ Cư trú
 XÂY DỰNG MÔ HÌNH ER
˜ Bước 1: Liệt kê, chính xác hóa và lựa chọn
thông tin cơ sở
˜ Xác định một từ điển bao gồm tất cả các thuộc tính (không
bỏ sót bất cứ thông tin nào).
˜ Chính xác hóa các thuộc tính đó. Thêm các từ cần thiết để
thuộc tính đó mang đầy đủ ý nghĩa, không gây lầm lẫn, hiểu
nhầm.
˜ Chú ý: Để lựa chọn các đặc trưng cần thiết, duyệt từ trên
xuống và chỉ giữ lại những thuộc tính đảm bảo yêu cầu sau:
¿ Thuộc tính cần phải đặc trưng cho một lớp các đối tượng được xét.
¿ Chọn một thuộc tính một lần, nếu lặp lại thì bỏ qua.
¿ Một thuộc tính phải là sơ cấp (Nếu giá trị của nó có thể suy ra từ các
thuộc tính khác thì bỏ qua).
 XÂY DỰNG MÔ HÌNH ER…

˜ Bước 2: Xác định các thực thể, thuộc tính.

- Duyệt danh sách các thuộc tính từ trên xuống để
tìm ra thuộc tính tên gọi. Mỗi thuộc tính tên gọi
sẽ tương ứng với một thực thể.
- Gán các thuộc tính cho từng thực thể.
- Xác định thuộc tính định danh cho từng thực thể.
 XÂY DỰNG MÔ HÌNH ER…
˜ Bước 3: Xác định các mối quan hệ và các thuộc
tính riêng
- Xét các thuộc tính còn lại, tìm tất cả các động từ (ứng với thuộc
tính đó).
- Với mỗi động từ, trả lời các câu hỏi: Ai? Cái gì? Ở đâu? Khi
nào? Bằng cách nào?
 XÂY DỰNG MÔ HÌNH ER…
˜ Bước 4: Vẽ sơ đồ mô hình thực thể- liên kết, xác định lực
lượng tham gia liên kết cho các thực thể.

˜ Bước 5: Chuẩn hóa sơ đồ và thu gọn sơ đồ

- Chuẩn hóa: Loại bỏ các thuộc tính lặp, nhóm lặp và các thuộc tính phụ
thuộc thời gian -> sơ đồ chỉ còn các thực thể đơn, thuộc tính đơn.
- Thu gọn sơ đồ: Nếu một thực thể có tất cả các đặc trưng:
¿ Là thực thể treo: chỉ tham gia vào một mối quan hệ và chứa 1 TT duy
nhất (có thể có thuộc tính thứ 2 thêm vào làm định danh).
¿ Mối quan hệ là bậc hai và không có thuộc tính riêng.
¿ Mối quan hệ là 1: N hay 1:1
 VÍ DỤ
Quy tắc nghiệp vụ của hệ thống CSDL COMPANY như sau:

1. Công ty có nhiều phòng/ban (DEPARTMENTs). Mỗi phòng/ban

có tên (name), mã số (number) duy nhất và có một nhân viên
(employee) làm quản lý (manages) phòng/ban. Chúng ta lưu lại
ngày bắt đầu (start date) làm quản lý phòng/ban của nhân viên đó.

2. Mỗi phòng/ban có thể có nhiều địa điểm khác nhau (locations).

3. Mỗi phòng/ban điều hành một số dự án (PROJECTs). Mỗi dự

án có tên (name), mã số (number) duy nhất và chỉ có một địa
điểm (location).
 VÍ DỤ…
4. Với mỗi nhân viên (EMPLOYEE), chúng ta lưu lại những thông tin
sau: tên (name), số bảo hiểm xã hội (social security number), địa chỉ
(address), lương (salary), giới tính (sex), ngày sinh (birth date).
5. Mỗi nhân viên làm việc ở một phòng/ban, nhưng có thể làm việc cho
nhiều dự án. Chúng ta lưu lại số giờ làm việc (the number of hours per
week) của từng nhân viên trong từng dự án.
6. Chúng ta lưu lại thông tin về người quản lý trực tiếp (direct
supervisor), của mỗi nhân viên. Người quản lý trực tiếp cũng là một
nhân viên.
7. Mỗi nhân viên có những người phụ thuộc vào họ (DEPENDENTs).
Mỗi người phụ thuộc ta lưu lại thông tin về tên (name), giới tính (sex),
ngày sinh (birth date) và quan hệ (relationship)
 YÊU CẦU

Xác định các thực thể và các mối quan

hệ giữa các thực thể, xây dựng mô
hình thực thể liên kết
MÔ HÌNH HOÁ YÊU CẦU
BẰNG UML
(Unified Modeling Language)
 UML (UNIFIED MODELING
LANGUAGE)
- Là một công nghệ chuẩn cho việc mô hình hóa
phần mềm hướng đối tượng,
- Là kết quả của sự thống nhất hệ thống ký hiệu của
3 phương pháp hướng đối tượng tiêu biểu,
- Được hỗ trợ bởi một số CASE tools,
- Bạn có thể mô hình 80% của hầu hết vấn đề bằng
cách dùng chỉ khoảng 20% UML,
VAI TRÒ CỦA UML TRONG DỰ ÁN PM
 LỚP (CLASS) LÀ GÌ ?
Một lớp mô tả một nhóm các đối tượng (objects)
với:
- Các đặc tính tương tự (thuộc tính - attributes),
- Cùng hành vi ứng xử (phương thức - operations),
- Quan hệ như nhau đối với các objects khác.
- Và có chung ngữ nghĩa (“semantics”).
 VÍ DỤ VỀ LỚP
Nhân viên (employee): có 1 tên (name), mã số nhân viên
(employee#) và bộ phận trực thuộc (department); một nhân
viên thì có thể được thuê (hired), bị sa thải (fired); mỗi nhân
viên làm việc trong một hay nhiều dự án (assignproject)
TÌM LỚP TỪ CÁC YÊU CẦU
ĐỐI TƯỢNG VÀ LỚP
CÁC KIỂU QUAN HỆ GIỮA CÁC LỚP
 QUAN HỆ KẾT HỢP

Đối tượng có mối quan hệ kết hợp

(associations) với đối tượng khác
Ví dụ: Nam:employee có quan hệ kết
hợp với Mekong1: project
BẢN SỐ (MULTIPLICITY) CỦA QUAN
HỆ KẾT HỢP
VÍ DỤ VỀ BẢN SỐ CỦA QUAN HỆ KẾT HỢP
CHÚ Ý
 CHÚ Ý
 Hướng đối tượng (Object Oriented –
OO) là một cách tốt để khảo sát các
chi tiết của vấn đề
+ Tránh những chắp vá tự nhiên của cấu
trúc
+ Cung cấp một phương thức chặt chẽ
để hiểu rõ thực tế
 CHÚ Ý
 Tuy nhiên:
- OO thiên về thiết kế hơn là phân tích:
Trong RE, sơ đồ quan hệ không phản ánh
các lớp chương trình
- Đối với bước phân tích, lược đồ UML
được dùng để phác họa chứ không phải
bản thiết kế.
- Nhưng cũng có thể trở thành bản thiết kế
khi dùng trong đặc tả
CHÚ Ý
 BÀI TẬP

Xác định các Lớp (các thuộc tính,

phương thức) của hệ thống phần
mềm mà các nhóm đăng ký
MÔ HÌNH HÓA TƯƠNG TÁC
HỆ THỐNG
 MÔ HÌNH HÓA TƯƠNG TÁC HỆ THỐNG
 Tương tác với hệ thống mới
- Con người sẽ tương tác với hệ thống thế nào?
- Khi nào/Tại sao họ tương tác với hệ thống?
 Use case (UC)
- Giới thiệu mô hình UC
- Định nghĩa các tác nhân
- Định nghĩa các tình huống (cases)
- Các đặc tính mở rộng
 Biểu đồ tuần tự: Trình tự thời gian của
các sự kiện bao gồm trong UC
 Use cases
 Chúng được khởi tạo bởi một tác nhân.
 Chúng mô hình hóa một tương tác giữa tác nhân
và hệ thống.
 Chúng mô tả một chuỗi các hành động.
 Chúng nắm bắt các yêu cầu chức năng.
 Chúng nên cung cấp một số giá trị cho tác nhân.
 Chúng biểu biểu một luồng sự kiện hoàn thiện và
đầy đủ ý nghĩa.
 Tác nhân (Actor)
 Ai là người sử dụng hệ thống?
 Ai sẽ là người Admin của hệ thống (tức
người cài đặt, quản lý, bảo trì… hệ thống)?
 Hệ thống này có được sử dụng bởi bất kỳ
một hệ thống nào khác không? (*)
 Ai là người input dữ liệu vào hệ thống?
 Ai là người cần những dữ liệu output?
 Tác nhân (Actor)
 Một tác nhân là một người hoặc một
đối tượng khác có tương tác với hệ
thống.
 Tác nhân có thể là một người, nhưng
nó cũng có thể là một hệ thống khác.
 Mọi stakeholder của hệ thống là các
ứng cử cho các tác nhân
 Stakeholders
• Người chủ công ty du lịch (Travel Agency Owner)
• Người dùng 1 – Người từ U.S. (User 1)
• Người dùng 2 – Người từ Pháp (User 2)
• Người phát triển (Developer)
• Người quản lý nội dung (content Manager)
• Bộ phận phục vụ khách hàng (Customer Service
Representative)
• Người cung cấp khách sạn (Hotel Provider), Công ty
cho thuê xe ô tô (Car Rental Agent) và đại diện hãng
hàng không (Airline Representative)
 SƠ ĐỒ USE CASE (UC diagram)
Nắm bắt mối quan hệ giữa các nhân tố và Use Cases
CÁC KÝ HIỆU TRONG SƠ ĐỒ UC
VÍ DỤ VỀ SƠ ĐỒ UC
QUAN HỆ KẾ THỪA
VÍ DỤ VỀ QUAN HỆ KẾ THỪA
NHẬN BIẾT CÁC TÁC NHÂN
 VÍ DỤ
Xác định các tác nhân trong sơ đồ use case sử dụng
một chiếc xe
NHẬN BIẾT CÁC TÁC NHÂN
 VÍ DỤ

Xác định các tác nhân trong sơ đồ

use case sắp xếp lịch họp
TÌM KIẾM USE CASE
LẬP TÀI LIỆU USE CASE
LUỒNG SỰ KIỆN CHO USE CASE
Luồng sự kiện mô tả Use case cho
hệ thống rút tiền tự động
 VÍ DỤ

Xác định luồng sự kiện mô

tả Use case sắp xếp lịch
họp
MÔ HÌNH HÓA TRÌNH TỰ CỦA CÁC SỰ
KIỆN
MÔ HÌNH HÓA TRÌNH TỰ CỦA CÁC SỰ
KIỆN
 BÀI TẬP THỰC HÀNH
- Xác định các Tác nhân (Actors), các
Use cases (UCs) và xây dựng biểu đồ
UC.
- Mô tả các UC chính bằng luồng sự
kiện.
- Xác định các lớp (Class) và vẽ
biểu đồ lớp.
CÁC ĐẶC TẢ BỔ SUNG
 NỘI DUNG

 Các khái niệm cơ bản

 Thiết lập độ đo các yêu cầu.

 Các yếu tố vs tiêu chuẩn

 YÊU CẦU PHI CHỨC NĂNG
(NON-FUNCTIONAL REQUIREMENTS - NFR)
 NFRs là gì ? Các hệ số chất lượng, tiêu
chuẩn thiết kế; các độ đo
 Tiếp cận hướng sản phẩm với NFRs: Tạo
ra sự đặc tả các hệ số chất lượng
 Tiếp cận hướng tiến trình với NFRs:
Phân tích mục tiêu linh động (softgoal) cho
các thỏa hiệp trong thiết kế
KIM TỰ THÁP YÊU CẦU
 CHỨC NĂNG VS. PHI CHỨC NĂNG

 Các yêu cầu chức năng mô tả cái hệ

thống sẽ làm
 Các yêu cầu phi chức năng là những
ràng buộc toàn thể trên hệ thống phần
mềm
 CÁC YÊU CẦU CHỨC NĂNG

 Các chức năng có thể nắm bắt trong use

cases.
 Các hành vi có thể được phân tích bằng
việc vẽ biểu đồ trình tự, biểu đồ trạng
thái,…
 Khả năng lần vết để giải quyết những vấn
đề rắc rối của một chương trình
 CÁC YÊU CẦU PHI CHỨC NĂNG

 Chi phí phát triển, chi phí vận hành, khả

năng thực thi, độ tin cậy, khả năng bảo trì,
tính khả chuyển, tính thiết thực,…
 Thường được biết như chất lượng phần
mềm, hoặc chỉ là ” các khả năng ” (” - ilities”)
 Thường không được cài đặt trong một mô-
đun duy nhất của chương trình.
 SUY LUẬN CÁC YÊU CẦU PHI CHỨC NĂNG

 Khách hàng thường quên các yêu cầu này và

không cung cấp chúng trừ khi họ được hỏi.
 Khách hàng thường không nhận thức được chi phí
cải thiện các tham số cụ thể.
 Người dùng thường không biết kỹ thuật dể hiểu
một số yêu cầu kỹ thuật.
 Một số yêu cầu là khó đo lường,
 SUY LUẬN CÁC YÊU CẦU PHI CHỨC NĂNG

 Tạo một danh sách tất cả các loại yêu cầu bổ sung.
 Với mỗi loại, tạo một hoặc nhiều câu hỏi.
 Giải thích với khách hàng sự ảnh hưởng và chi phí
của mỗi quyết định.
 Nắm bắt các phản hồi của khách hàng cho mỗi câu
hỏi.
 Gán độ ưu tiên hoặc trọng số cho mỗi yêu cầu.
CÁC LOẠI YÊU CẦU BỔ SUNG
CÁC LOẠI YÊU CẦU BỔ SUNG
 CÁC LOẠI YÊU CẦU BỔ SUNG
 Chức năng (Functional): non – use case
 Khả năng sử dụng (Usability)
 Độ tin cậy (Reliability)
 Hiệu năng (Performance)
 Khả năng hỗ trợ (Supportability)
 Ràng buộc thiết kế (Design Constraints)
 Yêu cầu triển khai (Implementation Requirements)
 Yêu cầu vật lý (Physical Requirements)
 Các yêu cầu về giấy phép và luật pháp (Licensing and
legal requirements)
NHỮNG TRỞ NGẠI CỦA NFRS
 Khó để mô hình hóa
 Thường ở trạng thái không hình thức nên:
Thường mâu thuẫn, khó thực hiện trong suốt
quá trình phát triển và khó đánh giá khách
hàng nào ưu tiên để phân phối
 Khó tạo ra các tiêu chuẩn để có thể đo
lường
 SUY LUẬN CÁC YÊU CẦU BỔ SUNG
TỪ CÁC ĐẶC TRƯNG
 Duyệt qua mọi đặc trưng,
 Xác định những đặc trưng nào không
đươc ánh xạ vào trong các UC và chuyển
chúng thành các yêu cầu bổ sung
 Thông thường không có sự thay đổi cần
thiết nào
 SUY LUẬN CÁC YÊU CẦU BỔ SUNG
TỪ CÁC ĐẶC TRƯNG
Ví dụ:
- Các tab riêng biệt được xây dựng cho các
chức năng chính
- Chức năng đặt trước vé máy bay sẽ sẵn
dùng từ trang chủ
- Mật khẩu sẽ được yêu cầu để truy cập đến
các màn hình quản trị viên.
 BÀI TẬP THỰC HÀNH

Rà soát, bổ sung các yêu cầu

phi chức năng trong hệ thống
phần mềm mà nhóm đã đăng ký
CÁC YÊU CẦU PHI CHỨC NĂNG
CÁC THUỘC TÍNH CỦA YÊU CẦU BỔ SUNG
CÁC THUỘC TÍNH CỦA YÊU CẦU BỔ SUNG
 CÁC THUỘC TÍNH CỦA YÊU CẦU BỔ SUNG

- Tính ưu tiên
- Kiểu
- Trạng thái
- Độ khó
- Độ ổn định
- Rủi ro
- ...
 MỘT VÀI CHÚ Ý
- Các yêu cầu phi chức năng là không bắt
buộc
- Nhiều yêu cầu phi chức năng có thể bị lờ
đi nếu chúng không thể áp dụng
- Nhiều yêu cầu phi chức năng có thể bị
loại bỏ bởi khách hàng và nhà phân tích
YC
 MỘT VÀI CHÚ Ý

- Một số yêu cầu (đặc biệt là liên quan

đến tính hiệu năng/thực thi) có thể biến
đổi, phụ thuộc vào số người dùng. Khi
đó, một bảng với các yêu cầu thực thi
bởi số người dùng mô phỏng được tạo.
VÍ DỤ
TẦM QUAN TRỌNG CỦA CÁC NFRS

- Bắt buộc
- Mong đợi
- Tốt khi có
 SỰ THỎA MÃN CỦA KHÁCH HÀNG

- Các tham số được sử dụng trong các yêu cầu

sẽ được đáp ứng chính xác như đã mô tả
- Giá trị phép đo sẽ khá gần với các giá trị mong
đợi
- Kết quả càng tốt, sự thỏa mãn càng tốt
 SỰ THỎA MÃN CỦA KHÁCH HÀNG

Ví dụ
- Hệ thống thời gian thực: hệ thống tự động
phân loại hàng
- Hệ thống mà xử lý giao dịch và các file theo
loạt đang chạy
- Hệ thống các báo cáo sẽ được hiển thị trong
20 giây hoặc ít hơn
 TIẾP CẬN NFRS

 Sản phẩm vs. Tiến trình

 Định lượng (Quantitative) vs. Định

tính (Qualitative)
 TIẾP CẬN HƯỚNG SẢN PHẨM
(PRODUCT-ORIENTED APPROACHES)
 Tập trung vào chất lượng của hệ thống (hoặc
phần mềm)
 Nắm bắt các tiểu chuẩn thiết lập của mỗi yêu
cầu
 Có thể đo lường chúng khi sản phẩm được
thiết kế
 TIẾP CẬN HƯỚNG TIẾN TRÌNH
(PROCESS-ORIENTED APPROACHES)
 Tập trung vào các yêu cầu phi chức năng
(NFRs) nào có thể dùng trong tiến trình thiết
kế
 Phân tích tương tác giữa NFRs và các chọn
lựa thiết kế
 Có thể đưa ra các quyết định thiết kế phù
hợp
 ĐỊNH LƯỢNG VS. ĐỊNH TÍNH
 Định lượng:
• Tìm thang đo các thuộc tính về chất lượng
• Tính toán mức độ cho một thiết kế đáp ứng
với các mục tiêu chất lượng nào
 Định tính:
• Nghiên cứu các dạng quan hệ giữa các mục
tiêu chất lượng
 CÁC YÊU TỐ VS. TIÊU CHUẨN
 Các yếu tố chất lượng: Liên quan đến
quan hệ khách hàng (customer-related) bao
gồm hiệu năng, tính toàn vẹn, độ tin cậy, tính
chính xác,
 Tiêu chuẩn thiết kế: Liên quan tới kỹ
thuật (hướng phát triển) chẳng hạn như quản
lý các bất thường, tính hoàn thiện, tính ổn
định, khả năng lưu vết, tính trực quan.
 CÁC YÊU TỐ VS. TIÊU CHUẨN

 Trong quá trình phân tích yêu cầu:

- Xác định quan hệ quan trọng của mỗi yếu tố
chất lượng từ quan điểm của khách hàng!
- Xác định tiêu chuẩn thiết kế mà mỗi yếu tố
này phụ thuộc
- Thiết lập độ đo lường các yêu cầu
CÁC YÊU CẦU PHI CHỨC NĂNG THEO BOEHM
CÁC YÊU CẦU PHI CHỨC NĂNG THEO MCCALL
THIẾT LẬP ĐỘ ĐO CÁC YÊU CẦU
 THIẾT LẬP ĐỘ ĐO YÊU CẦU

 Xác định ‘tiêu chuẩn đáp ứng’ cho mỗi yêu

cầu: Đặt ‘tiêu chuẩn đáp ứng’ bên cạnh yêu cầu:
Ví dụ: Đối với phần mềm ATM mới
- Yêu cầu: “Phần mềm phải trực quan và rõ ràng”
- Tiêu chuẩn đáp ứng: “95% khách hàng hiện có của
ngân hàng sẽ có thể rút tiền và chuyển tiền trong
vòng 2 phút khi sử dụng sản phẩm lần đầu tiên”
 THIẾT LẬP ĐỘ ĐO YÊU CẦU

 Chọn tiêu chuẩn đáp ứng tốt

- Các đối tác thường hiếm khi mô tả điều này
- Các tiêu chuẩn đúng không luôn rõ ràng
- Làm việc với các đối tác để tìm ra các tiêu
chuẩn đáp ứng tốt
 THIẾT LẬP CÁC THAY THẾ
- Đôi khi, chất lượng không thể đo lường trực
tiếpTìm các định danh thay thế
- Tính dễ sử dụng: Được thay thế bởi “Một vài
dữ liệu nhập bị lỗi”
- Tính dễ bảo trì: Được thay thế bởi “Liên kết
không chặt chẽ”.
 MỤC TIÊU LINH HOẠT (SOFTGOALS)

Một số mục tiêu có thể không bao giờ được đáp ứng
một cách đầy đủ
SOFTGOALS NHƯ CÁC TIÊU CHUẨN LỰA CHỌN
 BÀI TẬP NHÓM

- Hoàn thiện nội dung về UC

- Xác định các yêu cầu phi chức năng, thiết lập
các độ đo yêu cầu (hoặc các tiêu chuẩn đo
lường) và xây dựng các thay thế tương ứng
cho đề tài của nhóm
 ĐẶC TẢ YÊU CẦU
(Requirement Specifications)
 Tại sao cần đặc tả
 Yêu cầu của đặc tả
 Cấu trúc tài liệu đặc tả
 Đặc tả thực hiện kết nối yêu cầu với những
thành phần khác bằng cách mô tả chúng trong
một tài liệu đặc tả yêu cầu phần mềm (SRS -
Software Requirement Specification document).

 Nhưng một SRS không phải nhất thiết là một

tài liệu chỉ trên giấy tờ.
 Chuyển tải thông tin: Giải thích lĩnh vực ứng dụng và hệ
thống cần phát triển
 Lập hợp đồng:
- Được xem như một ràng buộc hợp lệ;
- Biểu diễn sự thỏa thuận và như một lời cam kết.
 Làm cơ sở cho việc đánh giá phần mềm:
- Hỗ trợ việc kiểm tra và kiểm chứng (Verification and
Validation - V&V)
- Cung cấp thông tin để kiểm tra liệu hệ thống được phân phối
có đáp ứng được các yêu cầu
 Làm cơ sở cho việc quản lý thay đổi
 Khách hàng & Người dùng: Quan tâm đến các yêu cầu hệ
thống…nhưng không biết các chi tiết về yêu cầu phần mềm;
 Nhà phân tích (yêu cầu) hệ thống: Viết những đặc tả liên quan.
 Người phát triển, Lập trình viên: Phải cài đặt, sử dụng các yêu
cầu để hiểu hệ thống cần được phát triển như thế nào
 Kiểm thử viên: Phải kiểm tra rằng các yêu cầu được
đáp ứng
 Quản lý dự án: Phải đo lường và kiểm soát dự án
…
 Xét 2 dự án khác nhau:
A: Dự án nhỏ, 1 người lập trình, 2 tháng làm việc: Người
lập trình thảo luận với khách hàng, sau đó viết khoảng 2-
trang ghi chú
B: Dự án lớn, 50 người lập trình, 2 năm làm việc: Đội
phân tích lập mô hình các yêu cầu, sau đó viết khoảng
500-trang tài liệu đặc tả yêu cầu phần mềm
 Một ‘SRS’ có thể được viết bởi
Nhà thầu:
- SRS thì thực sự là một lời mời cho những đề xuất
- Phải đủ tổng quát để có thể chọn lựa được một người đấu thầu tốt…
- Đủ chi tiết để loại bỏ những người đấu thầu không hợp lý
 Một ‘SRS’ có thể được viết bởi
Người đấu thầu:
- SRS là một đề xuất để cài đặt một hệ thống đáp ứng khách hàng
- Phải đủ chi tiết để chứng tỏ tính khả thi và khả năng vể kỹ thuật
- Đủ tổng quát để tránh vượt quá cam kết
 Một ‘SRS’ có thể được viết bởi…
Nhà phát triển được tuyển chọn:
- Phản ánh sự thấu hiểu về các yêu cầu khách hàng của nhà
phát triển
- Một hình thức cơ sở cho sự đánh giá việc thực thi trên hợp
đồng
Hoặc bởi một người thầu RE độc lập!
 Hợp lệ (hoặc “đúng”)  Nhất quán
 Không mơ hồ  Dễ kiểm tra
 Hoàn chỉnh  Dễ sửa đổi
 Dễ hiểu (Rõ ràng)  Dễ lần vết
Đặc tả yêu cầu phần mềm cần chú trọng:
 Chức năng hóa: Nhiệm vụ phần mềm là làm gì?
 Giao diện bên ngoài
 Yêu cầu thực thi: Tốc độ, sự sẵn dùng, thời gian đáp
ứng, thời gian phục hồi của những chức năng phần
mềm khác nhau và những thứ khác
Đặc tả yêu cầu phần mềm cần chú trọng:
 Các thuộc tính chất lượng: tính khả chuyển, tính chính xác,
khả năng bảo trì, tính bảo mật và những xem xét khác?
 Các ràng buộc thiết kế phải tuân theo trong quá trình cài đặt:
Có bất kỳ tác động nào của các chuẩn được yêu cầu, ngôn
ngữ cài đặt, các chính sách toàn vẹn CSDL, giới hạn nguồn
tài nguyên, môi trường vận hành và những thứ khác?
 Những kế hoạch phát triển dự án: chi phí, đội ngũ nhân
viên, lịch biểu, các phương pháp, công cụ, …
 Những kế hoạch đảm bảo dự án: Quản lý cấu hình, kiểm
tra & kiểm chứng, kế hoạch kiểm thử, đảm bảo chất lượng,
…
 Các thiết kế: Ngoại trừ những ràng buộc trong phạm vi ứng
dụng của thiết kế
 Mô tả: Mô tả về menu (chức năng) được xây dựng
 Thông tin: Cung cấp các thông tin cần thiết để hệ
thống hoạt động.
 Hoạt động của hệ thống và yêu cầu cụ thể đối với
hệ thống.
Một công ty quản lý vận tải cần xây dựng “Sổ kỹ thuật xe”
 Mô tả: Menu này cung cấp thông tin cá biệt các xe nằm trong
danh sách phương tiện mà công ty đang khai thác. Những thông
tin đó bao gồm :
• Theo dõi thay dầu nhớt:
• Theo dõi lọc nhớt:
• Theo dõi lọc dầu:
• Quản lý hồ sơ tai nạn:
THEO DÕI THAY DẦU NHỚT:
Mô tả: Menu này theo dõi việc thay dầu nhớt định kỳ theo số kms thực tế vận
hành của từng xe. Công ty sẽ ban hành quy trình bảo dưỡng xe định kỳ làm căn
cứ để xây dựng menu này.
 Qui tắc thay dầu máy cho xe: Bộ phận kỹ thuật có trách nhiệm tham mưu
với Ban Giám đốc ấn định số kms vận hành với từng chiếc xe để làm mốc
thay dầu máy.
 Cách tính số kms: Số kms được dùng để theo dõi việc thay dầu máy được
tính bằng tổng số kms theo lệnh điều xe đã thực hiện của mỗi xe tương
ứng.
 Phương thức theo dõi: Trước hạn thay dầu máy 1,000 kms và 500 kms,
phần mềm cảnh báo cho người lập lệnh điều xe về việc thay dầu máy cho
xe. Người làm lệnh điều xe phải thông báo cho cán bộ kỹ thuật yêu cầu lên
lịch thay dầu máy và cập nhật tình trạng cho xe trên phần mềm.
 Trước hạn thay dầu máy 50 kms (chỉ bao gồm quãng đường xe đã vận
hành theo lệnh điều xe đã thực hiện) thì phần mềm không cho phép lập
Lệnh điều xe cho xe đó
QUẢN LÝ HỒ SƠ TAI NẠN:

Quản lý hồ sơ tai nạn dựa vào quy chế QTVT01.

Về cơ bản, việc lập hồ sơ tai nạn trên phần mềm là bước
đầu tiên để giải quyết tai nạn đó dưới góc độ tài chính kế
toán (bồi thường và/hoặc các chi phí khác).
Mọi tạm ứng, thanh toán liên quan đến việc giải quyết tai
nạn đều phải tham chiếu đến hồ sơ tai nạn đã khai báo
trên phần mềm.
 Một công ty quản lý vận tải cần xây dựng “Danh sách lái phụ xe”
Mô tả: Menu này sẽ cung cấp thông tin và hồ sơ của lái phụ xe cho danh mục
nhân viên công ty làm cơ sở để tính lương và các loại phụ cấp. Công ty sẽ
ban hành lại QTVT05 và QTVT07 để làm cơ sở xây dựng menu này. Mục tiêu
của menu này nhằm thiết lập một bước phê duyệt việc tuyển dụng và sa thải
lái phụ xe để đưa vào danh sách.
Thông tin nhân sự cần có:
Họ và tên
Ảnh
Địa chỉ đăng ký hộ khẩu
Số CMT ND, ngày cấp, nơi cấp
Số điện thoại
Số bằng lái xe, ngày cấp, nơi cấp và hạng bằng lái.
Ngày bắt đầu thử việc
Ngày làm việc chính thức
Ngày nghỉ việc (nếu có)
Một công ty quản lý vận tải cần xây dựng “Danh sách lái phụ xe”

Hồ sơ cần upload lên phần mềm:

Sơ yếu lý lịch
CMT ND
Bằng lái
Thư mời làm việc
Hợp đồng lao động
Quyết định khen thưởng, kỷ luật (nếu có)
Quyết định nghỉ việc (nếu có)

Các danh sách cần lập:

Lái xe chính
Lái xe phụ
Phụ xe
Lái xe đã nghỉ việc
Một công ty quản lý vận tải cần xây dựng “Quản lý Chi phí
vận hành”
Mô tả
Menu này nhằm (1) xây dựng chi phí định mức cho xe/cung
đường cụ thể; (2) lập lệnh điều xe cho cả xe Delta và xe của
nhà cung cấp; (3) lập bảng kê chi phí định mức để thanh
toán tiền và dầu diesel cho lái xe; (4) thiết lập liên kết giữa
vận tải với sales/marketing, quản lý nhà cung cấp và giao
nhận
(1) Xây dựng chi phí định mức theo xe/cung đường
 Đặc tả yêu cầu nhằm một số mục đích: Chuyển tải thông tin;
Lập hợp đồng; Làm cơ sở cho việc kiểm tra; Làm cơ sở cho
việc quản lý các thay đổi.
 Đặc tả yêu cầu có hai kiểu người dùng: Có chuyên môn và
không chuyên môn.
 Đặc tả tốt thì rất khó viết: đảm bảo các tính chất hoàn chỉnh,
nhất quán, hợp lệ, không mơ hồ, dễ kiểm tra, dễ sửa đổi, dễ lần
vết.
 BÀI TẬP NHÓM
- Viết tài liệu đặc tả yêu cầu phần
mềm (SRS)
- Hoàn thiện báo cáo theo mẫu
 KIỂM TRA, KIỂM CHỨNG YÊU CẦU,
SẮP XẾP YÊU CẦU THEO THỨ TỰ ƯU TIÊN
 NỘI DUNG

Kiểm tra và kiểm chứng các yêu cầu

Sắp xếp yêu cầu theo thứ tự ưu tiên

 KIỂM TRA VÀ KIỂM CHỨNG
(VERIFICATION AND VALIDATION)

 Các khái niệm cơ bản

 Kiểm tra

 Kiểm chứng
KIỂM TRA VÀ KIỂM CHỨNG
TIÊU CHUẨN KIỂM TRA VÀ KIỂM CHỨNG
 HAI TIÊU CHUẨN KIỂM TRA
TÍNH CHÍNH XÁC

 Đặc tả (S) được cho trong thuộc tính của lĩnh

vực (D) thỏa mãn các yêu cầu (R)

 Chương trình (P) thực hiện trên một máy tính

(C) cụ thể đáp ứng với đặc tả (S)

 HAI TIÊU CHUẨN KIỂM CHỨNG
SỰ HOÀN THIỆN

Chúng ta đã xem xét (và hiểu) tất cả các yêu

cầu (Requirements) quan trọng?

Chúng ta đã xem xét (và hiểu) tất cả các thuộc

tính lĩnh vực (Domain properties) liên quan?

VÍ DỤ VỀ V&V
 ĐẶC ĐIỂM PHẦN MỀM

 Phần mềm thì vô hình, mơ hồ, trừu tượng

 Không có quy luật tự nhiên nào bên trong
các hành vi phần mềm
 Không có các ràng buộc tự nhiên nào trong
các phần mềm phức tạp
 Phần mềm hoàn toàn có thể thực hiện một
công việc lặp đi lặp lại
CHU TRÌNH ĐIỀU TRA
CHU TRÌNH ĐIỀU TRA NHANH
 CÁC KỸ THUẬT KIỂM CHỨNG

 Lập bản mẫu (Prototyping)

 Phân tích mô hình (Model Analysis)

 Kiểm duyệt (Inspection)

 LẬP BẢN MẪU

 “Một bản mẫu phần mềm là một kiến trúc

được cài đặt cụ thể trước để các khách
hàng, người dùng hoặc nhà phát triển có thể
hiểu rõ thêm về một vấn đề hay giải pháp
của nó.” [Davis 1990]
 “Lập bản mẫu là tiến trình xây dựng mô
hình làm việc của hệ thống” [Agresti 1986]
 CÁC LOẠI BẢN MẪU

 Bản mẫu dùng thử: Là bản mẫu sẽ bị bỏ

đi khi thu được các kiến thức mong
muốn.
 Bản mẫu tiến hoá: Là bản mẫu được
phát triển dần trong quá trình xây dựng
hệ thống
HƯỚNG TIẾP CẬN LẬP BẢN MẪU
PHÂN TÍCH MÔ HÌNH (MODEL ANALYSIS)
 KIỂM DUYỆT

 Kiểm duyệt là một hình thức xem xét cụ

thể đã được chứng minh là cực kỳ hiệu
quả trong việc phát hiện các lỗi của phần
mềm.
 Kiểm duyệt khác các kỹ thuật kiểm
chứng khác ở cấu trúc của nó
 LẬP CẤU TRÚC SỰ KIỂM DUYỆT
 Checklist
- Dùng 1 danh sách các câu hỏi kiểm tra/vấn đề
- review được cấu trúc bởi vấn đề trong danh sách
 Walkthough
- Một người phải có mặt trong từng bước kiểm tra sản
phẩm
- review được cấu trúc bởi sản phẩm
 Round Robin
- Mỗi reviewer lần lượt nếu ra một vấn đề
- review thì được cấu trúc bởi đội review
 Tốc độ Review
- Mỗi reviewer có 3 phút để xem xét lại 1 vấn đề, sau đó
chuyển sang cho người kế tiếp
- Tốt cho việc đánh giá khả năng hiểu thấu vấn đề!
KIỂM TRA VÀ KIỂM CHỨNG ĐỘC LẬP
 CÁC KỸ THUẬT KIỂM TRA

 Thực hiện lưu vết đặc tả

 Kiểm thử

 Kiểm duyệt mã lệnh

 Phân tích mã lệnh

 SẮP XẾP YÊU CẦU
(REQUIREMENTS PRIORITIZATION)

 Tại sao cần sắp xếp các yêu cầu

theo thứ tự ưu tiên?

 Định hướng theo Chi phí –Giá trị

 CƠ SỞ CỦA SỰ ƯU TIÊN
 Cái gì cần được chọn để cài đặt
 Đối với mỗi yêu cầu/đặc tính, cần xác định các vấn
đề sau:
Nó quan trọng thế nào với khách hàng?
Chi phí để cài đặt nó là bao nhiêu ?
Sẽ có rủi ro nào khi cố gắng thực hiện nó?

 Thực thi khẩn cấp:

Một số yêu cầu bắt buộc
Một số yêu cầu nên dứt khoát loại bỏ
 “Các yêu cầu hợp lý
TIẾP CẬN THEO CHI PHÍ/GIÁ TRỊ
(COST-VALUE)
 ƯỚC LƯỢNG CHI PHÍ/GIÁ TRỊ
 2 cách tiếp cận:
- Định mức tuyệt đối: Đòi hỏi phải có kinh nghiệm chuyên môn
- Các giá trị liên quan: Dễ dàng để làm rõ hơn; Sắp thứ tự ưu tiên
dựa trên sự sắp xếp các vấn đề
 Quá trình so sánh – chọn lựa
- Cơ sở để sắp xếp – với mỗi cặp yêu cầu (i,j), xét i>j? Chẳng hạn
bubblesort – bắt đầu với thứ tự ngẫu nhiên và hoán đổi mỗi cặp nếu
sai thứ tự cần n*(n-1)/2 bước so sánh
- Dựng Cây thứ tự nhị phân (Binary Sort Tree): Cần O(nlogn)
bước so sánh
Dựng cây phủ tối tiểu (Minimal Spanning Tree): Với mỗi cặp (Ri,
Ri+1) : tính khoảng cách giữa chúng, cần n-1 bước so sánh
MỘT SỐ VẤN ĐỀ PHÁT SINH
 SỰ PHÂN CẤP THỨ TỰ ƯU TIÊN
 Nhóm các yêu cầu theo một cấu trúc phân cấp: Cây
mục tiêu (A goal tree) hoặc Cây NFR (NFR-Non function
requirements tree)
 Chỉ thực hiện sự so sánh giữa các nhánh của cùng
một nút:
ANALYTIC HIERARCHY PROCESS (AHP)
VẼ ĐỒ THỊ LỢI NHUẬN TRÊN VỐN ĐẦU TƯ
(ROI GRAPH)
 Thực hiện quá trình AHP hai lần: để đánh giá
quan hệ Giá trị và đánh giá quan hệ Chi phí
 Dùng kết quả để tính toán tỷ số ROI (Return On
Investment) :
TIÊU CHUẨN CHỌN LỰA KHÁC
MINH HỌA “GIÁ TRỊ” TỪ CÁC ĐỐI TÁC
TÍNH “TRỌNG SỐ” CỦA CÁC ĐỐI TÁC
CÁC PHƯƠNG PHÁP GIẢI QUYẾT “MÂU THUẪN”
CÁC PHƯƠNG PHÁP GIẢI QUYẾT “MÂU THUẪN”
 ÔN TẬP
THẢO LUẬN