ĐỀ CƯƠNG ÔN TẬP PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM

65
SE-K48
ĐỀ CƯƠNG PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM
*************************
ĐỀ CƯƠNG PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM 1
************************* 1
Chương 0. Cơ sở của phân tích và thiết kế phần mềm 5
1. Nêu khái niệm phân tích và thiết kế phần mềm (Software analysis and development)
5
2.Phân biệt khái niệm Phương pháp luận (methodologies) và Kỹ thuật (technique) 5
3.Công cụ (tool): Vai trò, tác dụng. Nêu tên một số công cụ chính và ứng dụng của
những công cụ này 5
4. Phân tích viên (Software Analyst): Vai trò và vị trí của cán bộ này trong công ty
phần mềm 6
5. Quá trình phát triển của phương pháp tiếp cận phân tích và thiết kế phàn mềm 6
6. So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm: phương pháp cổ
điển, phương pháp hướng tiến trình, phương pháp hướng dữ liệu 7
7. Hãy nêu phân loại phần mềm theo ứng dụng 7
8. [Thiếu] 7
Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm 7
1. Mô tả quy trình công nghệ học yêu cầu phần mềm ( Requirement Engineering ) 7
2. Hãy nêu bản chất của yêu cầu phần mềm 9
3. Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng 9
4. Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần
mềm 9
5. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp
xác định yêu cầu phần mềm Phỏng vấn (interview) 10
6. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp
xác định yêu cầu phần mềm Hội thảo 10
7. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp
xác định yêu cầu phần mềm Brainstorming 11

8. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp
xác định yêu cầu phần mềm Storyboarding 12
9. Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp
xác định yêu cầu phần mềm áp dụng UseCase 13
10. Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp
xác định yêu cầu phần mềm áp dụng Prototyping 14
11. Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm 14
12. Xác định và quản lý giới hạn của các yêu cầu phần mềm 15
13. Trình bày phương pháp xác định các yêu cầu phần mềm từ khách hàng 17
14. Trình bày các bước (quy trình) .Phân tích các yêu cầu phần mềm 17
15. Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm 17
16. Nêu các tiêu chí chất lượng và đo lường chất lượng yêu cầu phần mềm 18
17. Phân biệt các khái niệm kiểm thử và đánh giá các yêu cầu phần mềm 18
18. Quan hệ giữa yêu cầu và thực hiện. [Chưa làm] 19
19. Sử dụng phương pháp Traceability để kiểm thử các yêu cầu phần mềm 19
65
SE-K48
20. Hãy cho biết khái niệm ROI và phương pháp xác định ROI khi xây dựng 20
các yêu cầu phần mềm 20
21. Kỹ thuật quản lý thay đổi yêu cầu phần mềm 22
22. Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm 23
23. Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm 23
24. Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU) 24
25. Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm 24
26. Nêu phương pháp và kỹ thuật kiểm duyệt (review) lại các yêu cầu đã xây 24
dựng 24
27. Kiểm thử (testing) yêu cầu phần mềm 24
28. Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm 25
29. Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần
mềm 26

30. Nêu tên một số kỹ thuật phát hiện các yêu cầu phần mềm 28
31. Phân loại người sử dụng có vai trò như thế nào trong phát hiện các yêu cầu phần
mềm 28
32. Nêu tên các kỹ thuật mô hình hoá yêu cầu phần mềm. Hãy đưa ra giải thích ngắn
gọn về đặc điểm của từng kỹ thuật 28
33. Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và
Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào
trong tài liệu SRS 29
34. Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm. Nêu tên một số phương pháp
kiểm thử yêu cầu phần mềm thông dụng mà em biết 29
35. Nêu các phương pháp theo dõi vết của yêu cầu phần mềm 29
36. Quản lý thay đổi yêu cầu phần mềm 30
37. chức năng của EA hỗ trợ đặc tả yêu cầu phần mềm 31
38. Các chức năng của EA hỗ trợ mô hình hóa yêu cầu phần mềm 33
39. Các kỹ thuật trong EA giúp phân tích yêu cầu phần mềm 33
Chương 2. Thiết kế phần mềm (Software Design) 35
1.Nêu quy trình thiết kế phần mềm mức Logic 35
2. Các phương pháp tạo các thiết kế mức logic (Logical Design) 35
3. Đặc tả tài liệu thiết kế mức logic 35
4. Kiểm thử và tối ưu thiết kế mức logic 36
5. Quá trình mô hình hóa dữ liệu mức logic 36
6. Quá trình và các phương pháp tạo các thiết kế mức vật lý 37
7. Nêu phương pháp xác định các yêu cầu đối với kiến trúc phần mềm 37
8. Nêu các hướng tiếp cận xây dựng kiến trúc phần mềm 38
9. Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability, 42
Performance, Security, Testability, Usability 42
10. Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability,
Performance, Security, Testability, Usability 43
12. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm
Modifiability 44

13. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm
44
Performance 44
65
SE-K48
14. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm
45
Security 45
15. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm
46
Testability 46
16. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm
Usability: 46
17. Phương pháp ATAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu 47
18. Phương pháp CBAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu 47
Câu 19: Đặc điểm và bản chất của phương pháp Function-oriented(structured) Design
48
Câu 20: Đặc điểm và bản chất của phương pháp Object-Oriented Design 48
Câu 21: Đặc điểm và bản chất của phương pháp Data-structure Centered Design 50
22. Nêu đặc điểm và bản chất phương pháp Component-based Design (CBD) 50
23.Nêu khái niệm về MSF và các phase trong MSF 51
24.Nêu quá trình thiết kế giao diện và tương tác phần mềm 51
25.Nêu các yêu cầu của giao diện và tương tác 51
26.Nêu một số kỹ thuật trong thiết kế giao diện và tương tác 52
27.Đặc điểm mô hình hóa thiết kế dữ liệu mức khái niệm (conceptual data modeling)
52
The first normal form 1NF 52
The second normal form 2NF 53
28. Đặc điểm mô hình hóa dữ liệu mức khái niệm 53
29. Quá trình mô hình hóa dữ liệu mức khái niệm 53

30. Nêu một số các kỹ thuật trong mô hình hóa dữ liệu mức khái niệm [Chưa làm] 53
31. Đặc điểm mô hình hóa dữ liệu mức Logic 53
32. Quá trình mô hình hóa dữ liệu mức Logic 54
34. Nêu các kỹ thuật đảm bảo chất lượng phần mềm ở giai đoạn thiết kế 54
35. Nêu các đặc điểm trong giai đoạn ổn định và giai đoạn triển khai 55
36. Các yêu cầu của đặc tả phần mềm 55
37. Định dạng đặc tả phần mềm: Các loại tài liệu 56
38. Các quy định chung về định dạng đặc tả 56
39. Một số kỹ thuật chính trong thiết kế đặc tả 56
40. Nêu các phương pháp kiểm duyệt, kiểm thử và đánh giá các đặc tả phần mềm 57
Các tiêu thức để đánh giá một đặc tả: tính nhất quán, tính thân thiện dễ sử dụng 57
41. Các chức năng của EA giúp thiết kế phần mềm mức Logic 58
42. Các chức năng của EA giúp phân tích các thuộc tính chất lượng của kiến trúc phần
mềm 58
Chương 3. Xây dựng phần mềm (Software Construction) 58
Câu 1:Trình tự thiết kế chi tiết 58
Câu 2: Nêu các kỹ thuật thiết kế thành phần phần mềm : Phân chia thành các thành
phần,xác định đặc tả chức năng ,Giao diện giữa các thành phần 58
Câu 3: Nêu các kỹ thuật thiết kế vào /ra :Thiết kế báo cáo ,Thiết kế giao diện người
dùng ,Thiết kế màn hình ,Phương pháp kiểm tra vào /ra và thiết kế thông báo 59
Câu 4: Thiết kế dữ liệu vật lý 59
65
SE-K48
Câu 5: Nêu tên các tài liệu thiết kế chi tiết 60
Câu 6: Nêu tổ chức các tài liệu thiết kế chi tiết 60
7. Nêu các biểu mẫu thiết kế màn hình [Không chắc chắn]: 62
8. Nêu các biểu mẫu thiết kế báo cáo [Không chắc chắn]: 62
9. Nêu các phương pháp xét duyệt thiết kế chi tiết 62
10. Nêu trình tự thiết kế chương trình 62
11. Nêu các tiêu chuẩn thiết kế chương trình 62

12. Nêu các tiêu chuẩn phân chia module 63
13.[Thiếu] 64
14. Tạo tài liệu thiết kế chương trình 64
15. Nêu các phương pháp xét duyệt thiết kế [Chưa làm] 65
16. Nêu các phương pháp thiết kế chi tiết và sản xuất phần mềm [Chưa làm] 65
17. Các chức năng của EA giúp thiết kế chi tiết phần mềm 65
Câu 18. Các chức năng của EA giúp thiết kế dữ liệu mức vật lí 65
65
SE-K48
Chương 0. Cơ sở của phân tích và thiết kế phần mềm
1. Nêu khái ni ệ m phân tích và thi ế t k ế ph ầ n m ề m (Software analysis and development)

Thiết kế phần mềm bao gồm cả chu trình từ xác định kiến trúc, thành phần, giao diện và các
nhân tố khác của một hệ thống hay một thành phần nào đó, lẫn kết quả của chu trình đó(định
nghĩa của IEEE ).
2.Phân biệt khái niệm Phương pháp luận (methodologies) và Kỹ thuật (technique)
Methodologies(Phương pháp luận) Technique(kĩ thuật)
- Phương pháp chung(cách tiếp cận) để tạo ra
phần mềm.
- Hiện tại có hai luồng chính của các phương
pháp luận:
+ Structured Methodology(phương pháp cấu
trúc)- (SSADM phân tích cấu trúc và phương
pháp thiết kế…)
+ Object Oriented Methodology(phương pháp
hướng đối tượng)(OOA/OOD…)
- Được thiết kế ra để làm chuẩn hoá quá trình
phần mềm
- Phương pháp cụ thể trong một giai đoạn của
phương pháp luận, thực hiện cụ thể của phương

pháp luận.
VD: SSADM: dùng 3 kĩ thuật chủ yếu: mô hình
dữ liệu logic, mô hình luồng dữ liệu, mô hình
ứng xử thực thể
OOA/OOD: UML
(Tham khảo K47)
- Phương pháp luận là các hướng tiếp cận khi phân tích thiết kế phần mềm nói chung. Đây
là các phương pháp tuân theo một chuẩn thiết kế nào đó được đưa ra nhằm làm chuẩn hóa
quá trình thiết kế phần mềm. Ví dụ: phương pháp tiếp cận trên xuống, phương pháp tiếp
cận hướng dữ liệu, …
- Các kĩ thuật là các phương pháp được sử dụng để thực hiện một giai đoạn nào đó trong
toàn bộ chu trình phát triển phần mềm. Ví dụ:
o Phương pháp đặc tả hình thức là kĩ thuật dùng để mô tả các đặc tả của phần mềm
dựa trên các luật hình thức.
o Phương pháp Jackson là kĩ thuật dùng để định nghĩa thuật toán của một chương
trình theo cấu trúc dữ liệu đầu vào.
3.Công cụ (tool): Vai trò, tác dụng. Nêu tên một số công cụ chính và ứng dụng của những
công cụ này
Trả lời :
- Vai trò: cung cấp những hỗ trợ tự động hoặc bán tự động cho các quy trình và phương
pháp phân tích thiết kế phần mềm. Nói cách khác công cụ chính là những phần mềm
được tạo ra nhằm mục đích sử dụng chung.
- Tác dụng: khi một công cụ được tích hợp thì những thông tin do nó tạo ra có thể được sử
dụng cho việc xây dựng và phát triển các phần mềm khác. Chính vì vậy việc sử dụng
công cụ có một số tác dụng như sau:
65
SE-K48
o Rút ngắn thời gian phát triển hệ thống
o Kích cỡ phát triển được rút ngắn lại
o Dịch vụ nâng cấp được kèm theo

- Một số công cụ và vai trò của nó:
o CAD: (Computer Aided Design) thiết kế có máy tính hỗ trợ. Người làm ra bản
thiết kế bằng cách nhận sự hỗ trợ của máy tính qua hiển thị đồ họa.
o CAM: (Computer Aided Manufactoring) chế tạo có máy tính hỗ trợ. Hỗ trợ cho
quản lý tiến trình, chuẩn bị cho sản xuất, kiểm thử xử lý và lắp ráp.
o CAE: (Computer Aided Engineering) kĩ nghệ có máy tính hỗ trợ. Là hệ thống hỗ
trợ cho một loạt các công việc bao gồm từ thiết kế sản phẩm, kiểm thử hiệu năng
và chế tạo.
4. Phân tích viên (Software Analyst): Vai trò và vị trí của cán bộ này trong công ty phần
mềm
Trả lời :
- Vai trò: nhìn nhận được các yêu cầu đặt ra đối với hệ thống cả về phía người dùng lẫn về
phía hệ thống ví dụ như về quy mô hệ thống, về chức năng của hệ thống, lấy được các
yêu cầu của khách hàng… Từ đó đề ra các chiến lược để thiết kế và phát triển hệ thống.
Do đó phân tích viên cần phải có các yếu tố sau :
o Am hiểu về công việc của công nghệ phần mềm.
o Có nhiều kinh nghiệm và thành thạo trong lập trình phần mềm.
o Có hiểu biết chung về nghiệp vụ.
o Có các kĩ năng giải quyết vấn đề.
o Khả năng giao tiếp tốt.
o Linh hoạt và có khả năng thích nghi.
- Vị trí: Có vị trí quan trọng đầu tiên trong một dự án. Nếu không đưa ra được những phân
tích điểm lợi của dự án hay những điểm yếu cần khắc phục cũng như những yêu cầu cần
thiết đặt ra của dự án thì có thể dẫn tới thất bại dự án. Trong một công ty phần mềm, là
người chịu trách nhiệm phân tích những hướng phát triển trong tương lai của công ty
cũng như đưa ra những ưu nhược điểm của các mô hình phát triển hiện thời mà công ty
đang áp dụng.
5. Quá trình phát triển của phương pháp tiếp cận phân tích và thiết kế phàn mềm
- Hướng tiếp cận hướng tiến trình:
o Tập trung vào các giải thuật và xử lý dữ liệu

o Quá trình phát triển phần mềm tập trung thể hiệnc ác phương pháp xử lý dữ liệu.
o Cấu trúc dữ liệu thông thường không được thể hiện rõ
o Nhược điểm của hướng tiếp cận: các tệp dữ liệu rất khó xây dựng để thỏa mãn
phần mềm.
- Hướng tiếp cận hướng dữ liệu:
o Mô tả tổ chức của dữ liệu: mô tả dữ liệu được lấy ở đâu ra và sử dụng như thế
nào
o Mô hình dữ liệu được thành lập cũng như mối quan hệ giữa các dữ liệu này
o Sử dụng các business rules dể chỉ ra phương pháp xử lý dữ liệu
- Hướng tiếp cận hướng kiến trúc:
o Lựac họn kiến trúcvà công nghệ phần mềm để thực hiện bài toán
65
SE-K48
o Áp dụng phương pháp prototyping để nhah chóng xây dựng được phần mềm
o Sử dụng các partern kiến trúc mẫu để chỉ ra phương pháp xử lý dữ liệu
6. So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm: phương pháp cổ điển,
phương pháp hướng tiến trình, phương pháp hướng dữ liệu
So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm:
- Phương pháp cổ điển: là phương pháp phân tích và thiết kế có cấu trúc. Các yêu cầu về
hệ thống đích được phát triển được phân tích bằng việc đặc biệt chú ý tới chức năng của
hệ thống và luồng dữ liệu giữa các chức năng. Mục đích của phương pháp này là chuyển
các tiến trình trong biểu đồ DFD thành các module chương trình và tiến hành phân chia
các module bằng cách tiếp cận trên xuống.
- Phương pháp hướng tiến trình: việc phân tích và thiết kế đặt trọng tâm vào các chức năng
do phần mềm thực hiện. Không có chuẩn rõ ràng để định nghĩa đơn vị chức năng do đó
việc định nghĩa này có thể ảnh hưởng bởi cách nghĩ riêng của người thiết kế. Khó điều
chỉnh các yêu cầu cho nhiều người dùng. Sử dụngc ác chức năng chồng chéo nhau là khó
tránh khỏi. Kết quả là hệ thống bao gồm nhiều chức năng chồng chéo nhau là một trong
những nhân tố làm cho việc bảo trì trở nên khó khăn.
- Phương pháp hướng dữ liệu: dữ liệu không thay đổi bởi các yêuc ầu hay đòi hỏi của

người dùng về thao tác nghiệp vụ. Trong thiết kế hướng dữ liệu hệ thống được thiết kế
dựa trên cấu trúc tiến trình dữ liệu. Việc phân tích thiết kế được tiến hành cho dữ liệu
được tách bạch với yêuc ầu hay đòi hỏi của người dùng về thao tác. Do vậy tiến trình
được xác định và tích hợp vào trong các thủ tục chuyên dụng dữ liệu.
7. Hãy nêu phân loại phần mềm theo ứng dụng
Phân loại phần mềm theo ứng dụng:
- Phần mềm hệ thống
- Phần mềm thời gian thực
- Phần mềm quản lý
- Phần mềm công nghệ và khoa học
- Phần mềm nhúng
- Phần mềm trí tuệ nhân tạo
8. [Thiếu]
Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm
1. Mô tả quy trình công nghệ học yêu cầu phần mềm ( Requirement Engineering ).
Quy trình công nghệ học phần mềm được chia thành 2 giai đoạn: Phát triển yêu cầu và Quản lý
yêu cầu. Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn: Phát hiện yêu cầu,
Phân tích yêu cầu, Đặc tả yêu cầu và kiểm thử yêu cầu.
65
SE-K48
HÌNH 1-2. Phân cấp công nghệ học yêu cầu.
- Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn:
Phát hiện yêu cầu
Phân tích yêu cầu
Đặc tả yêu cầu
Kiểm thử yêu cầu.
- Quản lý yêu cầu được hiểu là :”thiết lập và duy trì một thoả thuận với khách hàng về các yêu
cầu của dự án phần mềm” (CMU/SEI 1995). Quản lý yêu cầu gồm các bước sau.
Xác định giới hạn yêu cầu phần mềm. (Requirement baseline).
Duyệt các giới hạn của phần mềm.

Quản lý các thay đổi yêu cầu phần mềm.
Quy trình phát triển được thể hiện trên hình vẽ sau:
HÌNH 1-3. Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu.
65
SE-K48
Mô tả quy trình như sau:
Maketing Customer Managerment lấy yêu cầu từ khách hàng, sau đó các yêu cầu đó được tổng
hợp lại, phân tích, thỏa thuận với khách hàng, rà soát lại ( Đây là quá trình phát triển yêu cầu ).
Kết quả của quá trình phát triển yêu cầu là bản Baseline Requrirements. Tài liệu này được chuyển
chuẩn hóa và làm mốc cho cả quá trình thay đổi ( gọi là phiên bản cơ sở 1.0).
Phiên bản cơ sở 1.0 được gửi cho khách hàng, bộ phận MCM lại tiếp tục đàn phán với khách
hàng trên cơ sở phiên bản này, những yêu cầu thay đổi được tổng hợp, xử lý cập nhập lại
Baseline Requirements.
Với mỗi thay đổi cập nhập lại gồm : thay đổi cái gì, ai là người thay đổi, thay đổi ảnh hưởng như
thế nào đến hệ thống, đề phòng ra sao. Tất cả các thông tin trên được chuẩn hóa thành phiên bản
1.1.
Bây giờ phiên bản 1.1 được lấy làm cơ sở. Quy trình cứ tiếp tục cho đến khi có sự thống nhất từ
khách hàng và đội phát triển.
2. Hãy nêu bản chất của yêu cầu phần mềm.
Bản chất của yêu cầu phần mềm là mâu thuẫn.
Sự mâu thuẫn thể hiện ở ý niệm về yêu cầu phần mềm xuất phát từ khách hàng và từ người sử
dụng.
• Các yêu cầu phần mềm xuất phát từ người sử dụng đối với người phát triển phần
mềm thông thường quá trừu tượng, ở mức cao.
• Ngược lại yêu cầu phần mềm được mô tả từ người phát triển đối với người sử
dụng lại ở mức quá thấp, quá chi tiết cho nên người sử dụng không thể hiểu hết
được.
Vì sự mâu thuẫn đó nên IEEE 1997 đã đưa ra một định nghĩa yêu cầu phần mềm nhìn từ góc độ
người sử dụng và người phát triển, và những yêu cầu đó cần được đúc kết thành một văn bản để
thống nhất giữa 2 bên.

Định nghĩa IEEE:
• Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để
giải quyết một vấn đề hoặc để giải quyết một mục tiêu. (1)
• Điều kện hay khả năng cần phải thỏa mãn hoặc cần có của 1 hệ thống hoặc 1
thành phần hệ thống nhằm đáp ứng 1 hợp đồng, 1 tiêu chuẩn hoặc 1 đặc tả của
một tài liệu khác.(2)
• Văn bản thể hiện các điều kiện khả năng được thể hiện ở (1) và (2).
3. Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng.
Định nghĩa IEEE về yêu cầu phần mềm từ phía khách hàng:
• Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để
giải quyết một vấn đề hoặc để giải quyết một mục tiêu. (1)
4. Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm
Thói quen tốt:
• Luôn hỏi lại người dùng những gì mình chưa hiểu hết về yêu cầu của họ.
• Không chỉ khảo sát yêu cầu với một loại người sử dụng, mà phải bao quát tất cả
những người sử dụng.
• Đánh dấu những điểm chưa rõ trong đặc tả: Đôi khi chúng ta thiếu một số thông
tin về các yêu cầu phần mềm, chúng ta cần thảo luận với người sử dụng để hiểu
65
SE-K48
chi tiết hơn. Tất cả những chỗ như vậy đc đánh đấu là TBD( Tobe determined).
 Tất cả TBD này phải đc giải quyết trước khi bắt đầu quá trình phân tích và
xây dựng phần mềm.
Thói quen không tốt:
• Tự mình nghĩ ra những yêu cầu của người dùng, hay tự cho mình là người dùng
phần mềm.
• Người sử dụng là chuyên viên trong lĩnh vực nào đó nên có thói quen nghĩ là tất
cả các phân tích viên đề là các chuyên gia trong lĩnh vực đó  Đưa ra các yêu
cầu ngắn gọn mà ko miêu tả kỹ lưỡng hơn chúng là gì.
5. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác

định yêu cầu phần mềm Phỏng vấn (interview).
Đặt ra các câu hỏi về bản chất của các vấn đề người dùng. Để giải quyết vấn đề này, cần
sử dụng các câu hỏi:
- Người sử dụng là ai?
- Khách hàng là ai?
- Nhu cầu của họ có khác nhau không?
- Trong trường hợp nào thì có thể tìm thấy giải pháp cho vấn đề này?
Nội dung của cuộc phỏng vấn có thể được thực hiện theo mẫu như sau:
- Thiết lập tiểu sử người dùng hay khách hàng.
- Đi vào vấn đề
- Tìm hiểu về môi trường người dùng
- Tóm tắt lại những gì thu được.
- Phân tích đầu vào trên các vấn đề của khách hàng.
- Đi vào giải pháp của mình (nếu thích hợp).
- Đi vào cơ hội.
- Đi vào sự đáng tin cậy, hiệu quả và các nhu cầu hỗ trợ.
- Những yêu cầu khác
- Bao quát lại
- Tổng kết phân tích.
Những điểm cần lưu ý khi tiến hành phỏng vấn:
- Chuẩn bị trước nội dung cần phỏng vấn. Xem lại các câu hỏi trước khi tiến hành
phỏng vấn.
- Trước cuộc phỏng vấn nên tìm hiểu về nền tảng của các bên liên quan và công ty
được phỏng vấn.
- Ghi lại những câu trả lời trong quá trình phỏng vấn (Không cố gắng lấy ra thông
tin trong lúc này).
- Tham khảo mẫu trong quá trình phỏng vấn để đảm bảo đặt ra những câu hỏi đúng
đắn.
6. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác
định yêu cầu phần mềm Hội thảo.

65
SE-K48
Quy trình thực hiện và kỹ thuật xác định yêu cầu phần mềm hội thảo.
- Chuẩn bị Hội thảo
o Quảng bá nội dung
o Đảm bảo các bên liên quan sẽ tham dự.
o Chuẩn bị hậu cần tốt.
o Khởi động vật chất (warm-up materials): gửi material ra trước hội thảo để
chuẩn bị tham dự và cũng để tăng hiệu quả của cuộc hội thảo. Có 2 loại
warm-up materials:
 Thông tin cụ thể về dự án. Trong đó có thể bao gồm bản phác thảo
của các tài liệu yêu cầu, liệt kê những tính năng được đề nghị, bản
sao các cuộc phỏng vấn với những người dùng tiềm năng, báo cáo
phân tích về xu hướng, thư từ khách hàng, báo cáo lỗi về hệ thống
hiện hành, chỉ thị quản lý mới, dữ liệu marketing mới….
 Chuẩn bị cách suy nghĩ vượt ra khỏi giới hạn.
- Chuẩn bị vai trò cho facilitator (vai trò như người dẫn chương trình hay người chủ
tọa):
o Đó là người bên ngoài, có kinh nghiệm.xử lý về quản lý yêu cầu hoặc.
o Là một thành viên trong nhóm và đã đạt được những thành tựu nhất định.
- Lên lịch trình Hội thảo
- Chạy chương trình
o Các vấn đề và phương pháp thương mại
o Brainstorming
o Sự trình bày và những việc tiếp theo: sau Hội thảo, facilitator ghi lại các
kết quả thu được. Sau đó, facilitator kết thúc nhiệm vụ của mình và
chuyển sang cho nhóm phát triển.
7. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác
định yêu cầu phần mềm Brainstorming
Brainstorming gồm có 2 pha:

- Nêu ra các ý tưởng: Mục đích là đưa ra được càng nhiều ý tưởng càng tốt, mục đích mới
là bề rộng, chưa cần có chiều sâu.
- Thâu tóm lại ý tưởng: Phân tích các ý tưởng được đưa ra, chọn lọc, tổ chức, đánh giá,
mở rộng theo chiều sâu, tinh chỉnh chúng lại thành ý tưởng thích hợp.
Kỹ thuật này có những lợi ích chính sau:
• Khuyến khích được mọi thành viên tham gia.
• Cho phép các thành viên tranh luận với nhau về các ý kiến đề xuất.
• Người điều phối hoặc thư ký duy trì cuộc hội thảo không bị gián đoạn.
• Diễn ra nhanh chóng.
• Đưa ra các giải pháp khả thi cho vấn đề.
65
SE-K48
• Khuyến khích các ý tưởng, suy nghĩ sáng tạo, độc đáo.
Quy định:
 Không được phép tranh cãi, phê bình gay gắt.
 Tự do sáng tạo, tưởng tượng.
 Đưa ra càng nhiều ý tưởng càng tốt
 Nghiên cứu tổng hợp lại ý tưởng hay.
8. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác
định yêu cầu phần mềm Storyboarding
Có 3 loại Storyboarding:
 Bị động: Gồm các bản phác thảo, những hình ảnh, slide Người phân tích đảm
nhiệm vai trò hệ thống và hiểu rõ về người sử dụng thông qua storyboard.
 Chủ động: Làm người sử dụng thấy được kết quả cho dù nó chưa được hoàn
thành.
 Tương tác: Tạo cho người dùng kinh nghiệm về hệ thống. Các thành viên đóng
vai trò như người sử dụng.
Những chú ý:
 Không nên đầu tư quá nhiều vào Storyboarding
 Storyboard nên dễ chỉnh sửa.

 Không nên làm quá chi tiết. Điều đó sẽ gây khó khăn khi sử dụng các kỹ thuật
hoặc công cụ khác nhau khi cài đặt sau này.
 Cố gắng làm cho storyboard liên hệ với nhau, tương tác được với nhau.
65
SE-K48
9. Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác
định yêu cầu phần mềm áp dụng UseCase.
Use Case là một phương pháp luận trong ngôn ngữ mô hình hóa UML. Đó là một phương
pháp luận khá hoàn chỉnh cho việc phát triển phần mềm hướng đối tượng. Use case được mô tả
qua biểu đồ Use-case.
Use case mô tả tương tác giữa người dùng với hệ, nó cho biết các actor (Các tác nhân) ,
các chức năng của hệ thống. Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên
ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía
hệ thống (tức là Use case). Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ
và được miêu tả trong biểu đồ Use case của UML. Mỗi một Use case được mô tả trong tài liệu, và
nó sẽ đặc tả các yêu cầu của khách hàng.
Xây dựng mô hình Use-case:
- Bước đầu tiên của quá trình mô hình hóa Use-Case là định nghĩa hệ thống(Xác định
phạm vi của hệ thống – Hình chữ nhật liền nét) : Vì hệ thống là một thành phần của
mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được
định nghĩa rõ ràng. Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải
bao giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra
tác vụ nào có khả năng được tự động hóa tốt nhất ở hệ thống này và tác vụ nào thì tốt
nhất nên thực hiện thủ công hoặc dành cho các hệ thống khác. Một khía cạnh khác
cần chú ý là hệ thống cần phải lớn tới mức độ nào trong phiên bản đầu tiên của nó.
Cố gắng tối đa cho phiên bản đầu tiên của hệ thống thường là cách mà người ta hay
thực hiện, thế nhưng những mục tiêu quá tầm như vậy có thể khiến cho hệ thống trở
nên quá lớn và thời gian để cung cấp hệ thống quá lâu.
- Tìm ra các tác nhân(Actor) và các use-case
o Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử

dụng hệ thống. Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn
nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là nhận thông điệp
xuất phát từ hệ thống, hoặc là thay đổi các thông tin cùng với hệ thống. Nói
một cách ngắn gọn, tác nhân thực hiện các Use Case. Thêm một điều nữa,
một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ như
là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một
loại trang thiết bị phần cứng nào đó tương tác với hệ thống).
o Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân
nhận được. Một Use Case trong ngôn ngữ UML được định nghĩa là một tập
hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết
quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể.
Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác
nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống.
- Mô tả các Use-case
- Định nghĩa mối quan hệ giữa các Use-case
- Kiểm tra và phê chuẩn mô hình.
Ví dụ:
65
SE-K48
10. Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác
định yêu cầu phần mềm áp dụng Prototyping.
Prototyping là phương pháp xác định yêu cầu phần mềm bằng cách đưa ra các mẫu thử.
Người phát triển sẽ dựa vào các yêu cầu khảo sát để đưa ra 1 sản phẩm ban đầu phác thảo có thể
bằng công nghệ khác với công nghệ sẽ được sử dụng. Sau đó có sự trao đổi với người sử dụng, từ
đó tìm ra các yêu cầu một cách cụ thể, rõ ràng hơn, đặc biệt là các yêu cầu có tính “mờ”. Việc tạo
mẫu thử có thể được sử dụng nhiều lần ở nhiều phần và giai đoạn khác nhau. Các mẫu thử được
tạo ra có thể có khả năng tái sử dụng, các mẫu thử sau sẽ phát triển liên tiếp nên nền các mẫu thử
trước.(Mô hình tiến hóa)
Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm như là sự
thực thi riêng lẻ của hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng và khách

hàng hiểu cặn kẽ hơn về yêu cầu của hệ thống.
Với mục đích phân tích yêu cầu ta có thể chon xây dựng các mẫu thử : throwaway,
horizontal, user interface. (Nếu muốn nói cụ thể từng loại mọi người đọc sách Managing
Requirement Software chương 13 nhe)
Để xây dựng các mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người
phát triển phải khảo sát các yêu cầu của hệ thống, tiến hành trao đổi đàm phán với khách hàng.
Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử. Dựa vào các yêu cầu đã khảo sát tạo bản
mẫu rồi tro đổi với người sử dụng, với khách hàng, để phát hiện cụ thể hơn các yêu cầu đặc biệt
các yêu cầu có tính “mờ”. Tiến hành phát triển theo mẫu thử đã được phê duyệt, sau bước đó tiếp
tục tạo các mẫu thử có thể sử dụng các mẫu thử đã có từ trước.
11. Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm
Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi của dự án. Phạm vi dự án là
một hàm của:
• Chức năng cần có để đáp ứng nhu cầu người dùng.
• Tài nguyên sẵn sàng cho dự án.
• Thời gian cần có để có thể thực hiện dự án.
65
SE-K48
Phạm vi dự án.
 Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers, nhân
viên đảm bảo chất lượng
Nếu thời gian đủ dài, kết quả công việc có thể được tăng lên, nhưng nó không tăng tỷ
lệ với tài nguyên đầu tư thêm. Hiệu quả tổng thể của dự án vì thế mà sẽ bị giảm sút.
Thêm tài nguyên thậm chí có thể làm chậm dự án bởi vì cần phải đào tạo và hỗ trợ
cho nhân sự mới, vì thế sẽ làm giảm năng suất của dự án.
Nhằm mục đích phân tích phạm vi, ta coi tài nguyên là không đổi trong suốt dự án.
 Thời gian, có thể thay đổi nếu như tài nguyên sẵn có không đủ để hoàn thành các
chức năng mong muốn. Để phân tích phạm vi, ta coi như thời gian là yếu tố cố định.
Chức năng tổng thể bị giới hạn bởi thời gian (cố định) và tài nguyên (cũng cố định), vì thế
phạm vi khả thi chính là hình chữ nhật màu trắng.

Nếu hiệu năng đòi hỏi phải bổ sung đặc tính của hệ thống bằng với tài nguyên trên thời gian
sẵn có thì dự án có phạm vi khả thi.
Thông thường trong công nghiệp, các dự án đều là dự án vượt phạm vi.
12. Xác định và quản lý giới hạn của các yêu cầu phần mềm
Một số vấn đề quan trọng khi xác định giới hạn của các yêu cầu phần mềm:
• Thiết lập một ranh giới cho các yêu cầu cấp cao, một tập các đặc tính được đánh
chỉ mục sẽ được phân cho một phiên bản cụ thể của sản phẩm.
• Thiết lập ở mức phác thảo hiệu năng của mỗi đặc tính của ranh giới.
• Ước lượng rủi ro cho mỗi đặc tính, hay xác suất thực hiện có thể gây ra ảnh hưởng
tới lịch trình và ngân sách.
• Sử dụng các dữ liệu này, thiết lập ranh giới đảm bảo sự phân phối các đặc tính có
ảnh hưởng đến thành công của dự án.
a. Ranh giới của các yêu cầu.
65
SE-K48
Mục đích của quản lý giới hạn của các yêu cầu phần mềm là nhằm thiết lập một ranh
giới cho các yêu cầu cấp cao của dự án. Chúng ta xác định ranh giới theo: tập các đặc tính
được chia thành các chỉ mục, hay các yêu cầu sẽ được phân phối cho một phiên bản cụ thể
nào đó của ứng dụng.
Ranh giới các yêu cầu.
Ranh giới vạch ra phải:
• Ít nhất là có thể chấp nhận được đối với khách hàng.
• Có một khả năng thành công hợp lý.
Bước đầu tiên để tạo ranh giới đơn giản là liệt kê các đặc tính được định nghĩa cho
ứng dụng. Chìa khóa của bước này chính là việc điều khiển mức độ chi tiết.
b. Thiết lập mức ưu tiên.
Trong thiết lập mức ưu tiên, quan trọng là khách hàng và người dùng, quản đốc hoặc
một người đại diện nào đó, chứ không phải đội phát triển, sẽ thiết lập mức ưu tiên từ bộ
phận marketing trong nhà.
c. Định mức hiện năng.

Thiết lập mức thô cho hiệu năng mỗi đặc tính của ranh giới đã đề xuất. Chia nhóm
theo 3 mức: thấp-trung bình-cao.
d. Bổ sung yếu tố rủi ro.
Chúng ta coi xét rủi ro là xác suất việc thực hiện đặc tính sẽ gây ra tác động bất lợi
đến lịch trình và ngân sách. Rủi ro cho phép chúng ta ước đoán được tác động của việc gộp
mỗi đặc tính riêng biệt vào trong ranh giới. Một đặc tính có độ rủi ro cao có tác động rất
xấu đến dự án, dù cho tất cả các đặc tính khác được hoàn thành đúng thời hạn.
Rủi ro cũng được chia thành 3 mức như với hiệu năng.
e. Thu hẹp phạm vi.
65
SE-K48
Thông thường mức ưu tiên, hiệu năng và rủi ro không đồng nhất với nhau. Có nhiều
chỉ mục cấp thiết lại có hiệu năng thấp, nhiều chỉ mục hữu dụng lại khó thực hiện. Từ đó, ta
có thể xem xét ưu tiên cho các đặc tính, áp dụng vào các tài nguyên được cung cấp để tăng
tối đa lợi ích cho khách hàng. Có thể thêm nhân lực cho đội dự án hoặc có thể cho một số
tính năng có độ ưu tiên thấp hơn, dành nguồn lực để phát triển các tính năng tối cần thiết.
13. Trình bày phương pháp xác định các yêu cầu phần mềm từ khách hàng
Trong khi xác định yêu cầu của khách hàng, ta phải xem xét có hai dạng khách hàng:
-Khách hàng cung cấp các yêu cầu về nghiệp vụ : Cung cấp các thông tin về công ty, về các đặc
điểm ở mức độ cao, về mô hình và phạm vi của hệ thống.
-Khách hàng cung cấp các yêu cầu người sử dụng " cung cấp các thông tin về từng nhiệm vụ cụ
thể mà họ sẽ làm việc với phần mềm.
Ta cần phối hợp, kết hợp chặt chẽ với hai loại khách hàng trên
Phương pháp xác định yêu cầu của khách hàng :
-Lên lịch hẹn gặp rõ ràng khi thực hiện công việc trao đổi với khách hàng
-Tạo môi trường thân thiện với khách hàng trong khi thực hiện xác định các yêu cầu, tránh làm
cho khách hàng khó chịu trong quá trình phỏng vấn(đây là vấn đề rất nhạy cảm)
-Trong khi trao đổi với khách, cần tôn trọng các quyền lợi của khách hàng.
-Trong quá trình trao đổi, sử dụng các ngôn từ thông dụng, không sử dụng nhiều các thuật ngữ tin
học

-Cần trao đổi về công việc của khách hàng, nắm bắt, học và hiểu các công việc đó(để khi thiết kế
và xác định chức năng cho phần mềm chính xác). Yêu cầu khách hàng giải thích từng đặc điểm
công việc nếu chưa hiểu rõ để phần mềm được làm ra sẽ tốt và dễ sử dụng hơn.
-Khi xác định được các yêu cầu của khách hàng, cần thực hiện việc đánh trọng số, tức là xác định
mức độ quan trọng của từng yêu cầu khách hàng để tập trung xây dựng phần mềm hợp lý.
-Tôn trọng khách hàng, ngay cả khi phương pháp của khách hàng khác với mình, vì có thể đó là ý
tưởng mới!
-Kết thúc quá trình trao đổi, cần viết các đặc tả phần mềm
14. Trình bày các bước (quy trình) .Phân tích các yêu cầu phần mềm
Sau khi thu thập được các thông tin về yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân
tích các yêu cầu đó. Mục đích của việc phân tích này là để xác các yêu cầu đó có dư thừa, mức độ
quan trọng của các yêu cầu đó.
-Từ các yêu cầu phần mềm, ta xác định biếu đồ use case.
-Xác định các hoạt động nghiệp vụ với các điểm bắt đầu và kết thúc. Trong các chu trình này, ta
cần xác định các đối tượng tham gia, các luồng thông tin và điều khiển trong chu trình
-Xác định vấn đề của môi trường hoạt động phần mềm
-Thực hiền kết nối các yêu cầu nghiệp vụ và yêu cầu của người sử dụng
-Mô ta cụ thể chính xác các điều kiện và thuận lợi trong khi thực hiện các yêu cầu đó

15. Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm
Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm là:
1. Mã giả (Pseudocode)
2. Máy trạng thái hữu hạn (Finite state machines)
3. Cây quyết định (Decision trees)
4. Cây quyết định dạng đồ thị (Graphic decision trees)
65
SE-K48
5. Biểu đồ hoạt động (Activity diagrams (flowcharts))
6. Mô hình thực thể liên kết (Entity relationship models)
7. Phân tích hướng đối tượng (Object-oriented analysis)

8. Phân tính cấu trúc (Structured analysis)
9. Biểu đồ luồng dữ liệu (Data flow Diagrams)
16. Nêu các tiêu chí chất lượng và đo lường chất lượng yêu cầu phần mềm.
1. Tiêu chí chất lượng.
a. Các tiêu chí chất lượng đối với người sử dụng.
1) Đáp ứng (availability)
2) Hiệu quả (eficiency)
3) Mềm dẻo (flexibility)
4) Tính toàn vẹn (integrity)
5) Khả năng kết hợp vơi hệ thống (interoperability)
6) Tin cậy (realibility)
7) Khả năng kiểm soát các dữ liệu không chính xác (robustness)
8) Dễ sử dụng (usability)
b. Các tiêu chí chất lượng của phân tích viên.
1) Bảo dưỡng (maintainability)
2) Hiệu quả (portability)
3) Mềm dẻo (reusability)
4) Dễ kiểm tra (testability)
 Như vậy tổng cộng có 12 thuộc tính chất lượng, cần phải cân bằng các thuộc tính chất lượng.
2. Đo lường chất lượng yêu cầu phần mềm. Để đánh giá một yêu cầu phần mềm như thế nào
là tốt, dựa vào các đặc điểm sau.
a. Các đặc điểm đối với từng yêu cầu phần mềm.
1) Đầy đủ ( complete )
2) Chính xác (Correct)
3) Khả thi ( feasible)
4) Cần thiét ( necessary).)
5) Xếp hạng tính quan trọng và ổn định (Ranked for importance and
stability)
6) Rõ ràng.
7) Có thể kiểm tra được (Verifiable)

b. Các đặc điểm của một tài liệu đặc tả phần mềm tốt.
1) Đầy đủ.
2) Có thể sửa đổi (Modifiable)
3) Có thể thể theo dõi được (Traceable)
4) Thống nhất ( consistent)
17. Phân biệt các khái niệm kiểm thử và đánh giá các yêu cầu phần mềm.
* Kiểm thử các yêu cầu phần mềm (Testing): Việc kiểm thử yêu cầu phần mềm nhằm xác định
các yêu cầu có đáp ứng được các yêu cầu của người sử dụng không. Công việc được thực hiện
như sau:
• Viết các trường hợp kiểm thử cho các yêu cầu.
• Sử dụng mô hình hộp đen từ các trường hợp kiểm thử để đánh giá họat động hành vi của
hệ thống.
65
SE-K48
• Duyệt các hành vi và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng
yêu cầu của người sử dụng hay không.
Quy trình kiểm thử:
•Business Requirement
•Use Case
•Functional Requirement
Các công cụ sử dụng:
•Dialog Map
•Test Case
•Ma trận theo dõi các trường hợp sửdụng
* Đánh giá các yêu cầu phần mềm
Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với yêu
cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân
thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm.
Cụ thể việc đánh dựa vào các đặc điểm sau:
a. Các đặc điểm đối với từng yêu cầu phần mềm tốt.

a. Đầy đủ ( complete )
b. Chính xác (Correct)
c. Khả thi ( feasible)
d. Cần thiét ( necessary).)
e. Xếp hạng tính quan trọng và ổn định (Ranked for importance and
stability)
f. Rõ ràng.
g. Có thể kiểm tra được (Verifiable)
b. Các đặc điểm của một tài liệu đặc tả phần mềm tốt.
a. Đầy đủ.
b. Có thể sửa đổi (Modifiable)
c. Có thể thể theo dõi được (Traceable)
d. Thống nhất ( consistent)
(Có thể trả lời theo đặc tính chất lượng).
18. Quan hệ giữa yêu cầu và thực hiện. [Chưa làm]
19. Sử dụng phương pháp Traceability để kiểm thử các yêu cầu phần mềm
Yêu cầu phần mềm có tính phân cấp.
65
SE-K48
Cho nên cách tốt nhất để kiểm thử các yêu cầu phần mềm là dò vết, đi từ trên xuống dưới, theo
từng nhánh, để xem yêu cầu đã đáp ứng với mong muốn người sử dụng hay chưa. Kỹ thuật
traceability sẽ làm công việc dò vết này.
Traceability đi từ yêu cầu cao nhất ( Bessiness requirement ), đặt liên kết tới các yêu cầu liên
quan, từ yêu cầu tổng quát cho đến yêu cầu con, tạo thành một cây phân cấp. Như vậy khi tiến
hành kiểm thử sẽ kiểm thử dựa theo các nhánh trên các cây phân cấp này.
20. Hãy cho biết khái niệm ROI và phương pháp xác định ROI khi xây dựng
các yêu cầu phần mềm
( Đáp án cũ: ROI là cụm từ viết tắt của Return on Investment ( Lợi nhuận trên vốn đầu tư ).
Là 1 khái niệm trong công nghệ phần mềm. ROI là một phương pháp dùng để xác định giá trị của
đầu tư phần mềm trong từng trạng thái của sự phát triển từ khởi điểm ban đầu cho đến giai đoạn

triển khai.
ROI gồm các nhân tố sau:
Tính dễ hiểu
Tính dễ liên lạc
Liên kết với các yêu cầu của công ty
Chuẩn về công nghệ
)
Tất cả các nhân tố trên được xây dựng cho những người sử dụng ROI để định giá đầu tư
phần mềm.
Các nhà phát triển phần mềm có thể tăng lợi nhuận của dự án và nâng cao chất lượng của
phầnmềm đảm bảo đúng thời gian, đúng chi phí bằng cách giảm những yêu cầu lỗi.
65
SE-K48
Trong các phần mềm đã phát triển, chi phí bỏ ra để sửa chữa những yêu cầu lỗi là rất tốn
kém, nếu phát hiện càng muộn chi phí lại còn tốn kếm hơn. Sau đây là hình minh họa cho
chi phí sửa lỗi yêu cầu.
Như vậy để giảm bớt những chi phí này cần phải giảm bớt nguyên nhân yêu cầu sai bằng
việc quản lý yêu cầu thật hiệu quả.
Vốn đầu tư: chi phí để quản lý yêu cầu hiệu quả.
Lợi nhuận: Chi phí thu được do không phải sửa các yêu cầu sai.
ROI=Lợi nhuận/Vốn đầu tư.
What Does Return On Investment - ROI Mean?
A performance measure used to evaluate the efficiency of an investment or to compare
the efficiency of a number of different investments. To calculate ROI, the benefit (return)
of an investment is divided by the cost of the investment; the result is expressed as a
percentage or a ratio.
The return on investment formula:
Return on investment is a very popular metric because of its versatility and simplicity.
That is, if an investment does not have a positive ROI, or if there are other opportunities
with a higher ROI, then the investment should be not be undertaken.

Investopedia explains Return On Investment - ROI
Keep in mind that the calculation for return on investment and, therefore the definition,
can be modified to suit the situation -it all depends on what you include as returns and
costs. The definition of the term in the broadest sense just attempts to measure the
profitability of an investment and, as such, there is no one "right" calculation.
For example, a marketer may compare two different products by dividing
the revenue that each product has generated by its respective marketing expenses. A
financial analyst, however, may compare the same two products using an entirely
65
SE-K48
different ROI calculation, perhaps by dividing the net income of an investment by the
total value of all resources that have been employed to make and sell the product.
This flexibility has a downside, as ROI calculations can be easily manipulated to suit the
user's purposes, and the result can be expressed in many different ways. When using this
metric, make sure you understand what inputs are being used.
21. Kỹ thuật quản lý thay đổi yêu cầu phần mềm
Một điều rõ ràng rằng, thay đổi là một phần tấp yếu của quá trình xây dựng yêu cầu phần
mềm, thay đổi có thể đến từ bên trong hoặc bên ngoài, vì vậy quản lý thay đổi là cần
thiết.
1.Thay đổi là không thể tránh được , đặt kế hoạch cho nó
2.Vạch ranh giới cho yêu cầu
3.Thiết lập một kênh đơn để điều khiển thay đổi
4.Sử dụng hệ thống điều khiển thay đổi để bắt các thay đổi
5.Quản lý thay đổi một cách phân cấp
(
Recognize that change is inevitable, and plan for it.
Baseline the requirements.
Establish a single channel to control change.
Use a change control system to capture changes.
Manage change hierarchically.

Sách Manaing software requirements)
)
Thay đổi yêu cầu phần mềm có tính phân cấp, có nghĩa là thay đổi một yêu cầu ở mức
trên sẽ kéo theo những yêu cầu mức dưới.
65
SE-K48
Do đó cần phải theo vết các thay đổi, để biết thay đổi nào dẫn đến thay đổi nào, khi có thay đổi
cần phải thông báo cho những ai. Kỹ thuật ma trận theo dõi yêu cầu phần mềm có thể đạt được
mục đích như vậy
Quá trình lập ma trận như sau:
(1)Xác định các mối liên kết và các khả năng lập ma trận
(2) Chọn dạng ma trận: tổng hợp hay chi tiết
(3) Chọn các chức năng/ các yêu cầu cần theo dõi
(3) Xác định phương pháp gán nhãn các yêu cầu
(4) Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liênkết
(5) Thông báo cho những người tham gia về sự liên kết
(6) Kiểm soát sự liên kết trong quá trình phá triển phần mềm
22. Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm
Mô tả hoàn chỉnh ứng xử của hệ thống đã phát triển , bao gồm tập các trường hợp
sử dụng ( use cases ) mô tả mọi tương tác người dùng với phần mềm . Ngoài ra SRS còn
chưa các yêu cầu bổ sung ( các yêu cầu ép ràng buộc lên thiết kế hoặc triển khai như hiệu
suất , chất lượng…)
23. Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm
Là hiểu biết hệ thống của khách hang vào thời điểm thiết kế và phát triển phần mềm. Đó
là hợp đồng đảm bảo về cả khách hang và sự hiểu biết hệ thống,các nhu cầu khác trước
khi ấn định thời điểm.
65
SE-K48
24. Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU)
-Giao diện

-Chức năng
-Cơ sở dữ liệu
-Bảo mật
-Chất lượng
-Hạn chế.
25. Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm
• Làm theo và sử dụng các mẫu đặc tả (ví dụ IEEE 830-1998)
• Xác định rõ các nguồn gốc của yêu cầu phần mềm trong đặc tả
• Đặt nhãn cho các yêu cầu phần mềm
• Ghi lại các nguyên tắc công việc
• Tạo ma trận theo dõi phần mềm
26. Nêu phương pháp và kỹ thuật kiểm duyệt (review) lại các yêu cầu đã xây
dựng
• Lập kế hoạch
• Các buổi họp mặt
• Chuẩn bị
• Các buổi họp duyệt
• Làm sửa đổi
• Kết thúc
Công cụ sử dụng, mẫu sử dụng
• Các tiêu thức đánh giá
• Requirement Inspection Checklist
27. Kiểm thử (testing) yêu cầu phần mềm
Kiểm thử yêu cầu phần mềm là công việc thực hiện lại sau khi có được các yêu cầu phần
mềm từ phía NSD, chủ dự án…Qúa trình này là một quá trình cân nhắc về khả năng đáp
ứng lại yêu cầu phần mềm do những hạn chế về nhân lực, thời gian và tài chính của đội
ngũ phát triển phần mềm.
Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của phần
mềm, ảnh hưởng đến kiến trúc hệ thống.
Nhìn chung kiểm thử phần mềm là một quá trình kiểm tra các yêu cầu phần mềm, từ đó

đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên
là người sử dụng và người phát triển hệ thống.
Tại sao phải kiểm thử yêu cầu phần mềm:
65
SE-K48
- Do tính chất 2 mặt của yêu cầu phần mềm: Cách nhìn và suy nghĩ về phần mềm
từ phía người sử dụng và cách nhìn, suy nghĩ về phần mềm từ phía nhà phát triển.
- Người sử dụng đưa ra những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình
phát triển phần mềm
- NSD đưa ra các yêu cầu và đề nghị rất khó chấp nhận là gây khó khăn cho các lập
trình viên
- NSD đưa ra các yêu cầu nhập nhằng và mơ hồ, quá trình kiểm thử sẽ có trách
nhiệm làm rõ các yêu cầu này.
- Phát hiện các đặc tính thừa do người phát triển hệ thống đưa thêm vào hoặc các
yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thiết
- Kiểm tra khả năng đáp ứng về mặt kỹ thuật
- Đặc tả rõ ràng và chi tiết các yêu cầu
Tiêu chí kiểm thử yêu cầu phần mềm
- Hoàn thiện
- Chính xác
- Khả thi
- Cần thiết
- Rõ ràng
- Kiểm tra được, xác minh được
Quy trình kiểm thử yêu cầu phần mềm:
• Bussiness Requirement
• Use Case
• Functional Requirement
Các công cụ sử dụng:
• Dialog Map

• Test Case
• Ma trận theo dõi các trường hợp sử dụng
28. Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm
(theo slide mới phần 1.4. Khác với 9 thuộc tính chất lượng của IEEE ??? )
Các đặc tính chất lượng đối với người sử dụng
• Availability
• Efficiency
• Flexibility
• Integrity
• Interoperability
• Realibility
• Robustness
• Usability
Các đặc tính chất lượng đối với PTV:
• Maintainability