NEW
Font size
WorksheetsCâu hỏi về Phân tích và đặc tả yêu cầu phần mềm
Total questions: 21
Worksheet time: 11mins
Yêu cầu phần mềm là gì?
Là đoạn mã nguồn mà lập trình viên viết ra để hệ thống hoạt động.
Là những mô tả chi tiết về những gì hệ thống phần mềm cần phải thực hiện và những ràng buộc nó phải thỏa mãn, bao gồm cả chức năng và phi chức năng.
Là bản thiết kế giao diện để người dùng sử dụng phần mềm.
Là hướng dẫn cài đặt phần mềm.
Vì sao cần có yêu cầu phần mềm rõ ràng?
Để lập trình viên không phải trao đổi với khách hàng nhiều lần.
Để đảm bảo tất cả các bên (khách hàng, đội phát triển, đội kiểm thử) có chung một hiểu biết thống nhất về hệ thống cần làm, giảm rủi ro và chi phí sửa đổi sau này.
Vì đây chỉ là thủ tục hành chính bắt buộc.
Để tiết kiệm thời gian lập trình.
Yêu cầu chức năng (Functional Requirement) là gì?
Là các tính năng, hành vi cụ thể mà hệ thống phải cung cấp cho người dùng hoặc hệ thống khác. Ví dụ: Hệ thống cho phép độc giả tìm kiếm sách.
Là các ràng buộc về hiệu năng, bảo mật, độ tin cậy. Ví dụ: Hệ thống hoạt động tốt trên các trình duyệt web.
Là các tài liệu thiết kế chi tiết.
Là yêu cầu từ phía nhà quản lý dự án.
Ví dụ nào là yêu cầu chức năng?
Hệ thống phải xử lý 1000 yêu cầu/giây.
Người dùng có thể đăng nhập và thay đổi mật khẩu cá nhân.
Hệ thống phải chạy trên trình duyệt Chrome.
Phần mềm phải tuân thủ chuẩn ISO 9001.
Yêu cầu phi chức năng (Non-functional Requirement) là gì?
Là các chức năng bổ sung ít quan trọng.
Là các yêu cầu về cách thức hệ thống vận hành như hiệu năng, tính khả dụng, bảo mật, tính di động.
Là yêu cầu người dùng nhập dữ liệu.
Là các đặc tả của thuật toán.
Ví dụ nào là yêu cầu phi chức năng?
Người dùng có thể in hóa đơn sau khi mua hàng.
Hệ thống phải hồi trong vòng 1 giây cho mỗi thao tác tìm kiếm.
Người dùng có thể tạo tài khoản mới.
Khách hàng có thể đổi mật khẩu.
Quy trình kỹ nghệ yêu cầu (Requirement Engineering) gồm những bước nào?
Thu thập và phân tích yêu cầu – Đặc tả yêu cầu – Thẩm định yêu cầu.
Thiết kế – Lập trình – Kiểm thử.
Mục đích của bước Thu thập yêu cầu là gì?
Để phân công công việc cho nhóm lập trình.
Để hiểu rõ nhu cầu, mong muốn và bối cảnh thực tế của khách hàng, từ đó xác định đúng phạm vi và mục tiêu của phần mềm.
Để kiểm thử phần mềm.
Để lập kế hoạch ngân sách dự án.
Bước Thẩm định yêu cầu nhằm mục đích gì?
Kiểm tra phần mềm đã lập trình có chạy đúng không.
Đảm bảo các yêu cầu đã được ghi lại chính xác, đầy đủ, không mâu thuẫn và phản ánh đúng mong muốn của khách hàng.
Kiểm thử giao diện phần mềm.
Kiểm tra mã nguồn có tối ưu không.
Một yêu cầu tốt cần có thuộc tính “Tính nhất quán” (Consistency). Điều đó nghĩa là gì?
Các yêu cầu không được mâu thuẫn với nhau, tránh gây hiểu nhầm cho nhóm phát triển.
Các yêu cầu dễ đọc, dễ hiểu.
Các yêu cầu được viết bằng cùng một ngôn ngữ.
Các yêu cầu phải giống hệt trong mọi tài liệu.
Thuộc tính “Tính khả kiểm” (Verifiability) của yêu cầu nghĩa là gì?
Yêu cầu phải có thể đo lường hoặc kiểm chứng được thông qua kiểm thử hoặc đánh giá.
Yêu cầu phải dễ nhớ đối với lập trình viên.
Yêu cầu phải ngắn gọn.
Yêu cầu không được thay đổi theo thời gian.
Thuộc tính “Tính chính xác” (Correct) của SRS nghĩa là gì?
Các yêu cầu được viết ngắn gọn, không dài dòng.
Mỗi yêu cầu phải phản ánh đúng nhu cầu thực tế của khách hàng và các bên liên quan, không có sai lệch so với mong muốn ban đầu.
Các yêu cầu được viết bằng ngôn ngữ hình thức.
Các yêu cầu không thay đổi theo thời gian.
Thuộc tính “Tính đầy đủ” (Complete) của SRS nghĩa là gì?
Tài liệu chỉ liệt kê một số yêu cầu quan trọng nhất.
Tài liệu phải bao quát tất cả các yêu cầu chức năng và phi chức năng, bao gồm cả các ràng buộc, trường hợp đặc biệt và các điều kiện biên.
Tài liệu chỉ cần viết các yêu cầu chức năng.
Tài liệu không cần mô tả giao diện hay dữ liệu.
Thuộc tính “Tính không nhập nhằng” (Unambiguous) của SRS nghĩa là gì?
Mỗi yêu cầu chỉ có một cách hiểu duy nhất, không gây hiểu nhầm cho người đọc.
Các yêu cầu phải ngắn gọn.
Các yêu cầu phải dễ kiểm thử.
Các yêu cầu không được thay đổi theo thời gian.
Sắp xếp độ quan trọng và độ ổn định của mỗi yêu cầu có ý nghĩa gì trong SRS?
Các yêu cầu cần được đánh dấu rõ ràng về mức độ ưu tiên (quan trọng/ít quan trọng) và mức độ ổn định (ít thay đổi/thường xuyên thay đổi) để hỗ trợ lập kế hoạch phát triển và quản lý rủi ro.
Các yêu cầu phải được viết theo thứ tự chữ cái A–Z.
Các yêu cầu được nhóm theo chức năng.
Các yêu cầu phải được viết bởi cùng một người.
Đặc tả yêu cầu phần mềm (Software Requirements Specification - SRS) là gì?
Là tài liệu thiết kế chi tiết của hệ thống.
Là tài liệu chính thức mô tả đầy đủ, chi tiết tất cả các yêu cầu chức năng và phi chức năng mà phần mềm phải đáp ứng.
Là bản hướng dẫn sử dụng phần mềm.
Là tài liệu kiểm thử phần mềm.
Mục tiêu chính của đặc tả yêu cầu là gì?
Để giảm công việc lập trình.
Để tạo ra cơ sở thống nhất cho tất cả các bên (khách hàng, nhà phát triển, kiểm thử) về hệ thống cần xây dựng.
Để thay thế giai đoạn phân tích.
Để viết kế hoạch dự án.
Tài liệu SRS thường trả lời cho câu hỏi nào?
Hệ thống sẽ được triển khai như thế nào (How).
Vì sao cần xây dựng hệ thống (Why).
Hệ thống cần làm gì, chức năng và ràng buộc nào phải đáp ứng (What).
Ai sẽ tham gia phát triển hệ thống (Who).
Những thành phần thường có trong tài liệu SRS là gì?
Giới thiệu, mô tả tổng quan, yêu cầu chức năng, yêu cầu phi chức năng, ràng buộc hệ thống, phụ lục.
Kế hoạch dự án, tiến độ, chi phí.
Biểu đồ Gantt, sơ đồ nguồn nhân lực.
Kế hoạch kiểm thử chi tiết.
Tại sao tài liệu SRS quan trọng trong quá trình phát triển phần mềm?
Vì đây là căn cứ pháp lý, cơ sở cho thiết kế, lập trình, kiểm thử và cả việc bàn giao sản phẩm.
Vì đây là hướng dẫn sử dụng cho người dùng.
Vì đây là bản thiết kế giao diện.
Ai thường là người viết và chịu trách nhiệm chính về SRS?
Lập trình viên.
Business Analyst hoặc nhóm phân tích hệ thống, với sự tham gia của khách hàng và nhóm phát triển.
Người dùng cuối.
Tester.
