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

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. 34
Chương 2. Thiết kế phần mềm (Software Design) 36
1.Nêu quy trình thiết kế phần mềm mức Logic 36
2. Các phương pháp tạo các thiết kế mức logic (Logical Design) 36
3. Đặc tả tài liệu thiết kế mức logic 36
4. Kiểm thử và tối ưu thiết kế mức logic 37
5. Quá trình mô hình hóa dữ liệu mức logic 37
6. Quá trình và các phương pháp tạo các thiết kế mức vật lý 38
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 38
8. Nêu các hướng tiếp cận xây dựng kiến trúc phần mềm 39
9. Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability, 43
Performance, Security, Testability, Usability 43
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. 44
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. 45

32. Quá trình mô hình hóa dữ liệu mức Logic 55
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ế 55
35. Nêu các đặc điểm trong giai đoạn ổn định và giai đoạn triển khai 56
36. Các yêu cầu của đặc tả phần mềm 56
37. Định dạng đặc tả phần mềm: Các loại tài liệu 57
38. Các quy định chung về định dạng đặc tả 57
39. Một số kỹ thuật chính trong thiết kế đặc tả 57
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 58
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. 58
41. Các chức năng của EA giúp thiết kế phần mềm mức Logic 59
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. 59
Chương 3. Xây dựng phần mềm (Software Construction) 59
Câu 1:Trình tự thiết kế chi tiết 59
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 59
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 60
Câu 4: Thiết kế dữ liệu vật lý 60
Câu 5: Nêu tên các tài liệu thiết kế chi tiết 61
Câu 6: Nêu tổ chức các tài liệu thiết kế chi tiết 61
65
SE-K48
7. Nêu các biểu mẫu thiết kế màn hình [Không chắc chắn]: 63
8. Nêu các biểu mẫu thiết kế báo cáo [Không chắc chắn]: 63
9. Nêu các phương pháp xét duyệt thiết kế chi tiết 63
10. Nêu trình tự thiết kế chương trình 63
11. Nêu các tiêu chuẩn thiết kế chương trình 64
12. Nêu các tiêu chuẩn phân chia module 64
13.[Thiếu] 65

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

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

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 để

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

- 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 đề.
• Khuyến khích các ý tưởng, suy nghĩ sáng tạo, độc đáo.
Quy định:
65
SE-K48
 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.

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,

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.
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
65
SE-K48
đượ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.

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)
5. Biểu đồ hoạt động (Activity diagrams (flowcharts))
6. Mô hình thực thể liên kết (Entity relationship models)
65
SE-K48
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)

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.
• 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.
65
SE-K48
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)

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,

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

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