Phân tích yêu cầu phần mềm

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 tập Môn học: Phân tích yêu cầu phần mềm Giảng viên: PGS.TS Huỳnh Quyết Thắng Danh sách sinh viên: (nhóm ) Lê Trung Hiếu 20111568 CNTT-TT 2.3 K56 Đàm Văn Hoài 20111600 CNTT-TT 2.3 K56 Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56 Đoàn Văn Đạt 20111370 CNTT-TT 2.3 K56 Hà Nội – 4/2014 IT4460 Nhóm Mục lục Phân tích yêu cầu phần mềm Page IT4460 Nhóm I Mười đặc tính chất lượng của một bản đặc tả yêu cầu phần mềm tốt 1.1 Tính đắn (correct) - Một đặc tả yêu cầu phần mềm tốt yêu cầu xác định phải phần mềm đáp ứng Mỗi yêu cầu cần mô tả xác chức xây dựng Sự đảm bảo cho tính đắn tham chiếu đến nguồn yêu cầu, khách hàng đặc tả yêu cầu hệ thống mức cao Một yêu cầu phần mềm mà xung đột với yêu cầu hệ thống tương ứng không đắn Chỉ trình bày người dùng xác định tính đắn yêu cầu người dùng, điều cho biết rà soát yêu cầu ta cần có mặt người dùng người đại diện họ - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo phần mềm đáp ứng đầy đủ đặc tả yêu cầu phần mềm Đây tiêu chí để đánh giá phần mềm có đáp ứng yêu cầu người dùng hay không 1.2 Tính hoàn chỉnh (complete) - Mỗi yêu cầu cần mô tả đầy đủ chức chuyển giao Nó phải chứa tất thông tin cần thiết để nhà phát triển thiết kế thực thi chức Nếu yêu cầu phần mềm chưa rõ ràng, có cảm giác thiếu nói yêu cầu đó, họ đánh dấu yêu cầu "TBD To Be Determined" - ký hiệu chuẩn IEEE 830 Như rà soát toàn tài liệu SRS, tìm yêu cầu bị đánh dấu TBD để tiếp tục hoàn thiện SRS - Phải xác định kết liệu đầu vào, đặc biệt phải xác định kết liệu đầu vào hợp lệ liệu đầu vào không hợp lệ - Phải có đầy đủ nhãn tài liệu tham khảo cho tất số liệu, bảng biểu, sơ đồ SRS định nghĩa tất điều khoản đơn vị đo lường Phân tích yêu cầu phần mềm Page IT4460 Nhóm - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo yêu cầu mô tả đầy đủ 1.3 Tính quán (consistent) -Các yêu cầu phần mềm không xung đột với yêu cầu phần mềm khác yêu cầu cấp cao (hệ thống kinh doanh) Tất mâu thuẫn yêu cầu cần phải phân giải trước trình phát triển diễn Bạn yêu cầu đơn (single requirement) đắn tận bạn tiến hành số nghiên cứu yêu cầu - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo yêu cầu phần mềm không xung đột lẫn nhau, đảm bảo tính quán yêu cầu phần mềm 1.4 Tính khả thi (Feasible) - Khả thi có nghĩa có thể thực thi yêu cầu khả giới hạn biết hệ thống môi trường hoạt động hệ thống Một yêu cầu không có tính khả thi nếu nó không thể thực hiện được hoặc có thể thực hiện yêu cầu chi phí lớn (về nhân lực, về tài chính, về tài nguyên phần cứng, phần mềm, hoặc về độ phức tạp tính toán) - Để tránh yêu cầu không khả thi, cần thành viên nhóm dự án làm việc với những nhân viên bán hàng nhà phân tích yêu cầu trình xử lý yêu cầu (elicitation process) Người đánh giá tính khả thi yêu cầu mặt kỹ thuật chỉ yêu cầu thực thi với chi phí lớn - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo các yêu cầu được đưa có thể thực hiện được thực tế Nếu một yêu cầu không thể hoàn thành thì nó sẽ ảnh hưởng tới toàn bộ dự án Yêu cầu đó có thể làm lãng phí một lượng lớn công sức, tài nguyên mà đem lại lợi ích quá nhỏ cho dự án Thêm Phân tích yêu cầu phần mềm Page IT4460 Nhóm vào đó, việc không thể hoàn thành yêu cầu ảnh hưởng rất lớn tới uy tín của người phát triển phần mềm Vì vậy, một SRS tốt cần đảm bảo mọi yêu cầu đề có tính khả thi 1.5 Tính thay đổi (Modifiable) - Một SRS có thể thay đổi cần đảm bảo mỗi cần bổ sung, sửa đổi hay loại bỏ một yêu cầu nào đó thì công việc này cần được thực hiện một cách nhanh chóng, chính xác và vẫn đảm bảo tính nhất quán với các yêu cầu còn lại - Để tăng tính thay đổi yêu cầu phần mềm, viết yêu cầu thật rõ ràng, mạch lạc (fine grain fashion), gán nhãn khác cho yêu cầu Người đọc không thích nhìn thấy dấu chấm đầu hàng tài liệu, dò tìm yêu cầu, phải dò qua yêu cầu cụ thể - tốn thời gian không rõ ràng (vì nhãn) Một cách để loại bỏ dấu chấm, xếp yêu cầu theo bảng chữ - dùng chữ để gán nhãn - SRS có thể được nghiên cứu lại cần thiết cần phải trì thông tin diễn biến thay đổi yêu cầu Điều đòi hỏi yêu cầu dán nhãn diễn giải riêng rẽ với yêu cầu khác cho yêu cầu tham chiếu xác Mỗi yêu cầu xuất lần SRS để tránh không quán thể (instance) yêu cầu nơi khác Một bảng nội dung (table of contents), index, danh sách tham chiếu chéo (cross – reference listing) làm SRS dễ sửa chữa - IEEE 830-1998 hỗ trợ xây dựng SRS với đặc tính chất lượng này để có thể tiết kiệm thời gian, chi phí cho quá trình đàm phán và quản lý yêu cầu phần mềm Một SRS có đặc tính “có thể sửa đổi” sẽ giúp việc sửa đổi chỉ cần làm ở một số ít nơi của SRS, đồng thời không cần lo lắng về việc những thay đổi này mâu thuẫn với các yêu cầu trước đó Phân tích yêu cầu phần mềm Page IT4460 1.6 Nhóm Tính cần thiết (Necessary) - Mỗi yêu cầu cần phải tài liệu hoá mà khách hàng thật cần hệ thống khác bên cần Một cách khác để xác nhận “tính cần thiết” yêu cầu đề xuất từ bên mà bạn biết rõ người đó có thầm quyền đề yêu cầu - Nếu một yêu cầu phần mềm không đáp ứng nguyện vọng của bất kì khách hàng hay hệ thống nào thì nó là yêu cầu không cần thiết, cần phải loại bỏ Việc thực hiện yêu cầu này không mang lại lợi ích nào cho dự án phần mềm, chỉ làm lãng phí công sức, tài nguyên - IEEE 839-1998 hỗ trợ xây dựng SRS với đặc tính chất lượng này để đảm bảo mọi yêu cầu được đưa SRS đều cần thiết cho dự án phần mềm Chỉ các yêu cầu thật sự cần thiết mới cần đầu tư thời gian, công sức để hoàn thành 1.7 Có độ ưu tiên (Prioritized) - Gán thứ tự ưu tiên cho yêu cầu, tính (feature), use case để hình dung lịch trình phát triển phiên phần mềm Nếu tất yêu cầu coi quan quản trị dự án không xác định cách thức thi công yêu cầu phát sinh trình thi công dự án, không kiểm soát ngân sách, lịch biểu nhân lục án - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo người quản trị dự án đánh giá xác mức độ quan yêu cầu Tù có đánh giá, kiểm soát tất yêu cầu có yêu cầu phát sinh thêm Người quản trị đầu tư mức với yêu cầu tương ứng với mức độ ưu tiên 1.8 Có thể truy vết (Traceable) - Bạn cần phải liên kết yêu cầu tới nguồn phát sinh nó, tới Phân tích yêu cầu phần mềm Page IT4460 Nhóm phần tử thiết kế, mã nguồn, test cases thực thi kiểm tra đắn việc thi công yêu cầu Các yêu cầu theo vết gán nhãn viết theo cách có cấu trúc, chi tiết thuyết minh đầy đủ - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để người làm dự án tìm đường yêu cầu phần mềm từ nguyên nhân phát sinh đến lúc thiết kế để đáp ứng yêu cầu phần mềm Mỗi yêu cầu cần xác định cách rõ ràng nguồn phát sinh, vị trí khâu thiết kế Truy viết giúp người làm dự án tìm lỗi sai hay thiếu sót yêu cầu cách nhanh chóng biết vết yêu cầu 1.9 Không nhập nhằng (Unambiguous) - Tất đọc báo cáo yêu cầu có cách hiểu, cách diễn giải quán nội dung yêu cầu Do ngôn ngữ tự nhiên có tính nhập nhằng cao nên viết yêu cầu rõ ràng, cụ thể, đơn nghĩa dễ Cách hiệu để loại bỏ tính nhập nhằng mô tả báo cáo yêu cầu ngôn ngữ hình thức use-case chẳng hạn, qua kịch sử dụng cụ thể - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để giúp cho SRS trình bày rõ ràng nhất,tường minh Tất yêu cầu trùng lặp hay trùng ý nghĩ với điều có SRS dự án dễ dẫn đến thất bại Một phần mềm trùng lặp chức với phần mềm tồi 1.10 Kiểm tra (Verifiable) - Hãy kiểm tra yêu cầu để xem liệu bạn nghĩ số lượng nhỏ phép tests sử dụng cách tiếp cận kiểm tra khác tra (inspection) chứng minh (demonstration) để biết liệu yêu cầu Phân tích yêu cầu phần mềm Page IT4460 Nhóm cài đặt hợp lệ sản phẩm hay không Nếu yêu cầu kiểm tra xác định liệu có cài đặt đắn hay không trở thành vấn đề gây tranh cãi Các yêu cầu không quán, không khả thi nhập nhằng kiểm tra - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để người làm dự án kiểm tra cài đặt yêu hợp lí hay chưa, sai chưa tối ưu Một SRS kiểm tra nhanh phát lỗi yêu cầu trình triển khai dự án giúp giảm chi phí tiền bạc nhân lực để sửa chữa II Các Tips để viết đặc tả yêu cầu phần mềm Đưa đánh giá dựa góc nhìn nhà phát triển Bất kể phía đối tác đưa yêu cầu nào, quan điểm nào, nên đứng quan điểm nhà phát triển để đánh giá yêu cầu Bản thân phía đối tác đưa yêu cầu phần mềm nào, mang góc nhìn quan điểm họ Thông thường, họ người ngành công nghệ thông tin, không hiểu hết rõ đặc thù công việc phát triển phần mềm khả máy tính Do đó, phải đánh giá, nhận xét yêu cầu phần mềm góc nhìn nhà phát triển Làm bật yêu cầu cấu trúc phân cấp Và nên suy nghĩ, đánh giá dựa theo cấu trúc phân cấp Bởi thân cấu trúc phân cấp mang nhiều thông tin mối quan hệ logic yêu cầu: Yêu cầu lớn, yêu cầu nhỏ, yêu cầu cha – con, yêu cầu mức phân cấp… Chính cấu trúc giúp việc đánh giá trở nên xác, hợp lý, sát Đặc biệt đánh giá dựa hình ảnh trực quan dễ dàng suy nghĩ vấn đề đầu mà hình ảnh hỗ trợ Và thực tế chứng minh, hầu hết người đối mặt với vấn đề phức tạp cấu trúc phân cấp (nó phân rã vấn đề lớn thành vấn đề nhỏ - hiểu giải được) Nếu không biểu diễn theo cấu trúc phân cấp, khó nhận mối quan hệ logic yêu cầu/mục yêu cầu, khó nhận đâu yêu cầu lớn, đâu yêu cầu nhỏ, … Phân tích yêu cầu phần mềm Page IT4460 Nhóm Cố gắng viết câu đoạn ngắn - đơn giản (write concisely): o Tránh đoạn văn nói dài Bởi đoạn văn dài, với nhiều ý, cuối lại không chốt yêu cầu mà nói tới xác gì! o Dùng ngữ pháp, tả, ngắt câu phù hợp (nên để người thông thạo ngôn ngữ sử dụng để viết SRS) o Dùng từ vựng lĩnh vực kinh doanh (đôi việc không sử dụng xác từ làm thay đổi toàn ý nghĩa mà yêu cầu muốn diễn đạt) Trong đoạn nói yêu cầu phần mềm đó, có nhiều thông tin quan trọng, lại không rõ yêu cầu cần xây dựng gì! Thay đó, đừng để yêu cầu chức viết đoạn dài, đưa mô tả tảng (additional descriptive background), context chức ngoài, tách bạch với mô tả chức Đừng yêu cầu người khác rà soát lại tài liệu chưa kiểm tra ngữ pháp - tả Sẽ tốt có giỏi ngôn ngữ rà soát lại SRS, tìm vấn đề dùng từ câu, tài liệu tốt mặt diễn đạt yêu cầu phần mềm Phải có văn mô tả cho hành vi mong muốn lẫn ngoại lệ - Chúng ta mong đợi hệ thống hoạt động theo hành vi mà ta mong muốn, nhiên, chương trình viết với nhiều đoạn mã để xử lý lỗi, ngoại lệ Và không xác định lỗi, ngoại lệ cách xử lý chúng trình xây dựng yêu cầu phần mềm, có vân đề! developers ngoại lệ cố gắng thiết kế xử lý ngoại lệ theo cách mà lý tưởng từ quan điểm người dùng không nghĩ lỗi/ngoại lệ Và lần chương trình gặp lỗi, ngoại lệ đó, crash! Công việc ngoại lệ bị thiếu nên thực tester, họ nghĩ điều tồi tệ xảy với chương trình Tránh ràng buộc thiết kế (design constraints) không cần thiết Tránh việc đưa vào SRS nhiều ý tưởng giải (solution ideas) Có nghĩa đừng đưa nhiều ràng buộc thiết kế vào tài liệu SRS Phân tích yêu cầu phần mềm Page IT4460 Nhóm cách kết hợp nhiều ý tưởng giải pháp tài liệu hướng dẫn, trừ có lý đặc biệt thỏa đáng Viết yêu cầu mức chi tiết hợp lý Khó để xác định xem tài liệu SRS cần viết chi tiết đến mức nào, hướng dẫn, chia yêu cầu phần mềm thành phận mà độc lập kiểm tra Các từ "and" "or" xác định yêu cầu phần mềm có kết hợp với hay không Ví dụ gặp từ "and" yêu cầu phần mềm, ta đặt câu hỏi, phải vế từ "and" yêu cầu? Hay chúng mặt logic yêu cầu khác cần chia (split)? Viết yêu cầu cách xác, cụ thể, không mơ hồ gây nhầm lẫn Một số lập trình viên thích yêu cầu phần mềm mơ hồ, gây nhầm lẫn, để bắt tay vào xây dựng, họ xây dựng mà họ muốn ? Và chí người dùng thích yêu cầu mơ hồ, gây nhầm lẫn, cho phép họ định nghĩa lại yêu cầu theo ý mà họ muốn thời điểm cụ thể! Điều không tốt chút cho việc xây dựng phần mềm chất lượng tốt! Có số từ nên sử dụng để viết yêu cầu, số từ nên tránh Nên sử dụng từ "sẽ", "phải" thay nói "nên", "có lẽ", "có thể", … (should, may, might, could, can, if possible, if you feel like, if you have time, if you get around) Nên chọn số thuật ngữ sử dụng cách quán từ đầu đến cuối SRS nói chức hệ thống Một người bạn tác giả gợi ý thay từ should cụm từ "probably won't (có lẽ không)", hỏi ý kiến người dùng có đồng ý với yêu cầu (phần mềm) không, thông thường, người dùng nói không (tức thân cụm từ probably won't mơ hồ, không rõ ràng) Một số người viết yêu cầu phần mềm sử dụng should - nói đến chức yêu cầu hệ thống, might - chức mong muốn có hệ thống, may - chức tùy chọn; điều thực không tốt, thân từ giao tiếp hàng ngày nhiều sử dụng thay Chính điều khiến cho việc sử dụng Phân tích yêu cầu phần mềm Page 10 IT4460 Nhóm chúng làm văn trở nên thiếu tính quán, yêu cầu thiếu tính đơn nghĩa! Như cần tránh sử dụng từ gây nhầm lẫn mang tính chủ quan Phân tích yêu cầu phần mềm Page 11 IT4460 Nhóm Phân biệt Requirements Verification và Requirements Validation 1.1 Phân biệt - Requirements Validation (Xác nhận yêu cầu) Đây là việc kiểm tra rằng có phải một sản phẩm đúng được xây dựng hay không Cần chắc chắn rằng sản phẩm xây dựng (hay nâng cấp) sẽ làm thỏa mãn các bên liên quan Điều này được tiến hành bằng việc đối chiếu lại bản đặc tả yêu cầu phần mềm với mục tiêu và yêu cầu của các bên liên quan - Requirement Verification (Kiểm chứng yêu cầu) Đây là việc kiểm tra rằng có phải một sản phẩm được xây dựng đúng hay không Cần chắc chắn rằng mỗi bước được cho phép quá trình xây dựng phần mềm đều mang lại lợi ích cho việc xây dựng sản phẩm đúng Việc này được tiến hành thông qua đối chiếu đối tượng được tạo theo bản đặc tả yêu cầu phần mềm với bản đặc tả đó Sự khác hai công việc vai trò đặc tả yêu cầu phần mềm Với xác nhận yêu cầu, đặc tả yêu cầu phần mềm kiểm tra xem có phản ánh xác yêu cầu bên liên quan hay không Còn với kiểm chứng yêu cầu, đặc tả yêu cầu dùng làm mẫu để đánh giá phần mềm xây dựng có phù hợp hay không Phân tích yêu cầu phần mềm Page 12 IT4460 Nhóm Các so sánh cụ thể: Xác nhận yêu cầu Kiểm chứng yêu cầu (Requirements Validation) (Requirements Verification) Xác nhận yêu cầu là các thủ tục kiểm tra động (thay đổi theo diễn biến của dự án, tùy vào các bên liên quan), có tác dụng để sửa chữa đặc tả yêu cầu Kiểm chứng yêu cầu là các thủ tục kiểm tra tĩnh (có các quy tắc cho sẵn để áp dụng), có tác dụng ngăn ngừa sự sai khác của phần mềm với đặc tả Là quá trình mang tính chủ quan của Là quá trình mang tính khách quan, các bên liên quan, phụ thuộc rất các tiêu chuẩn kĩ thuật được áp dụng nhiều vào đánh giá của người dùng để so sánh sản phẩm với đặc tả Khi phát hiện lỗi, cần sửa chữa đặc Khi phát hiện lỗi, việc sửa chữa tốn tả (chi phí thấp nếu chưa tạo sản ít chi phí phẩm), nếu sản phẩm đã được tạo thì chi phí khắc phục rất cao 1.2 Ảnh hưởng Xác nhận yêu cầu (Requirements Validation) Xác nhận yêu cầu công việc quan trọng trình phân tích đặc tả yêu cầu phần mềm - Những ảnh hưởng Xác nhận yêu cầu: + Việc xác nhận yêu cầu giúp cho yêu cầu đặc tả phản ánh nguyện vọng bên liên quan Các khách hàng, người dùng cung cấp bản chạy được của phần mềm và được dùng thử để xem đã đáp ứng được đúng yêu cầu của mình chưa Nếu có bất cứ phát hiện nào, các lỗi đó sẽ được thông báo cho người phát triển để chỉnh sửa Việc này đảm bảo sản phẩm được tạo sẽ đáp ứng đúng yêu cầu người dùng, và được chấp nhận + Việc xác nhận yêu cầu tạo sự nhất trí, tin tưởng giữa các bên liên quan, tạo định hướng thống nhất cho giai đoạn thiết kế, viết mã nguồn hệ thống + Lỗi của quá trình Xác nhận yêu cầu phát hiện dẫn đến sự thay đổi của bản đặc tả yêu cầu phần mềm, dẫn đến một loạt phản ứng dây chuyền, làm thay đổi từ khâu phân tích thiết kế tới viết mã nguồn Phân tích yêu cầu phần mềm Page 13 IT4460 Nhóm 1.3 Ảnh hưởng của 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 hành thiết kế và lập trình sản phẩm phần mềm - Những ảnh hưởng của Kiểm chứng yêu cầu: + Kiểm chứng yêu cầu giúp phần mềm được tạo đúng với đặc tả của yêu cầu phần mềm Nếu phát hiện lỗi, những nhà phát triển phần mềm sẽ được thông báo để sửa chữa, đó đảm bảo rằng phần mềm được hoàn thành thì nó sẽ phù hợp với các đặc tả yêu cầu + Việc kiểm chứng yêu cầu giúp rà soát lỗi của những người thiết kế, lập trình, qua đó nâng cao ý thức làm việc cẩn trọng, nghiêm túc của đội ngũ phát triển phần mềm + Trong giai đoạn thiết kế, Kiểm chứng yêu cầu giúp điều chỉnh những bản thiết kế hệ thống một cách chính xác, tối ưu Các lỗi tạo được điều chỉnh trước giao cho đội ngũ lập trình, làm giảm đáng kể chi phí sửa lỗi + Trong giai đoạn cài đặt, Kiểm chứng yêu cầu giúp điều chỉnh những lỗi lập trình từ các mức thấp, làm giảm chi phí sửa lỗi bởi tránh được việc lan truyền lỗi + Các lỗi được phát hiện của Kiểm chứng yêu cầu thường không gây phản ứng dây chuyền, chỉ dẫn đến việc sửa đổi một hoặc một số module của hệ thống Phân tích yêu cầu phần mềm Page 14 IT4460 Nhóm Kỹ thuật duyệt kiểm soát yêu cầu phần mềm Simple Check 2.1 Quy trình thực • Người kiểm duyệt, kiểm soát yêu cầu phải có kiến thức từ trước (các phản hồi từ khách hàng ) • Quan sát xem có sai lệch hệ thống • Mô hình hóa : Mô tả giải thích vấn đề • Phân tích kiểm tra đặc tính mô hình 2.2 Thời gian thực Kỹ thuật simple check kỹ thuật kiểm tra khác cách truy xuất nguồn gốc yêu cầu kỹ thuật simple check thực giai đoạn phát triển 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 Kỹ thuật duyệt kiểm soát yêu cầu phần mềm prototyping Kỹ thuật Prototyping kỹ thuật xây dựng kiến trúc cài đặt cụ thể trước để khách hàng, người dùng nhà phát triển hiểu rõ thêm vấn đề hay giải pháp Các hướng tiếp cận Prototyping: • Bản mẫu trình diễn: Dùng để chứng minh khái niệm, giải thích đặ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 lựa chọn thiết kế • Bản mẫu thử nghiệm : khai thác đặc tính kỹ thuật, kiểm tra thích hợp kỹ thuật Phân tích yêu cầu phần mềm Page 15 IT4460 Nhóm • Bản mẫu tiến triển : phát triển thấy tiến trình tiếp diễn tương thích với hệ thống 3.1 Quy trình thực • Lựa chọn nguyên mẫu để thử nghiệm • Sau lựa chọn nguyên mẫu để thử nghiệm xây dựng kịch thử nghiệm • Cần phải có kế hoạch cụ thể để xây dựng kịch thử nghiệm cho bao quát toàn yêu cầu phần mềm 3.2 Thời gian thực Kỹ thuật prototyping để trợ giúp cho việc xác định yêu cầu phần mềm nên thực đồng thời với 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 Page 16 IT4460 Nhóm Kỹ thuật duyệt kiểm soát yêu cầu phần mềm Functional test design 4.1 Quy trình thực  Xác định chức mà phần mềm dự kiến thực  Tạo liệu đầu vào dựa thông số kỹ thuật chức  Xác định đầu dựa thông số kỹ thuật chức  Thực trường hợp thử nghiệm  So sánh kết đầu thực tế dự kiến  Kiểm tra xem ứng dụng làm việc theo nhu cầu khách hàng 4.2 Thời gian thực Functional test design cách tiếp cận kiểm tra, trường hợp thử nghiệm, điều kiện liệu có nguồn gốc từ yêu cầu Nó bao gồm kiểm tra chức thuộc tính chức hiệu suất, độ tin cậy khả sử dụng Thử ngiệm chức (functional testing) gọi thử nghiệm hộp đen (black box testing) thử nghiệm sử dụng ca thử nghiệm thiết kế dựa đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát khiếm khuyết Thử nghiệm chức nhìn nhận mô đun thử nghiệm hộp đen, quan tâm đến chức (hành vi) mô đun, tức kiểm tra xem có hoạt động với đặc tả hay không Các ca kiểm thử bao gồm trường hợp bình thường không bình thường (dữ liệu không hợp lệ ) mô đun Thông thường, thử nghiệm với liệu, chiến lược chung thiết kế liệu thử nghiệm phân hoạch (dữ liệu) tương đương Phân hoạch tương đương chia miền liệu vào thành vùng, mà vùng chứa liệu có hành vi Do đó, vùng liệu cần xây dựng ca thử nghiệm Thêm vào ca sử dụng biên giới vùng Theo kinh nghiệm, sai sót lập trình thường sảy liệu biên Kiểm tra chức cấp độ hệ thống phải phát triển sớm hay muộn ? - Có thể (và nên) 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ó thử nghiệm liên quan - Không chức (ví dụ, độ tin cậy) độc quyền (ví dụ, xác định Phân tích yêu cầu phần mềm Page 17 IT4460 Nhóm nên không xảy ra) yêu cầu khó khăn để xác nhận với thử nghiệm - Mỗi trường hợp yêu cầu kiểm tra phải bắt nguồn từ yêu cầu Phát minh yêu cầu kiểm tra kỹ thuật xác nhận hiệu Thiết kế xét nghiệm phát sai sót đặc điểm kỹ thuật (ngay trước thiết kế xây dựng hệ thống)! - Thiếu thông tin không rõ ràng mô tả yêu cầu làm cho khó khăn để xây dựng kiểm tra • Một số quy trình phát triển phần mềm (ví dụ phương pháp nhanh nhẹn) bắt đầu với kiểm thử trước 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 Công cụ điển hình  Dialog map  Test case  Ma trận theo dõi trường hợp sử dụng 4.4 Phân tích yêu cầu phần mềm Page 18 IT4460 Nhóm Kỹ thuật duyệt kiểm soát yêu cầu phần mềm User manual Development 5.1 Quy trình thực • Làm để cài đặt bắt đầu với hệ thống • Mô tả chức làm thực • Làm để có khỏi rắc rối • Những phận hệ thống không thực 5.2 Thời gian thực • Giống thiết kế thử nghiệm chức • Có phải thực số điểm • Tiết lộ vấn đề trước • Buộc nhìn chi tiết yêu cầu • Đặc biệt hữu ích ứng dụng giàu giao diện người dùng / cho yêu cầu khả sử dụng Phác thảo sổ tay người dùng từ sớm quy trình phát triển yêu cầu dùng tài liệu đặc tả yêu cầu 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 mô tả tất chức mà người dùng thấy (user – visible functionality) ngôn ngữ dễ hiểu Các yêu cầu khác thuộc tính chất lượng, yêu cầu hiệu suất, chức không thấy người dùng (not visible to users) tài liệu hoá SRS 5.3 Tác nhân tham gia • Các PTV • Các đại diện NSD (Product champions) • Tất thành viên công ty phần mềm tham gia vào trình thực phần mềm:LTV, nhà kiểm thử, v.v Công cụ điển hình • Một số phần mềm soạn thảo văn • Phần mềm đồ họa • Một số mẫu hướng dẫn sử dụng có sẵn 5.4 Kỹ thuật duyệt kiểm soát yêu cầu phần mềm Reviews and Inspections Một nhóm kỹ sư phần mềm, kỹ sư hệ thống người có kinh nghiệm Phân tích yêu cầu phần mềm Page 19 IT4460 Nhóm lĩnh vực yêu cầu phần mềm đọc phân tích yêu cầu, tìm vấn đề tiềm tàng để thảo luận, thống với công việc cần làm để giải vấn đề Đây kỹ thuật kiểm chứng yêu cầu sử dụng rộng rãi Có nhiều chứng tính hiệu kỹ thuật Kỹ thuật tốn kém: • • • Cần chuẩn bị lên kế hoạch cẩn thận Cần kiểm tra trước duyệt Cần danh sách kiểm duyệt phù hợp Một số kỹ thuật kiểm duyệt kiểm soát yêu cầu phần mềm: Phân theo hình thức 6.1 Đọc văn yêu cầu phần mềm: Yêu cầu người không tác giả văn yêu cầu phần mềm đọc kiểm duyệt Đọc phê duyệt: Khuyến khích người kiểm duyệt đọc cẩn thận có trách nhiệm Đọc lướt: Đây kỹ thuật không thức, mức tổng quát cao, đọc để có nhìn tổng quát văn yêu cầu Kỹ thuật cần phải dẫn dắt tác giả văn bản/chuyên gia Kỹ thuật kiểm duyệt thức (Formal Inspections): kiểm duyệt cách chi tiết, cụ thể có cấu trúc Xác định rõ ràng vai trò người tham gia kiểm duyệt xác dịnh rõ điều kiện để kết thúc việc kiểm duyệt Kiểm duyệt tập trung: Các chuyên viên kiểm duyệt có vai trò xác định, chuyên viên tìm kiếm số lỗi định yêu cầu phần mềm Kiểm duyệt tích cực: Tác giả văn hỏi trực tiếp chuyên viên kiểm duyệt câu hỏi liên quan đến văn Quy trình thực Plan review Đội kiểm duyệt lựa chọn, thời gian, địa điểm gặp mặt Phân tích yêu cầu phần mềm Page 20 IT4460 Nhóm ấn định Phân phát tài liệu liên quan Văn yêu cầu phần mềm phân phát cho thành viên đội kiểm duyệt Chuẩn bị cho việc kiểm duyệt yêu cầu Mỗi thành chuyên viên kiểm duyệt đọc yêu cầu để tìm xung đột, thiếu sót, mâu thuẫn, lệch chuẩn vấn đề khác Tổ chức gặp mặt Các vấn đề nhận xét cá nhân văn yêu cầu phần mềm đưa thảo luận, việc cần làm để giải vấn đề đưa Thực việc cần làm (kết bước 4) Giải vấn đề cách tuân thủ thực hành động thống bước Duyệt lại văn Văn yêu cầu phần mềm duyệt lại để kiểm chứng hợp lý hành động thống Kết bước này, văn cuối chấp nhận, cần kiểm duyệt lại Đôi khi, để giảm thiểu chi phí trình kiểm duyệt yêu cầu, cần phải thực bước "pre-review checking" Nghĩa kiểm tra văn tìm kiếm vấn đề trực tiếp, 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 Có thể áp dụng xây dựng xong bước đầu yêu cầu phần mềm từ biện pháp thu thập Khi đó, vấn đề tồn yêu cầu phần mềm Và cần phải loại bỏ vấn đề trước đem văn yêu cầu thương thảo Áp dụng cần xác minh yêu cầu viết thỏa mãn bên Phân tích yêu cầu phần mềm Page 21 IT4460 Nhóm liên quan Hay nói cách khác, tìm đồng thuận từ phía khác hàng 6.3 • • • Tác nhân tham gia Những người đến từ lĩnh vực khác mang đến kỹ kiến thức khác để kiểm duyệt yêu cầu phần mềm Họ cảm thấy tham gia có vai trò trình xây dựng yêu cầu phần mềm, họ hiểu nhu cầu/yêu cầu bên lại Nhóm kiểm duyệt luôn có bên chuyên gia, bên người dùng Các vấn đề kiểm duyệt: • • • • • Tính rõ ràng yêu cầu: Các yêu cầu diễn tả cách "tệ", khó hiểu, vô tình bỏ qua thông tin thu thập suốt trình xác định yêu cầu Thiếu thông tin: Một số thông tin vă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 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 xung đột Các yêu cầu không thực tế: Các yêu cầu thực (unimplementable) với trình độ công nghệ tại, với ràng buộc hệ thống Các bên liên quan tình cần bàn bạc để định làm cho yêu cầu trở nên thực tế Phân tích yêu cầu phần mềm Page 22 IT4460 Nhóm Kỹ thuật Fagan Inspection Fagan Inspection đặc trưng quy định tham gia, người kiểm duyệt tham gia người có vai trò kiểm duyệt Mỗi lần họp bàn không tiếng Chỉ cần khoảng thời gian thành viên tham gia kiểm duyệt tập trung vào công việc Cần - người kiểm duyệt Tác giả văn yêu cầu phần mềm đóng vai trò người trình diễn văn Các số liệu thu thập Điều quan trọng số liệu tác giả văn yêu cầu phần mềm đến Người người giám sát suốt trình kiểm duyệt Có 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 đảm bảo vấn đề tìm thấy phải sửa chữa Tất người kiểm duyệt cần tự chuẩn bị trước cách sử dụng danh sách kiểm duyệt (checklists) Các vấn đề ghi lại theo khuôn dạng đặc biệt Fagan Inspection giống "brain storming" phát yêu cầu phần mềm Nó phiên động não để phát vấn đề yêu cầu phần mềm Cần kiểm duyệt lại nhiều 5% văn yêu cầu phải thay đổi (bởi việc sửa chữa lỗi đó, lại phát sinh lỗi Sửa nhiều, dễ sinh lỗi mới) Phân tích yêu cầu phần mềm Page 23 IT4460 Phân tích yêu cầu phần mềm Nhóm Page 24 [...]... phẩm phần mềm - Những ảnh hưởng của Kiểm chứng yêu cầu: + Kiểm chứng yêu cầu giúp phần mềm được tạo ra đúng với đặc tả của yêu cầu phần mềm Nếu phát hiện ra lỗi, những nhà phát triển phần mềm sẽ được thông báo để sửa chữa, do đó đảm bảo rằng khi phần mềm được hoàn thành thì nó sẽ phù hợp với các đặc tả yêu cầu + Việc kiểm chứng yêu cầu. .. của quá trình Xác nhận yêu cầu phát hiện ra dẫn đến sự thay đổi của bản đặc tả yêu cầu phần mềm, dẫn đến một loạt phản ứng dây chuyền, làm thay đổi từ khâu phân tích thiết kế tới viết mã nguồn Phân tích yêu cầu phần mềm Page 13 IT4460 Nhóm 3 1.3 Ảnh hưởng của 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 hành thiết... tả yêu cầu phần mềm với bản đặc tả đó Sự khác 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. .. tiến hành bằng việc đối chiếu lại bản đặc tả yêu cầu phần mềm với mục tiêu và yêu cầu của các bên liên quan - Requirement Verification (Kiểm chứng yêu cầu) Đây là việc kiểm tra rằng có phải một sản phẩm đang được xây dựng đúng hay không Cần chắc chắn rằng mỗi bước được cho phép trong quá trình xây dựng phần mềm đều mang lại lợi ích cho việc xây dựng sản... mềm Page 12 IT4460 Nhóm 3 Các so sánh cụ thể: Xác nhận yêu cầu Kiểm chứng yêu cầu (Requirements Validation) (Requirements Verification) Xác nhận yêu cầu là các thủ tục kiểm tra động (thay đổi theo diễn biến của dự án, tùy vào các bên liên quan), có tác dụng để sửa chữa đặc tả yêu cầu Kiểm chứng yêu cầu là các thủ tục kiểm tra tĩnh (có các quy tắc cho... Ảnh 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 ảnh 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 bản chạy được của phần mềm và được dùng thử... 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 Phân tích yêu cầu phần mềm Page 17 IT4460 Nhóm 3 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à...IT4460 Nhóm 3 chúng làm văn bản trở nên thiếu tính nhất quán, các yêu cầu thiếu tính đơn nghĩa! Như vậy cần tránh sử dụng các từ gây nhầm lẫn và mang tính chủ quan Phân tích yêu cầu phần mềm Page 11 IT4460 Nhóm 3 1 Phân biệt Requirements Verification và Requirements Validation 1.1 Phân biệt - Requirements Validation (Xác nhận yêu cầu) Đây là việc kiểm tra rằng có phải một sản phẩm đúng... 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 Phân tích yêu cầu phần mềm Page 19 IT4460 Nhóm 3 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... 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