Loại nỗ lực nào trong các lựa chọn dưới đây đòi hỏi phải có nhiều yêu cầu và công việc phát triển để tạo ra một sản phẩm phần mềm giải pháp đóng gói? Để sử dụng gói phần mềm như là nó, không cần phải thay đổi hoặc bổ sung thêm bất kỳ điều gì. Điều này có nghĩa là bạn có thể sử dụng nó ngay lập tức mà không cần phải thực hiện bất kỳ công việc nào. Tuy nhiên, nếu bạn muốn sử dụng gói phần mềm này để đáp ứng các yêu cầu cụ thể của mình, bạn sẽ cần phải thực hiện một số công việc để xác định các yêu cầu cụ thể của dự án. Điều này có thể bao gồm việc thu thập thông tin từ khách hàng, xác định các yêu cầu chức năng và không chức năng, và tạo ra các tài liệu yêu cầu chi tiết. Cuối cùng, nếu bạn muốn mở rộng hoặc tùy chỉnh gói phần mềm này để đáp ứng các yêu cầu cụ thể của mình, bạn sẽ cần phải thực hiện một số công việc phát triển phần mềm để tạo ra các tính năng mới hoặc sửa đổi các tính năng hiện có.

Để xác định liệu bạn đã hoàn thành yêu cầu thu thập thông tin (requirements elicitation) hay chưa, bạn cần xem xét các dấu hiệu sau. Một dấu hiệu tốt là khi các yêu cầu mới được đề xuất đều có mức độ ưu tiên cao. Tuy nhiên, điều này không phải lúc nào cũng đúng. Một dấu hiệu khác là khi các nhà phát triển và kiểm thử viên đánh giá yêu cầu cho một khu vực cụ thể và không có nhiều câu hỏi được đặt ra. Điều này cho thấy yêu cầu đã được rõ ràng và đầy đủ. Một dấu hiệu khác nữa là khi các tính năng mới được đề xuất, yêu cầu của người dùng hoặc yêu cầu chức năng đều được coi là nằm trong phạm vi dự án. Điều này cho thấy yêu cầu đã được thu thập đầy đủ và chính xác. Cuối cùng, nếu người dùng không đưa ra các vấn đề mới mà chưa được đề cập trong các cuộc thảo luận trước đó, thì cũng có thể coi là một dấu hiệu tốt.

Câu hỏi này yêu cầu bạn đánh giá tính chính xác của tuyên bố rằng tất cả các dự án công nghệ thông tin của doanh nghiệp đều chọn thay thế tất cả các quy trình kinh doanh thủ công bằng tự động hóa quy trình kinh doanh. Tuy nhiên, điều này không phải lúc nào cũng đúng. Một số dự án có thể chọn tự động hóa một số quy trình kinh doanh, nhưng không phải tất cả. Ngoài ra, một số dự án có thể chọn duy trì một số quy trình kinh doanh thủ công vì lý do cụ thể. Vì vậy, tuyên bố này không phải lúc nào cũng chính xác.

Khi thực hiện yêu cầu thu thập thông tin (requirements elicitation), có nhiều kỹ thuật được sử dụng để thu thập thông tin từ khách hàng hoặc người liên quan. Trong số các kỹ thuật này, có một số kỹ thuật không phù hợp hoặc không cần thiết. Kỹ thuật 'Fill all of the team roles' không phải là một kỹ thuật thu thập thông tin, mà là một kỹ thuật xây dựng đội ngũ. Nó liên quan đến việc đảm bảo rằng các thành viên trong đội ngũ có đủ kỹ năng và vai trò để thực hiện công việc một cách hiệu quả. Tuy nhiên, nó không liên quan trực tiếp đến quá trình thu thập thông tin.

Trong các lựa chọn trên, Mock-up là thuật ngữ có cùng ý nghĩa với vertical prototype. Vertical prototype thường được sử dụng trong thiết kế sản phẩm hoặc ứng dụng để mô tả bản thiết kế chi tiết và đầy đủ về một phần hoặc toàn bộ sản phẩm. Nó thường bao gồm các chi tiết về giao diện người dùng, chức năng và thiết kế của sản phẩm. Mock-up cũng có ý nghĩa tương tự, thường được sử dụng để mô tả bản thiết kế hoặc mô hình của một sản phẩm hoặc ứng dụng. Nó giúp các nhà thiết kế và phát triển có thể xem xét và đánh giá sản phẩm trước khi triển khai. Trong khi Navigation structure và Tree Navigation liên quan đến cấu trúc và giao diện người dùng của sản phẩm, nhưng chúng không phải là thuật ngữ chính xác để mô tả vertical prototype.

Để xác định các lớp người dùng của hệ thống phần mềm mới đang phát triển, chúng ta nên bắt đầu bằng cách hỏi người tài trợ dự án (project sponsor) về những người họ dự kiến sẽ sử dụng hệ thống. Sau đó, chúng ta có thể brainstorm để nghĩ ra càng nhiều lớp người dùng càng tốt. Việc này giúp đảm bảo rằng hệ thống được thiết kế để đáp ứng nhu cầu của tất cả các lớp người dùng.

Khi các nhà quản lý và các tester tham gia vào quá trình đạt được thỏa thuận về yêu cầu, điều quan trọng là phải đảm bảo rằng các yêu cầu có thể được xác minh. Điều này có nghĩa là các yêu cầu phải cụ thể, rõ ràng và có thể đo lường được. Điều này giúp các tester xác định được các trường hợp thử nghiệm cần thiết và đảm bảo rằng các yêu cầu được thực hiện một cách chính xác. Ngoài ra, các nhà quản lý cũng cần đảm bảo rằng các yêu cầu sẽ không ảnh hưởng đến mục tiêu kinh doanh của họ. Điều này có nghĩa là các yêu cầu phải được thiết kế để đáp ứng nhu cầu của khách hàng và không gây ra bất kỳ thiệt hại nào cho doanh nghiệp. Vì vậy, cả hai điều kiện trên đều là đúng.

Sơ đồ có thể được sử dụng để giải thích các khái niệm khác nhau trong thiết kế hệ thống. Trong đó, sơ đồ có thể giúp minh họa về phạm vi của hệ thống, mối quan hệ giữa các lớp, thông tin lưu chuyển và các thực thể trong hệ thống. Ví dụ, sơ đồ có thể được sử dụng để minh họa về phạm vi của hệ thống, bao gồm các thành phần và các phần tử quan trọng của hệ thống. Ngoài ra, sơ đồ cũng có thể được sử dụng để minh họa về mối quan hệ giữa các lớp, giúp người xem hiểu rõ về cách các lớp tương tác với nhau. Tóm lại, sơ đồ là công cụ quan trọng trong thiết kế hệ thống, giúp người thiết kế và người xem hiểu rõ về các khái niệm và mối quan hệ trong hệ thống.

Các dự án được ủy thác thường liên quan đến các nhóm có cùng văn hóa công ty. Điều này có thể mang lại lợi thế vì các thành viên trong nhóm có thể dễ dàng hiểu và làm việc với nhau. Tuy nhiên, cũng có thể là một điểm yếu nếu các thành viên trong nhóm không có đủ kỹ năng hoặc kinh nghiệm để hoàn thành dự án. Văn hóa công ty có thể ảnh hưởng đến cách thức làm việc, cách thức giải quyết vấn đề và cách thức giao tiếp của nhóm. Vì vậy, việc hiểu và quản lý văn hóa công ty là rất quan trọng trong các dự án được ủy thác.

Quyền lợi của khách hàng phần mềm được quy định trong yêu cầu hóa đơn bao gồm tất cả các lựa chọn sau, EXCEPT: 'Được nghe ý tưởng và phương án thay thế cho yêu cầu và cho giải pháp của họ'. Điều này là không đúng vì khách hàng phần mềm không có quyền được nghe ý tưởng và phương án thay thế từ nhà cung cấp phần mềm. Thay vào đó, khách hàng phần mềm có quyền được cung cấp thông tin chi tiết và chính xác về yêu cầu và giải pháp phần mềm. Họ cũng có quyền nhận được hệ thống phần mềm đáp ứng nhu cầu chức năng và kỳ vọng chất lượng của họ. Cuối cùng, khách hàng phần mềm có quyền được cung cấp thông tin về đặc điểm của sản phẩm giúp sản phẩm dễ sử dụng.

Câu hỏi này yêu cầu bạn xác định thông tin không đúng về khách hàng phần mềm. Các lựa chọn bao gồm: một phần của các bên liên quan, một cá nhân hoặc tổ chức nhận được lợi ích trực tiếp hoặc gián tiếp từ sản phẩm, họ có thể yêu cầu, trả tiền, chọn, chỉ định, sử dụng hoặc nhận được đầu ra được tạo bởi sản phẩm phần mềm. Tuy nhiên, 'như vậy là nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp' không phải là khách hàng phần mềm. Khách hàng phần mềm thường là người sử dụng cuối cùng hoặc tổ chức có nhu cầu sử dụng sản phẩm phần mềm. Nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp có thể là các bên liên quan khác nhau nhưng không phải là khách hàng phần mềm.

Trong sơ đồ ngữ cảnh, các thực thể bên ngoài được minh họa bằng hình dạng và dữ liệu lưu chuyển được minh họa bằng đường nét.