Yêu cầu phần mềm (Requirements) GV: Hoàng Thị Hà

Chương 3: Yêu cầu phần mềm (Requirements) GV: Hoàng Thị Hà Email: htha@vnua.edu.vn 05/10/2018 Nội dung Yêu cầu phần mềm Tiến trình kỹ nghệ yêu cầu – Nghiên cứu khả thi – Thu thập phân tích u cầu • Các phương pháp phát u cầu • Các kỹ thuật phân tích u cầu – Làm tài liệu yêu cầu – Thẩm định yêu cầu Đặc tả yêu cầu phần mềm Yêu cầu phần mềm • Tiêu chí quan trọng chất lượng phần mềm? Phần mềm thỏa mãn yêu cầu người dùng • Yêu cầu phần mềm: Những người ta muốn có phần mềm phát triển Ví dụ Travel Agency: Yêu cầu người dùng • Hãng du lịch TravelGood đến gặp bạn (người làm phần mềm) đề nghị làm dự án phần mềm sau: – Mơ tả tốn / u cầu người dùng TravelGood muốn cung cấp cho khách hàng họ ứng dụng đặt vé lập kế hoạch du lịch Ứng dụng cần cho phép khách lập kế hoạch chuyến bay khách sạn Đầu tiên, khách hàng xếp chuyến đi, sau đặt vé đặt phịng khách sạn cho chuyến Người dùng lập kế hoạch cho nhiều chuyến Ngồi ra, phần mềm cịn cho phép hủy chuyến đặt Ví dụ Travel Agency: Yêu cầu hệ thống • Sau nhận làm phần mềm cho TravelGood đội phát triển chi tiết hóa thành yêu cầu hệ thống: Người dùng lập kế hoạch chuyến cách chọn trình tự điểm đến, lưu lại (kèm theo sơ đồ mô tả kịch ca sử dụng) Hệ thống cần ứng dụng Web, chạy tất hệ điều hành hầu hết trình duyệt Ứng dụng Web phải triển khai server tiêu chuẩn GlassFish Tomcat Hệ thống phải dễ sử dụng: đạt test usability (kèm chi tiết cụ thể) … Project: Hệ thống quản lý luận văn cao học • Học viên cao học ngành CNTT cần làm luận văn tốt nghiệp Mỗi luận văn có 01 giáo viên hướng dẫn Trong q trình làm luận văn, học viên có hoạt động sau mà giáo vụ Khoa cần quản lý: – Học viên đăng ký làm luận văn (đề cương giáo viên hướng dẫn) – Báo cáo tiến độ theo đợt Khoa tổ chức, học viên cần đăng ký có giáo viên hướng dẫn đồng ý, báo cáo hội đồng có ghi lại nhận xét – Bảo vệ luận văn theo đợt, Khoa tổ chức, giáo viên hướng dẫn đồng ý Software requirements Hệ thống quản lý luận văn cao học • Học viên – Được cấp tài khoản sử dụng hệ thống – đăng ký đề tài với giáo viên hướng dẫn theo quy trình (các bước sơ đồ gắn kèm) – tra cứu tên thơng tin giáo viên – xem danh sách đề tài đăng ký • Giáo vụ – Xem danh sách học viên đăng ký đề tài – Tạo tài khoản cho học viên theo danh sách • • • • • • học viên tối đa luận văn giáo viên hướng dẫn giáo viên hướng dẫn nhiều học viên Hệ thống có giao diện Web HỌc viên sửa thơng tin thân Cho phép 1000 người sử dụng song song Chạy IE, Chrome, Cốc Cốc, Firefox, Opera Mini, Safari Ví dụ khác Đặc tả yêu cầu người dùng Phần mềm phải cung cấp phương tiện để biểu diễn truy nhập file bên tạo công cụ khác Đặc tả yêu cầu hệ thống 1.1 Người dùng cần cung cấp tiện ích để định nghĩa kiểu file 1.2 Mỗi kiểu file ngồi biểu diễn dạng biểu tượng phần hiển thị người dùng 1.3 Mỗi kiểu file ngồi có cơng cụ dùng cho loại file 1.4 Cần cung cấp tiện ích để người dùng định nghĩa biểu tượng cho file 1.5 Khi người dùng chọn biểu tượng đại diện cho file ngoài, hiệu ứng việc chọn gọi cơng cụ tương ứng với kiểu file để chạy 88 Yêu cầu người dùng / Yêu cầu hệ thống • Yêu cầu người dùng - User requirements – Các phát biểu ngôn ngữ tự nhiên cộng với sơ đồ dịch vụ mà hệ thống cung cấp ràng buộc vận hành – Được viết cho khách hàng • Yêu cầu hệ thống – System requirements – Một tài liệu có cấu trúc bao gồm mô tả chi tiết chức dịch vụ hệ thống với ràng buộc vận hành – Định nghĩa cần cài đặt • Có thể phần hợp đồng khách hàng người nhận thầu Ví dụ yêu cầu hệ thống Identifier Priority Requirement REQ1 The system shall keep the door locked at all times, unless commanded otherwise by authorized user When the lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically armed (if still disarmed) REQ2 The system shall lock the door when commanded by pressing a dedicated button REQ3 The system shall, given a valid key code, unlock the door and activate other devices REQ4 The system should allow mistakes while entering the key code However, to resist “dictionary attacks,” the number of allowed failed attempts shall be small, say three, after which the system will block and the alarm bell shall be sounded REQ5 The system shall maintain a history log of all attempted accesses for later review REQ6 The system should allow adding new authorized persons at runtime or removing existing ones REQ7 The system shall allow configuring the preferences for device activation when the user provides a valid key code, as well as when a burglary attempt is detected REQ8 The system should allow searching the history log by specifying one or more of these parameters: the time frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.) This function shall be available over the Web by pointing a browser to a specified URL REQ9 The system should allow filing inquiries about “suspicious” accesses This function shall be available over the Web 10 05/10/2018 Thẩm định yêu cầu • (Requirement validation) quan tâm đến việc chứng tỏ yêu cầu định nghĩa hệ thống mà khách hàng thực muốn • Chi phí lỗi yêu cầu cao đến mức công đoạn thẩm định quan trọng – Việc sửa lỗi yêu cầu sau bàn giao phần mềm tốn gấp 100 lần chi phí cho việc sửa lỗi cài đặt 56 Các tiêu chí cho thẩm định • Hiệu lực – Validity – Hệ thống có cung cấp chức phục vụ tốt yêu cầu khách hàng hay khơng? • Nhất qn – Consistency – Có yêu cầu xung đột khơng? • Đầy đủ – Completeness – Có đủ chức mà khách hàng địi hỏi hay khơng? • Thực tế – Realism – Có thể cài đặt yêu cầu phạm vi công nghệ ngân sách cho phép hay khơng? • Kiểm định – Verifiability – Có cách kiểm tra yêu cầu xem chúng thỏa mãn chưa hay không? 57 Kĩ thuật thẩm định yêu cầu • Duyệt yêu cầu – Requirements reviews – Đọc phân tích lại cách có hệ thống (khơng dùng chương trình tự động) • Phiên thử nghiệm – Prototyping – Dùng mơ hình chạy hệ thống để kiểm tra yêu cầu (Chương 17) • Tạo ca kiểm thử (test case) – Viết test dành cho yêu cầu để kiểm tra khả kiểm thử 58 Quản lý yêu cầu Yêu cầu phần mềm luôn thay đổi! • Mơi trường doanh nghiệp kĩ thuật thay đổi – Phần cứng  giao diện – Luật thay đổi, nhu cầu doanh nghiệp thay đổi  thay đổi chức • Khách hàng, người sử dụng thay đổi – Thay đổi chức • Xung đột yêu cầu nảy sinh, yêu cầu với yêu cầu cũ 59 Quản lý yêu cầu • Để quản lý yêu cầu, cần xác định – Định danh yêu cầu: Mỗi yêu cầu có định danh riêng để tiện cho việc tham chiếu yêu cầu lần vết – Quy trình quản lý thay đổi: hoạt động đánh giá ảnh hưởng chi phí thay đổi – Chính sách lần vết: cách ghi lại lưu trữ quan hệ yêu cầu yêu cầu với thiết kế tương ứng với – Cơng cụ hỗ trợ: hỗ trợ thực cơng việc cách có hiệu CASE tool, spreadsheet, sở liệu 60 Quản lý thay đổi Xác định vấn đề Phân tích vấn đề, đặc tả thay đổi Phân tích thay đổi & đánh giá chi phí Thực thay đổi Yêu cầu chỉnh sửa 05/10/2018 61 Quản lý thay đổi yêu cầu • Nên áp dụng cho tất thay đổi đề xuất yêu cầu • Các giai đoạn – Phân tích vấn đề: Thảo luận vấn đề yêu cầu đề xuất thay đổi; Bổ sung chi tiết; Chốt lại điểm thay đổi – Phân tích thay đổi đánh giá chi phí Đánh giá hiệu ứng thay đổi yêu cầu khác; Ra định có thực thay đổi hay khơng – Thực thay đổi Cập nhật tài liệu yêu cầu tài liệu khác để thực thay đổi xét 62 Đặc tả yêu cầu phần mềm 63 Khái niệm • Đặc tả yêu cầu phần mềm công việc xây dựng tài liệu đặc tả • Tài liệu đặc tả yêu cầu tài liệu mô tả hướng khách hàng viết ngơn ngữ khách hàng Khi dùng ngôn ngữ tự nhiên khái niệm trừu tượng • Tài liệu đặc tả yêu cầu (đặc tả chức năng) mô tả hướng người phát triển, sở hợp đồng làm phần mềm Nó khơng phép mơ hồ, không dẫn đến hiểu nhầm khách hàng người phát triển Với yêu cầu mơ hồ người phát triển thực cách rẻ cịn khách hàng khơng muốn vậy., sử dụng tới cơng cụ như: mơ hình hóa, mơ hình tốn học hình thức (a formal mathematical model), tập hợp kịch sử dụng, nguyên mẫu tổ hợp cơng cụ nói 64 Các phương pháp đặc tả • Có hai phương pháp đặc tả: – Đặc tả phi hình thức – Đặc tả hình thức 65 Các tính chất Tài liệu đặc tả phần mềm – Đúng – Không nhập nhằng – Hoàn chỉnh – Chứng minh – Ổn định – Dễ hiểu (bởi NSD) – Ngắn gọn, xúc tích 66 Cấu trúc tài liệu đặc tả • Kết bước phân tích tạo đặc tả yêu cầu phần mềm (Software Requirement Specification – SRS) Đặc tả yêu cầu phải rõ phạm vi sản phẩm, chức cần có, đối tượng người sử dụng ràng buộc vận hành sản phẩm Có nhiều chuẩn khác xây dựng tài liệu, định dạng SRS thông dụng (theo chuẩn IEEE 830-1984) Cấu trúc tài liệu đặc tả sau: 67 Cấu trúc tài liệu đặc tả (theo chuẩn IEEE – chuẩn tài liệu đặc tả yêu cầu) Lời nói đầu Giới thiệu – – – – Mô tả chung – – – – – Tổng quan sản phẩm Chức sản phẩm Đối tượng người dùng Ràng buộc tổng thể Giả thiết lệ thuộc Yêu cầu chi tiết – – – – – – – Mục đích Phạm vi Định nghĩa Tài liệu tham khảo Yêu cầu chức Yêu cầu phi chức Yêu cầu giao diện Yêu cầu hiệu suất Ràng buộc thiết kế Thuộc tính Yêu cầu khác Phụ lục Mục lục 68 CÂU HỎI VÀ BÀI TẬP CHƯƠNG 3 Yêu cầu phần mềm gì? Có loại u cầu phần mềm gì? Cho ví dụ minh họa hệ thống phần mềm nhúng cho máy rút tiền tự động ATM ngân hàng Có loại tài liệu yêu cầu phần mềm nào? Đối tượng loại tài liệu yêu cầu ai? Trình bày bước tiến trình phát phân tích u cầu Trình bày kỹ thuật khác để nhận biết phân tích yêu cầu Cấu trúc tài liệu yêu cầu gồm mục gì? Đặc tả u cầu phần mềm gì? Có hình thức đặc tả nào? Khi cần áp dụng hình thức đặc tả này? Hãy thu thập phân tích yêu cầu viết tài liệu đặc tả yêu cầu Phần mềm Quản lý vật tư Khoa CNTT- Học viện Nông nghiệp Việt Nam 69 Question? 70