Software Requirements - SWR302

Một Requirements Change Control Board (RCCB) đóng vai trò quan trọng trong quá trình quản lý yêu cầu. RCCB là một nhóm được chỉ định để đánh giá và quyết định liệu các thay đổi yêu cầu có được chấp nhận hay không. Họ sẽ xem xét kỹ lưỡng các đề xuất thay đổi, đảm bảo rằng chúng không ảnh hưởng đến chất lượng, thời gian và ngân sách của dự án. RCCB cũng sẽ đánh giá liệu các thay đổi có đáp ứng được yêu cầu và mục tiêu của dự án hay không. Nếu các thay đổi được chấp nhận, RCCB sẽ đảm bảo rằng chúng được cập nhật và phản ánh trong các tài liệu yêu cầu và kế hoạch dự án. Nếu các thay đổi bị từ chối, RCCB sẽ giải thích lý do và đề xuất các giải pháp thay thế. Quá trình này giúp đảm bảo rằng các yêu cầu của dự án được quản lý một cách hiệu quả và chính xác, giảm thiểu khả năng xảy ra sai sót và cải thiện chất lượng của dự án.

Seilevel là một công ty chuyên về quy trình phát triển phần mềm và tư vấn. Họ đã phát triển một công cụ để giúp ước tính thời gian phát triển yêu cầu. Công cụ này được gọi là 'A requirements effort estimation spreadsheet'. Công cụ này cho phép các nhà phát triển và quản lý dự án ước tính thời gian và công sức cần thiết để phát triển yêu cầu. Điều này giúp họ lập kế hoạch và quản lý dự án một cách hiệu quả hơn. Công cụ này cũng giúp giảm thiểu rủi ro và tăng cường khả năng hoàn thành dự án đúng hạn.

Use Case và User Story là hai phương pháp khác nhau để mô tả yêu cầu của người dùng trong quá trình phát triển phần mềm. Use Case là một tài liệu kinh doanh mô tả yêu cầu hoặc tính năng của một ứng dụng, trong khi User Story là một tài liệu kiểm thử mô tả các bước để xác minh và xác thực rằng yêu cầu hoặc tính năng đó tồn tại. Use Case thường chứa các mô tả chi tiết và dài hơn, trong khi User Story chứa các mô tả đơn giản và ngắn gọn. Điều này giúp cho các nhà phát triển và kiểm thử viên có thể hiểu rõ yêu cầu và tính năng của ứng dụng một cách hiệu quả.

Elicitation là quá trình thu thập thông tin từ người dùng, chuyên gia hoặc các nguồn khác để hiểu rõ hơn về yêu cầu của dự án. Có nhiều hoạt động khác nhau trong quá trình này, bao gồm định nghĩa tầm nhìn sản phẩm và phạm vi dự án, tổ chức phỏng vấn để thu thập thông tin, quan sát người dùng khi họ thực hiện công việc và mô hình hóa môi trường ứng dụng. Trong số các hoạt động này, mô hình hóa môi trường ứng dụng không phải là một hoạt động thu thập thông tin từ người dùng hoặc chuyên gia, mà là một hoạt động để tạo ra mô hình hoặc bản đồ của môi trường ứng dụng để hiểu rõ hơn về yêu cầu của dự án. Vì vậy, mô hình hóa môi trường ứng dụng không phải là một hoạt động thu thập thông tin, mà là một hoạt động khác trong quá trình phát triển dự án.

Khi viết yêu cầu rõ ràng và ngắn gọn, mục tiêu chính là giúp người đọc hiểu rõ và dễ dàng thực hiện yêu cầu đó. Sử dụng ngôn ngữ đơn giản, tránh sử dụng jargon và giữ các câu ngắn gọn và trực tiếp là một trong những nguyên tắc quan trọng. Điều này giúp giảm thiểu khả năng hiểu lầm và đảm bảo rằng yêu cầu được thực hiện một cách chính xác. Ngoài ra, sử dụng ngôn ngữ đơn giản cũng giúp tăng cường sự hiểu biết và giảm thiểu khả năng xảy ra lỗi. Việc sử dụng jargon hoặc ngôn ngữ phức tạp có thể dẫn đến sự hiểu lầm và làm cho yêu cầu trở nên khó hiểu hơn. Vì vậy, việc viết yêu cầu rõ ràng và ngắn gọn là một phần quan trọng của quy trình lập kế hoạch và quản lý dự án.

ERD (Entity-Relationship Diagram) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu, giúp mô tả mối quan hệ giữa các thực thể (entities) trong một hệ thống dữ liệu. Trong ERD, mỗi thực thể được mô tả bằng một hình dạng đặc trưng, chẳng hạn như hình chữ nhật hoặc hình oval. Các mối quan hệ giữa các thực thể được thể hiện bằng các đường kết nối giữa các hình dạng này. Một trong những đặc điểm quan trọng của ERD là việc mô tả tính chất (attributes) của mỗi thực thể. Tính chất này có thể bao gồm các thông tin như tên, địa chỉ, số điện thoại, v.v. Ngoài ra, ERD cũng mô tả mối quan hệ giữa các thực thể, bao gồm cả mối quan hệ một-một (one-to-one), một-nhiều (one-to-many) và nhiều-nhiều (many-to-many).

Requirements Traceability Matrix (RTM) là một công cụ quan trọng trong quản lý dự án, giúp theo dõi và xác minh mối liên hệ giữa các yêu cầu của dự án và các tài liệu khác như thiết kế, thử nghiệm và mã nguồn. RTM thường được thể hiện dưới dạng một bảng tính hoặc một biểu đồ, giúp dễ dàng theo dõi và quản lý các yêu cầu của dự án. Trong RTM, mỗi yêu cầu sẽ được liên kết với các tài liệu khác, chẳng hạn như thiết kế, thử nghiệm và mã nguồn, giúp đảm bảo rằng các yêu cầu đã được thực hiện đúng và đáp ứng được các yêu cầu của dự án. RTM cũng giúp xác minh rằng các yêu cầu đã được thực hiện đúng và đáp ứng được các yêu cầu của dự án, giúp giảm thiểu rủi ro và đảm bảo chất lượng của dự án.

Requirements tracing là một kỹ thuật quan trọng trong quản lý dự án và phát triển phần mềm. Nó giúp tạo ra các liên kết giữa các yêu cầu của dự án, các nhiệm vụ trong kế hoạch dự án và tiến độ phát triển. Một trong những lợi ích tiềm năng của việc thực hiện requirements tracing là giúp xác định các yêu cầu bị thiếu mà không có liên kết với các yêu cầu của người dùng hoặc kinh doanh. Điều này có thể giúp giảm thiểu chi phí phát triển và tăng cường chất lượng sản phẩm cuối cùng. Requirements tracing cũng giúp xác định các yêu cầu không phù hợp hoặc không cần thiết, từ đó giúp tối ưu hóa quy trình phát triển và giảm thiểu chi phí. Ngoài ra, requirements tracing còn giúp xác định các điểm cần cải thiện trong quy trình phát triển và giúp đội ngũ phát triển cải thiện kỹ năng và hiệu suất của mình.

Requirements management là một phần quan trọng của quy trình phát triển phần mềm, bao gồm việc thu thập, xác định, xác minh và quản lý các yêu cầu của khách hàng. Trong quá trình này, các kỹ sư phần mềm thường phải thực hiện các hoạt động như thu thập yêu cầu từ khách hàng, xác định và xác minh các yêu cầu, và quản lý các thay đổi trong yêu cầu. Một trong những hoạt động quan trọng trong requirements management là việc quản lý các thay đổi trong yêu cầu và đề xuất các thay đổi mới.

Requirements tracing là một kỹ thuật quan trọng trong quá trình tái thiết kế (reengineering) hệ thống. Nó giúp xác định và theo dõi các yêu cầu của hệ thống từ giai đoạn thiết kế ban đầu đến giai đoạn triển khai và vận hành. Một trong những lợi ích chính của requirements tracing trong tái thiết kế là nó giúp tái sử dụng các thành phần từ hệ thống cũ. Điều này có thể giúp giảm thiểu thời gian và chi phí cần thiết để phát triển hệ thống mới. Khi tái sử dụng các thành phần đã tồn tại, các nhà phát triển có thể tập trung vào việc cải thiện và nâng cấp các thành phần này thay vì phải xây dựng lại từ đầu. Điều này cũng giúp đảm bảo rằng hệ thống mới có thể tương thích với hệ thống cũ và giảm thiểu thời gian cần thiết để tích hợp các thành phần mới. Ngoài ra, requirements tracing cũng giúp xác định các khu vực cần thay thế hoàn toàn hệ thống cũ, giúp các nhà phát triển tập trung vào việc phát triển hệ thống mới thay vì cố gắng sửa chữa hệ thống cũ.

Kỹ thuật thang ba mức (Three-level scale technique) là một phương pháp được sử dụng trong quản lý dự án và phát triển sản phẩm để phân loại yêu cầu dựa trên mức độ quan trọng và cấp độ ưu tiên. Theo kỹ thuật này, yêu cầu được phân loại thành ba mức độ quan trọng: thấp, trung bình và cao. Yêu cầu có mức độ quan trọng cao thường là những yêu cầu quan trọng và cấp thiết, cần được ưu tiên thực hiện trước. Yêu cầu có mức độ quan trọng trung bình là những yêu cầu quan trọng nhưng không cấp thiết, có thể được thực hiện sau. Yêu cầu có mức độ quan trọng thấp thường là những yêu cầu không quan trọng và không cấp thiết, có thể được bỏ qua hoặc thực hiện sau. Tuy nhiên, trong câu hỏi, có một thông tin không chính xác về kỹ thuật thang ba mức. Câu trả lời không chính xác là 'Low-priority requirements are not important but urgent for some stakeholders.' Điều này không đúng vì yêu cầu có mức độ quan trọng thấp không phải lúc nào cũng không quan trọng. Yêu cầu có mức độ quan trọng thấp có thể không quan trọng đối với một số người nhưng lại quan trọng đối với một số người khác. Vì vậy, câu trả lời không chính xác này không phản ánh đúng bản chất của kỹ thuật thang ba mức.

Câu hỏi trắc nghiệm này liên quan đến khái niệm 'yêu cầu' trong thiết kế và phát triển sản phẩm. Yêu cầu là một khái niệm quan trọng trong lĩnh vực kỹ thuật phần mềm và thiết kế sản phẩm. Có nhiều định nghĩa khác nhau về yêu cầu, nhưng một định nghĩa chính xác và phổ biến nhất là: 'Yêu cầu là một đặc tả về những gì nên được thực hiện. Chúng là những mô tả về cách hệ thống nên hoạt động, hoặc về một tính chất hoặc thuộc tính của hệ thống. Chúng có thể là một hạn chế đối với quá trình phát triển hệ thống.' Định nghĩa này nhấn mạnh rằng yêu cầu không chỉ là những gì khách hàng muốn, mà còn là những đặc tả cụ thể về cách hệ thống nên hoạt động và những tính chất hoặc thuộc tính của hệ thống. Điều này giúp đảm bảo rằng hệ thống được thiết kế và phát triển đúng cách và đáp ứng được nhu cầu của khách hà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 của dự án. Có nhiều hoạt động khác nhau trong quá trình elicitation, bao gồm định nghĩa tầm nhìn và phạm vi dự án, tổ chức phỏng vấn với người dùng, quan sát người dùng thực hiện công việc của họ và mô hình hóa môi trường ứng dụng.

Các yếu tố cản trở việc tái sử dụng yêu cầu bao gồm sự thiếu tham gia của các bên liên quan, việc cập nhật và kiểm soát phiên bản thường xuyên của tài liệu yêu cầu, định dạng tiêu chuẩn hóa cho tài liệu yêu cầu và yêu cầu được viết bằng ngôn ngữ tự nhiên chứa sự không rõ ràng, thiếu thông tin và giả định ẩn. Trong số các yếu tố này, yêu cầu được viết bằng ngôn ngữ tự nhiên chứa sự không rõ ràng, thiếu thông tin và giả định ẩn là một trong những yếu tố quan trọng nhất cản trở việc tái sử dụng yêu cầu. Điều này là vì ngôn ngữ tự nhiên thường chứa các từ ngữ không rõ ràng, các từ đồng nghĩa và các từ trái nghĩa, khiến cho việc hiểu và diễn giải yêu cầu trở nên khó khăn hơn. Ngoài ra, ngôn ngữ tự nhiên cũng thường chứa các giả định ẩn, khiến cho việc tái sử dụng yêu cầu trở nên khó khăn hơn. Vì vậy, việc sử dụng ngôn ngữ tự nhiên để viết yêu cầu có thể dẫn đến sự không rõ ràng, thiếu thông tin và giả định ẩn, khiến cho việc tái sử dụng yêu cầu trở nên khó khăn hơn.

Throwaway prototype là một phương pháp thiết kế và phát triển phần mềm được sử dụng khi đội ngũ phát triển gặp phải sự không chắc chắn, không rõ ràng, không đầy đủ hoặc không rõ ràng trong yêu cầu. Phương pháp này cho phép đội ngũ phát triển xây dựng một phiên bản thử nghiệm của phần mềm để 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 phiên bản thử nghiệm, đội ngũ phát triển thường bỏ qua các kỹ thuật xây dựng phần mềm vững chắc để tập trung vào việc xây dựng một phiên bản thử nghiệm nhanh chóng và hiệu quả. Tuy nhiên, phiên bản thử nghiệm này không được thiết kế để phát hành và thường được loại bỏ sau khi hoàn thành mục đích của nó. Vì vậy, việc gọi nó là 'phiên bản thử nghiệm có thể phát hành' là không chính xác.

Mockup là một công cụ thiết kế được sử dụng để tạo ra mô hình hoặc bản sao của một sản phẩm hoặc hệ thống. Nó thường được sử dụng trong quá trình thiết kế và phát triển sản phẩm để giúp các nhà thiết kế và phát triển hiểu rõ về yêu cầu và chức năng của sản phẩm. Mockup có thể được tạo ra bằng nhiều phương pháp khác nhau, bao gồm sử dụng phần mềm thiết kế, viết mã, hoặc thậm chí là sử dụng các công cụ trực tuyến.

Requirements management là một phần quan trọng trong quy trình phát triển phần mềm, bao gồm các hoạt động liên quan đến việc thu thập, xác định, xác minh và quản lý yêu cầu của khách hàng. Các hoạt động chính của requirements management bao gồm việc theo dõi trạng thái của yêu cầu, theo dõi thay đổi và phiên bản của yêu cầu, và xác minh rằng yêu cầu đã được thực hiện đúng như mong đợi.

Requirements management là một phần quan trọng của quy trình phát triển phần mềm, bao gồm việc thu thập, xác định, xác minh, kiểm tra và quản lý yêu cầu của khách hàng. Trong các hoạt động này, yêu cầu được xem xét và điều chỉnh liên tục để đảm bảo rằng chúng phù hợp với mục tiêu và yêu cầu của dự án. Một trong những hoạt động quan trọng trong requirements management là việc quản lý thay đổi yêu cầu và đề xuất thay đổi yêu cầu mới. Điều này giúp đảm bảo rằng yêu cầu được cập nhật và phù hợp với tình hình thực tế của dự án.

Requirements tracing là một kỹ thuật quan trọng trong quản lý dự án và phát triển sản phẩm. Nó giúp tạo ra mối liên kết giữa các yêu cầu của dự án, kế hoạch dự án và tiến độ phát triển. Một trong những lợi ích tiềm năng của việc thực hiện requirements tracing là việc xác định các yêu cầu bị thiếu mà không có liên kết với các yêu cầu của người dùng hoặc kinh doanh. Điều này giúp đảm bảo rằng tất cả các yêu cầu quan trọng đều được bao gồm trong dự án và giảm thiểu khả năng xảy ra lỗi hoặc thiếu sót. Ngoài ra, requirements tracing cũng giúp tăng cường theo dõi dự án bằng cách tạo ra mối liên kết giữa các nhiệm vụ trong kế hoạch dự án và tiến độ phát triển. Tuy nhiên, nó không trực tiếp giảm chi phí vòng đời sản phẩm hoặc xác định các yêu cầu tuân thủ quy định.

Khi phân tích ngôn ngữ khách hàng, một 'verb' thường đại diện cho hành động hoặc quá trình được thực hiện. Trong ngữ cảnh này, một mô hình phân tích phù hợp cho 'verb' trong ngôn ngữ khách hàng là 'Processes in a Data Flow Diagram (DFD)'. DFD là một công cụ phân tích hệ thống được sử dụng để mô tả quá trình và lưu lượng dữ liệu trong một hệ thống. Các quá trình trong DFD đại diện cho các hoạt động hoặc hành động được thực hiện trong hệ thống, bao gồm cả các hành động được thực hiện bởi khách hàng. Vì vậy, 'Processes in a Data Flow Diagram (DFD)' là một mô hình phân tích phù hợp cho 'verb' trong ngôn ngữ khách hàng.