Ôn tập cuối kỳ SWR302 Fall 2022

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.

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

Để trả lời câu hỏi này, chúng ta cần hiểu mục đích của việc xác định yêu cầu. Các lựa chọn không đúng về động lực cho việc xác định yêu cầu bao gồm: Quản lý dự án, Bảo trì, Kiểm tra, Chế tạo lại và Chuyển đổi. Những hoạt động này không phải là động lực chính cho việc xác định yêu cầu. Thay vào đó, chúng ta có các động lực như: Tìm kiếm yêu cầu bị thiếu, Tìm kiếm yêu cầu không cần thiết, Xác thực và tuân thủ, Phân tích tác động của thay đổi, Quản lý dự án (dù không phải là động lực chính).

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.

Các mối quan hệ giữa Use Case được định nghĩa như sau: Một mối quan hệ Include cho biết một Use Case bao gồm hành vi được mô tả trong Use Case khác. Một mối quan hệ Extend cho biết một Use Case có thể mở rộng hành vi được mô tả trong Use Case khác. Tương tự như kế thừa trong lập trình, mối quan hệ Generalization giữa Use Cases cho biết Use Case con là một dạng cụ thể hơn của Use Case cha. Use Case con thừa kế tất cả các tính năng và mối quan hệ của Use Case cha và có thể thêm mới các tính năng và mối quan hệ. Tất cả các mối quan hệ trên đều đúng và được sử dụng trong việc mô hình hóa Use Case.

Câu trả lời đúng về thỏa thuận về yêu cầu là: "Khách hàng đồng ý rằng các yêu cầu đáp ứng nhu cầu của họ.". Điều này có nghĩa là khách hàng cần đảm bảo rằng các yêu cầu được đưa ra đã được thiết kế để đáp ứng nhu cầu và mong muốn của họ. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện một cách chính xác và hiệu quả. Trong khi các yêu cầu khác có thể không chính xác hoặc không đầy đủ, điều này sẽ dẫn đến sự thất vọng và lãng phí thời gian. Vì vậy, việc khách hàng đồng ý rằng các yêu cầu đáp ứng nhu cầu của họ là rất quan trọng để đảm bảo rằng dự án được thực hiện một cách thành công.

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 chiều cơ bản của tái sử dụng yêu cầu bao gồm phạm vi tái sử dụng, cơ chế tái sử dụng và thừa kế tái sử dụng. Trong đó, phạm vi tái sử dụng và cơ chế tái sử dụng là hai chiều quan trọng để xác định mức độ tái sử dụng và hiệu quả của quá trình tái sử dụng. Thừa kế tái sử dụng là một phương pháp tái sử dụng yêu cầu, giúp giảm thiểu thời gian và công sức trong việc phát triển phần mềm. Ngược lại, phạm vi sửa đổi không phải là một chiều cơ bản của tái sử dụng yêu cầu, mà là một khía cạnh liên quan đến quá trình tái sử dụng. Nó mô tả mức độ thay đổi cần thiết để phù hợp hóa yêu cầu đã được tái sử dụng với yêu cầu mới.

Các yêu cầu chức năng mô tả đầy đủ như cần thiết về hành vi mong đợi của hệ thống phần mềm. Chúng xác định các hành vi mà sản phẩm sẽ thể hiện trong các điều kiện cụ thể. Chúng mô tả những gì nhà phát triển phải thực hiện để cho phép người dùng thực hiện các nhiệm vụ của họ (yêu cầu người dùng), từ đó đáp ứng các yêu cầu kinh doanh. Ví dụ, yêu cầu chức năng có thể bao gồm các chức năng như đăng nhập, đăng ký, tìm kiếm thông tin, v.v. Mục tiêu của các yêu cầu chức năng là đảm bảo rằng hệ thống phần mềm đáp ứng được các yêu cầu của người dùng và đáp ứng được các mục tiêu kinh doanh của tổ chức.

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.

Một trong những mô hình quản lý rủi ro là mô hình chuyển thông tin rủi ro thành quyết định và hành động. Mô hình này thường được sử dụng trong các tổ chức để đưa ra quyết định dựa trên thông tin rủi ro. Trong các lựa chọn trên, 'Analyze' là một trong những mô hình quản lý rủi ro phù hợp với mô tả này. Mô hình 'Analyze' giúp tổ chức phân tích và đánh giá rủi ro, từ đó đưa ra quyết định và hành động để giảm thiểu hoặc phòng ngừa rủi ro. Điều này giúp tổ chức có thể đưa ra quyết định sáng suốt và hiệu quả hơn.

Tính chất chất lượng là một khái niệm quan trọng trong thiết kế và phát triển hệ thống. Nó được định nghĩa là một đặc tả về 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ủ. Ví dụ, một hệ thống có thể phải đáp ứng tính chất bảo mật, tính khả dụng hoặc hiệu suất. Tính chất chất lượng thường được sử dụng để mô tả các yêu cầu không chức năng của hệ thống, bao gồm cả các yêu cầu về dịch vụ và tính năng.

Để mô hình hóa các yêu cầu và phân bổ các yêu cầu vào các subsystem, chúng ta cần hiểu rõ khái niệm 'hoạt động nên được thực hiện theo các giai đoạn'. Điều này liên quan đến quá trình phân tích yêu cầu (Requirements Analysis) để xác định các hoạt động cần được thực hiện và phân bổ chúng vào các subsystem phù hợp. Quá trình này bao gồm việc xác định các yêu cầu chức năng và không chức năng, phân tích các yêu cầu và xác định các hoạt động cần được thực hiện. Sau đó, chúng ta sẽ phân bổ các hoạt động này vào các subsystem phù hợp dựa trên các yêu cầu chức năng và không chức năng đã xác định. Quá trình này đòi hỏi sự hiểu biết sâu sắc về các yêu cầu và khả năng của các subsystem.

Để điền vào chỗ trống trong câu sau, chúng ta cần tìm từ ngữ phù hợp. Từ ngữ đó phải 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.

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.

Mục tiêu của phần Background trong tài liệu Vision và Scope là mô tả lý do và bối cảnh cho sản phẩm mới hoặc thay đổi đối với sản phẩm hiện có. Nó giải thích 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. Phần này giúp người đọc hiểu rõ hơn về mục tiêu và tầm quan trọng của sản phẩm. Nó cũng cung cấp thông tin về các yếu tố ảnh hưởng đến việc xây dựng sản phẩm, bao gồm cả các thách thức và cơ hội. Mục tiêu của phần Background là cung cấp bối cảnh và lý do cho việc xây dựng sản phẩm, giúp người đọc hiểu rõ hơn về tầm quan trọng và mục tiêu của sản phẩm.

Một CRUD matrix là một kỹ thuật phân tích dữ liệu nghiêm ngặt được sử dụng để phát hiện các yêu cầu trùng lặp trong hệ thống. Kỹ thuật này giúp xác định các yêu cầu không cần thiết hoặc không phù hợp, từ đó giúp giảm thiểu sự phức tạp của hệ thống và tăng cường hiệu suất. Trong một CRUD matrix, các yêu cầu được phân loại thành bốn loại: tạo (Create), đọc (Read), cập nhật (Update) và xóa (Delete). Bằng cách phân tích các yêu cầu này, các nhà phát triển có thể xác định các yêu cầu trùng lặp và loại bỏ chúng, từ đó giúp cải thiện chất lượng của hệ thống.

Điểu án ngữ cảnh là một công cụ quan trọng trong thiết kế hệ thống, giúp xác định ranh giới và các mối liên hệ giữa hệ thống đang phát triển và các hệ thống khác trong môi trường xung quanh. Nó cho phép các nhà phát triển hiểu rõ hơn về hệ thống và các yếu tố ảnh hưởng đến nó. Câu trả lời đúng về điểu án ngữ cảnh là: 'Điểu án ngữ cảnh thể hiện rõ ranh giới và các mối liên hệ giữa hệ thống đang phát triển và các hệ thống khác trong môi trường xung quanh.'

Các tính chất của yêu cầu bao gồm: 1. Ngày yêu cầu được tạo ra, 2. Số phiên bản hiện tại của yêu cầu, 3. Người viết yêu cầu, 4. Độ ưu tiên và 5. Xác thực yêu cầu. Để trả lời câu hỏi này, chúng ta cần xác định các tính chất quan trọng của yêu cầu. Tính chất 1 là ngày tạo ra yêu cầu, giúp chúng ta theo dõi lịch sử của yêu cầu. Tính chất 2 là số phiên bản hiện tại của yêu cầu, giúp chúng ta biết được phiên bản nào đang được sử dụng. Tính chất 3 là người viết yêu cầu, giúp chúng ta biết được người chịu trách nhiệm về yêu cầu. Tính chất 4 là độ ưu tiên, giúp chúng ta biết được mức độ quan trọng của yêu cầu. Tính chất 5 là xác thực yêu cầu, giúp chúng ta biết được yêu cầu đã được kiểm tra và xác minh chưa. Vì vậy, các tính chất của yêu cầu bao gồm: ngày tạo ra yêu cầu, số phiên bản hiện tại của yêu cầu, người viết yêu cầu, độ ưu tiên và xác thực yêu cầu.

Khi cố gắng thể hiện, phân tích hoặc khám phá mô tả các nhiệm vụ người dùng, phương pháp thể hiện phù hợp nhất là sử dụng các câu chuyện người dùng, kịch bản và mô tả trường hợp sử dụng. Phương pháp này cho phép bạn mô tả các nhiệm vụ người dùng một cách chi tiết và cụ thể, đồng thời cũng giúp bạn phân tích và khám phá các yêu cầu của người dùng. Các câu chuyện người dùng giúp bạn hiểu rõ hơn về các nhu cầu và mong muốn của người dùng, trong khi các kịch bản và mô tả trường hợp sử dụng giúp bạn xác định các yêu cầu chức năng và không chức năng của hệ thống.