Mục lục


CHƯƠNG I. TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM VÀ QUY TRÌNH
1. Các quan điể m khác nhau trong đinh ngḥia về yêu cầ u phầ n mề m. Đinh ngḥia ̃
chuẩn theo IEEE.
<bai tap tuan 1> or slide
2. Hãy nêu bản chất của yêu cầu phần mềm. Nêu định nghĩa yêu cầu phần mềm
nhìn từ phía khách hàng
 Bản chất
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).

 Định nghĩa từ 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)
3. 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


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ì.
4. Nêu các thuôc tính chất lương của yêu cầu phần mề m. Quan hê ̣ giữa các thuôc
tính chất lương.
5. Nêu các phương pháp phân loai yêu cầ u phầ n mềm. Phân tích đăc điể m của

từng phân loai
6. Mô tả Quy trình công nghệ học yêu cầu phần mềm (Requirement Engineering


Process)
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.

- 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:

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.
7. Nêu vai trò của từng tác nhân trong yêu cầu phần mề m. Ảnh hưởng của các tác

nhân đến các thuôc tính chất lương yêu cầ u phần mềm
CHƯƠNG II. PHÁT HIỆN, TỔNG HỢP VÀ PHÂN TÍCH CÁC YÊU CẦU PHẦN
MỀM và CHƯƠNG III. ĐẶC TẢ CÁC YÊU CẦU PHẦN MỀM
1. Trình bày quy trình, kỹ thuật và nội dung cần hoàn thành 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.


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.
2. Nêu các phương pháp để phát hiên yêu cầu phần mềm và nguồn gốc yêu cầ u
phần mềm
3. So sánh đánh giá các kỹ thuât phát hiên yêu cầ u phần mềm

 Phương pháp phỏng vấn
 Phương pháp bảng hỏi
 Phương pháp quan sát
 Phương pháp nghiên cứu tài liệu và các
phần mềm tương ứng
<Xem bai tập tuần 2> or slide
4. 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 (Interviewing customers and
domain experts)
Đặ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
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 Bảng hỏi (Questionnaires).
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.
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 Nghiên cứu tài liệu và các Hệ thống phần mềm tương tự (Study of
documents and software systems)


Các thông tin mang lại
 Các vấn đề còn tồn đọng trong hệ thống

 Các cơ hội tiếp cận nhu cầu mới
 Phương hướng tiếp cận có thể tác động đến yêu cầu của HTTT
 Lí do tồn tại của hệ thống hiện hành
 Tìm ra tên và vị trí của những cá nhân có liên quan tới hệ thống. Giúp cho việc giao
tiếp, liên lạc đúng mục tiêu hơn
 Dữ liệu cấu trúc, quy tắc xử lí dữ liệu
Những hạn chế
 Thiếu tài liệu
 Tài liệu hết hạn
 Các tài liệu cũng là nguồn cung cấp thông tin không đúng, trùng lặp
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 đề.
• Khuyến khích các ý tưởng, suy nghĩ sáng tạo, độc đáo.
Quy định:
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 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.
9. Nêu các phương pháp phân nhóm yêu cầu phần mề m. Muc đích của phân

nhóm. Đánh giá kết quả phân nhóm.
10. Nêu các phương pháp mô hình hó a các yêu cầ u phầ n mề m.
11. 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. Nêu các kỹ

thuật áp dụng trong 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 đó
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)

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)
12. Trình bà y kỹ thuât thương lư ơng và thỏ a thuân yêu cầ u phần mềm. Đánh giá
quan hê ̣ giữa các tiêu chí "chất lương", "thời gian thưc hiên" trong thương
lương. ̣
13. Mô tả ngắn gọn cấu trúc của Tài liệu đặc tả yêu cầu phần mềm theo chuẩn

IEEE830-1998. 14. Nêu các kỹ thuật gán nhãn các yêu cầu phần mềm theo chuẩn
IEEE830-1998.
Nôi dung gồm có 6 phần:


1. Giới thiệu chung
1.1 Mục đích
1.2 Tài liệu thỏa thuận
1.3 Đối tượng đự định và đề xuất đọc
1.4 Phạm vi dự án
1.5 Tài liệu tham khảo.
2. Mô tả hệ thống
2.1 Quan điểm sản phẩm
2.2 Đặc tính sản phẩm
2.3 Các lớp và đặc điểm của user
2.4 Môi trường hoạt động
2.5 Thiết kế và các hạn chế thực hiện
2.6 Tài liệu người dung
2.7 Giả định và phụ thuộc
3. Tính năng hệ thống
3.1 Mô tả và ưu tiên
3.2 Trình tự kích thích/phản hồi

3.3 Yêu cầu chức năng
4. Yêu cầu giao diện bên ngoài
4.1 Giao diện người dung
4.2 Giao diện phần cứng
4.3 Giao diện phần mềm
4.4 Giao diện truyền thông
5. Yêu cầu không có chức năng khác
5.1 Các yêu cầu hiệu suất
5.2 Các yêu cầu an toàn
5.3 Các yêu cầu bảo mật
5.4 Thuộc tính chất lượng phầm mềm.
6. Yêu cầu khác

CHƯƠNG IV. DUYỆT VÀ KIỂM SOÁT CÁC YÊU CẦU PHẦN MỀM
1. Phân biệt hai khái niệm: Requirements Verification and Requirements
Validation. Làm rõ sự khác biệt của các khái niệm này.
 Requirements Verification (Xác nhận):
Kiểm tra xem đúng là sản phẩm khách hàng yêu cầu đang được xây dựng không .
Đảm bảo rằng các phần mềm đang được phát triển ( hoặc thay đổi) sẽ làm hài lòng
tất cả các bên liên quan hay là được thẩm định bởi các bên liên quan tới sản phẩm.
Kiểm tra tính nhất quán của các đặc tả yêu cầu của các sản phẩm phần mềm đang
phát triển ( thiết kế, thực hiện,...) đối với các đặc tả kĩ thuật.
Chiếm khoản 20% khối lượng công việc nhưng có vai trò hết sức quan trọng hiệu
quả đôi lúc chiếm phần lớn hiệu quả chung do có liên quan tới khách hàng.


- Validation là điều kiện Đủ.
 Requirements Validation (Kiểm chứng)

Kiểm tra xem việc xây dựng sản phẩm đó có thực hiện đúng không, có chạy chính

xác không.
Phải đảm bảo rằng mỗi bước tiếp theo trong quá trình xây dựng phần mềm sẽ
mang đến những sản phẩm phù hợp.
Kiểm tra các đặc tả yêu cầu phần mềm đối với yêu cầu và mục tiêu của các bên
liên quan.
- Chiếm 80% công việc, ảnh hưởng trực tiếp tới chất
lượng của sản phẩm.
- Verification là điều kiện Cần.
2. Nêu các phương pháp xem xét lai yêu cầ u phầ n mề m. Những tác nhân nào
tham gia vào xem xét lai yêu cầ u phầ n mề m.

3. Trình bày kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Simple Check: Quy

trình thực hiện, Khi nào áp dụng, những tác nhân tham gia thực hiện, Các mẫu
văn bản điển hình.
Quy trình thực hiện:
1 . Kiểm tra nguồ gốc yêu cầu phần mềm
+ Các yêu cầu phần mềm chúng ta miêu tả phải đúng với những yêu cầu của khách
hàng.
+ Theo dõ dấu vết của mộ yêu cầu phần mềm (Tracing Requirement)
2. Kiểm tra lại ma trận theo dõ các yêu cầu phần mềm (Requirement Traceability
Matrix)
+ Đảm bảo các yêu cầu phần mềm phải được xem xé, nếu không xem xé thì phải
có lí do
+ Đảm bảo tất cả các tài liệu đặc tả phải hợp lý.
3. Kiểm tra các yêu cầu phần mềm được trình bày tốt theo các tiêu chí đã được thảo
luận, kiểm soát tính chính xác, tính không trùng lặp của các yêu cầu phần mềm
Áp dụng tại: Các tài liệu yêu cầu phần mềm vừa được lập xong
Tác nhân tham gia: Người lập xong các tài liệu yêu cầu phần mềm và kiểm tra lại.
Mẫu văn bản điển hình:

+ Tài liệu đặc tả yêu cầu phần mềm
+ Ma trận theo dõ các yêu cầu phần mềm
4. Trình bày kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Prototyping: Quy

trình thực hiện, Khi nào áp dụng, những tác nhân tham gia thực hiện, công cụ
điển hình.
Là phương pháp tốt cho việc xác nhận của người sử dụng hay khách hàng.


 Rất dễ để tiếp cận.
 Dễ dàng giúp các bên liên quan phát hiện ra vấn đề để giải quyết.
 Phong phú và đủ thể loại tư những hệ thống nhỏ đến các hệ thống vô cùng lớn.
 Có xu hướng phát triển lớn.
Quá trình thực hiện:
 Chọn thử nghiệm nguyên mẫu
 Phát triển các kịch bản thử nghiệm
 Lập kế hoạch cẩn thận là rất cần thiết để xây dựng mộ tập hợp các kịch bản thử nghiệm
cung cấp vùng hoạt độg rộg rãi cho các yêu cầu.
 Ngườ sử dụng không nên chỉ sử dụng xung quanh hệ thống vì có thể sẽ không bao giơ
thực hiện các tính năng hệ thống quan trọng
 Thực hiện các kịch bản thử nghiệm
 Viết tài liệu bằng cách sử dụng công cụ báo cáo vấn đề
Trường hợp sử dụng: Sử dụng để lựa chọn kịch bản hoặc trường hợp sử dụng cho phiên
gợi mở.
Nguyên liệu đánh giá :
 Tài liệu nguồ
 Danh sách kiểm tra
 Tài liệu hỗ trợ
 Thư mờ
 Kế hoạch tổng thể

 Issue/Defect Log
 Thông tin dữ liệu tóm tắt

5. Trình bày kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Reviews and

Inspections. Quy trình thực hiện, Khi nào áp dụng, những tác nhân tham gia
thực hiện, Các công cụ điển hình.
Đồng bộ
+ Phương pháp tiếp cận truyền thống
+ Dựa trên cuộc họp


Không đồng bộ
+ Tương đối mới
+ Thay thế họp mặt bằng liên lạc thư điện tử.
Phương pháp đánh giá đồng bộ
Bước 1 : Lên kế hoạch / tổng quan
Lựa chọn ngườ đánh giá
Phân công vai trò
Phân phối tài liệụ
Thảo liệu công việc đánh giá chung
Leader:
 Quản lý kiểm tra
 Hành xử như ngườ điều hành viên
 Xác định / mờ ngườ đánh giá
 Ngườ chỉ định vai trò
 Phân phối tài liệu
 Sắp xếp thờ gian, địa điểm gặp mặt
Author:
 Tạo ra các tài liệu để đánh giá

 Giúp trả lờ câu hỏi
 Thườg không trực tiếp tham gia đánh giá
 Chỉnh sửa tài liệu nếu cần thiết
Inspector / Reviewer:
 Làm quen tài liệu đúng thờ gian
 Đánh giá tài liệu cho các khiếm khuyết
 Tìm kiếm các khiếm khuyết (nếu có)
 Sử dụng các danh sách hoặc tài liệu hỗ trợ khác.
 Liên hệ sớm với lãnh đạo nếu có vướng mắc hoặc việc đánh giá có thế là mộ sự lãng
phí thờ gian


Scibe / Recorder:
 Ghi lại các vấn đề được nêu lên
 Tốt nhất không phải là điều hành viên hay ngườ đánh giá
 Ghi lại thông tin rõ rang
Bước 2: Chuẩn bị
 Ngườ đánh giá làm quen với các tài liệu được đánh giá
 Cần phải quen với các tài liệu kịp thờ gian cho cuộ họp đánh giá
Bước 3: Họp đánh giá, kiểm tra
 Nhóm đánh giá cố gắng xác định các khiếm khuyết
 Các khiếm khuyết không có định vào thờ điểm này
 Cuộ hợp kéo dài ít hơn 2 giơ
 Cách tiếp cận vòng tròn hoặc tiếp cận đọc (Reader approach)
 Ngườ ghi chép ghi lại tất cả các vấn đề
+ Vị trí xác định khiếm khuyết
+ Lý do tại sao đó là khiếm khuyết (trích dẫn yêu cầu hoặc danh sách kiểm tra)
+ Mức đô nghiêm trọng (Lớn, nhỏ)
+ Không ghi lại tên ngườ đánh giá khiếm khuyết
+ Cố gắng để hiển thị cho tất cả ngườ tham gia (tránh trùng lặp)

Bước 4: Làm lại
 Tác giả nhận bản ghi khiếm khuyết
 Xác định các khiếm khuyết thực sư và “false positives”
 Sửa chữa khiếm khuyết, cung cấp các biện minh cho “false
positives”
Bước 5: Theo dõi
 Lãnh đạo xác minh các khiếm khuyết đã được giải quyết
 Quyết định nếu văn bản qua được buổi đánh giá hoặc cần thêm
buổi đánh giá khác


Phương pháp đánh giá không đồng bộ
 Ưu điểm: Sức mạnh tổng hợp. Giáo dục. Dự kiến thời hạn. Cạnh tranh. Hạn chế tối đa
“false positves”,
 Nhược điểm:Chi phí (mất thờ gian sản xuất so với chi phí của khiếm khuyết). Khó
khăn trong lập trình thờ
gian, địa điểm cho khách đánh giá trên diện rộg
 Formal, Technical, Asynchronous Review Method
(FTArm): Phương pháp đánh giá chính thức, kỹ thuật, không đồg bộ
Phát triển bởi Philip Johnson tại Đại học Hawaii
+ Giai đoạn 1 : Chọn nhân sự và tổ chức tài liệu
+ Giai đoạn 2: Định hướng của ngườ tham gia tới nhiệm vụ được
giao
+ Giai đoạn 3: Đánh giá cá nhân
+ Giai đoạn 4: Xem xét hô sơ
+ Giai đoạn 5: Củng cố
 Thông tin liên lạc không được thực hiện trong cuộ họp truyền
thống
+ Email
+ Thông báo hộ đồg quản trị.

CHƯƠNG V. CÁC KỸ THUẬT NÂNG CAO CHẤT LƯỢNG YÊU CẦU PHẦN
MỀM
1. Phân tích các thà nh phầ n trong ma trân vết yêu cầ u phầ n mề m. Vai trò của
ma trân ̣ trong theo dõi các 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
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.

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

2. Phân tích vai trò của các tác nhân ảnh hưởng đến quá trình quản lý yêu cầu

phần


3. Mô tả ngắn gọn các kỹ thuật trong quản lý yêu cầu phần mềm: Change Control

(Kiểm soát thay đổi), Kiểm soát phiên bản (Version Control), Theo dõi trạng thái
cầu phần mềm (Requirements status Tracking), Theo dõi vết yêu cầu
(Requirements Tracing).
Change Control (Kiểm soát thay đổi):
 Đề xuất thay đổi
 Phân tích tác động
 Ra quyết định
 Cập nhật các văn bản yêu cầu
 Cập nhật kế hoạch
 Đo lường sự biến động yêu cầu
Kiểm soát phiên bản (Version Control):
 Xác định sơ đồ xác định phiên bản
 Xác định yêu cầu tài liệu phiên bản
 Xác định các phiên bản yêu cầu riêng
Theo dõi trạng thái cầu phần mềm (Requirements status Tracking):
 Xác định trạng thái yêu cầu có thể
 Ghi lại tình trạng của từng yêu cầu
 Báo cáo sự phân bố trạng thái của tất cả các yêu cầu
Theo dõi vết yêu cầu (Requirements Tracing):
 Xác định liên kết đến các yêu cầu khác
 Xác định liên kết đến các yếu tố hệ thống khác
4. Mô tả bản chất và nội dung công việc trong Truy hồi (theo dõi vết) yêu cầu phần
mềm. Nêu các phương pháp theo dõi vết của yêu cầu phần mềm.

-Tính năng truy xuất nguồn gốc đề cập đến khả năng mô tả và thực hiện vòng đời
của yêu cầu, cả về phía trước lẫn phía sau (tức là từ nguồn gốc, thông qua sự phát
triển và đặc điểm kỹ thuật của nó, triển khai và sử dụng, và thông qua tất cả các
giai đoạn của sàng lọc liên tục và lặp lại trong bất kỳ giai đoạn nào) ".
- Một đặc tả yêu cầu phần mềm có thể được theo dõi nếu nguồn gốc của mỗi
Yêu cầu của nó là rõ ràng và nếu nó tạo điều kiện cho việc tham khảo của mỗi
Yêu cầu trong quá trình phát triển trong tương lai hoặc tài liệu nâng cao.
- Truy xuất nguồn cung cấp cho sự hỗ trợ thiết yếu trong việc hiểu các mối quan
hệ
Tồn tại trong và ngoài yêu cầu phần mềm, thiết kế, và thực hiện
- Một liên kết hoặc mối quan hệ được xác định giữa các thực thể
5. Nêu một số kỹ thuật quản lý thay đổi yêu cầu phần mềm

Lý do thay đổi yêu cầu phần mềm .
Các tác nhân bên ngoài: thay đổi vấn đề, người sử dụng thay đổi quyết định của mình,
môi trường bên ngoài thay đổi, hệ thống mới tồn tại. .
Các tác nhân bên trong: chúng ta đã không hỏi những người đúng các câu hỏi đúng tại
thời gian đúng trong suốt quá trình tập hợp yêu cầu ban đầu. Chúng ta đã không tạo ra


một tiến trình thực hành để giúp đỡ việc quản lý thay đổi yêu cầu mà thông thường
xảy ra theo chiều hướng tăng tiến.
Quá trình để quản lý thay đổi:
1.Đoán nhận những thay đổi tất yếu, và lên kế hoạch xử lý nó..
2.Thiết lập ranh giới các yêu cầu.
3.Thiết lập một kênh đơn để kiểm soát sự thay đổi..
4.Sử dụng một hệ điều khiển thay đổi để nắm bắt những thay đổi..
5.Quản lý sự thay đổi theo phân cấp.
Quản lý Cấu hình các yêu cầu :
1. Ngăn ngừa những yêu cầu không hợp pháp và các phá hoại tiềm tàng hay những

yêu cầu thay đổi linh tinh.
2. Bảo đảm việc duyệt lại những tài liệu về yêu cầu.
3.Làm thuận tiện việc lấy lại và/ hoặc xây dựng lại những phiên bản trước của tài liệu.
4. Hỗ trợ quản lý, tổ chức ranh giới “giải thoát kế hoạch” cho những cải tiến hoặc cập
nhập ngày càng tăng của hệ thống.
5.Ngăn chặn đồng thời việc cập nhật tài liệu hay xung đột và không cho phép cập