Quiz: SWR302_SP23_FE - Đề thi FE học kì SPRING 2023 có đáp án và giải thích chi tiết

Các nguồn thông tin liên kết theo dấu vết có thể bao gồm nhiều loại khác nhau. Ví dụ, nếu nguồn liên kết là yêu cầu hệ thống, thì đích liên kết có thể là yêu cầu chức năng. Nếu nguồn liên kết là yêu cầu người dùng, thì đích liên kết cũng có thể là yêu cầu chức năng. Tương tự, nếu nguồn liên kết là thành phần thiết kế, thì đích liên kết có thể là mã nguồn. Do đó, tất cả các câu trả lời trên đều có thể đúng tùy thuộc vào ngữ cảnh cụ thể.

Mô tả và phạm vi (Vision và Scope) là những khái niệm quan trọng trong quá trình phát triển sản phẩm. Mô tả (Vision) là một bức tranh tổng thể về sản phẩm mà chúng ta muốn tạo ra, trong khi phạm vi (Scope) xác định các yêu cầu và chức năng chính của sản phẩm. Các hoạt động của người ủng hộ sản phẩm (Product Champions) trong giai đoạn này nên tập trung vào việc thu thập thông tin và yêu cầu từ khách hàng và các bên liên quan. Điều này được gọi là Elicitation. Quá trình Elicitation giúp chúng ta hiểu rõ hơn về nhu cầu và mong muốn của khách hàng, từ đó có thể xây dựng một sản phẩm đáp ứng được nhu cầu của họ.

Tỷ lệ nhà phát triển đến phân tích kinh doanh trong dự án thông thường (default) thường được coi là 3:1. Điều này có nghĩa là một nhà phân tích kinh doanh có thể tạo ra đủ yêu cầu để giữ bảy nhà phát triển bận rộn. Tuy nhiên, tỷ lệ này có thể thay đổi tùy thuộc vào quy mô và phức tạp của dự án. Trong một số trường hợp, tỷ lệ có thể cao hơn hoặc thấp hơn 3:1. Ví dụ, trong dự án nhỏ, tỷ lệ có thể là 1:1, trong khi trong dự án lớn, tỷ lệ có thể là 6:1 hoặc thậm chí 9:1. Vì vậy, tỷ lệ 3:1 chỉ là một ước tính chung và có thể không áp dụng được cho mọi dự án.

Hoạt động thu thập yêu cầu (requirements elicitation) là bước quan trọng trong quy trình phát triển phần mềm. Để chuẩn bị cho hoạt động này, chúng ta cần thực hiện một số bước quan trọng. Trong các lựa chọn dưới đây, có một lựa chọn không thuộc về việc chuẩn bị cho hoạt động thu thập yêu cầu. Lựa chọn đó là "Prepare resource:". Điều này có nghĩa là việc chuẩn bị nguồn lực không phải là một bước quan trọng trong việc chuẩn bị cho hoạt động thu thập yêu cầu. Thay vào đó, chúng ta cần quyết định phạm vi và chương trình thu thập yêu cầu, chuẩn bị các câu hỏi và mô hình thử nghiệm, và lưu giữ các vấn đề mở.

Trong tài liệu yêu cầu, giả định về người dùng của phần mềm được mô tả ở phần mô tả đặc điểm của người dùng. Đây là phần quan trọng để hiểu rõ về đối tượng sử dụng phần mềm, bao gồm cả đặc điểm cá nhân, kỹ năng và kinh nghiệm của họ. Thông tin này sẽ giúp các nhà phát triển tạo ra phần mềm phù hợp với nhu cầu và khả năng của người dùng, từ đó đảm bảo rằng phần mềm được sử dụng một cách hiệu quả và an toàn.

Khi áp dụng yêu cầu tái sử dụng dựa trên quan điểm của người dùng, lợi ích chính là cải thiện sự nhất quán chức năng giữa các ứng dụng kinh doanh liên quan. Điều này có nghĩa là các ứng dụng sẽ có giao diện và chức năng tương tự nhau, giúp người dùng dễ dàng sử dụng và hiểu biết. Ngoài ra, yêu cầu tái sử dụng cũng giúp giảm thiểu sự lặp lại và cải thiện hiệu suất phát triển. Từ đó, các ứng dụng sẽ được phát triển nhanh chóng hơn và có chất lượng cao hơn.

Để điền vào chỗ trống trong câu sau, chúng ta cần tìm từ ngữ phù hợp. Câu đó mô tả các sự kiện bên ngoài có thể kích hoạt hành vi trong hệ thống. Nó mô tả ranh giới phạm vi cho hệ thống bằng cách đặt tên các sự kiện kinh doanh có thể được kích hoạt bởi người dùng, các sự kiện được kích hoạt theo thời gian (temporal) hoặc các tín hiệu được nhận từ các thành phần bên ngoài, chẳng hạn như thiết bị phần cứng. Trong các lựa chọn trên, "A event list" là lựa chọn phù hợp nhất. Điều này là vì danh sách sự kiện (event list) là một danh sách các sự kiện có thể xảy ra trong hệ thống, bao gồm cả các sự kiện được kích hoạt bởi người dùng, thời gian hoặc tín hiệu từ các thành phần bên ngoài.

Khái niệm yêu cầu không chức năng có cùng ý nghĩa với đặc tính chất lượng hoặc yêu cầu chất lượng dịch vụ. Yêu cầu không chức năng thường bao gồm các thuộc tính như tính bảo mật, tính khả dụng, tính tương thích, tính mở rộng, tính bảo trì, tính dễ sử dụng và tính ổn định. Những thuộc tính này giúp đảm bảo rằng hệ thống hoặc ứng dụng đáp ứng được các yêu cầu và tiêu chuẩn của người dùng, tổ chức hoặc thị trường. Vì vậy, việc xác định và quản lý các yêu cầu không chức năng là rất quan trọng trong quá trình phát triển phần mềm.

Khái niệm Yêu cầu chức năng (Functional Requirement) được định nghĩa như sau: Một hoặc nhiều khả năng liên quan logic của hệ thống cung cấp giá trị cho người dùng và được mô tả bởi một bộ yêu cầu chức năng. Yêu cầu chức năng là những yêu cầu liên quan đến chức năng của hệ thống, bao gồm những gì hệ thống cần làm, những gì hệ thống cần cung cấp cho người dùng. Ví dụ, yêu cầu chức năng có thể bao gồm yêu cầu hệ thống phải có khả năng nhập liệu, xuất dữ liệu, tính toán, lưu trữ dữ liệu v.v. Yêu cầu chức năng thường được mô tả bằng các yêu cầu chức năng cụ thể, chẳng hạn như yêu cầu hệ thống phải có khả năng nhập liệu dữ liệu khách hàng, yêu cầu hệ thống phải có khả năng xuất báo cáo doanh số hàng tháng v.v.

Trong phương pháp phát triển dự án Agile, vai trò truyền thống của Business Analyst thường được thay thế bởi Product Owner. Product Owner là người chịu trách nhiệm xác định yêu cầu và mục tiêu của dự án, đồng thời đảm bảo rằng các yêu cầu này được ưu tiên và thực hiện một cách hiệu quả. Họ cũng là người đại diện cho khách hàng và đảm bảo rằng dự án đáp ứng được nhu cầu và kỳ vọng của họ. Trong khi đó, Scrum Master là người hỗ trợ và hướng dẫn đội ngũ phát triển để đảm bảo rằng họ tuân thủ các quy trình và nguyên tắc của Agile. Team là đội ngũ phát triển thực hiện dự án, trong khi Tester là người chịu trách nhiệm kiểm tra và đảm bảo chất lượng của sản phẩm. Vì vậy, trong dự án sử dụng phương pháp Agile, vai trò Business Analyst thường được thay thế bởi Product Owner.

Kỹ thuật xác định ưu tiên yêu cầu dựa trên tầm quan trọng và cấp thiết thuộc về phương pháp MoSCoW. MoSCoW là một kỹ thuật được sử dụng để xác định và sắp xếp các yêu cầu của dự án dựa trên tầm quan trọng và cấp thiết. Các yêu cầu được phân loại thành bốn loại: Must-Haves (phải có), Should-Haves (nên có), Could-Haves (có thể có) và Won't-Haves (không có). Phương pháp này giúp cho các nhà phát triển và quản lý dự án xác định được những yêu cầu quan trọng nhất và ưu tiên thực hiện chúng trước.

Các yếu tố cơ bản tạo nên yêu cầu kinh doanh bao gồm mục tiêu kinh doanh, chỉ số hiệu suất, tuyên bố phạm vi và tầm nhìn, và yêu cầu chức năng. Tuy nhiên, cơ hội kinh doanh không phải là một trong những yếu tố cơ bản này. Cơ hội kinh doanh thường được coi là một khái niệm rộng hơn, bao gồm cả mục tiêu kinh doanh và các cơ hội kinh doanh tiềm năng. Trong khi đó, mục tiêu kinh doanh, chỉ số hiệu suất, tuyên bố phạm vi và tầm nhìn, và yêu cầu chức năng là những khái niệm cụ thể hơn, được sử dụng để xác định và mô tả yêu cầu kinh doanh cụ thể.

Các khu vực tiềm ẩn rủi ro được liệt kê dưới đây. Hãy xác định khu vực nào thuộc về các phân ngành kỹ thuật của quy trình thu thập yêu cầu (elicitation processes) trong kỹ thuật yêu cầu.

Khái niệm yêu cầu người dùng (User Requirement) được định nghĩa là một mô tả về tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc một ràng buộc mà hệ thống phải tuân thủ. Điều này có nghĩa là yêu cầu người dùng xác định những gì hệ thống phải làm hoặc không làm để đáp ứng nhu cầu và mong muốn của người dùng. Ví dụ, một yêu cầu người dùng có thể là hệ thống phải có khả năng lưu trữ dữ liệu một cách an toàn hoặc hệ thống phải có khả năng xử lý thông tin một cách nhanh chóng. Yêu cầu người dùng là một phần quan trọng trong quá trình phát triển hệ thống, vì nó giúp đảm bảo rằng hệ thống đáp ứng được nhu cầu và mong muốn của người dùng.

Các yêu cầu kinh doanh mô tả tại sao tổ chức đang triển khai hệ thống, lợi ích kinh doanh mà tổ chức hy vọng đạt được. Fokus là trên các mục tiêu kinh doanh của tổ chức hoặc khách hàng yêu cầu hệ thống. Các yêu cầu kinh doanh giúp xác định được mục tiêu và lợi ích mà hệ thống cần đạt được. Nó giúp cho việc triển khai hệ thống trở nên hiệu quả hơn và đáp ứng được nhu cầu của tổ chức. Các yêu cầu kinh doanh cũng giúp cho việc đo lường hiệu suất của hệ thống trở nên dễ dàng hơn. Nó giúp cho việc đánh giá và cải thiện hệ thống trở nên hiệu quả hơn.

Các công cụ phát triển yêu cầu bao gồm các công cụ mô hình hóa, thu thập thông tin và tạo bản mẫu. Trong số các lựa chọn trên, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu. Công cụ kiểm soát phiên bản được sử dụng để theo dõi và quản lý các phiên bản của mã nguồn, thường được sử dụng trong quy trình phát triển phần mềm. Trong khi đó, công cụ mô hình hóa giúp tạo ra các mô hình của hệ thống, công cụ thu thập thông tin giúp xác định yêu cầu của hệ thống và công cụ tạo bản mẫu giúp tạo ra các bản mẫu của hệ thống. Vì vậy, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu.

Các thuật ngữ sau có thể được sử dụng thay thế cho nhau. Dưới đây là giải thích về các thuật ngữ này và thuật ngữ tiêu chuẩn trong ngành công nghiệp.

Khi muốn giải quyết yêu cầu mâu thuẫn giữa các lớp người dùng, cách tiếp cận phù hợp nhất là dựa trên mục tiêu kinh doanh. Điều này có nghĩa là việc đưa ra quyết định sẽ được hướng dẫn bởi các mục tiêu kinh doanh, giúp đảm bảo rằng các quyết định được đưa ra là có lợi cho doanh nghiệp. Cách tiếp cận này giúp giải quyết mâu thuẫn giữa các lớp người dùng bằng cách đặt mục tiêu kinh doanh lên trên hết, giúp đảm bảo rằng các quyết định được đưa ra là có lợi cho doanh nghiệp.

Để cải thiện các thuật ngữ không rõ ràng (tốt hơn, nhanh hơn, chất lượng cao hơn), chúng ta cần xác định rõ ràng những gì được hiểu là 'tốt hơn' hay 'nhanh hơn'. Trong đó, cách phù hợp nhất là định lượng được mức độ cải thiện nào là đủ trong 6 lĩnh vực chức năng hoặc khía cạnh chất lượng cụ thể. Điều này giúp đảm bảo rằng mọi người có cùng một tiêu chuẩn và hiểu biết về những gì được coi là 'tốt hơn' hay 'nhanh hơn'. Ví dụ, nếu chúng ta đang cải thiện tốc độ của một hệ thống, chúng ta có thể định lượng được mức độ cải thiện tối thiểu là bao nhiêu phần trăm. Điều này giúp tránh những hiểu lầm và đảm bảo rằng mọi người có cùng một mục tiêu.

Một bản đồ hệ sinh thái (Ecosystem map) là một công cụ giúp bạn hiểu rõ hơn về các hệ thống liên quan đến hệ thống của bạn và cách chúng tương tác với nhau. Nó giúp bạn xác định ranh giới và các mối quan hệ giữa hệ thống của bạn và các hệ thống khác trong môi trường xung quanh. Bản đồ hệ sinh thái không chỉ giúp bạn hiểu rõ hơn về hệ thống của mình mà còn giúp bạn xác định các cơ hội và thách thức tiềm ẩn trong môi trường xung quanh. Nó cũng giúp bạn xác định các hệ thống quan trọng cần được xem xét khi phát triển hệ thống của mình.

Khi thực hiện quá trình ưu tiên và tất cả các yêu cầu đều có cùng mức độ ưu tiên, có thể nói rằng bạn chưa thực sự ưu tiên chúng. Điều này có nghĩa là quá trình ưu tiên không mang lại hiệu quả như mong đợi. Trong thực tế, nếu tất cả các yêu cầu đều có cùng mức độ ưu tiên, điều đó có nghĩa là bạn chưa phân biệt được giữa các yêu cầu quan trọng và không quan trọng. Quá trình ưu tiên là nhằm mục đích xác định và ưu tiên các yêu cầu quan trọng nhất, giúp bạn tập trung vào các công việc quan trọng và đạt được mục tiêu một cách hiệu quả hơn. Vì vậy, nếu tất cả các yêu cầu đều có cùng mức độ ưu tiên, có thể nói rằng bạn chưa thực sự ưu tiên chúng.

Khuôn khổ yêu cầu kinh doanh trong bản ghi chép tầm nhìn và phạm vi tài liệu mô tả các yêu cầu kinh doanh chính của sản phẩm mới. Nó nêu rõ lý do và bối cảnh cho việc tạo ra sản phẩm mới hoặc thay đổi đối với sản phẩm hiện có. Mô tả lịch sử hoặc tình huống dẫn đến quyết định xây dựng sản phẩm này. Nói cách khác, phần này giải thích tại sao và làm thế nào sản phẩm mới được tạo ra, bao gồm cả lý do và bối cảnh của nó.

Quá trình lập kế hoạch dự án bao gồm các hoạt động liên quan đến việc lập kế hoạch và quản lý dự án. Trong các lựa chọn trên, có một hoạt động không thuộc về quá trình lập kế hoạch dự án. Đó là "Có các nhà phát triển xem xét các yêu cầu". Hoạt động này không phải là một phần của quá trình lập kế hoạch dự án, mà là một phần của quá trình kiểm tra và xác minh các yêu cầu. Quá trình lập kế hoạch dự án bao gồm các hoạt động như sử dụng yêu cầu để ước tính kích thước dự án, cập nhật kế hoạch khi yêu cầu thay đổi, sử dụng ưu tiên yêu cầu để điều khiển vòng lặp quá trình, v.v. Vì vậy, hoạt động "Có các nhà phát triển xem xét các yêu cầu" không thuộc về quá trình lập kế hoạch dự án.

Để mô hình hóa các yêu cầu và phân bổ các yêu cầu vào các subsystem, chúng ta cần hiểu rõ khái niệm 'hoạt động nên được thực hiện theo các giai đoạn'. Điều này liên quan đến quá trình phân tích yêu cầu (Requirements Analysis) để xác định các hoạt động cần được thực hiện và phân bổ chúng vào các subsystem phù hợp. Quá trình này bao gồm việc xác định các yêu cầu chức năng và không chức năng, phân tích các yêu cầu và xác định các hoạt động cần được thực hiện. Sau đó, chúng ta sẽ phân bổ các hoạt động này vào các subsystem phù hợp dựa trên các yêu cầu chức năng và không chức năng đã xác định. Quá trình này đòi hỏi sự hiểu biết sâu sắc về các yêu cầu và khả năng của các subsystem.

Khi không có tiếp xúc với khách hàng trong quá trình phát triển phần mềm, khoảng cách mong đợi (expectation gap) thường sẽ tăng lên. Điều này là vì các nhà phát triển phần mềm không thể trực tiếp nhận được phản hồi và yêu cầu từ khách hàng, dẫn đến sự hiểu lầm về nhu cầu và mong đợi của họ. Kết quả là, phần mềm có thể không đáp ứng được nhu cầu thực sự của khách hàng, dẫn đến sự chênh lệch giữa mong đợi và thực tế. Ngoài ra, việc thiếu tiếp xúc với khách hàng cũng có thể dẫn đến sự chậm trễ trong việc nhận ra và sửa lỗi các vấn đề, khiến khoảng cách mong đợi tiếp tục tăng lên.

Trong quá trình phát triển yêu cầu, bạn cần xác định vai trò của mình. 'The research specialist' là lựa chọn đúng vì nó mô tả người thực hiện nghiên cứu và thu thập thông tin để xác định nhu cầu của khách hàng. Người này sẽ tìm kiếm và phân tích dữ liệu để hiểu rõ hơn về yêu cầu của khách hàng, từ đó giúp phát triển yêu cầu chính xác và hiệu quả. Vai trò này đòi hỏi sự chuyên môn và kỹ năng nghiên cứu để thu thập và phân tích dữ liệu một cách chính xác.

Các mục đích cơ bản của prototyping bao gồm làm rõ, hoàn thiện và xác minh yêu cầu, khám phá các lựa chọn thiết kế và tạo một phần tử sẽ phát triển thành sản phẩm cuối cùng. Trong đó, mục đích tạo một phần tử sẽ phát triển thành sản phẩm cuối cùng là một phần quan trọng của quá trình prototyping. Tuy nhiên, mục đích tạo một bản mẫu điện tử bao gồm phần mềm hoạt động cho chỉ một phần của giải pháp không phải là một mục đích cơ bản của prototyping. Thay vào đó, nó có thể được coi là một ứng dụng cụ thể của prototyping.

Trong quá trình thu thập yêu cầu (elicitation) có thể xảy ra tình trạng bỏ sót các yêu cầu quan trọng. Điều này có thể dẫn đến việc dự án phần mềm không đáp ứng được nhu cầu của người dùng. Vì vậy, việc xác định và thu thập đầy đủ các yêu cầu là rất quan trọng trong suốt quá trình phát triển phần mềm. Nếu các yêu cầu quan trọng bị bỏ sót, dự án phần mềm có thể không thể hoàn thành đúng như kế hoạch.

Khu vực cơ hội kinh doanh trong bản mẫu tài liệu tầm nhìn và phạm vi mô tả lý do và ngữ cảnh cho sản phẩm mới hoặc thay đổi đối với sản phẩm hiện có. Nó mô tả lịch sử hoặc tình huống dẫn đến quyết định xây dựng sản phẩm này. Điều này giúp xác định rõ mục tiêu và hướng đi của dự án. Trong phần này, bạn cần giải thích lý do tại sao cần xây dựng sản phẩm mới hoặc thay đổi sản phẩm hiện có, bao gồm cả tình huống dẫn đến quyết định này. Điều này sẽ giúp bạn và các thành viên trong dự án hiểu rõ hơn về mục tiêu và hướng đi của dự án.

Mô hình yêu cầu kỹ thuật (Software Requirements Specification - SRS) là một tài liệu mô tả chi tiết các yêu cầu của hệ thống. Nó được tạo ra trong quá trình phát triển yêu cầu, khi các yêu cầu được xác định, phân tích và xác thực. Vì vậy, SRS thuộc về tài sản quá trình phát triển yêu cầu (Requirements Development Process Assets).

Mô tả về cơ hội tái sử dụng yêu cầu bảo mật: Trong nhiều trường hợp, yêu cầu bảo mật và xác thực người dùng thường giống nhau trên các hệ thống khác nhau. Ví dụ, các hệ thống có thể có yêu cầu chung rằng tất cả sản phẩm phải có đăng nhập đơn giản sử dụng Active Directory cho xác thực người dùng. Điều này cho phép tái sử dụng yêu cầu bảo mật và giảm thiểu thời gian và chi phí phát triển. Ngoài ra, việc tái sử dụng yêu cầu bảo mật cũng giúp đảm bảo tính nhất quán và bảo mật trên toàn hệ thống.

Các câu sau có đúng hay sai? Câu 1: Ở bất kỳ đâu có các hàm (function), thì đều có dữ liệu. Câu 2: Tính năng phần mềm được chỉ định để tạo, sửa đổi, hiển thị, xóa, xử lý và sử dụng dữ liệu. Câu 1 đúng vì bất kỳ chương trình nào cũng cần sử dụng dữ liệu để thực hiện các chức năng của nó. Dữ liệu có thể là các biến, mảng, đối tượng, tệp tin,... Câu 2 cũng đúng vì các chức năng phần mềm thường liên quan đến việc tạo, sửa đổi, hiển thị, xóa, xử lý và sử dụng dữ liệu. Ví dụ, một chương trình quản lý khách sạn có thể tạo mới, sửa đổi, hiển thị thông tin khách hàng, xóa thông tin khách hàng,... Tóm lại, các câu trên đều đúng.

Khi phát triển kịch bản kiểm thử dựa trên yêu cầu, kiểm thử viên có thể phát hiện nhiều lỗi liên quan đến yêu cầu. Tuy nhiên, trong các lựa chọn trên, kiểm thử viên không nên tập trung vào việc kiểm tra các quy ước lập trình. Điều này vì quy ước lập trình là các quy định về cách viết mã, không phải là yêu cầu chức năng của hệ thống. Kiểm thử viên nên tập trung vào việc xác định các yêu cầu chức năng không rõ ràng, mâu thuẫn hoặc không thể đo lường được, vì những lỗi này có thể ảnh hưởng đến chất lượng của hệ thống.

Loại phân tích dự đoán (predictive analytic) thường liên quan đến việc tạo ra các kịch bản 'nếu - thì' để so sánh dự đoán tương lai. Điều này cho phép các nhà phân tích và quản lý đưa ra quyết định sáng suốt hơn về các chiến lược kinh doanh và đầu tư. Ví dụ, một công ty có thể sử dụng phân tích dự đoán để dự đoán doanh số bán hàng trong tương lai dựa trên các yếu tố như xu hướng thị trường, giá cả và nhu cầu của khách hàng. Từ đó, họ có thể đưa ra quyết định về việc tăng hoặc giảm sản xuất, mở rộng hoặc thu hẹp các kênh phân phối, hoặc thậm chí là thay đổi chiến lược tiếp thị.

Trong quá trình tạo ra tài liệu yêu cầu kiểm tra, hoạt động cơ bản cuối cùng là 'Follow-up'. Đây là bước cuối cùng trong chuỗi hoạt động kiểm tra, bao gồm các bước khác như chuẩn bị, cuộc họp kiểm tra, sản phẩm kiểm tra ban đầu, sản phẩm kiểm tra cuối cùng và sửa đổi. Hoạt động 'Follow-up' liên quan đến việc kiểm tra lại sản phẩm sau khi đã được sửa đổi để đảm bảo rằng các vấn đề đã được giải quyết và sản phẩm đáp ứng được yêu cầu.

Kỹ thuật Workshop là một phương pháp thu thập yêu cầu hiệu quả trong quy trình thu thập yêu cầu. Để thực hiện một Workshop thành công, cần có một số bước quan trọng. Đầu tiên, cần lên kế hoạch một chương trình (Plan an agenda), đặt thời gian giới hạn cho các cuộc thảo luận (Time box discussions), đảm bảo có đủ số lượng thành viên tham gia nhưng chỉ bao gồm các bên liên quan quan trọng (Keep the team small but include the right stakeholders), giữ cho tất cả mọi người đều tham gia và tập trung (Keep everyone engaged), chuẩn bị các câu hỏi và mô hình giả (Prepare questions and straw man models ahead of time). Tuy nhiên, một số kỹ thuật không thuộc về phương pháp Workshop, chẳng hạn như 'Fill all of the team roles' (Điền đầy đủ các vai trò của đội ngũ), tức là cố gắng mời đủ mọi người tham gia mà không cần xem xét kỹ lưỡng về vai trò và tính cần thiết của họ.

Khi viết Specification yêu cầu phần mềm, bạn nên viết chi tiết hơn trong trường hợp nào? Câu trả lời đúng là khi khách hàng tham gia sâu vào quá trình phát triển phần mềm. Điều này có nghĩa là khách hàng sẽ tham gia vào các cuộc thảo luận, cung cấp thông tin chi tiết về yêu cầu của họ và sẽ được cập nhật thường xuyên về tiến độ của dự án. Việc này giúp đảm bảo rằng phần mềm cuối cùng được phát triển đáp ứng đúng nhu cầu của khách hàng và giảm thiểu khả năng xảy ra sai sót. Ngoài ra, việc khách hàng tham gia sâu vào quá trình phát triển cũng giúp tăng cường sự hiểu biết và đồng thuận giữa các bên liên quan, từ đó giúp dự án được hoàn thành một cách hiệu quả hơn.

Sử dụng biểu đồ Use case giúp bạn biểu diễn mối quan hệ giữa cách dữ liệu được lưu trữ. Biểu đồ này mô tả các trường hợp sử dụng của hệ thống và mối quan hệ giữa chúng. Tuy nhiên, biểu đồ Use case không trực tiếp liên quan đến cách dữ liệu được lưu trữ trong cơ sở dữ liệu. Nó tập trung vào việc mô tả các hoạt động và chức năng của hệ thống, chứ không phải là cách dữ liệu được tổ chức và lưu trữ. Vì vậy, câu trả lời đúng là FALSE.

Trong dự án hệ thống thời gian thực và hệ thống nhúng, nhà phân tích nên phân tích các yêu cầu hệ thống riêng lẻ thành nhiều yêu cầu được suy ra. Loại yêu cầu nào sẽ phân bổ cho người?

Một mục tiêu của một phân loại yêu cầu là giúp tổ chức dữ liệu vào các lớp. Điều này giúp chúng ta nghĩ về các lớp mà chúng ta có thể bỏ qua nếu không có phân loại. Ví dụ, khi phân loại yêu cầu cho một hệ thống quản lý thư viện, chúng ta có thể tạo các lớp như 'sách', 'nhân viên', 'khách hàng'. Việc phân loại này giúp chúng ta xác định rõ các yêu cầu của hệ thống và tránh bỏ qua các yêu cầu quan trọng. Ngoài ra, phân loại yêu cầu cũng giúp chúng ta dễ dàng tìm kiếm và truy cập các yêu cầu đã được xác định.

Khi khách hàng trình bày yêu cầu của họ bằng cách sử dụng động từ (Verb), bạn nên sử dụng mô hình phân tích sử dụng các đối tượng có trạng thái (Objects with states - STD). Mô hình này giúp bạn hiểu rõ hơn về các hoạt động và trạng thái của các đối tượng trong hệ thống. Nó cũng giúp bạn xác định rõ các yêu cầu của khách hàng và chuyển chúng thành các yêu cầu chức năng cụ thể. Ngoài ra, mô hình này còn giúp bạn phân tích và thiết kế hệ thống một cách hiệu quả hơn.

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.

Khái niệm yêu cầu hệ thống (System Requirement) được định nghĩa là mô tả về một tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc một ràng buộc mà hệ thống phải tuân thủ. Điều này bao gồm các thuộc tính như hiệu suất, độ tin cậy, khả năng tương thích và các yêu cầu khác không liên quan trực tiếp đến chức năng của hệ thống. Yêu cầu hệ thống thường được xác định dựa trên yêu cầu của người dùng, yêu cầu của quy trình kinh doanh và các ràng buộc về kỹ thuật. Mục tiêu của yêu cầu hệ thống là đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu và nhu cầu của người dùng, đồng thời đảm bảo rằng hệ thống có thể vận hành một cách ổn định và hiệu quả.

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.

Các mối quan hệ giữa Use Case được định nghĩa như sau: Một mối quan hệ Include cho biết một Use Case bao gồm hành vi được mô tả trong Use Case khác. Một mối quan hệ Extend cho biết một Use Case có thể mở rộng hành vi được mô tả trong Use Case khác. Tương tự như kế thừa trong lập trình, mối quan hệ Generalization giữa Use Cases cho biết Use Case con là một dạng cụ thể hơn của Use Case cha. Use Case con thừa kế tất cả các tính năng và mối quan hệ của Use Case cha và có thể thêm mới các tính năng và mối quan hệ. Tất cả các mối quan hệ trên đều đúng và được sử dụng trong việc mô hình hóa Use Case.

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.

Ví dụ về yêu cầu tương tự cho các nền tảng đa dạng là cơ hội tái sử dụng yêu cầu. Điều này xảy ra khi một ứng dụng được triển khai trên nhiều nền tảng khác nhau, chẳng hạn như Mac và Windows hoặc iOS và Android. Mặc dù có thể có một số khác biệt về yêu cầu chi tiết và/hoặc thiết kế giao diện người dùng dựa trên nền tảng, nhưng vẫn sử dụng một bộ yêu cầu cốt lõi. Điều này cho phép tái sử dụng các yêu cầu và giảm thiểu sự lặp lại trong quá trình phát triển phần mềm.

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.

Validation (xác thực) là một khái niệm quan trọng trong quy trình phát triển phần mềm. Nó giúp xác định xem sản phẩm của một hoạt động phát triển có đáp ứng được yêu cầu của nó hay không. Trong đó, có hai khái niệm liên quan đến xác thực là Verification và Validation. Verification (kiểm tra) liên quan đến việc xác thực xem sản phẩm có đáp ứng được yêu cầu hay không, còn Validation (xác thực) liên quan đến việc xác thực xem sản phẩm có đáp ứng được mục tiêu kinh doanh hay không. Trong câu hỏi này, câu trả lời đúng là "Validation of requirements assesses whether you have written the right requirements: they trace back to business objectives.". Điều này có nghĩa là xác thực yêu cầu giúp xác định xem các yêu cầu đã được viết đúng chưa và chúng có liên quan đến mục tiêu kinh doanh hay không.

Kỹ năng của một nhà phân tích kinh doanh bao gồm nhiều yếu tố khác nhau. Trong số đó, kỹ năng điều phối (facilitation skills) giúp họ tổ chức và dẫn dắt các cuộc họp, thảo luận và các hoạt động nhóm một cách hiệu quả. Kỹ năng quan sát (observational skills) giúp họ thu thập thông tin và dữ liệu cần thiết. Kỹ năng tổ chức (organizational skills) giúp họ quản lý và sắp xếp công việc một cách khoa học. Kỹ năng lãnh đạo (leadership skills) giúp họ đưa ra quyết định và dẫn dắt nhóm. Tuy nhiên, kỹ năng lập trình và kỹ thuật (coding and technical skills) không phải là kỹ năng cần thiết cho một nhà phân tích kinh doanh. Họ có thể không cần phải lập trình hoặc có kiến thức kỹ thuật sâu rộng, nhưng họ cần phải có khả năng hiểu và làm việc với các công nghệ và hệ thống hiện có.

Câu hỏi này yêu cầu người đọc đánh giá tính đúng sai của một tuyên bố. Tuyên bố cho rằng các dự án khác nhau sẽ đòi hỏi cùng một bộ các đặc tính chất lượng. Điều này không phải lúc nào cũng đúng vì các dự án khác nhau có thể có các yêu cầu và mục tiêu khác nhau. Vì vậy, câu trả lời đúng là 'False'.

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.