Software Requirements - SWR302

Sự cải tiến quy trình phần mềm là một quá trình liên tục và cần được thực hiện một cách có mục tiêu. Trong đó, các quy trình được cải tiến liên tục để đáp ứng nhu cầu và mục tiêu của tổ chức. Điều này đòi hỏi sự tham gia và cam kết của tất cả các thành viên trong tổ chức, bao gồm cả nhân viên và lãnh đạo. Quan điểm 'Prioritizing individual contributions over teamwork' không phù hợp với nguyên tắc này vì nó đặt ưu tiên vào đóng góp cá nhân hơn là sự hợp tác và làm việc nhóm. Trong khi đó, các nguyên tắc khác như 'People and organizations change only when they have an incentive to do so', 'Process changes should be goal-oriented', và 'Process improvement should be evolutionary and continuous' đều phản ánh đúng tinh thần của sự cải tiến quy trình phần mềm.

Một khách hàng phần mềm (software customer) là một cá nhân hoặc tổ chức có lợi ích trực tiếp hoặc gián tiếp từ sản phẩm phần mềm. Họ có thể yêu cầu, trả tiền, chọn, chỉ định, sử dụng hoặc nhận được kết quả được tạo ra bởi sản phẩm phần mềm. Khách hàng phần mềm bao gồm cả những người có lợi ích trực tiếp từ sản phẩm phần mềm, chẳng hạn như người sử dụng cuối cùng, cũng như những người có lợi ích gián tiếp, chẳng hạn như các bên liên quan, nhà cung cấp dịch vụ hoặc các tổ chức có liên quan khác. Trong câu hỏi này, các lựa chọn A, B và C đều mô tả đúng về khách hàng phần mềm. Tuy nhiên, lựa chọn D, 'Such as legal staff, compliance auditors, suppliers', không hoàn toàn chính xác. Các nhân viên pháp lý, kiểm toán viên tuân thủ và nhà cung cấp có thể là những bên liên quan quan trọng, nhưng chúng không phải là khách hàng phần mềm chính thức. Họ có thể được coi là những bên liên quan hoặc nhà cung cấp dịch vụ, nhưng không phải là những người có lợi ích trực tiếp hoặc gián tiếp từ sản phẩm phần mềm.

Validation of requirements là một phần quan trọng trong quá trình phát triển yêu cầu, giúp đảm bảo rằng các yêu cầu đã được viết đúng và phù hợp với mục tiêu kinh doanh. Quá trình này bao gồm việc kiểm tra và xác minh các yêu cầu đã được viết để đảm bảo chúng có tất cả các đặc tính mong muốn của yêu cầu chất lượng cao. Điều này bao gồm việc đảm bảo rằng các yêu cầu rõ ràng, cụ thể, dễ hiểu và không mâu thuẫn với nhau. Quá trình này cũng giúp đảm bảo rằng các yêu cầu đã được viết phù hợp với mục tiêu kinh doanh và chiến lược của tổ chức. Việc thực hiện quá trình này giúp xây dựng một giải pháp chính xác và hiệu quả, đáp ứng được các mục tiêu kinh doanh đã được đặt ra.

Câu hỏi này yêu cầu bạn xác định phương pháp không liên quan đến giải pháp đóng gói. Phương pháp đóng gói là khi bạn sử dụng một giải pháp đã được tạo sẵn, có thể được mua hoặc tải xuống, để giải quyết một vấn đề cụ thể. Giải pháp đóng gói thường đã được thiết kế và thử nghiệm trước đó, giúp giảm thiểu thời gian và công sức cần thiết để triển khai và duy trì hệ thống. Trong khi đó, phương pháp xây dựng hệ thống bằng cách sử dụng nhân viên của mình là một phương pháp khác, nơi bạn xây dựng hệ thống từ đầu bằng cách sử dụng nhân viên của mình. Điều này đòi hỏi sự hiểu biết sâu sắc về công nghệ, kỹ năng và kinh nghiệm của nhân viên, cũng như khả năng quản lý và điều phối dự án. Phương pháp này cho phép bạn có sự kiểm soát hoàn toàn về hệ thống và có thể được tùy chỉnh để đáp ứng nhu cầu cụ thể của doanh nghiệp. Vì vậy, phương pháp xây dựng hệ thống bằng cách sử dụng nhân viên của mình không phải là một phương pháp liên quan đến giải pháp đóng gói.

Câu hỏi trắc nghiệm này liên quan đến các dự án được giao thầu ngoài (outsourced projects). Các lựa chọn A, B và C đều liên quan đến các vấn đề thường gặp khi thực hiện dự án được giao thầu ngoài. Lựa chọn A cho biết dự án có thể tận dụng kỹ năng phát triển sẵn có trong nội bộ công ty. Lựa chọn B cho biết khó khăn trong việc lấy ý kiến của nhà phát triển về yêu cầu và truyền đạt phản hồi của người dùng về phần mềm đã được giao về cho nhà phát triển. Lựa chọn C cho biết 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 có sự khác biệt trong việc hiểu yêu cầu được phát hiện muộn trong dự án. Tuy nhiên, lựa chọn A không liên quan đến các vấn đề thường gặp khi thực hiện dự án được giao thầu ngoài. Thay vào đó, nó cho thấy lợi ích của việc thực hiện dự án trong nội bộ công ty.

Requirements validation là quá trình xác minh rằng các yêu cầu đã được phát triển có đáp ứng được các yêu cầu và mục tiêu kinh doanh. Nó là một phần quan trọng của quá trình phát triển yêu cầu và giúp đảm bảo rằng các yêu cầu được viết chính xác và đầy đủ. Quá trình này bao gồm việc đánh giá và kiểm tra các yêu cầu để đảm bảo chúng có tất cả các tính chất mong muốn của các yêu cầu chất lượng cao. Điều này bao gồm việc xác minh rằng các yêu cầu có thể đo lường được, rõ ràng, dễ hiểu, không mâu thuẫn và có thể thực hiện được. Quá trình này cũng bao gồm việc xác minh rằng các yêu cầu có thể đáp ứng được các mục tiêu kinh doanh và chiến lược của tổ chức.

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.

Change management trong Agile projects là quá trình quản lý và điều chỉnh thay đổi trong quá trình phát triển dự án. Agile processes harness change for the customer's competitive advantage, tức là Agile quy trình tận dụng sự thay đổi để mang lại lợi thế cạnh tranh cho khách hàng. Accepting change giúp đáp ứng mục tiêu và ưu tiên kinh doanh đang phát triển và phù hợp với giới hạn của kế hoạch và tầm nhìn con người. Agile methods vary as to their philosophy on this point, tức là các phương pháp Agile khác nhau về quan điểm của họ về điểm này, không có một phương pháp duy nhất "đúng" hoặc sai. Tuy nhiên, Agile projects manage change by maintaining a specific backlog of work to be done, tức là dự án Agile quản lý sự thay đổi bằng cách duy trì một danh sách cụ thể các công việc cần được thực hiện. Điều này không phải là một phần của Agile change management, mà là một phương pháp quản lý dự án truyền thống.

Requirement engineering là quá trình xác định và xác minh các yêu cầu của một hệ thống hoặc sản phẩm. Quá trình này bao gồm các bước sau: - Elicitation: Xác định và thu thập các yêu cầu của khách hàng hoặc người sử dụng. - Documentation: Xây dựng và lưu trữ các tài liệu về yêu cầu. - Analysis: Xác minh và phân tích các yêu cầu để đảm bảo chúng rõ ràng và không mâu thuẫn. - Design: Sử dụng các yêu cầu đã xác định để thiết kế hệ thống hoặc sản phẩm. - Testing: Kiểm tra hệ thống hoặc sản phẩm để đảm bảo nó đáp ứng các yêu cầu đã xác định. - Deployment: Đưa hệ thống hoặc sản phẩm vào hoạt động. - Maintenance: Cập nhật và bảo trì hệ thống hoặc sản phẩm để đảm bảo nó vẫn đáp ứng các yêu cầu. Trong câu hỏi này, đáp án đúng là '. design' vì design không phải là một bước trong quá trình requirement engineering. Design là một bước trong quá trình phát triển sản phẩm, nhưng nó không phải là một bước trong quá trình xác định và xác minh các yêu cầu.

Một Business analyst (BA) là người chịu trách nhiệm thu thập, phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. Các nhiệm vụ chính của một BA bao gồm: - Communicate requirements: Truyền đạt yêu cầu của khách hàng hoặc tổ chức đến các thành viên khác trong dự án. - Document requirements: Lưu trữ và quản lý yêu cầu của khách hàng hoặc tổ chức. - Analyze requirements: Phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. - Elicit requirements: Thu thập và xác định nhu cầu của khách hàng hoặc tổ chức. - Assurance requirements: Đây là một nhiệm vụ không phải là trách nhiệm chính của một BA. Assurance requirements thường liên quan đến việc đảm bảo rằng các yêu cầu đã được thực hiện đúng và đáp ứng được nhu cầu của khách hàng hoặc tổ chức. Điều này thường là trách nhiệm của các chuyên gia khác như kiểm toán viên hoặc chuyên gia đảm bảo chất lượng. Vì vậy, Assurance requirements là một nhiệm vụ không phải là trách nhiệm chính của một Business analyst.

Requirements development là quá trình xác định và xác minh các yêu cầu của một dự án. Quá trình này bao gồm nhiều bước khác nhau, bao gồm Analysis, Validation, Design và Elicitation. Tuy nhiên, trong số các bước này, Design không phải là một phần của Requirements development.

Requirements analysis là bước quan trọng trong quy trình phát triển phần mềm, giúp đảm bảo rằng tất cả các bên liên quan hiểu rõ và thống nhất về yêu cầu của dự án. Trong quá trình này, các kỹ thuật khác nhau được sử dụng để xác định, phân tích và xác minh các yêu cầu. Một số kỹ thuật phổ biến bao gồm mô hình hóa môi trường ứng dụng, tạo mẫu và bản demo giao diện người dùng và kỹ thuật, phân tích khả năng thực hiện yêu cầu, ưu tiên các yêu cầu và mô hình hóa các yêu cầu. Tuy nhiên, kỹ thuật xác định nguồn gốc của yêu cầu không phải là một kỹ thuật phổ biến trong bước Requirements analysis. Thay vào đó, kỹ thuật này thường được sử dụng trong bước xác định yêu cầu ban đầu, nơi các yêu cầu được thu thập và xác định từ các nguồn khác nhau. Vì vậy, trong câu hỏi, đáp án 'Identify requirement origins' không phải là một kỹ thuật phổ biến cho Requirements analysis.

Use Cases là một phương pháp quan trọng trong việc thu thập và xác định yêu cầu của hệ thống. Chúng mô tả các tương tác giữa hệ thống và các thực thể bên ngoài, chẳng hạn như người dùng, thiết bị, hoặc các hệ thống khác. Mục đích chính của Use Cases là xác định các yêu cầu chức năng của hệ thống và cách chúng được sử dụng bởi người dùng. Điều này giúp các nhà phát triển hiểu rõ hơn về nhu cầu của người dùng và tạo ra các giải pháp phù hợp. Use Cases thường được sử dụng trong giai đoạn thiết kế và phát triển của dự án phần mềm. Chúng được thể hiện dưới dạng sơ đồ Use Case, bao gồm các yếu tố như người dùng, hệ thống, và các tương tác giữa chúng. Sơ đồ này giúp các nhà phát triển xác định các yêu cầu chức năng của hệ thống và cách chúng được sử dụng bởi người dùng. Ngoài ra, Use Cases còn giúp các nhà phát triển xác định các rủi ro và hạn chế của hệ thống, từ đó có thể đưa ra các giải pháp phù hợp. Tóm lại, Use Cases là một công cụ quan trọng trong việc thu thập và xác định yêu cầu của hệ thống, giúp các nhà phát triển tạo ra các giải pháp phù hợp và hiệu quả.

Requirements problems là những vấn đề liên quan đến yêu cầu của dự án, bao gồm cả yêu cầu không rõ ràng, không đầy đủ hoặc không chính xác. Khi có các vấn đề về yêu cầu, nó có thể dẫn đến nhiều hậu quả tiêu cực, trong đó có sự chậm trễ và phải thực hiện lại công việc. Điều này xảy ra vì các nhà phát triển phải dành nhiều thời gian và nguồn lực để hiểu và thực hiện lại các yêu cầu không rõ ràng hoặc không chính xác. Ngoài ra, sự chậm trễ và phải thực hiện lại công việc cũng có thể dẫn đến tăng chi phí và giảm hiệu suất của dự án. Vì vậy, việc giải quyết các vấn đề về yêu cầu là rất quan trọng để đảm bảo dự án được thực hiện đúng thời hạn và đạt được chất lượng tốt.

Vision và Scope Document là một tài liệu quan trọng trong quá trình phát triển dự án, nó được sử dụng để định nghĩa mục tiêu, phạm vi và yêu cầu của dự án. Vision Document thường được xây dựng dựa trên các yêu cầu kinh doanh, nó giúp xác định mục tiêu và hướng đi của dự án. Scope Document thì lại tập trung vào việc xác định phạm vi của dự án, bao gồm các yêu cầu và hạn chế của dự án. Vì vậy, Vision và Scope Document được coi là một phần quan trọng của quá trình phát triển dự án và được xây dựng dựa trên các yêu cầu kinh doanh.

Scope creep là một thuật ngữ được sử dụng trong quản lý dự án để mô tả tình trạng khi phạm vi của một dự án tiếp tục tăng lên trong một cách không kiểm soát được suốt quá trình phát triển dự án. Điều này có thể dẫn đến việc dự án bị kéo dài thời gian, chi phí tăng cao và chất lượng sản phẩm giảm xuống. Scope creep thường xảy ra khi các yêu cầu của khách hàng hoặc các thành viên trong dự án thay đổi liên tục, dẫn đến việc phạm vi của dự án phải được mở rộng để đáp ứng các yêu cầu mới. Điều này có thể gây ra nhiều vấn đề cho dự án, bao gồm việc mất tập trung, tăng chi phí và giảm chất lượng sản phẩm. Để tránh scope creep, các dự án thường cần có một kế hoạch rõ ràng, một quy trình kiểm soát phạm vi và một sự tham gia tích cực của các thành viên trong dự án.

Một yêu cầu cao cấp (high-level requirement) cho một sản phẩm chứa nhiều hệ thống phụ (subsystems) có thể bao gồm cả phần mềm và phần cứng. Yêu cầu này thường được xác định bởi các yêu cầu kinh doanh (business requirement) và được sử dụng để định hướng tổng thể cho sản phẩm. Yêu cầu kinh doanh thường bao gồm các mục tiêu và yêu cầu của khách hàng, trong khi yêu cầu cao cấp tập trung vào các chức năng và đặc điểm chính của sản phẩm. Trong trường hợp này, yêu cầu cao cấp sẽ bao gồm các yêu cầu về chức năng và không chức năng (functional và nonfunctional requirements) của từng hệ thống phụ, cũng như các yêu cầu về tương tác giữa chúng. Do đó, đáp án đúng là 'System requirement' vì nó bao gồm tất cả các yêu cầu liên quan đến sản phẩm và hệ thống phụ của nó.

Câu hỏi này liên quan đến nguyên tắc đảm bảo mỗi đơn vị mã thực hiện một chức năng cụ thể, rõ ràng mà không bị ảnh hưởng bởi các phần khác của hệ thống. Strong cohesion là nguyên tắc đảm bảo rằng mỗi module hoặc đơn vị mã có một chức năng cụ thể và rõ ràng, không bị ảnh hưởng bởi các module khác. Điều này giúp giảm thiểu sự tương tác không mong muốn giữa các module và tăng cường tính bảo mật và độ tin cậy của hệ thống. Strong cohesion cũng giúp dễ dàng bảo trì và sửa lỗi hệ thống vì mỗi module có một chức năng cụ thể và rõ ràng.

Khi xây dựng một hệ thống lưu trữ dữ liệu dựa trên đám mây cho ứng dụng bản đồ mới, công ty phát triển ứng dụng cần chọn một cơ sở dữ liệu phù hợp để quản lý dữ liệu vị trí của người dùng. Trong trường hợp này, Aerospike là lựa chọn tốt nhất. Aerospike là một cơ sở dữ liệu NoSQL có khả năng xử lý dữ liệu lớn và phân tán, phù hợp với yêu cầu của ứng dụng bản đồ. Nó có thể quản lý dữ liệu vị trí của người dùng một cách hiệu quả và nhanh chóng, đồng thời cũng có khả năng mở rộng để đáp ứng nhu cầu của ứng dụng. Ngoài ra, Aerospike cũng hỗ trợ các tính năng như phân tích dữ liệu và quản lý dữ liệu thời gian thực, giúp ứng dụng bản đồ có thể cung cấp thông tin chính xác và cập nhật về vị trí của người dùng.

Elicitation là quá trình thu thập thông tin từ người dùng hoặc chuyên gia để hiểu rõ hơn về yêu cầu hoặc vấn đề cần giải quyết. Có nhiều kỹ thuật khác nhau để thực hiện việc này, bao gồm phỏng vấn (Interviews), nhóm thảo luận (Focus groups), quan sát (Observations). Tuy nhiên, các khóa học đào tạo (Training courses) không phải là một kỹ thuật thu thập thông tin, mà là một phương pháp giáo dục để giúp người dùng hoặc chuyên gia phát triển kỹ năng và kiến thức. Vì vậy, Training courses không phải là một kỹ thuật elicitation.