Tính chất chất lượng bên ngoài (external quality attribute) là những đặc điểm của một hệ thống hoặc phần mềm mà người dùng quan tâm. Các lựa chọn bên dưới đều là tính chất chất lượng bên ngoài, ngoại trừ một trong số đó. Tính sẵn có (Availability) là khả năng của hệ thống để sẵn sàng sử dụng khi người dùng cần. Tính toàn vẹn (Integrity) là khả năng của hệ thống để đảm bảo dữ liệu được cập nhật và lưu trữ chính xác. Tính an toàn (Safety) là khả năng của hệ thống để đảm bảo an toàn cho người dùng và hệ thống. Tính tái sử dụng (Reusability) là khả năng của hệ thống để được sử dụng lại trong nhiều dự án khác nhau. Tuy nhiên, tính tái sử dụng không phải là một tính chất chất lượng bên ngoài, mà là một tính chất chất lượng bên trong (internal quality attribute).

Throwaway prototype là một loại prototype được xây dựng để đáp ứng nhu cầu cụ thể trong một giai đoạn nhất định. Nó thường được sử dụng khi đội ngũ phát triển gặp phải sự không chắc chắn, mơ hồ, không đầy đủ hoặc không rõ ràng trong yêu cầu. Mục đích chính của một prototype như vậy là để trả lời các câu hỏi, giải quyết sự không chắc chắn và cải thiện chất lượng yêu cầu. Khi xây dựng một prototype như vậy, đội ngũ phát triển không cần phải tuân thủ các kỹ thuật xây dựng phần mềm nghiêm ngặt. Điều này cho phép họ tập trung vào việc giải quyết các vấn đề quan trọng và tạo ra một sản phẩm có thể đáp ứng nhu cầu của khách hàng. Tuy nhiên, nó không phải là một sản phẩm cuối cùng và có thể được loại bỏ sau khi hoàn thành.

Một mockup là một mô hình giả lập của hệ thống, thường được sử dụng trong quá trình thiết kế và phát triển phần mềm. Nó cho phép người dùng tương tác với hệ thống và đánh giá các tính năng và giao diện người dùng. Trong các lựa chọn trên, câu trả lời sai là 'nó đi sâu vào tất cả các lớp kiến trúc hoặc vào chi tiết chức năng'. Điều này không đúng vì mockup thường chỉ tập trung vào giao diện người dùng và các hành vi cơ bản của hệ thống, chứ không phải tất cả các lớp kiến trúc và chi tiết chức năng.

Khi bạn tạo bản mẫu toàn bộ giải pháp thay vì chỉ những phần có khả năng cao nhất, rủi ro cao nhất hoặc phức tạp nhất, bạn sẽ gặp phải một số vấn đề. Đầu tiên, bạn có thể đang đầu tư quá nhiều nỗ lực vào bản mẫu, điều này có thể dẫn đến lãng phí thời gian và nguồn lực. Thứ hai, bạn có thể bị phân tâm bởi những chi tiết nhỏ nhặt, điều này có thể khiến bạn mất tập trung vào mục tiêu chính. Cuối cùng, bạn có thể gặp áp lực phải phát hành bản mẫu sớm, điều này có thể dẫn đến việc bạn phải cắt giảm các tính năng quan trọng hoặc giảm chất lượng của bản mẫu. Ngoài ra, bạn cũng có thể tạo ra những kỳ vọng không thực tế về hiệu suất của bản mẫu, điều này có thể dẫn đến thất vọng khi bản mẫu không đạt được những kỳ vọng đó.

Kỹ thuật MoSCoW là một phương pháp được sử dụng để xác định ưu tiên các yêu cầu trong một dự án. Mỗi chữ cái viết hoa trong MoSCoW đại diện cho một mức độ ưu tiên khác nhau. M - Must (Phải có), S - Should (Nên có), C - Could (Có thể có), W - Won't (Không có). Vì vậy, đáp án đúng là "Must, Should, Could, Won't".

Câu hỏi này yêu cầu bạn xác định hoạt động không liên quan đến xác minh yêu cầu. Trong quá trình phát triển yêu cầu, có bốn thành phần chính: xác định yêu cầu, phân tích yêu cầu, xác minh yêu cầu và xác định yêu cầu. Xác minh yêu cầu là một hoạt động quan trọng để đảm bảo yêu cầu có tất cả các tính chất mong muốn của yêu cầu chất lượng cao. Nó cũng đảm bảo rằng yêu cầu đã được viết đúng và có liên quan đến mục tiêu kinh doanh. Tuy nhiên, câu trả lời không chính xác trong lựa chọn này là "Itis the fourth component of requirements development." vì nó chỉ là một phần của quá trình phát triển yêu cầu, không phải là hoạt động xác minh yêu cầu.

Một bản mẫu phần mềm là một bản dựng thử nghiệm của một sản phẩm mới. Nó thường được tạo ra để kiểm tra ý tưởng và xác định các yêu cầu của sản phẩm. Bản mẫu phần mềm có thể được xem là một phần thực hiện của sản phẩm mới, vì nó chỉ bao gồm một số tính năng hoặc chức năng của sản phẩm. Nó cũng có thể được xem là một bản dựng khả thi của sản phẩm mới, vì nó thể hiện một cách khả thi để triển khai sản phẩm. Ngoài ra, bản mẫu phần mềm cũng có thể được xem là một bản dựng sơ bộ của sản phẩm mới, vì nó thường được tạo ra trước khi sản phẩm được hoàn thiện. Tuy nhiên, bản mẫu phần mềm không phải lúc nào cũng là bản dựng hoàn chỉnh của sản phẩm mới.

Các yếu tố sau đây có thể ngăn cản việc tái sử dụng yêu cầu. Yêu cầu được viết bằng ngôn ngữ tự nhiên có thể chứa các sự không rõ ràng, thiếu thông tin và giả định ẩn. Điều này có thể dẫn đến việc khó khăn trong việc hiểu và thực hiện yêu cầu. Vì vậy, việc tái sử dụng yêu cầu sẽ gặp khó khăn khi yêu cầu không được viết rõ ràng và chính xác.

Trong quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng. Chúng không chỉ ảnh hưởng đến kế hoạch dự án mà còn tác động trực tiếp đến quá trình thiết kế và viết mã nguồn. Yêu cầu cũng giúp xác định các hoạt động kiểm tra và thử nghiệm, đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn và yêu cầu đã được đặt ra. Vì vậy, yêu cầu (requirements) là nền tảng quan trọng để xây dựng một sản phẩm phần mềm chất lượng cao.

Trong phát triển agile, các câu chuyện người dùng (user stories) và các câu chuyện lớn (epics) là hai khái niệm quan trọng. Câu chuyện người dùng là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, giúp khởi đầu cho các cuộc thảo luận chi tiết. Các câu chuyện lớn, hoặc epics, là những câu chuyện người dùng quá lớn để được triển khai trong một chu kỳ phát triển (iteration) duy nhất. Vì vậy, chúng thường được chia nhỏ thành nhiều câu chuyện người dùng nhỏ hơn để dễ dàng triển khai.

Câu hỏi này yêu cầu bạn xác định thông tin không liên quan đến dự án được giao ngoài (outsourced projects). Các lựa chọn bao gồm: - Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. - Đó là khó khăn hơn để có được ý kiến của nhà phát triển về yêu cầu và để chuyển lại phản hồi của người dùng về phần mềm đã được giao cho nhà phát triển. - Cần có định nghĩa hợp đồng chính thức về yêu cầu, điều này có thể dẫn đến tranh chấp nếu sự khác biệt trong việc giải thích được phát hiện muộn trong dự án. Câu trả lời đúng là: Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. Vì dự án được giao ngoài thường không tận dụng kỹ năng phát triển có sẵn trong nội bộ mà thay vào đó là thuê ngoài để thực hiện.

Để xử lý một yêu cầu thay đổi, có bốn nhiệm vụ cần được thực hiện. Trước hết, chúng ta phải đánh giá yêu cầu thay đổi (evaluate change request). Tiếp theo, chúng ta phải đưa ra quyết định thay đổi (make change decision). Sau đó, chúng ta phải thực hiện thay đổi (implement the change). Cuối cùng, chúng ta phải kiểm tra lại thay đổi (verify the change) để đảm bảo rằng nó đã được thực hiện đúng cách và không có lỗi nào.