SWR302 Software Requirements – Bộ ôn tập thi lại số 1 (40 câu)

Hoạt động nào không thuộc quy trình kiểm thử? Quy trình kiểm thử bao gồm các hoạt động thiết kế kiểm thử sớm, có người dùng tạo ra các kiểm thử chấp nhận, theo dõi yêu cầu đến kiểm thử, cập nhật kế hoạch khi yêu cầu thay đổi. Tuy nhiên, hoạt động không thuộc quy trình kiểm thử là thiết kế kiểm thử dựa trên yêu cầu. Thiết kế kiểm thử nên được thực hiện độc lập với yêu cầu để đảm bảo tính khách quan và toàn diện. Việc thiết kế kiểm thử dựa trên yêu cầu có thể dẫn đến kiểm thử không đầy đủ hoặc không chính xác.

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.

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.

Loại nỗ lực nào trong các lựa chọn dưới đây đòi hỏi ít nhất 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?

Dưới đây là câu hỏi về việc sử dụng danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Câu hỏi yêu cầu người tham gia đánh giá tính chính xác của tuyên bố: 'Phát triển danh sách kiểm tra lỗi và sử dụng nó cho tất cả các loại tài liệu yêu cầu'. Để trả lời câu hỏi này, chúng ta cần xem xét vai trò của danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Danh sách kiểm tra lỗi là một công cụ quan trọng giúp đảm bảo chất lượng của sản phẩm phần mềm. Nó giúp phát hiện và sửa lỗi trong quá trình phát triển, từ đó cải thiện chất lượng của sản phẩm. Việc sử dụng danh sách kiểm tra lỗi cho tất cả các loại tài liệu yêu cầu là một thực hành tốt, giúp đảm bảo rằng tất cả các yêu cầu được kiểm tra và xác minh một cách đầy đủ. Điều này giúp giảm thiểu khả năng xảy ra lỗi và cải thiện chất lượng của sản phẩm phần mềm. Vì vậy, tuyên bố trên là đúng.

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.

Để tìm được giọng nói của người dùng, chúng ta cần thực hiện các bước sau. Trước hết, chúng ta phải xác định được các lớp người dùng khác nhau cho sản phẩm của mình. Sau đó, chúng ta cần chọn và làm việc với các cá nhân đại diện cho mỗi lớp người dùng và các nhóm liên quan khác. Tiếp theo, chúng ta cần thống nhất về người quyết định yêu cầu cho dự án của mình. Cuối cùng, chúng ta cần hiểu được các nhiệm vụ mà người dùng thực hiện trong quá trình hoạt động kinh doanh của họ. Tuy nhiên, không phải tất cả các lựa chọn đều là bước trong quá trình tìm kiếm giọng nói của người dùng. Lựa chọn không phải bước trong quá trình này là 'Các nhiệm vụ họ thực hiện trong quá trình hoạt động kinh doanh của họ'.

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?

Ecosystem map là một công cụ giúp minh họa ranh giới và các mối liên kết giữa hệ thống đang phát triển và tất cả các yếu tố khác trong vũ trụ. Nó giúp chúng ta hiểu rõ hơn về hệ thống và cách nó tương tác với các hệ thống khác. Ecosystem map không chỉ dừng lại ở việc minh họa ranh giới và các mối liên kết, mà còn giúp chúng ta xác định các hệ thống liên quan đến hệ thống đang quan tâm và cách chúng tương tác với nhau. Điều này giúp chúng ta có cái nhìn tổng quan hơn về hệ thống và cách nó hoạt động trong môi trường xung quanh.

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.

Yêu cầu được giả định là những yêu cầu mà người dùng mong đợi mà không có sự thể hiện rõ ràng. Điều này có thể xảy ra khi người dùng không thể mô tả rõ ràng những gì họ cần, nhưng họ vẫn có một hình dung về kết quả cuối cùng. Ví dụ, một người dùng có thể nói rằng họ muốn một hệ thống có thể quản lý dữ liệu của họ, nhưng họ không thể mô tả rõ ràng cách thức hoạt động của hệ thống. Trong trường hợp này, yêu cầu được giả định là hệ thống phải có khả năng quản lý dữ liệu một cách tự động và chính xác. Yêu cầu được giả định thường được phát hiện qua quá trình thu thập yêu cầu (requirements elicitation) và cần được xác định rõ ràng để đảm bảo rằng hệ thống đáp ứng được nhu cầu của người dùng.

Khi tiếp cận hệ thống, điều đầu tiên chúng ta cần làm là hiểu được những gì cần thiết và những gì không cần thiết. Điều này liên quan đến việc phân tích và đánh giá các thành phần của hệ thống, bao gồm cả những gì được gọi là 'meta-model analysis'. Meta-model analysis là quá trình phân tích và mô hình hóa các thành phần cơ bản của hệ thống, bao gồm các quy tắc, quy định và các yếu tố ảnh hưởng đến hệ thống. Quá trình này giúp chúng ta hiểu được cấu trúc và chức năng của hệ thống, từ đó có thể xác định được những gì cần thiết và những gì không cần thiết.

Mô tả phạm vi dự án thường thay đổi theo thời gian và phụ thuộc vào nhiều yếu tố như yêu cầu của khách hàng, nguồn lực và ngân sách. Trong khi đó, tầm nhìn sản phẩm thường là một khái niệm cố định, thể hiện mục tiêu và hướng phát triển của dự án. Vì vậy, phạm vi dự án có thể được xem là động hơn so với tầm nhìn sản phẩm.

Mẫu bản yêu cầu chung được viết từ góc độ người dùng được thể hiện như sau: "Tên lớp người dùng hoặc tên người dùng tham gia shall được phép làm gì với một đối tượng Điều kiện đủ Thời gian hoặc chất lượng phản hồi" Ví dụ: "Người dùng khách hàng shall được phép đặt hàng trực tuyến Điều kiện đủ: khách hàng đã đăng ký tài khoản Thời gian phản hồi: trong vòng 5 phút Chất lượng phản hồi: chính xác 100%" Mẫu này cho phép người dùng thể hiện rõ yêu cầu của mình từ góc độ người dùng, giúp cho việc viết yêu cầu trở nên rõ ràng và dễ hiểu hơn.

Để xác định template phù hợp với yêu cầu ví dụ được viết dựa trên quan điểm của hệ thống, chúng ta cần phân tích yêu cầu. Yêu cầu yêu cầu hệ thống hiển thị danh sách tất cả các thùng chứa hóa chất đang có trong kho nếu hóa chất được tìm thấy trong kho hóa chất. Template phù hợp với yêu cầu này là 'optional precondition optional trigger event the system shall expected system response'. Template này mô tả các điều kiện không bắt buộc, sự kiện kích hoạt và phản hồi của hệ thống khi đáp ứng yêu cầu.