Ôn tập thi lại SWR302 Summer 2024

Các hoạt động sau đây thuộc về các hoạt động cốt lõi của quản lý yêu cầu. Quản lý yêu cầu là một phần quan trọng trong chu kỳ phát triển sản phẩm, giúp đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện chính xác. Các hoạt động cốt lõi của quản lý yêu cầu bao gồm kiểm soát phiên bản, kiểm soát thay đổi, theo dõi trạng thái yêu cầu và theo dõi yêu cầu. Kiểm soát phiên bản giúp quản lý các phiên bản của yêu cầu, kiểm soát thay đổi giúp đảm bảo rằng các thay đổi được thực hiện một cách có hệ thống, theo dõi trạng thái yêu cầu giúp theo dõi tiến độ của yêu cầu và theo dõi yêu cầu giúp đảm bảo rằng các yêu cầu được thực hiện chính xác.

Quá trình phát triển yêu cầu đại diện bao gồm các hoạt động như chọn kỹ thuật thu thập yêu cầu, đánh giá yêu cầu, lập kế hoạch thu thập yêu cầu và phân tích yêu cầu. Tuy nhiên, hoạt động không được bao gồm trong quá trình này là chọn một chu kỳ phát triển phần mềm phù hợp. Chu kỳ phát triển phần mềm là một khái niệm rộng hơn và bao gồm nhiều giai đoạn khác nhau, chẳng hạn như lập kế hoạch, thiết kế, triển khai, thử nghiệm và bảo trì. Trong khi đó, quá trình phát triển yêu cầu đại diện chỉ tập trung vào việc thu thập, xác định và xác minh yêu cầu của hệ thống.

Mục tiêu quan trọng của việc viết yêu cầu là đảm bảo rằng bất kỳ ai đọc yêu cầu đều có cùng hiểu biết về yêu cầu đó. Điều này có nghĩa là yêu cầu phải rõ ràng, dễ hiểu và không gây nhầm lẫn. Mục tiêu này giúp tránh những hiểu lầm không cần thiết và đảm bảo rằng tất cả các bên liên quan đều có cùng mục tiêu. Ví dụ, nếu yêu cầu không rõ ràng, một người đọc có thể hiểu nó một cách khác với người đọc khác, dẫn đến việc thực hiện sai yêu cầu. Vì vậy, việc viết yêu cầu một cách rõ ràng và dễ hiểu là rất quan trọng để đảm bảo rằng tất cả các bên liên quan đều có cùng hiểu biết về yêu cầu.

Trong câu này, từ 'reuse' ám chỉ việc sử dụng lại các yêu cầu xác thực từ dự án trước đó. Từ 'all' chỉ ra rằng tất cả các yêu cầu xác thực đều có thể được sử dụng lại. Từ 'authentication requirements' ám chỉ các yêu cầu xác thực. Từ 'previous project' ám chỉ dự án trước đó. Từ 'library of reusable components' ám chỉ thư viện các thành phần có thể được sử dụng lại. Từ 'copy' ám chỉ việc sao chép các thành phần từ thư viện. Từ 'dimensions' ám chỉ các khía cạnh hoặc phương diện của việc sử dụng lại các yêu cầu xác thực. Vì vậy, câu này đang đề cập đến việc sử dụng lại các yêu cầu xác thực từ dự án trước đó bằng cách sao chép chúng từ thư viện các thành phần có thể được sử dụng lại.

Để xác định liệu bạn đã hoàn thành yêu cầu thu thập thông tin (requirements elicitation) hay chưa, bạn cần xem xét các tín hiệu sau. Đầu tiên, khi người dùng lặp lại các vấn đề họ đã thảo luận trước đó, điều đó có thể là dấu hiệu cho thấy bạn đã thu thập đủ thông tin. Thứ hai, nếu các yêu cầu mới được đề xuất đều được xác định là nằm ngoài phạm vi (out of scope), điều đó cho thấy bạn đã thu thập đủ thông tin về yêu cầu chính. Cuối cùng, nếu các yêu cầu mới được đề xuất đều có mức độ ưu tiên thấp, điều đó cũng cho thấy bạn đã thu thập đủ thông tin về yêu cầu chính.

Quá trình đánh giá sản phẩm dự án để xác định xem nó có đáp ứng nhu cầu của khách hàng hay không được gọi là Verification. Validation là quá trình xác định xem sản phẩm dự án có đáp ứng yêu cầu của khách hàng hay không. Checklist là một công cụ được sử dụng để đánh giá sản phẩm dự án. Testing là quá trình kiểm tra sản phẩm dự án để xác định xem nó có hoạt động đúng hay không. Tuy nhiên, Testing không phải là quá trình đánh giá sản phẩm dự án để xác định xem nó có đáp ứng nhu cầu của khách hàng hay không. Vì vậy, Testing là lựa chọn không đúng.

Khi định nghĩa rõ phạm vi của một dự án phần mềm trong tài liệu phạm vi, điều này giúp tránh hiện tượng phạm vi dự án mở rộng không kiểm soát được (scope creep). Điều này có thể dẫn đến lãng phí thời gian, tài nguyên và chi phí. Bằng cách xác định rõ phạm vi dự án, các nhà phát triển có thể tập trung vào các yêu cầu chính và tránh các yêu cầu không liên quan. Điều này giúp đảm bảo dự án được hoàn thành đúng hạn và đạt được mục tiêu mong muốn.

Kỹ thuật được sử dụng để thể hiện phạm vi của một dự án là gì? Để trả lời câu hỏi này, chúng ta cần hiểu rõ về các kỹ thuật khác nhau được sử dụng trong việc thể hiện phạm vi của một dự án. Ecosystem map (Bản đồ hệ sinh thái) và Context diagram (Bản đồ ngữ cảnh) là hai kỹ thuật được sử dụng để thể hiện phạm vi của một dự án. Ecosystem map giúp thể hiện các thành phần và mối quan hệ giữa chúng trong hệ sinh thái của dự án, trong khi Context diagram giúp thể hiện các đối tượng và mối quan hệ giữa chúng trong ngữ cảnh của dự án. Cả hai kỹ thuật này đều giúp người lập kế hoạch và quản lý dự án hiểu rõ về phạm vi của dự án và có thể đưa ra quyết định sáng suốt.

Các lợi ích của việc tái sử dụng yêu cầu hiệu quả bao gồm: Tái sử dụng yêu cầu giúp giảm thời gian phát triển dự án, giảm chi phí phát triển và giảm thiểu công việc lặp lại. Điều này đạt được bằng cách sử dụng lại các yêu cầu đã được xác định trước đó trong dự án khác, từ đó giảm thiểu thời gian và chi phí phát triển. Ngoài ra, tái sử dụng yêu cầu cũng giúp giảm thiểu công việc lặp lại và cải thiện chất lượng của dự án. Điều này đạt được bằng cách sử dụng các yêu cầu đã được xác định trước đó để phát triển dự án mới, từ đó giảm thiểu công việc lặp lại và cải thiện chất lượng của dự án.

Khi tiến hành thu thập yêu cầu (requirements elicitation), khách hàng cho biết, tiết kiệm X đồng mỗi năm về điện năng do các thiết bị không hiệu quả. Là một nhà phân tích, yêu cầu này thuộc loại yêu cầu nào?

Quá trình quản lý yêu cầu (Requirements Management) là một phần quan trọng trong vòng đời phát triển phần mềm. Nó bao gồm việc thu thập, xác định, phân tích, xác định và quản lý yêu cầu của khách hàng. Trong các hoạt động sau, hoạt động nào được coi là một phần của nỗ lực quản lý yêu cầu?

Elicitation là một quá trình hợp tác và phân tích bao gồm các hoạt động để thu thập, khám phá, trích xuất và thu thập yêu cầu. Quá trình này nhằm mục đích thu thập thông tin cần thiết từ khách hàng hoặc người sử dụng để xác định các yêu cầu của hệ thống hoặc sản phẩm. Elicitation thường bao gồm các hoạt động như thu thập yêu cầu, xác định yêu cầu và phân tích yêu cầu. Trong quá trình này, người tham gia sẽ thảo luận và chia sẻ ý tưởng để thu thập thông tin cần thiết. Quá trình này rất quan trọng vì nó giúp đảm bảo rằng các yêu cầu được thu thập chính xác và đầy đủ.

Trong một dự án Agile, vai trò của một nhà phân tích kinh doanh là xác định quy trình yêu cầu nhẹ nhàng, linh hoạt và thích nghi theo yêu cầu của dự án. Họ cũng cần giúp xác nhận rằng nhu cầu của khách hàng được thể hiện chính xác trong danh sách yêu cầu (backlog). Ngoài ra, họ cần hỗ trợ sắp xếp ưu tiên cho danh sách yêu cầu. Đ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 khách hàng.

Tracing yêu cầu là một quá trình quan trọng trong phát triển phần mềm, giúp đảm bảo rằng các yêu cầu của dự án được thực hiện chính xác và hiệu quả. Motivation chính cho việc tracing yêu cầu là để cải thiện chất lượng sản phẩm, giảm chi phí bảo trì và hỗ trợ tái sử dụng. Khi yêu cầu được tracing chính xác, các nhà phát triển có thể dễ dàng xác định và sửa lỗi, từ đó cải thiện chất lượng sản phẩm và giảm chi phí bảo trì. Ngoài ra, việc tracing yêu cầu cũng giúp hỗ trợ tái sử dụng các thành phần đã được phát triển, giảm thiểu thời gian và chi phí phát triển mới.

Khi triển khai giải pháp đóng gói, yêu cầu và công việc phát triển thường tăng dần theo một trình tự cụ thể. Trình tự này bắt đầu từ việc xác định yêu cầu và mục tiêu (4), sau đó là thiết kế và phát triển cơ bản (1), tiếp theo là thử nghiệm và kiểm tra (2), cuối cùng là triển khai và bảo trì (3). Vì vậy, trình tự đúng là 4, 1, 2, 3.

Để có thể sắp xếp danh sách dự án theo thứ tự chữ cái từ trước sang sau và ngược lại, người dùng phải có thể thực hiện được điều này. Điều này là một yêu cầu của người dùng vì nó liên quan trực tiếp đến cách người dùng tương tác với hệ thống. Yêu cầu này không liên quan đến chức năng của hệ thống mà là cách người dùng sử dụng hệ thống. Do đó, nó được coi là một yêu cầu của người dùng.

Một Requirements Traceability Matrix (RTM) là một công cụ quan trọng trong quá trình quản lý yêu cầu. Mục đích chính của RTM là theo dõi mối quan hệ giữa các yêu cầu và các tài liệu khác liên quan đến dự án. Điều này giúp đảm bảo rằng tất cả các yêu cầu đã được đáp ứng và các tài liệu khác đều phù hợp với yêu cầu. RTM cũng giúp xác định các yêu cầu nào đã được thực hiện và các yêu cầu nào vẫn còn chưa được thực hiện. Điều này giúp dự án được quản lý một cách hiệu quả và giảm thiểu các vấn đề phát sinh trong quá trình thực hiện.

Trong sơ đồ ngữ cảnh, các thực thể bên ngoài được minh họa bằng hình dạng và dữ liệu lưu chuyển được minh họa bằng đường nét.

Một số bên liên quan là khách hàng, chẳng hạn như nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp, nhà thầu và nhà đầu tư mạo hiểm. Họ có thể có quyền truy cập vào thông tin về dự án và có thể ảnh hưởng đến quyết định kinh doanh của công ty. Vì vậy, việc xác định và quản lý các bên liên quan là rất quan trọng để đảm bảo rằng thông tin dự án được bảo mật và tuân thủ các quy định.

Người dùng là một phần của nhóm khách hàng của sản phẩm. Tuy nhiên, người dùng không nhất thiết phải là khách hàng. Ví dụ, một người dùng có thể là nhân viên của công ty sử dụng sản phẩm, nhưng không phải là khách hàng của sản phẩm. Một người dùng cũng có thể là người sử dụng sản phẩm miễn phí, nhưng không phải là khách hàng. Do đó, người dùng không phải là một phần của nhóm khách hàng của sản phẩm. Thay vào đó, người dùng là một phần của nhóm người sử dụng sản phẩm.