Ôn tập thi lại SWR302 Fall 2023

Để 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ọ'.

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?

Khi chuẩn bị cho quá trình thu thập yêu cầu (elicitation) trên dự án của mình, bước đầu tiên quan trọng là quyết định phạm vi và chương trình thu thập yêu cầu (decide on elicitation scope and agenda). Điều này giúp bạn xác định rõ những gì cần thu thập, ai sẽ tham gia vào quá trình thu thập, và mục tiêu của quá trình thu thập yêu cầu. Bằng cách quyết định phạm vi và chương trình thu thập yêu cầu, bạn có thể đảm bảo rằng quá trình thu thập yêu cầu được thực hiện một cách hiệu quả và đạt được mục tiêu mong muốn. Ngoài ra, quyết định phạm vi và chương trình thu thập yêu cầu cũng giúp bạn tránh được những sai sót và nhầm lẫn trong quá trình thu thập yêu cầu.

Ký hiệu đồ họa cho phép bạn thể hiện các mục được xem xét và mối quan hệ giữa chúng. Điều này giúp dễ dàng theo dõi và phân tích các mối quan hệ phức tạp giữa các yếu tố khác nhau. Ví dụ, trong một sơ đồ tổ chức, ký hiệu đồ họa có thể được sử dụng để thể hiện mối quan hệ giữa các bộ phận khác nhau của công ty, bao gồm cả mối quan hệ giữa các nhân viên và các bộ phận khác nhau. Điều này giúp dễ dàng theo dõi và phân tích các mối quan hệ phức tạp giữa các yếu tố khác nhau.

Hoạt động mô hình hóa môi trường ứng dụng và tạo bản mẫu nên được thực hiện ở giai đoạn Elicitation. Elicitation là giai đoạn đầu tiên trong quá trình phát triển phần mềm, trong đó người phát triển sẽ thu thập thông tin về yêu cầu của khách hàng và mô hình hóa môi trường ứng dụng để hiểu rõ hơn về yêu cầu của khách hàng. Hoạt động này giúp người phát triển xác định rõ yêu cầu của khách hàng và tạo ra bản mô hình hóa môi trường ứng dụng để sử dụng trong các giai đoạn tiếp theo.

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

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

Phương pháp xác định ưu tiên yêu cầu dựa trên mức độ quan trọng và cấp thiết thuộc về kỹ thuật so sánh cặp đôi và xếp hạng (Pairwise comparison and rank ordering). Điều này có nghĩa là các yêu cầu sẽ được so sánh với nhau một cách cặp đôi để xác định mức độ quan trọng và cấp thiết của từng yêu cầu. Sau đó, các yêu cầu sẽ được xếp hạng theo mức độ quan trọng và cấp thiết để xác định ưu tiên thực hiện. Phương pháp này giúp đảm bảo rằng các yêu cầu quan trọng và cấp thiết được ưu tiên thực hiện trước.

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.

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?

Theo Karl Wiegers và Joy Beatty trong sách Software Requirements, phiên bản thứ ba, mô hình yêu cầu phần mềm (Software Requirements model) có bao nhiêu cấp độ? Cấp độ này được sử dụng để mô tả các yêu cầu phần mềm ở các mức độ khác nhau. Mô hình này bao gồm các cấp độ sau: cấp độ 1 - yêu cầu chức năng, cấp độ 2 - yêu cầu không chức năng và cấp độ 3 - yêu cầu kỹ thuật. Mỗi cấp độ này cung cấp thông tin chi tiết về các yêu cầu phần mềm ở mức độ khác nhau, giúp các nhà phát triển phần mềm hiểu rõ hơn về yêu cầu của khách hàng và thực hiện các yêu cầu đó một cách chính xác.

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.

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.

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

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.

Trong các dự án được giao thầu (Outsourced Projects), người mua (Acquirer) không cần phải gửi cho nhà cung cấp (Supplier) sản phẩm phần mềm đã hoàn thiện. Điều này là vì nhà cung cấp đã chịu trách nhiệm phát triển và cung cấp sản phẩm phần mềm. Người mua chỉ cần cung cấp các yêu cầu và tiêu chí chấp nhận để nhà cung cấp thực hiện và đảm bảo sản phẩm phần mềm đáp ứng được yêu cầu. Các tài liệu cần thiết mà người mua phải gửi cho nhà cung cấp bao gồm yêu cầu đề xuất (Request for proposal), yêu cầu kỹ thuật phần mềm (Software Requirements) và tiêu chí chấp nhận (Acceptance criteria).

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.

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.

Hoạt động không thuộc về quy trình thiết kế và mã hóa là: "Trace requirements to design and code". Hoạt động này liên quan đến việc theo dõi các yêu cầu để đảm bảo chúng được thực hiện một cách chính xác trong quy trình thiết kế và mã hóa. Tuy nhiên, nó không phải là một phần của quy trình thiết kế và mã hóa chính thức. Các hoạt động khác như "Have developers review requirements", "Use quality attributes to drive architecture", "Allocate requirements to components", và "Use requirement priorities to drive process iteration" đều là các bước quan trọng trong quy trình thiết kế và mã hóa.