Software Requirements - SWR302

Prioritization là một kỹ thuật quan trọng trong quản lý yêu cầu, giúp đảm bảo rằng các yêu cầu quan trọng nhất được thực hiện trước. Khi có các yêu cầu xung đột, prioritization giúp xác định các yêu cầu nào cần được ưu tiên cao nhất. Điều này giúp đảm bảo rằng các yêu cầu quan trọng nhất được đáp ứng trước, giảm thiểu khả năng xảy ra các vấn đề hoặc sai sót trong quá trình thực hiện. Ngoài ra, prioritization cũng giúp giảm thiểu chi phí và thời gian cần thiết để thực hiện các yêu cầu, đồng thời tăng cường hiệu suất và hiệu quả của dự án. Bằng cách ưu tiên các yêu cầu quan trọng nhất, các nhà phát triển và quản lý dự án có thể tập trung vào việc thực hiện các yêu cầu quan trọng nhất, giảm thiểu khả năng xảy ra các vấn đề hoặc sai sót trong quá trình thực hiện.

Requirements specifications là tài liệu mô tả các yêu cầu của hệ thống, bao gồm cả các yêu cầu chức năng và không chức năng. Các đối tượng mục tiêu của tài liệu này bao gồm cả các nhóm người có liên quan đến hệ thống, chẳng hạn như kiến trúc sư hệ thống và nhà phát triển, kỹ sư kiểm thử và phân tích chất lượng, thành viên dự án và các bên liên quan khác. Mục đích của tài liệu này là cung cấp thông tin chi tiết về các yêu cầu của hệ thống, giúp các nhóm người này hiểu rõ về các yêu cầu và thực hiện các công việc của mình một cách hiệu quả. Vì vậy, đáp án đúng là 'All of the others', vì các đối tượng mục tiêu của requirements specifications bao gồm cả các nhóm người trên.

Một yêu cầu của bên liên quan (stakeholder) là một điều kiện hoặc khả năng cần thiết để giải quyết một vấn đề hoặc đạt được một mục tiêu. Nó đại diện cho một nhu cầu hoặc yêu cầu của một bên liên quan, chẳng hạn như một người dùng, một khách hàng hoặc một nhà quản lý. Yêu cầu của bên liên quan thường được xác định thông qua quá trình phân tích yêu cầu, trong đó các bên liên quan được hỏi về các nhu cầu và mong muốn của họ. Yêu cầu của bên liên quan có thể bao gồm các điều kiện như tính năng, hiệu suất, độ tin cậy, bảo mật và khả năng tương thích. Việc xác định và quản lý các yêu cầu của bên liên quan là một phần quan trọng của quy trình phát triển sản phẩm hoặc giải pháp, vì nó giúp đảm bảo rằng sản phẩm hoặc giải pháp đáp ứng được nhu cầu và mong muốn của các bên liên quan.

Để quản lý dự án phần mềm một cách nghiêm túc, tổ chức cần đảm bảo rằng các thay đổi yêu cầu được đánh giá kỹ lưỡng trước khi được chấp nhận. Điều này giúp ngăn chặn các thay đổi không cần thiết và đảm bảo rằng các yêu cầu được cập nhật một cách hợp lý. Việc đánh giá các thay đổi yêu cầu giúp tổ chức xác định xem các thay đổi đó có phù hợp với mục tiêu và yêu cầu của dự án hay không. Ngoài ra, việc đánh giá các thay đổi yêu cầu cũng giúp tổ chức xác định xem các thay đổi đó có ảnh hưởng đến các thành phần khác của dự án hay không. Điều này giúp tổ chức tránh được các vấn đề không cần thiết và đảm bảo rằng dự án được thực hiện một cách hiệu quả. Vì vậy, câu trả lời đúng là 'Proposed requirements changes are thoughtfully evaluated before being committed to.'

External quality attributes là những đặc điểm được quan sát khi phần mềm đang chạy. Trong đó, Integrity là khái niệm liên quan đến tính toàn vẹn của dữ liệu. Nó đảm bảo rằng dữ liệu được nhập vào hệ thống được bảo vệ khỏi mất mát và sai sót. Integrity là một trong những đặc điểm quan trọng của phần mềm, giúp đảm bảo rằng dữ liệu được sử dụng để đưa ra quyết định chính xác và đáng tin cậy. Nó liên quan đến việc ngăn chặn mất mát thông tin và bảo vệ tính chính xác của dữ liệu được nhập vào hệ thống. Ví dụ, một hệ thống quản lý ngân sách cần đảm bảo rằng các giao dịch được thực hiện chính xác và không bị mất mát, để đảm bảo rằng tài khoản của người dùng được cập nhật chính xác. Integrity là một đặc điểm quan trọng của phần mềm và cần được xem xét khi thiết kế và phát triển phần mềm.

Khi bạn tạo bản mẫu toàn bộ giải pháp thay vì chỉ tạo bản mẫu cho phần không chắc chắn, có rủi ro cao hoặc phức tạp nhất, bạn sẽ tăng cường nỗ lực vào bản mẫu. Điều này có thể dẫn đến việc lãng phí thời gian và nguồn lực vào việc tạo bản mẫu mà không cần thiết. Trong khi việc tạo bản mẫu cho phần không chắc chắn, có rủi ro cao hoặc phức tạp nhất có thể giúp bạn xác định và giải quyết các vấn đề quan trọng trước khi đầu tư quá nhiều thời gian và nguồn lực vào giải pháp toàn bộ. Điều này giúp bạn tối ưu hóa thời gian và nguồn lực của mình, đồng thời giảm thiểu rủi ro và tăng cường hiệu suất của giải pháp.

Trong quá trình phát triển yêu cầu, thiết lập cơ chế quản lý thay đổi yêu cầu là rất quan trọng vì nó cho phép dự án thích nghi với nhu cầu thay đổi trong quá trình thực hiện. Điều này giúp dự án duy trì kiểm soát và tránh bị ảnh hưởng tiêu cực bởi những thay đổi không lường trước được. Cơ chế quản lý thay đổi yêu cầu giúp dự án cập nhật và điều chỉnh yêu cầu một cách có hệ thống, từ đó đảm bảo rằng dự án luôn đáp ứng được nhu cầu của khách hàng và đạt được mục tiêu dự kiến. Ngoài ra, cơ chế này cũng giúp dự án tránh được những sai sót và lỗi do thay đổi yêu cầu không được quản lý tốt.

Sản phẩm vision và phạm vi dự án mô tả mục tiêu và phạm vi của dự án. Sản phẩm vision là tuyên bố về sản phẩm cuối cùng sẽ đạt được mục tiêu kinh doanh và phần nào đó của tầm nhìn sản phẩm cuối cùng mà dự án hoặc vòng phát triển hiện tại sẽ xử lý. Nói cách khác, sản phẩm vision là bản mô tả về sản phẩm mà dự án đang hướng tới và phạm vi dự án là phần nào đó của sản phẩm đó mà dự án sẽ xử lý trong vòng phát triển hiện tại. Điều này giúp các bên liên quan hiểu rõ về mục tiêu và phạm vi của dự án, từ đó có thể đặt ra các mục tiêu và chỉ tiêu cụ thể để đo lường thành công của dự án.

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?

Các hoạt động thu thập yêu cầu người dùng và nhóm tập trung nên được thực hiện ở giai đoạn nào?

Câu hỏi này yêu cầu người trả lời đánh giá một chiến lược trong kỹ thuật yêu cầu. Chiến lược này liên quan đến việc tập trung vào những người quan trọng trong tổ chức khi thực hiện phỏng vấn. Người trả lời cần quyết định liệu chiến lược này có hiệu quả hay không. Trong kỹ thuật yêu cầu, việc tập trung vào những người quan trọng có thể giúp thu thập thông tin chính xác và đầy đủ hơn về yêu cầu của tổ chức. Tuy nhiên, cũng có thể có những hạn chế của chiến lược này, chẳng hạn như việc bỏ qua những người không quan trọng nhưng vẫn có thể cung cấp thông tin hữu ích. Người trả lời cần cân nhắc các ưu và nhược điểm của chiến lược này và đưa ra quyết định dựa trên kinh nghiệm và kiến thức của mình.

Trong mô hình Actor, một Actor được định nghĩa là một thực thể có thể là một người dùng, một hệ thống hoặc một phần của hệ thống. Điều này cho phép mô hình hóa các hệ thống phức tạp bằng cách chia chúng thành các Actor độc lập. Vì vậy, câu trả lời đúng là 1. A-subsystem or external system cannot be modelled as an actor.

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.

Kỹ năng không phải là cơ bản của một nhà phân tích kinh doanh là kỹ năng giao tiếp. Nhà phân tích kinh doanh cần có kỹ năng giao tiếp để truyền đạt ý tưởng và thông tin một cách hiệu quả. Tuy nhiên, kỹ năng giao tiếp không phải là một trong những kỹ năng cơ bản của một nhà phân tích kinh doanh. Các kỹ năng cơ bản khác bao gồm kỹ năng lập kế hoạch, kỹ năng phân tích, kỹ năng phỏng vấn và kỹ năng lắng nghe.

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

Khái niệm yêu cầu hệ thống (System Requirement) được định nghĩa là mô tả về một 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 bao gồm các thuộc tính như hiệu suất, độ tin cậy, khả năng tương thích và các yêu cầu khác không liên quan trực tiếp đến chức năng của hệ thống. Yêu cầu hệ thống thường được xác định dựa trên yêu cầu của người dùng, yêu cầu của quy trình kinh doanh và các ràng buộc về kỹ thuật. Mục tiêu của yêu cầu hệ thống là đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu và nhu cầu của người dùng, đồng thời đảm bảo rằng hệ thống có thể vận hành một cách ổn định và hiệu quả.

Kỹ thuật tự động hóa quy trình kinh doanh phù hợp nhất để giúp phát triển dự án giải pháp phần mềm đóng gói là thích nghi quy trình kinh doanh để cho phép sử dụng giải pháp phần mềm COTS (Commercial Off-The-Shelf). Điều này có nghĩa là phải thay đổi hoặc điều chỉnh các quy trình kinh doanh hiện tại để phù hợp với giải pháp phần mềm COTS đã chọn. Điều này giúp đảm bảo rằng giải pháp phần mềm được tích hợp một cách trơn tru và hiệu quả vào quy trình kinh doanh hiện tại của tổ chức. Việc thích nghi quy trình kinh doanh cũng giúp giảm thiểu các vấn đề liên quan đến việc tích hợp và đảm bảo rằng giải pháp phần mềm đáp ứng được các nhu cầu kinh doanh của tổ chức.

Các tính năng yêu cầu được tái sử dụng thường liên quan đến các yêu cầu chung và chức năng phổ biến. Ví dụ, 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. 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 một lần duy nhất sử dụng Active Directory cho xác thực người dùng. Ngoài ra, các ứng dụng kinh doanh thường chứa chức năng phổ biến mà yêu cầu và thậm chí cả thực hiện đầy đủ có thể được tái sử dụng. Các ví dụ bao gồm các hoạt động tìm kiếm, in ấn, các hoạt động tệp, hồ sơ người dùng, undo/redo và định dạng văn bản.

Khi phát triển yêu cầu dự án, việc tạo prototype là rất quan trọng. Có ba lý do chính để tạo prototype trong quá trình này. Thứ nhất, prototype có thể bao gồm phần mềm hoạt động cho một phần giải pháp, giúp xác định tính khả thi của ý tưởng. Thứ hai, prototype giúp khám phá tính vững chắc kỹ thuật của phương pháp đề xuất. Điều này cho phép phát hiện và sửa lỗi sớm trong quá trình phát triển. Cuối cùng, prototype tập trung vào trải nghiệm người dùng, giúp xác định xem sản phẩm có đáp ứng được nhu cầu và mong muốn của người dùng hay không.

Để cải thiện các thuật ngữ không rõ ràng (tốt hơn, nhanh hơn, chất lượng cao hơn), chúng ta cần xác định rõ ràng những gì được hiểu là 'tốt hơn' hay 'nhanh hơn'. Trong đó, cách phù hợp nhất là định lượng được mức độ cải thiện nào là đủ trong 6 lĩnh vực chức năng hoặc khía cạnh chất lượng cụ thể. Điều này giúp đảm bảo rằng mọi người có cùng một tiêu chuẩn và hiểu biết về những gì được coi là 'tốt hơn' hay 'nhanh hơn'. Ví dụ, nếu chúng ta đang cải thiện tốc độ của một hệ thống, chúng ta có thể định lượng được mức độ cải thiện tối thiểu là bao nhiêu phần trăm. Điều này giúp tránh những hiểu lầm và đảm bảo rằng mọi người có cùng một mục tiêu.