Báo cáo bài tập tuần: Phân tích yêu cầu phần mềm - Nhóm 3

Chia sẻ: Cau Be | Ngày: | Loại File: DOCX | Số trang:14

Thêm vào BST

Báo xấu

282
lượt xem 59
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Báo cáo bài tập tuần: Phân tích yêu cầu phần mềm - Nhóm 3 có kết cấu trình bày về Phân biệt Requirements Verification và Requirements Validation, kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Simple Check, kỹ thuật duyệt và kiểm soát yêu cầu phần mềm prototyping, kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Functional test design,... Mời các bạn tham khảo để nắm bắt nội dung bài báo cáo cụ thể hơn.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Báo cáo bài tập tuần: Phân tích yêu cầu phần mềm - Nhóm 3

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ––––––––––––––––––––––––*–––––––––––––––––––––– Báo cáo bài tập tuân ̀ Môn học: Phân tich yêu câu phân mêm ́ ̀ ̀ ̀ Tuân 4 :DUYỆT VÀ KIỂM SOÁT YÊU CẦU PHẦN MỀM ̀ ́ Nhom 3 Danh sách sinh viên: ́ Lê Trung Hiêu 20111568 CNTT-TT 2.3 K56 ̀ ̀ Đam Văn Hoai 20111600 CNTT-TT 2.3 K56 Nguyên Đức Cương ̃ 20111203 CNTT-TT 2.3 K56 ̀ ̣ Đoan Văn Đat 20111370 CNTT-TT 2.3 K56 Giảng viên: PGS.TS. Huynh Quyêt Thăng ̀ ́ ́ Hà Nội Ngày 16 tháng 5 năm 2014 Phân tích yêu cầu phần mềm. Tuần 4. Page 1
Mục lục Phân tích yêu cầu phần mềm. Tuần 4. Page 2
1. Phân biêt Requirements Verification và Requirements Validation ̣ 1.1. Phân biệt - Requirements Validation (Xac nhân yêu câu) ́ ̣ ̀ Đây là viêc kiêm tra răng có phai môt san phâm đung đang được xây ̣ ̉ ̀ ̉ ̣ ̉ ̉ ́ dựng hay không. Cân chăc chăn răng san phâm đang xây dựng (hay nâng ̀ ́ ́ ̀ ̉ ̉ câp) sẽ lam thoa man cac bên liên quan. Điêu nay được tiên hanh băng viêc ́ ̀ ̉ ̃ ́ ̀ ̀ ́ ̀ ̀ ̣ đôi chiêu lai ban đăc tả yêu câu phân mêm với muc tiêu và yêu câu cua cac ́ ́ ̣ ̉ ̣ ̀ ̀ ̀ ̣ ̀ ̉ ́ bên liên quan. - Requirement Verification (Kiêm chứng yêu câu) ̉ ̀ Đây là viêc kiêm tra răng có phai môt san phâm đang được xây dựng ̣ ̉ ̀ ̉ ̣ ̉ ̉ đung hay không. Cân chăc chăn răng môi bước được cho phep trong quá ́ ̀ ́ ́ ̀ ̃ ́ trinh xây dựng phân mêm đêu mang lai lợi ich cho viêc xây dựng san phâm ̀ ̀ ̀ ̀ ̣ ́ ̣ ̉ ̉ đung. Viêc nay được tiên hanh thông qua đôi chiêu đôi tượng được tao ra ́ ̣ ̀ ́ ̀ ́ ́ ́ ̣ theo ban đăc tả yêu câu phân mêm với ban đăc tả đo. ̉ ̣ ̀ ̀ ̀ ̉ ̣ ́ Sự khac nhau của hai công việc trên chính là ở vai trò của bản đặc tả ́ yêu cầu phần mềm. Với xác nhận yêu cầu, bản đặc tả yêu cầu ph ần mềm được kiểm tra xem có phản ánh chính xác các yêu cầu của nh ững bên liên quan hay không. Còn với kiểm chứng yêu cầu, bản đ ặc t ả yêu cầu được dùng làm mẫu để đánh giá phần mềm đang xây dựng có phù hợp hay không. Phân tích yêu cầu phần mềm. Tuần 4. Page 3
Cac so sanh cụ thê: ́ ́ ̉ ́ Xac nhân yêu câu ̣ ̀ Kiêm chứng yêu câu ̉ ̀ (Requirements Validation) (Requirements Verification) Xac nhân yêu câu là cac thủ tuc kiêm tra đông (thay ́ ̣ ̀ ́ ̣ ̉ ̣ Kiêm chứng yêu câu là cac thủ tuc kiêm tra tinh (có ̉ ̀ ́ ̣ ̉ ̃ đôi theo diên biên cua dự an, tuy vao cac bên liên ̉ ̃ ́ ̉ ́ ̀ ̀ ́ cac quy tăc cho săn để ap dung), có tac dung ngăn ́ ́ ̃ ́ ̣ ́ ̣ quan), có tac dung để sửa chữa đăc tả yêu câu ́ ̣ ̣ ̀ ngừa sự sai khac cua phân mêm với đăc tả ́ ̉ ̀ ̀ ̣ Là quá trinh mang tinh chủ quan cua cac bên liên ̀ ́ ̉ ́ Là quá trinh mang tinh khach quan, cac tiêu chuân kĩ ̀ ́ ́ ́ ̉ quan, phụ thuôc rât nhiêu vao đanh giá cua người ̣ ́ ̀ ̀ ́ ̉ thuât được ap dung để so sanh san phâm với đăc tả ̣ ́ ̣ ́ ̉ ̉ ̣ dung ̀ Khi phat hiên lôi, cân sửa chữa đăc tả (chi phí thâp ́ ̣ ̃ ̀ ̣ ́ Khi phat hiên lôi, viêc sửa chữa tôn it chi phí ́ ̣ ̃ ̣ ́ ́ nêu chưa tao ra san phâm), nêu san phâm đã được ́ ̣ ̉ ̉ ́ ̉ ̉ tao ra thì chi phí khăc phuc rât cao ̣ ́ ̣ ́ 1.2. Anh hưởng của Xác nhận yêu cầu (Requirements Validation) ̉ Xác nhận yêu cầu là công việc quan trọng trong quá trình phân tích và đặc tả yêu cầu phần mềm. - Những anh hưởng của Xác nhận yêu cầu: ̉ + Việc xác nhận yêu cầu giúp cho các yêu cầu đ ược đ ặc t ả luôn ph ản ánh đúng nguyện vọng của các bên liên quan. Các khách hàng, người dùng được cung câp ban chay được cua phân mêm và được dung thử để xem đã ́ ̉ ̣ ̉ ̀ ̀ ̀ đap ứng được đung yêu câu cua minh chưa. Nêu có bât cứ phat hiên nao, ́ ́ ̀ ̉ ̀ ́ ́ ́ ̣ ̀ cac lôi đó sẽ được thông bao cho người phat triên để chinh sửa. Viêc nay ́ ̃ ́ ́ ̉ ̉ ̣ ̀ đam bao khi san phâm được tao ra sẽ đap ứng đung yêu câu người dung, và ̉ ̉ ̉ ̉ ̣ ́ ́ ̀ ̀ được châp nhân. ́ ̣ + Viêc xac nhân yêu câu tao ra sự nhât tri, tin tưởng giữa cac bên liên ̣ ́ ̣ ̀ ̣ ́ ́ ́ quan, tao đinh hướng thông nhât cho giai đoan thiêt kê, viêt mã nguôn hệ ̣ ̣ ́ ́ ̣ ́ ́ ́ ̀ thông. ́ + Lôi cua quá trinh Xac nhân yêu câu phat hiên ra dân đên sự thay đôi ̃ ̉ ̀ ́ ̣ ̀ ́ ̣ ̃ ́ ̉ cua ban đăc tả yêu câu phân mêm, dân đên môt loat phan ứng dây chuyên, ̉ ̉ ̣ ̀ ̀ ̀ ̃ ́ ̣ ̣ ̉ ̀ lam thay đôi từ khâu phân tich thiêt kế tới viêt mã nguôn. ̀ ̉ ́ ́ ́ ̀ 1.3. Anh hưởng cua Kiêm chứng yêu câu (Requirements Verification) ̉ ̉ ̉ ̀ Kiêm chứng yêu câu phân mêm được tiên hanh thiêt kế và lâp trinh san ̉ ̀ ̀ ̀ ́ ̀ ́ ̣ ̀ ̉ ̉ phâm phân mêm ̀ ̀ - Những anh hưởng cua Kiêm chứng yêu câu: ̉ ̉ ̉ ̀ + Kiêm chứng yêu câu giup phân mêm được tao ra đung với đăc tả cua ̉ ̀ ́ ̀ ̀ ̣ ́ ̣ ̉ yêu câu phân mêm. Nêu phat hiên ra lôi, những nhà phat triên phân mêm se ̃ ̀ ̀ ̀ ́ ́ ̣ ̃ ́ ̉ ̀ ̀ được thông bao để sửa chữa, do đó đam bao răng khi phân mêm được hoan ́ ̉ ̉ ̀ ̀ ̀ ̀ thanh thì nó sẽ phù hợp với cac đăc tả yêu câu. ̀ ́ ̣ ̀ + Viêc kiêm chứng yêu câu giup rà soat lôi cua những người thiêt kê, ̣ ̉ ̀ ́ ́ ̃ ̉ ́ ́ lâp trinh, qua đó nâng cao ý thức lam viêc cân trong, nghiêm tuc cua đôi ngũ ̣ ̀ ̀ ̣ ̉ ̣ ́ ̉ ̣ ́ ̉ phat triên phân mêm ̀ ̀ Phân tích yêu cầu phần mềm. Tuần 4. Page 4
+ Trong giai đoan thiêt kê, Kiêm chứng yêu câu giup điêu chinh những ̣ ́ ́ ̉ ̀ ́ ̀ ̉ ban thiêt kế hệ thông môt cach chinh xac, tôi ưu. Cac lôi tao ra được điêu ̉ ́ ́ ̣ ́ ́ ́ ́ ́ ̃ ̣ ̀ chinh trước khi giao cho đôi ngũ lâp trinh, lam giam đang kể chi phí sửa lôi. ̉ ̣ ̣ ̀ ̀ ̉ ́ ̃ + Trong giai đoan cai đăt, Kiêm chứng yêu câu giup điêu chinh những ̣ ̀ ̣ ̉ ̀ ́ ̀ ̉ lôi lâp trinh ngay từ cac mức thâp, lam giam chi phí sửa lôi bởi tranh được ̃ ̣ ̀ ́ ́ ̀ ̉ ̃ ́ ̣ viêc lan truyên lôi. ̀ ̃ + Cac lôi được phat hiên cua Kiêm chứng yêu câu thường không gây ́ ̃ ́ ̣ ̉ ̉ ̀ phan ứng dây chuyên, chỉ dân đên viêc sửa đôi môt hoăc môt số module cua ̉ ̀ ̃ ́ ̣ ̉ ̣ ̣ ̣ ̉ hệ thông. ́ Phân tích yêu cầu phần mềm. Tuần 4. Page 5
2. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Simple Check 2.1. Quy trình thực hiện • Người kiểm duyệt, kiểm soát yêu cầu phải có các kiến thức từ trước (các phản hồi từ khách hàng ) • Quan sát xem có những cái gì sai lệch trong hệ thống hiện tại. • Mô hình hóa : Mô tả và giải thích vấn đề • Phân tích và kiểm tra các đặc tính của mô hình 2.2. Thời gian thực hiện Kỹ thuật simple check là kỹ thuật kiểm tra sự khác nhau bằng cách truy xuất nguồn gốc của yêu cầu vì vậy kỹ thuật simple check được thực hiện trong mọi giai đoạn phát triển của phần mềm. 2.3. Tác nhân tham gia • Lập trình viên • Bộ phận kiểm thử • Nhà quản lý dự án 3. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm prototyping Kỹ thuật Prototyping là một kỹ thuật xây dựng một kiến trúc được cài đặt cụ thể trước để các khách hàng, người dùng hoặc nhà phát triển có thể hiểu rõ thêm về một vấn đề hay giải pháp của nó. Các hướng tiếp cận của Prototyping: • Bản mẫu trình diễn: Dùng để chứng minh các khái niệm, giải thích các đặc tính thiết kế. • Bản mẫu thăm dò : dùng để xác định vấn đề, thu thập nhu cầu, làm rõ mục tiêu, so sánh các lựa chọn thiết kế • Bản mẫu thử nghiệm : khai thác các đặc tính kỹ thuật, kiểm tra sự thích hợp của một kỹ thuật Phân tích yêu cầu phần mềm. Tuần 4. Page 6
• Bản mẫu tiến triển : được phát triển khi thấy tiến trình tiếp diễn sẽ tương thích với hệ thống. 3.1. Quy trình thực hiện • Lựa chọn các nguyên mẫu để thử nghiệm • Sau khi đã lựa chọn được các nguyên mẫu để thử nghiệm thì xây dựng các kịch bản thử nghiệm. • Cần phải có một kế hoạch cụ thể để xây dựng các kịch bản thử nghiệm sao cho bao quát toàn bộ các yêu cầu phần mềm 3.2. Thời gian thực hiện Kỹ thuật prototyping để trợ giúp cho việc xác định yêu cầu phần mềm nên được thực hiện đồng thời với quá trình xác định yêu cầu phần mềm 3.3 Tác nhân tham gia • Lập trình viên • Bộ phần kiểm thử • Nhà quản lý dự án Phân tích yêu cầu phần mềm. Tuần 4. Page 7
4. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Functional test design 4.1. Quy trình thực hiện.  Xác định các chức năng mà phần mềm dự kiến sẽ thực hiện  Tạo ra các dữ liệu đầu vào dựa trên thông số kỹ thuật của chức năng  Xác định đầu ra dựa trên thông số kỹ thuật của chức năng  Thực hiện các trường hợp thử nghiệm  So sánh các kết quả đầu ra thực tế và dự kiến  Kiểm tra xem các ứng dụng làm việc theo nhu cầu của khách hàng 4.2. Thời gian thực hiện. Functional test design là một cách tiếp cận kiểm tra, trong đó trường hợp thử nghiệm, điều kiện và dữ liệu có nguồn gốc từ các yêu cầu. Nó bao gồm các bài kiểm tra chức năng và cũng thuộc tính không có chức năng như hiệu suất, độ tin cậy hoặc khả năng s ử dụng. Thử ngiệm chức năng (functional testing) còn gọi là thử nghiệm hộp đen (black box testing) là sự thử nghiệm sử dụng các ca th ử nghiệm được thiết kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết. Thử nghiệm chức năng nhìn nhận mô đun được thử nghiệm như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của mô đun, tức là kiểm tra xem có hoạt động đúng với đặc tả hay không. Các ca ki ểm th ử bao gồm các trường hợp bình thường và không bình thường (dữ li ệu không hợp lệ...) của mô đun. Thông thường, không thể thử nghiệm với mọi dữ liệu, chiến lược chung khi thiết kế dữ liệu thử nghi ệm là phân hoạch (dữ liệu) tương đương. Phân hoạch tương đương chia miền dữ liệu vào ra thành các vùng, mà mỗi vùng ch ứa các d ữ liệu có cùng hành vi. Do đó, đối với mỗi vùng dữ liệu chỉ cần xây dựng một ca thử nghiệm. Thêm vào đó là các ca sử dụng đối với biên giới của các vùng. Theo kinh nghiệm, các sai sót về lập trình thường sảy ra đối với các dữ liệu biên. Phân tích yêu cầu phần mềm. Tuần 4. Page 8
Kiểm tra chức năng ở cấp độ hệ thống phải được phát triển sớm hay muộn ? - Có thể (và nên) được bắt nguồn từ đặc tả yêu cầu - Mỗi (chức năng) yêu cầu cần phải có một thử nghiệm liên quan - Không chức năng (ví dụ, độ tin cậy) hoặc độc quy ền (ví d ụ, xác định những gì nên không xảy ra) yêu cầu là khó khăn hơn để xác nhận với các thử nghiệm - Mỗi trường hợp yêu cầu kiểm tra phải được bắt nguồn từ yêu cầu của nó - Phát minh ra các yêu cầu kiểm tra là m ột k ỹ thu ật xác nhận hiệu quả Thiết kế các xét nghiệm này có thể phát hiện sai sót trong đ ặc đi ểm kỹ thuật (ngay cả trước khi thiết kế và xây dựng hệ thống)! - Thiếu thông tin hoặc không rõ ràng trong bản mô tả yêu cầu có thể làm cho nó khó khăn để xây dựng các bài kiểm tra • Một số quy trình phát triển phần mềm (ví dụ như phương pháp nhanh nhẹn) bắt đầu với các bài kiểm thử trước khi trình phát triển phần mềm.(lập trình). 4.3. Tác nhân tham gia.  Khách hàng  Bộ phận lập trình  Bộ phận kiểm thử  Người quản lí dự án. 4.4. Công cụ điển hình  Dialog map  Test case  Ma trận theo dõi các trường hợp sử dụng Phân tích yêu cầu phần mềm. Tuần 4. Page 9
5. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm User manual Development. 5.1. Quy trình thực hiện • Làm thế nào để cài đặt và bắt đầu với hệ thống • Mô tả các chức năng và làm thế nào nó được thực hiện • Làm thế nào để có được ra khỏi rắc rối • Những bộ phận của hệ thống đã không được thực hiện 5.2. Thời gian thực hiện • Giống như thiết kế thử nghiệm chức năng • Có phải được thực hiện tại một số điểm • Tiết lộ các vấn đề trước đó • Buộc một cái nhìn chi tiết yêu cầu • Đặc biệt hữu ích nếu các ứng dụng giàu giao diện người dùng / cho các yêu cầu khả năng sử dụng Phác thảo sổ tay người dùng ngay từ sớm trong quy trình phát triển yêu cầu và dùng nó như là tài liệu đặc tả yêu cầu hoặc như một trợ giúp cho phân tích yêu cầu. Một tài liệu sổ tay người dùng tốt sẽ mô tả tất cả các chức năng mà người dùng thấy được (user – visible functionality) bằng một ngôn ngữ dễ hiểu. Các yêu cầu khác như các thuộc tính chất lượng, yêu cầu hiệu suất, chức năng không thấy được đối với người dùng (not visible to users) sẽ được tài liệu hoá trong SRS. 5.3. Tác nhân tham gia • Các PTV • Các đại diện của NSD (Product champions) • Tất cả các thành viên của công ty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm:LTV, các nhà kiểm thử, v.v 5.4. Công cụ điển hình • Một số phần mềm soạn thảo văn bản • Phần mềm đồ họa. Phân tích yêu cầu phần mềm. Tuần 4. Page 10
• Một số mẫu hướng dẫn sử dụng có sẵn. 6. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Reviews and Inspections Một nhóm các kỹ sư phần mềm, kỹ sư hệ thống và người có kinh nghiệm trong lĩnh vực yêu cầu phần mềm sẽ cùng đọc và phân tích các yêu cầu, tìm ra các vấn đề tiềm tàng để thảo luận, và thống nhất với nhau các công việc cần làm để giải quyết những vấn đề đó. Đây là một kỹ thuật kiểm chứng yêu cầu được sử dụng rộng rãi. Có rất nhiều bằng chứng về tính hiệu quả của kỹ thuật này. Kỹ thuật này có thể rất tốn kém: • Cần chuẩn bị và lên kế hoạch cẩn thận • Cần kiểm tra trước khi duyệt • Cần một danh sách kiểm duyệt phù hợp Một số kỹ thuật kiểm duyệt và kiểm soát yêu cầu phần mềm: Phân theo hình thức 1. Đọc văn bản yêu cầu phần mềm: Yêu cầu một người không là tác giả của văn bản yêu cầu phần mềm đó đ ọc và kiểm duyệt. 2. Đọc và phê duyệt: Khuyến khích người kiểm duyệt đọc cẩn thận hơn và có trách nhiệm hơn. 3. Đọc lướt: Đây là kỹ thuật không chính thức, ở mức tổng quát cao, đọc để có cái nhìn tổng quát về văn bản yêu cầu. Kỹ thuật này có thể cần phải được dẫn dắt bởi tác giả văn bản/chuyên gia. 4. Kỹ thuật kiểm duyệt chính thức (Formal Inspections): kiểm duyệt một cách chi tiết, cụ thể và có cấu trúc. Xác định rõ ràng vai trò của những người tham gia kiểm duyệt cũng nh ư xác dịnh rõ điều kiện để kết thúc việc kiểm duyệt. 5. Kiểm duyệt tập trung: Các chuyên viên kiểm duyệt có vai trò xác định, mỗi chuyên viên chỉ tìm kiếm một s ố l ỗi nh ất định trong yêu cầu phần mềm. 6. Kiểm duyệt tích cực: Tác giả văn bản sẽ hỏi trực tiếp các chuyên viên kiểm duyệt các câu hỏi liên quan đến văn bản. 6.1. Quy trình thực hiện 1. Plan review. Phân tích yêu cầu phần mềm. Tuần 4. Page 11
Đội kiểm duyệt được lựa chọn, thời gian, địa điểm gặp mặt cũng được ấn định. 2. Phân phát tài liệu liên quan Văn bản yêu cầu phần mềm được phân phát cho các thành viên đội kiểm duyệt. 3. Chuẩn bị cho việc kiểm duyệt các yêu cầu Mỗi thành chuyên viên kiểm duyệt đọc các yêu cầu để tìm ra các xung đột, thiếu sót, mâu thuẫn, lệch chuẩn và các vấn đề khác 4. Tổ chức gặp mặt Các vấn đề và nhận xét của mỗi cá nhân về văn bản yêu cầu phần mềm sẽ được đưa ra thảo luận, và các việc cần làm để giải quyết các vấn đề sẽ được đưa ra. 5. Thực hiện các việc cần làm (kết quả của bước 4) Giải quyết các vấn đề bằng cách tuân thủ thực hiện các hành động đã thống nhất ở bước 4. 6. Duyệt lại văn bản. Văn bản yêu cầu phần mềm được duyệt lại để kiểm chứng sự hợp lý của các hành động đã thống nhất. Kết quả của bước này, hoặc là văn bản cuối cùng được chấp nhận, hoặc là cần được kiểm duyệt lại. Đôi khi, để giảm thiểu chi phí của quá trình kiểm duyệt yêu cầu, cần phải thực hiện bước "pre-review checking". Nghĩa là kiểm tra văn bản và tìm kiếm các vấn đề trực tiếp, như là thiếu yêu cầu phần mềm, thiếu tuân thủ theo chuẩn, … 6.2. Thời gian thực hiện Có thể áp dụng khi mới xây dựng xong bước đầu các yêu cầu phần mềm từ các biện pháp thu thập. Khi đó, các vấn đề vẫn còn tồn tại trong các yêu cầu phần mềm. Và cần phải loại bỏ các vấn đề này trước khi đem văn bản yêu cầu đi thương thảo. Áp dụng khi cần xác minh rằng các yêu cầu mình viết ra sẽ thỏa mãn các bên liên quan. Hay nói cách khác, tìm sự đồng thuận từ phía khác hàng. Phân tích yêu cầu phần mềm. Tuần 4. Page 12
6.3. Tác nhân tham gia • Những người đến từ những lĩnh vực khác nhau sẽ mang đến những kỹ năng và kiến thức khác nhau để kiểm duyệt các yêu cầu phần mềm • Họ sẽ cảm thấy được tham gia và có vai trò trong quá trình xây dựng yêu cầu phần mềm, và họ sẽ hiểu hơn về nhu cầu/yêu cầu của các bên còn lại. • Nhóm kiểm duyệt luôn luôn có ít nhất một bên chuyên gia, một bên người dùng. Các vấn đề khi kiểm duyệt: • Tính rõ ràng của yêu cầu: Các yêu cầu được diễn tả một cách "tệ", khó hiểu, hoặc có thể vô tình bỏ qua thông tin nào đó đã được thu thập trong suốt quá trình xác định yêu cầu. • Thiếu thông tin: Một số thông tin trong văn bản yêu cầu phần mềm bị thiếu. • Xung đột yêu cầu: Có xung đột nghiêm trọng giữa các yêu cầu (các yêu cầu phủ định nhau). Các bên liên quan cần thương lượng để giải quyết xung đột. • Các yêu cầu không thực tế: Các yêu cầu có vẻ như không thể thực hiện được (unimplementable) với trình độ công nghệ hiện tại, hoặc với ràng buộc nào đó trong hệ thống. • Các bên liên quan trong tình huống này cần bàn bạc để quyết định làm cho yêu cầu đó trở nên thực tế hơn. Phân tích yêu cầu phần mềm. Tuần 4. Page 13
7. Kỹ thuật Fagan Inspection. Fagan Inspection được đặc trưng bởi các quy định ai sẽ tham gia, bao nhiêu người kiểm duyệt sẽ tham gia và mỗi người có vai trò gì trong kiểm duyệt. Mỗi lần họp bàn không quá 2 tiếng. Chỉ cần khoảng đó thời gian các thành viên tham gia kiểm duyệt tập trung vào công việc. Cần 3 - 5 người kiểm duyệt. Tác giả văn bản yêu cầu phần mềm sẽ đóng vai trò như người trình diễn văn bản. Các số liệu được thu thập. Điều quan trọng là các số liệu này tác giả văn bản yêu cầu phần mềm không được biết đến. Người đó chỉ như là một người giám sát suốt quá trình kiểm duyệt. Có một người chịu trách nhiệm điều tiết buổi họp bàn, bắt đầu việc kiểm duyệt, dẫn dắt buổi gặp và đảm bảo các vấn đề được tìm thấy phải được sửa chữa. Tất cả các người kiểm duyệt cần tự chuẩn bị trước bằng cách sử dụng danh sách kiểm duyệt (checklists). Các vấn đề được ghi lại theo khuôn dạng đặc biệt. Fagan Inspection giống như "brain storming" trong phát hiện yêu cầu phần mềm. Nó là một phiên động não để phát hiện các vấn đề trong yêu cầu phần mềm. Cần kiểm duyệt lại nếu nhiều hơn 5% văn bản yêu cầu phải thay đổi. (bởi việc sửa chữa 1 lỗi nào đó, lại phát sinh một lỗi mới. Sửa càng nhiều, càng dễ sinh ra lỗi mới). Phân tích yêu cầu phần mềm. Tuần 4. Page 14