Một nhà phân tích kinh doanh có thể chuyển đổi tiếng nói của khách hàng thành các thành phần mô hình cụ thể bằng cách xác định các từ khóa như danh từ, động từ và các tuyên bố điều kiện có thể ánh xạ đến các thành phần mô hình phân tích tương ứng. Điều này giúp họ hiểu rõ hơn về nhu cầu và mong muốn của khách hàng, từ đó tạo ra các mô hình phân tích chính xác và hiệu quả. Ngoài ra, việc xác định các từ khóa cũng giúp nhà phân tích kinh doanh tránh được sự nhầm lẫn và đảm bảo rằng các mô hình phân tích được xây dựng dựa trên thông tin chính xác và đáng tin cậy.

Một Entity Relationship Diagram (ERD) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Nó mô tả mối quan hệ giữa các thực thể (entity) trong một hệ thống dữ liệu. Các thành phần chính của một ERD bao gồm: thực thể (entity), mối quan hệ (relationship), quan hệ giữa thực thể (association), thuộc tính (attribute). Trong các lựa chọn trên, chỉ có một thành phần không phải là một phần của ERD. Đó là 'Cardinality'. Cardinality chỉ là một khái niệm trong ERD, nó mô tả số lượng thực thể tham gia vào một mối quan hệ. Nó không phải là một thành phần độc lập của ERD.

ERD (Entity-Relationship Diagram) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Để xác định câu trả lời sai, chúng ta cần hiểu rõ về các thành phần của ERD. Câu trả lời sai là 'Individual instances of an entity will have the same attribute values'. Điều này không đúng vì các bản sao riêng lẻ của một thực thể sẽ có các giá trị thuộc tính khác nhau. Ví dụ, trong một bảng khách hàng, mỗi khách hàng sẽ có một địa chỉ riêng biệt. Câu trả lời đúng về ERD bao gồm: 'The cardinality, or multiplicity, of each relationship is shown with a number or letter on the lines that connect entities and relationships', 'Each entity is described by one or more attributes' và 'The diamonds in the ERD represent relationships, which identify the logical linkages between pairs of entities'.

Khi đánh giá các thuộc tính chất lượng phần mềm, thuộc tính nội bộ (internal quality attribute) là những thuộc tính liên quan trực tiếp đến thiết kế và cấu trúc của phần mềm. Trong các lựa chọn trên, hiệu suất (Efficiency) là một thuộc tính nội bộ vì nó liên quan đến khả năng sử dụng tài nguyên của phần mềm, chẳng hạn như thời gian chạy, dung lượng bộ nhớ và tốc độ xử lý. Ví dụ, một phần mềm có thể được thiết kế để chạy nhanh chóng và hiệu quả, nhưng điều đó không nhất thiết phải đảm bảo rằng nó cũng dễ sử dụng (usability) hoặc an toàn (security). Tương tự, khả năng sẵn có (availability) cũng không phải là thuộc tính nội bộ vì nó liên quan đến khả năng truy cập và sử dụng phần mềm, chứ không phải là cấu trúc hoặc thiết kế của nó.

Khi tạo mô hình giả (mock-up), mục đích chính là để cải thiện thiết kế giao diện người dùng. Điều này bao gồm việc xác định các yếu tố như bố cục, màu sắc, hình ảnh và các yếu tố khác ảnh hưởng đến trải nghiệm người dùng. Ngoài ra, mô hình giả còn giúp kiểm tra tính khả thi của kiến trúc và cho phép người dùng đánh giá toàn bộ quy trình và yêu cầu. Tuy nhiên, mục đích không phải là tạo ra một giao diện người dùng giả mạo mà không có chức năng thực sự. Điều này có nghĩa là mô hình giả phải có một số chức năng cơ bản để cho phép người dùng tương tác và đánh giá.

Câu hỏi này yêu cầu bạn chọn phương pháp không liên quan đến kỹ thuật ưu tiên. Trong đó, 'In or out' không phải là một kỹ thuật ưu tiên. Kỹ thuật này thường được sử dụng để quyết định liệu một yêu cầu hoặc một dự án có được thực hiện hay không. Trong khi đó, các phương pháp khác như 'So sánh đôi và xếp hạng', 'Bảng thang ba mức', 'MoSCoW', 'Dựa trên rủi ro' đều liên quan đến việc ưu tiên các yêu cầu hoặc dự án.

Phương pháp đánh giá yêu cầu liên quan đến việc tác giả mô tả một sản phẩm và thu thập ý kiến về nó được gọi là phương pháp Peer deskcheck. Trong phương pháp này, tác giả sẽ mô tả chi tiết về sản phẩm và gửi cho các thành viên khác trong nhóm để họ có thể đưa ra ý kiến và góp ý. Điều này giúp đảm bảo rằng sản phẩm đáp ứng được yêu cầu và nhu cầu của khách hàng. Phương pháp này thường được sử dụng khi nhóm cần phải có sự tham gia và ý kiến của nhiều người để có thể tạo ra một sản phẩm tốt nhất.

Khi xác minh yêu cầu, chúng ta có thể ngăn chặn một số vấn đề tiềm ẩn. Đầu tiên, xác minh yêu cầu giúp ngăn chặn hiện tượng 'Scope creep', khi yêu cầu thay đổi không ngừng và vượt quá phạm vi ban đầu. Điều này có thể dẫn đến lãng phí thời gian và tài nguyên. Thứ hai, xác minh yêu cầu giúp ngăn chặn 'Misaligned Expectations', khi người dùng và nhà phát triển không có cùng hiểu biết về yêu cầu. Điều này có thể dẫn đến sự thất vọng và lãng phí thời gian. Cuối cùng, xác minh yêu cầu giúp ngăn chặn 'Cost Overruns and Delays', khi dự án bị chậm tiến độ và vượt quá ngân sách. Điều này có thể dẫn đến thiệt hại tài chính và ảnh hưởng đến uy tín của công ty.

COTS (Commercial Off-The-Shelf) là các phần mềm được phát triển sẵn và có sẵn trên thị trường. Khi triển khai COTS, một số gói phần mềm có thể được sử dụng ngay lập tức mà không cần phải tùy chỉnh quá nhiều. Điều này là do COTS đã được thiết kế để đáp ứng nhu cầu chung của nhiều doanh nghiệp, vì vậy chúng có thể đáp ứng được các yêu cầu cơ bản của doanh nghiệp mà không cần phải thay đổi quá nhiều. Tuy nhiên, không phải tất cả các COTS đều có thể được sử dụng như vậy, và một số gói phần mềm có thể cần phải được tùy chỉnh để phù hợp với nhu cầu cụ thể của doanh nghiệp.

Tracing yêu cầu là một quá trình quan trọng trong phát triển phần mềm, giúp đảm bảo rằng các yêu cầu của dự án được thực hiện chính xác và hiệu quả. Motivation chính cho việc tracing yêu cầu là để cải thiện chất lượng sản phẩm, giảm chi phí bảo trì và hỗ trợ tái sử dụng. Khi yêu cầu được tracing chính xác, các nhà phát triển có thể dễ dàng xác định và sửa lỗi, từ đó cải thiện chất lượng sản phẩm và giảm chi phí bảo trì. Ngoài ra, việc tracing yêu cầu cũng giúp hỗ trợ tái sử dụng các thành phần đã được phát triển, giảm thiểu thời gian và chi phí phát triển mới.

Trong ngữ cảnh của việc theo dõi yêu cầu, một ma trận theo dõi được sử dụng để thực hiện hai chức năng chính. Thứ nhất, nó được sử dụng để ánh xạ các yêu cầu đến các yếu tố khác của hệ thống như thiết kế và mã nguồn. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện một cách chính xác và không bỏ sót bất kỳ chi tiết nào. Thứ hai, nó được sử dụng để xác định các yêu cầu bị thiếu hoặc không cần thiết. Điều này giúp giảm thiểu các yêu cầu không cần thiết và đảm bảo rằng hệ thống được phát triển một cách hiệu quả và có hiệu suất cao.

Một chiến lược tránh rủi ro (risk avoidance) là việc không tham gia vào hoạt động có rủi ro. Điều này có nghĩa là bạn sẽ tránh hoàn toàn hoạt động có khả năng gây ra thiệt hại hoặc tổn thất. Ví dụ, nếu bạn đang xem xét việc đầu tư vào một công ty có lịch sử không tốt, chiến lược tránh rủi ro sẽ là việc không đầu tư vào công ty đó. Thay vào đó, bạn sẽ tìm kiếm các cơ hội đầu tư khác an toàn hơn. Chiến lược tránh rủi ro thường được sử dụng khi rủi ro có thể gây ra thiệt hại nghiêm trọng và không thể được kiểm soát.