Software Requirements - SWR302

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 phần mềm (Software Requirements Specification - SRS) là một tài liệu kỹ thuật mô tả các yêu cầu của hệ thống phần mềm. Nó được sử dụng để xác định và mô tả các yêu cầu của hệ thống phần mềm, bao gồm cả các yêu cầu chức năng và không chức năng. Mô hình này thường được sử dụng trong quá trình phát triển phần mềm để đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện đúng. Vì vậy, mô hình yêu cầu phần mềm thuộc về quá trình phát triển yêu cầu phần mềm.

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.

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ọ.

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 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.

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.

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.

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.

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.

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.