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

Khi yêu cầu thông tin về yêu cầu báo cáo từ khách hàng, một trong những câu hỏi đầu tiên cần hỏi là gì? Để hiểu rõ về nhu cầu của khách hàng và cung cấp giải pháp báo cáo phù hợp, chúng ta cần biết thông tin chi tiết về báo cáo hiện tại mà khách hàng đang sử dụng. Điều này giúp chúng ta xác định được các yêu cầu chính và bắt đầu thiết kế báo cáo phù hợp.

Agile là một phương pháp quản lý dự án linh hoạt và nhanh chóng, tập trung vào việc phát triển và cải thiện liên tục. Agile khuyến khích sự tương tác giữa các thành viên trong dự án, bao gồm cả khách hàng, để đảm bảo rằng dự án được thực hiện đúng theo yêu cầu và mong muốn của họ. Trong Agile, các thành viên trong dự án thường xuyên họp và thảo luận để cập nhật và điều chỉnh kế hoạch dự án. Điều này giúp dự án được thực hiện nhanh chóng và hiệu quả hơn.

Risk assessment là quá trình đánh giá và xác định các rủi ro tiềm ẩn trong một dự án. Quá trình này bao gồm việc phân tích và xác định các mối đe dọa, xác định mức độ nghiêm trọng của rủi ro và xác định các biện pháp phòng ngừa và giảm thiểu rủi ro. Mục tiêu của risk assessment là giúp dự án tránh được các rủi ro tiềm ẩn và giảm thiểu tác động của chúng khi chúng xảy ra. Quá trình này thường được thực hiện bởi các chuyên gia trong lĩnh vực dự án và rủi ro.

Planguage là một ngôn ngữ được thiết kế để giúp các nhà phát triển và quản lý dự án thể hiện rõ ràng và chính xác các thuộc tính chất lượng và mục tiêu dự án khác. Ngôn ngữ này cung cấp một bộ từ khóa phong phú cho phép người dùng tạo ra các tuyên bố chính xác về các thuộc tính chất lượng và mục tiêu dự án. Điều này giúp cho việc quản lý dự án trở nên dễ dàng hơn và giảm thiểu khả năng xảy ra sai sót. Planguage được sử dụng rộng rãi trong các dự án phần mềm và công nghệ để đảm bảo rằng các mục tiêu và yêu cầu của dự án được thực hiện một cách chính xác và hiệu quả.

Trong một tài liệu yêu cầu phần mềm, phần mô tả giao diện người dùng thuộc về phần nào?

Một đại diện được chỉ định của một lớp người dùng cụ thể cung cấp các yêu cầu người dùng cho nhóm mà họ đại diện. Người đại diện này đóng vai trò quan trọng trong việc xác định và ưu tiên các yêu cầu của nhóm, đảm bảo rằng các yêu cầu này được thực hiện một cách hiệu quả và phù hợp với mục tiêu của nhóm. Họ cũng phải có khả năng giao tiếp và làm việc hiệu quả với các thành viên khác trong nhóm, cũng như với các bên liên quan khác.

Để tìm kiếm các quy tắc kinh doanh, bạn có thể tham khảo các nguồn sau: Thứ nhất, kiến thức phổ biến từ tổ chức, thường được thu thập từ những người đã làm việc với doanh nghiệp trong một thời gian dài và hiểu rõ chi tiết về cách thức hoạt động của nó. Điều này giúp bạn hiểu được quy trình và quy tắc kinh doanh của tổ chức. Thứ hai, hệ thống di sản (Legacy systems) chứa các quy tắc kinh doanh trong yêu cầu và mã nguồn của chúng. Điều này cho phép bạn hiểu được cách thức hoạt động của hệ thống và các quy tắc kinh doanh được áp dụng. Thứ ba, phân tích tài liệu hiện có, bao gồm các yêu cầu kỹ thuật từ dự án trước, quy định, tiêu chuẩn ngành, tài liệu chính sách doanh nghiệp, hợp đồng và kế hoạch kinh doanh. Điều này giúp bạn hiểu được quy tắc kinh doanh và cách thức hoạt động của doanh nghiệp. Tóm lại, việc tìm kiếm quy tắc kinh doanh là một quá trình phức tạp và đòi hỏi sự tham gia của nhiều nguồn lực khác nhau.

Một mock-up và một prototype thường được sử dụng trong quá trình thiết kế và phát triển sản phẩm. Một mock-up là một bản sao hoặc mô hình của sản phẩm, thường được sử dụng để thể hiện ý tưởng và thiết kế ban đầu. Một prototype, mặt khác, là một phiên bản thực tế của sản phẩm, thường được sử dụng để thử nghiệm và đánh giá tính khả thi của sản phẩm. Trong khi một mock-up thường được gọi là một prototype, một proof of concept thường được gọi là một prototype. Điều này có nghĩa là một proof of concept là một phiên bản cơ bản hoặc thử nghiệm của sản phẩm, thường được sử dụng để chứng minh tính khả thi của ý tưởng và thiết kế.

Trong việc mô tả một trường hợp sử dụng, các điều kiện có khả năng ngăn cản trường hợp sử dụng thành công được gọi là ngoại lệ. Ngoại lệ là các điều kiện không mong muốn có thể xảy ra trong quá trình thực hiện một trường hợp sử dụng, chẳng hạn như lỗi dữ liệu, lỗi kết nối mạng, v.v. Khi xác định ngoại lệ, chúng ta cần phải xác định rõ nguyên nhân và cách giải quyết của chúng để đảm bảo rằng trường hợp sử dụng vẫn có thể hoạt động một cách hiệu quả. Ngoài ra, ngoại lệ cũng giúp chúng ta xác định các trường hợp sử dụng phụ, những trường hợp sử dụng có thể xảy ra nhưng không phải là trường hợp sử dụng chính.

Câu hỏi này yêu cầu bạn xác định thông tin không liên quan đến dự án được giao ngoài (outsourced projects). Các lựa chọn bao gồm: - Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. - Đó là khó khăn hơn để có được ý kiến của nhà phát triển về yêu cầu và để chuyển lại phản hồi của người dùng về phần mềm đã được giao cho nhà phát triển. - Cần có định nghĩa hợp đồng chính thức về yêu cầu, điều này có thể dẫn đến tranh chấp nếu sự khác biệt trong việc giải thích được phát hiện muộn trong dự án. Câu trả lời đúng là: Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. Vì dự án được giao ngoài thường không tận dụng kỹ năng phát triển có sẵn trong nội bộ mà thay vào đó là thuê ngoài để thực hiện.

Một bản mẫu phần mềm là một bản dựng thử nghiệm của một sản phẩm mới. Nó thường được tạo ra để kiểm tra ý tưởng và xác định các yêu cầu của sản phẩm. Bản mẫu phần mềm có thể được xem là một phần thực hiện của sản phẩm mới, vì nó chỉ bao gồm một số tính năng hoặc chức năng của sản phẩm. Nó cũng có thể được xem là một bản dựng khả thi của sản phẩm mới, vì nó thể hiện một cách khả thi để triển khai sản phẩm. Ngoài ra, bản mẫu phần mềm cũng có thể được xem là một bản dựng sơ bộ của sản phẩm mới, vì nó thường được tạo ra trước khi sản phẩm được hoàn thiện. Tuy nhiên, bản mẫu phần mềm không phải lúc nào cũng là bản dựng hoàn chỉnh của sản phẩm mới.

Throwaway prototype là một loại prototype được xây dựng để đáp ứng nhu cầu cụ thể trong một giai đoạn nhất định. Nó thường được sử dụng khi đội ngũ phát triển gặp phải sự không chắc chắn, mơ hồ, không đầy đủ hoặc không rõ ràng trong yêu cầu. Mục đích chính của một prototype như vậy là để trả lời các câu hỏi, giải quyết sự không chắc chắn và cải thiện chất lượng yêu cầu. Khi xây dựng một prototype như vậy, đội ngũ phát triển không cần phải tuân thủ các kỹ thuật xây dựng phần mềm nghiêm ngặt. Điều này cho phép họ tập trung vào việc giải quyết các vấn đề quan trọng và tạo ra một sản phẩm có thể đáp ứng nhu cầu của khách hàng. Tuy nhiên, nó không phải là một sản phẩm cuối cùng và có thể được loại bỏ sau khi hoàn thành.

Mỗi lựa chọn đều đóng vai trò quan trọng trong mô tả chi tiết của Software Requirements Specification (SRS). Tuy nhiên, 'System feature' không phải là một phần quan trọng trong mô tả tổng quan của SRS. SRS thường bao gồm các phần như 'Product perspective' (khái quát về sản phẩm), 'User classes and characteristics' (khái quát về người dùng), 'Operating environment' (khái quát về môi trường hoạt động), 'Design and implementation constraints' (khái quát về hạn chế trong thiết kế và triển khai), 'Assumptions and dependencies' (khái quát về giả định và phụ thuộc). 'System feature' thường được sử dụng để mô tả các tính năng cụ thể của hệ thống, chứ không phải là mô tả tổng quan.

Khi viết SRS, việc ghi nhãn các yêu cầu là rất quan trọng. Điều này cho phép chúng ta tham khảo các yêu cầu cụ thể trong yêu cầu thay đổi, lịch sử sửa đổi, liên kết, hoặc ma trận theo dõi yêu cầu. Ngoài ra, việc ghi nhãn yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong nhiều dự án khác nhau. Điều này giúp tiết kiệm thời gian và công sức trong quá trình phát triển phần mềm. Hơn nữa, việc ghi nhãn yêu cầu cũng giúp cải thiện sự hợp tác giữa các thành viên trong nhóm khi họ thảo luận về các yêu cầu.

Sự khác biệt giữa Use Cases và User Stories là gì? Use Cases là một tài liệu kinh doanh xác định yêu cầu phần mềm hoặc tính năng ứng dụng. Trong khi đó, User Stories là một tài liệu kiểm thử xác định các bước để xác minh và xác thực rằng yêu cầu phần mềm hoặc tính năng ứng dụng tồn tại. Use Cases thường được sử dụng để mô tả các yêu cầu kinh doanh và chức năng của ứng dụng, trong khi User Stories được sử dụng để mô tả các yêu cầu kiểm thử và xác thực. Ví dụ, một Use Case có thể mô tả cách một người dùng có thể tạo một tài khoản mới, trong khi một User Story có thể mô tả các bước để kiểm thử tính năng tạo tài khoản mới.

Để phân biệt giữa yêu cầu sản phẩm và yêu cầu dự án, chúng ta cần hiểu rõ về từng loại yêu cầu. Yêu cầu sản phẩm (Product requirements) tập trung vào các đặc điểm và tính năng của hệ thống phần mềm đang được xây dựng. Điều này bao gồm các yêu cầu về chức năng, hiệu suất, bảo mật và tương thích. Ví dụ, yêu cầu sản phẩm có thể bao gồm yêu cầu về giao diện người dùng, tính năng tìm kiếm, hoặc khả năng tương thích với các hệ thống khác. Yêu cầu dự án (Project requirements) lại tập trung vào các yêu cầu về nguồn lực, đào tạo và thay đổi cơ sở hạ tầng cần thiết để hoàn thành dự án. Điều này bao gồm các yêu cầu về nhân lực, đào tạo, cơ sở vật chất và thay đổi cơ sở hạ tầng. Ví dụ, yêu cầu dự án có thể bao gồm yêu cầu về đào tạo nhân viên, thay đổi cơ sở vật chất, hoặc mua sắm thiết bị mới. Câu trả lời đúng là: - Yêu cầu dự án bao gồm đào tạo nhân viên và thay đổi cơ sở hạ tầng cần thiết trong môi trường hoạt động. - Yêu cầu sản phẩm tập trung vào các đặc điểm và tính năng của hệ thống phần mềm đang được xây dựng.

Foment một mối quan hệ hợp tác giữa nhóm phát triển và các bên liên quan khác trong quá trình yêu cầu là rất quan trọng. Mục tiêu chính của việc này là đảm bảo rằng các nhu cầu kinh doanh, kỹ thuật và người dùng được đồng bộ hóa và tránh hiểu lầm. Khi các bên liên quan hợp tác chặt chẽ, họ có thể chia sẻ thông tin và hiểu rõ hơn về yêu cầu của dự án. Điều này giúp đảm bảo rằng dự án được thực hiện một cách hiệu quả và đáp ứng được nhu cầu của tất cả các bên liên quan. Ngoài ra, việc hợp tác cũng giúp giảm thiểu rủi ro và tăng cường sự tin tưởng giữa các bên.

Công cụ mà Seilevel đã phát triển để hỗ trợ việc ước tính nỗ lực phát triển yêu cầu là một bảng tính để ước tính nỗ lực yêu cầu. Bảng tính này giúp các chuyên gia yêu cầu ước tính chính xác nỗ lực cần thiết để hoàn thành các yêu cầu, từ đó giúp các nhà quản lý dự án lập kế hoạch và phân bổ nguồn lực một cách hiệu quả hơn. Bằng cách sử dụng bảng tính này, các chuyên gia yêu cầu có thể xem xét các yếu tố như mức độ phức tạp của yêu cầu, thời gian cần thiết để hoàn thành yêu cầu và các nguồn lực cần thiết để hoàn thành yêu cầu.

Mô hình Kano giúp phân tích yêu cầu người dùng bằng cách phân loại các tính năng thành ba loại: cơ bản, hiệu suất và thú vị. Các tính năng cơ bản là những tính năng cần thiết để sản phẩm hoạt động, chẳng hạn như khả năng hoạt động của một chiếc điện thoại. Các tính năng hiệu suất là những tính năng giúp sản phẩm hoạt động tốt hơn, chẳng hạn như tốc độ xử lý nhanh hơn. Các tính năng thú vị là những tính năng giúp sản phẩm trở nên thú vị hơn, chẳng hạn như khả năng chơi game. Mô hình Kano giúp các nhà phát triển hiểu rõ hơn về những gì người dùng mong đợi từ sản phẩm và giúp họ tập trung vào việc phát triển các tính năng quan trọng nhất.