Bài giảng Phân tích yêu cầu phần mềm - Lecture 11: Đặc tả yêu cầu - Requirements Specifications cung cấp cho người học các kiến thức: Tại sao cần viết đặc tả, yêu cầu của sự Đặc tả, cấu trúc của một tài liệu yêu cầu. Mời các bạn cùng tham khảo nội dung chi tiết.
Phân tích yêu cầu phần mềm Lecture 11: Đặc tả yêu cầu Requirements Specifications Tại cần viết đặc tả Mục đích người tham gia đặc tả Chọn kích thước quy cách thích hợp Yêu cầu Đặc tả Các đặc tính đặc tả tốt Các vấn đề chủ yếu Những khơng cần thiết đặc tả Cấu trúc tài liệu yêu cầu Chuẩn IEEE Phân tích yêu cầu phần mềm Yêu cầu vs Đặc tả Application Domain Machine Domain C - computers D - domain properties P - programs R - requirements R: S: Tôi muốn bảng kê thuốc lập theo thứ tự thời gian 3.11.2.3 Khi nhận danh mục thuốc phân phối đến, hệ thống thêm loại thuốc theo thứ tự vào mục bảng kê có 3.11.2.4 Khi bảng kê lập xong, hệ thống … P: D: Bảng phân phối bảng kê phân loại thuốc theo nhóm thuốc C: Phân tích u cầu phần mềm Đặc tả yêu cầu phần mềm Thực kết nối Yêu cầu với khác nào? Cần mô tả chúng tài liệu SRS (Software Requirement Specification) Nhưng SRS thiết tài liệu giấy tờ Mục tiêu SRS Chuyển tải thơng tin Giải thích lĩnh vực ứng dụng hệ thống cần phát triển Lập hợp đồng Có lẽ ràng buộc hợp lệ! Biểu diễn thỏa thuận lời cam kết Cơ sở cho việc đánh giá phần mềm Hỗ trợ kiểm thử, V&V “Đủ thông tin để kiểm tra liệu hệ thống phân phối có đáp ứng yêu cầu” Cơ sở cho việc quản lý thay đổi Người dùng SRS Khách hàng & Người dùng Quan tâm đến yêu cầu hệ thống… …nhưng chi tiết yêu cầu phần mềm Nhà phân tích (yêu cầu) hệ thống Viết đặc tả liên quan khác Người phát triển, Lập trình viên Phải cài đặc yêu cầu Kiểm thử viên Phải kiểm tra yêu cầu đáp ứng Quản lý dự án Phải đo lường kiểm sốt dự án Phân tích u cầu phần mềm Đặc tả tương thích Xét dự án khác nhau: A) Dự án nhỏ, người lập trình, tháng làm việc Người lập trình thảo luận với khách hàng, sau viết khoảng 2-trang ghi B) Dự án lớn, 50 người lập trình, năm làm việc Đội phân tích lập mơ hình u cầu, sau viết khoảng 500-trang tài liệu đặc tả yêu cầu phần mềm (SRS – SoftwareRequirements Specifications) Mục tiêu đặc tả? Nhà quản trị? Người đọc? Project A Project B Tạo thấu hiểu cho người lập trình; phản hồi cho người dùng Lập tài liệu; có chứa đầy đủ chi tiết cho tất lập trình viên Đặc tả khơng thiết; có sẵn nguồn tài nguyên Dùng đặc tả để ước lượng nguồn tài nguyên cần thiết hoạch định phát triển Chủ yếu : Tác giả đặc tả Thứ yếu : Khách hàng Chủ yếu : Lập trình viên, nhà quản trị, kiểm thử viên Thứ yếu : Khách hàng Phân tích yêu cầu phần mềm Một biến dạng: Tài liệu thầu (Procurement) Một ‘SRS’ viết bởi… …Nhà thầu (the procurer): SRS thực lời mời cho đề xuất Phải đủ tổng quát để chọn lựa người đấu thầu tốt… …và đủ chi tiết để loại bỏ người đấu thầu không hợp lý …Người đấu thầu (the bidders): SRS đề xuất để cài đặt hệ thống đáp ứng khách hàng Phải đủ chi tiết để chứng tỏ tính khả thi khả vể kỹ thuật …và đủ tổng quát để tránh vượt cam kết …Nhà phát triển tuyển chọn: Phản ánh thấu hiểu yêu cầu khách hàng nhà phát triển Một hình thức sở cho đánh giá việc thực thi hợp đồng …hoặc người thầu RE độc lập! Chọn lựa quan điểm để hoàn thành hợp đồng Sớm (giai đoạn khái niệm) đánh giá nhà đấu thầu lực khả biểu lộ Trễ (giai đoạn đặc tả chi tiết) nhiều công việc cho nhà thầu; kỹ RE phù hợp khơng có sẵn Chuẩn IEEE đề nghị SRS nên xây dựng nhà thầu người phát triển Phân tích yêu cầu phần mềm Các đặc tính SRS Source: Adapted from IEEE-STD-830-1998 Hợp lệ (hoặc “đúng”) Diễn tả nhu cầu thực đối tác (khách hàng, người dùng, …) Không có chứa thứ khơng “u cầu” Khơng mơ hồ Mỗi câu đọc xác theo cách Hoàn chỉnh Tất thứ hệ thống phải thực hiện… …và tất thứ khơng làm ! Hoàn thiện mức khái niệm E.g đáp ứng tất lớp input Hoàn thiện mức cấu trúc E.g không vi phạm chuẩn!!! Dễ hiểu (Rõ ràng) E.g người không chuyên môn máy tính Nhất qn Khơng chứa mâu thuẫn nội Sử dụng quán tất thuật ngữ Có thứ bậc Chỉ rõ quan hệ quan trọng /ổn định yêu cầu Dễ kiểm tra Một tiến trình tồn để kiểm thử thỏa mãn yêu cầu Dễ sửa đổi Có thể thay đổi khơng khó khăn Cấu trúc tốt tham khảo chéo Dễ lần vết Nguồn gốc yêu cầu rõ ràng Gán nhãn yêu cầu cho tham khảo sau Phân tích u cầu phần mềm Khơng có SRS hoàn chỉnh! Mơ hồ mở rộng mở rộng rút lại giảm Dư thừa hình thức hóa Khơng qn dẫn đến thêm giải thích Khơng dễ hiểu Khơng đầy đủ …etc! Phân tích u cầu phần mềm Dùng ký pháp phù hợp Source: Adapted from Easterbrook & Callahan, 1997 Ngôn ngữ tự nhiên? “Hệ thống báo cáo cho người điều khiển tất lỗi phát sinh từ chức then chốt xuất suốt thực quy trình then chốt khơng có lỗi tìm nguyên nhân.” (Điều theo đặc tả thực tế NASA trạm không gian quốc tế) Hoặc bảng định (decision table)? Phát sinh chức then chốt? F T F T F T F T Xuất quy trình then chốt? F F T T F F T T Khơng có lỗi tìm nguyên nhân? F F F F T T T T Báo cáo cho người điều khiển ? Phân tích yêu cầu phần mềm Nội dung SRS Đặc tả yêu cầu phần mềm cần trọng: Chức hóa Nhiệm vụ phần mềm làm gì? Giao diện bên Phần mềm tương tác với người, phần cứng hệ thống, phần cứng khác, phần mềm khác? Giả định phát sinh từ thực thể bên này? Yêu cầu thực thi Tốc độ, sẵn dùng, thời gian đáp ứng, thời gian phục hồi chức phần mềm khác thứ khác? Các thuộc tính chất lượng Tính khả chuyển, tính xác, khả bảo trì, tính bảo mật xem xét khác? Các ràng buộc thiết kế phải tuân theo q trình cài đặt Có tác động chuẩn yêu cầu, ngôn ngữ cài đặt, sách tồn vẹn CSDL, giới hạn nguồn tài nguyên, môi trường vận hành thứ khác? Phân tích u cầu phần mềm SRS khơng cần bao gồm … Source: Adapted from Davis, 1990, p183 Những kế hoạch phát triển dự án E.g chi phí, đội ngũ nhân viên, lịch biểu, phương pháp, công cụ, etc Chu kỳ sống SRS phần mềm lỗi thời Chu kỳ sống kế hoạch phát triền ngắn nhiều Những kế hoạch đảm bảo dự án Quản lý cấu hình, kiểm tra & kiểm chứng, kế hoạch kiểm thử, đảm bảo chất lượng, etc Nhóm người tham gia khác Chu kỳ sống khác Các thiết kế Lập yêu cầu làm thiết kế có người tham gia khác Phân tích thiết kế phạm vi chun mơn khác I.e Nhà phân tích u cầu khơng thực thiết kế! Ngoại trừ ràng buộc phạm vi ứng dụng thiết kế e.g Sự giao tiếp giới hạn hệ thống khác lý bảo mật 10 Phân tích u cầu phần mềm Các dạng lỗi điển hình Source: Adapted from Kovitz, 1999 Nhiễu (Noise) Văn chứa thông tin khơng liên quan đến đặc tính vấn đề Im lặng (Silence) Đặc tính khơng đề cập Đặc tả thừa (Over-specification) Văn mô tả định thiết kế cách chi tiết mô tả vấn đề Mâu thuẫn Văn định nghĩa đặctính theo số cách trái ngược Mơ hồ Văn thơng dịch theo cách khác Tham khảo lùi (Forward Ref.) Sự tham khảo đến thuật ngữ đặc tính mà chưa định nghĩa Mơ mộng (Wishful thinking) Văn mô tả siêu thực – đặc tinh mà kiểm tra Đặt yêu cầu với người dùng Không thể yêu cầu người dùng thực việc đó, mà giả sử họ làm Chơi trị xếp hình (Jigsaw puzzles) Thơng tin then chốt phân bố chéo tài liệu có tham khảo chéo Yêu cầu bề (Duckspeak) Yêu cầu dùng để xác nhận theo chuẩn Phát minh không cần thiết E.g ‘chức trình diễn input người dùng’ Thuật ngữ khơng qn Phát minh sau thay đổi thuật ngữ Đặt trách nhiệm vào người phát triển i.e làm cho người đọc phải vất vả để đốn mục đích Viết cho người đọc thù địch Có người đọc dạng người đọc thân thiện 11 Phân tích yêu cầu phần mềm Tổ chức Yêu cầu Cần tổ chức logic cho tài liệu Chuẩn IEEE cung cấp kiểu mẫu khác cho việc Ví dụ cấu trúc – tổ chức … …Tác nhân bên ngồi tình trạng bên ngồi e.g., cho hệ thống điều khiển máy bay hạ cánh, kiểu khác tình trạng hạ cánh: gió mạnh, khơng có nhiên liệu, đường băng ngắn, etc …Đặc tính hệ thống e.g., cho hệ thống điện thoại: chuyển hướng gọi, ngăn chặn gọi, nhóm gọi, etc …Đáp ứng hệ thống e.g., cho hệ thống tính lương: phát sinh số tiền, báo cáo chi phí, in thơng tin thuế; …Đối tượng bên ngồi e.g cho hệ thống thông tin thư viện, tổ chức cách phân loại sách …Kiểu người dùng e.g cho hệ thống hỗ trợ dự án: nhà quản trị, đội kỹ thuật, người quản lý, etc …Cách thức (mode) e.g cho xử lý từ (word processor): cách dàn trang (page layout mode), cách định dạng (outline mode), cách soạn thảo văn (text editing mode), etc …Hệ thống e.g cho tàu vũ trụ: điều khiển & kiểm soát, quản lý liệu, truyền thông tin, thiết bị đo, etc 12 Phân tích yêu cầu phần mềm Chuẩn IEEE cho SRS Source: Adapted from IEEE-STD-830-1993 See also, Blum 1992, p160 Introduction Purpose Scope Definitions, acronyms, abbreviations Reference documents Overview Overall Description Product perspective Product functions User characteristics Constraints Assumptions and Dependencies Specific Requirements Appendices Index Định nghĩa sản phẩm lĩnh vực ứng dụng Mô tả nội dung cấu trúc tài liệu yêu cầu Mô tả tất giao diện bên ngoài: hệ thống, người dùng, phần cứng, phần mềm, hệ điều hành, ràng buộc phần cứng Tổng quát chức chủ yếu, trường hợp sử dụng Mọi thứ hạn chế lựa chọn nhà phát triển (như luật lệ, độ tin cậy, trích, giới hạn phần cứng, tương quan, …) Tất yêu cầu viết (đây phần thân tài liệu) Chuẩn IEEE-STD cung cấp mẫu khác cho mục 13 Phân tích yêu cầu phần mềm Chuẩn IEEE STD Mục (Ví dụ) Source: Adapted from IEEE-STD-830-1993 See also, Blum 1992, p160 3.1 Yêu cầu giao diện bên 3.1.1 Giao diện người dùng 3.1.2 Giao diện phần cứng 3.1.3 Giao diện phần mềm 3.1.4 Giao diện truyền thông tin 3.2 Các yêu cầu chức Mục tổ chức chế độ vận hành (mode), lớp người dùng, đặc tính, etc Chẳng hạn: 3.2.1 Mode 3.2.1.1 Yêu cầu chức 1.1 … 3.2.2 Mode 3.2.1.1 Yêu cầu chức 1.1 … 3.2.2 Mode n 3.3 Các yêu cầu thực thi Lưu ý mô tả ngữ cảnh độ đo! 3.4 Các ràng buộc thiết kế 3.4.1 Các chuẩn thỏa thuận 3.4.2 Các giới hạn phần cứng etc 3.5 Các đặc tính hệ thống phần mềm 3.5.1 Độ tin cậy 3.5.2 Tính sẵn dùng 3.5.3 Tính bảo mật 3.5.4 Khả bảo trì 3.5.5 Tính khả chuyển 3.6 Các u cầu khác 14 Phân tích yêu cầu phần mềm Kết luận Đặc tả yêu cầu nhằm số mục đích: Chuyển tải thơng tin Lập hợp đồng Làm sở cho việc kiểm tra Làm sở cho việc quản lý thay đổi Đặc tả yêu cầu có số dạng người dùng: Có chun mơn khơng chun mơn Đặc tả tốt khó viết Hồn chỉnh, quán, hợp lệ, không mơ hồ, dễ kiểm tra, dễ sửa đổi, dễ lần vết… Dự án cần phải thay đổi Tổng công sức đặt vào đặc tả phụ thuộc vào hậu phát sinh lỗi yêu cầu 15 .. .Phân tích yêu cầu phần mềm Yêu cầu vs Đặc tả Application Domain Machine Domain C - computers D - domain properties P - programs R - requirements R: S: Tôi muốn bảng... quan, …) Tất yêu cầu viết (đây phần thân tài liệu) Chuẩn IEEE-STD cung cấp mẫu khác cho mục 13 Phân tích yêu cầu phần mềm Chuẩn IEEE STD Mục (Ví dụ) Source: Adapted from IEEE-STD-83 0-1 993 See also,... thống phân phối có đáp ứng yêu cầu” Cơ sở cho việc quản lý thay đổi Người dùng SRS Khách hàng & Người dùng Quan tâm đến yêu cầu hệ thống… …nhưng chi tiết yêu cầu phần mềm Nhà phân tích (yêu cầu)