SWR302 Software Requirements – Bộ ôn tập cuối kỳ số 2 (57 câu)

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.