Software Requirements - SWR302

Quá trình xử lý yêu cầu thay đổi (change request) thường bao gồm bốn bước chính: đánh giá yêu cầu thay đổi, đưa ra quyết định thay đổi, thực hiện thay đổi và kiểm tra lại thay đổi. Bước kiểm tra lại thay đổi (verify the change) là bước cuối cùng trong quá trình này, trong đó mục đích là xác nhận rằng thay đổi đã được thực hiện đúng và không có lỗi nào xảy ra. Bước này giúp đảm bảo rằng hệ thống hoặc ứng dụng đã được cập nhật một cách chính xác và an toàn. Nó cũng giúp xác định xem liệu thay đổi có đáp ứng được yêu cầu ban đầu hay không. Vì vậy, đáp án đúng là 'verify the change'.

Trong các dự án agile, sự hợp tác chặt chẽ giữa khách hàng và nhà phát triển thường dẫn đến việc yêu cầu có thể được ghi chép chi tiết hơn so với các dự án truyền thống. Điều này là do agile tập trung vào việc phát triển phần mềm nhanh chóng và linh hoạt, với sự tham gia tích cực của khách hàng trong suốt quá trình phát triển. Khi khách hàng và nhà phát triển làm việc cùng nhau, họ có thể xác định rõ hơn các yêu cầu của dự án và đảm bảo rằng chúng được thực hiện một cách chính xác. Kết quả là, yêu cầu có thể được ghi chép chi tiết hơn, bao gồm cả các chi tiết nhỏ và các yêu cầu phức tạp. Điều này giúp đảm bảo rằng phần mềm cuối cùng được phát triển đáp ứng được nhu cầu của khách hàng và đáp ứng được các tiêu chuẩn chất lượng cao.

Câu hỏi trắc nghiệm này liên quan đến việc phân loại yêu cầu của một hệ thống phần mềm. Yêu cầu 'The user must be able to sort the project list in forward and reverse alphabetical order' là một yêu cầu về chức năng của hệ thống, vì nó liên quan đến khả năng thực hiện một hành động cụ thể (sắp xếp danh sách dự án theo thứ tự chữ cái) mà không liên quan đến dữ liệu hoặc yêu cầu kinh doanh cụ thể. Do đó, nó được phân loại là một yêu cầu chức năng. Yêu cầu chức năng là một loại yêu cầu trong thiết kế phần mềm, mô tả các hành động hoặc chức năng mà hệ thống phải thực hiện để đáp ứng nhu cầu của người dùng.

Câu hỏi trắc nghiệm này liên quan đến tính chất chất lượng của hệ thống theo dõi hóa học. 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, giúp đảm bảo rằng hệ thống đáp ứng được yêu cầu và tiêu chuẩn của người dùng. Trong trường hợp này, câu hỏi trắc nghiệm đang hỏi về tính chất chất lượng 'Interoperability', nghĩa là khả năng tương tác và tích hợp giữa các hệ thống khác nhau. Cụ thể, câu hỏi đang hỏi về khả năng nhập dữ liệu hóa học từ các công cụ khác nhau như ChemDraw và MarvinSketch. Điều này cho thấy rằng hệ thống theo dõi hóa học cần phải có khả năng tương tác và tích hợp với các hệ thống khác nhau, bao gồm cả các công cụ thiết kế hóa học. Điều này giúp đảm bảo rằng hệ thống có thể nhận được dữ liệu hóa học từ các nguồn khác nhau và xử lý chúng một cách chính xác. Vì vậy, đáp án đúng cho câu hỏi trắc nghiệm này là 'Interoperability'.

Câu hỏi trắc nghiệm này liên quan đến chất lượng của hệ thống, cụ thể là khả năng tương tác giữa hệ thống và các công cụ khác. Trong trường hợp này, hệ thống cần có khả năng nhập bất kỳ cấu trúc hóa học hợp lệ nào từ công cụ ChemDraw (phiên bản 13.0 hoặc trước đó) và MarvinSketch (phiên bản 5.0 hoặc trước đó). Khả năng này được gọi là tương thích (Interoperability). Tương thích là khả năng của hệ thống để tương tác với các hệ thống, ứng dụng hoặc công cụ khác mà không cần phải thay đổi hoặc sửa đổi hệ thống. Trong trường hợp này, hệ thống cần có khả năng đọc và nhập dữ liệu từ các công cụ ChemDraw và MarvinSketch, điều này đòi hỏi khả năng tương thích cao.

Câu hỏi này liên quan đến khái niệm 'Scalability' trong thiết kế phần mềm. Scalability là khả năng của một hệ thống phần mềm để mở rộng hoặc giảm thiểu khả năng xử lý mà không ảnh hưởng đến hiệu suất hoặc chức năng của hệ thống. Trong trường hợp này, hệ thống phần mềm đã được phát triển ban đầu để xử lý một số lượng giao dịch nhất định, nhưng khách hàng muốn tăng gấp 10 lần số giao dịch. Tuy nhiên, hệ thống hiện tại không thể xử lý số lượng giao dịch tăng này do các quy trình monolithic và logic được kết nối chặt chẽ. Điều này cho thấy rằng hệ thống không có khả năng mở rộng, dẫn đến sự cần thiết phải nâng cấp hệ thống để đáp ứng nhu cầu mới của khách hàng. Do đó, chất lượng đặc trưng được đề cập trong câu hỏi này là Scalability.

Mock-up là một khái niệm quan trọng trong thiết kế và phát triển sản phẩm. Nó được định nghĩa là một bản mẫu hoặc bản sao của một sản phẩm hoặc một phần của sản phẩm, được tạo ra để thử nghiệm, đánh giá và cải thiện. Mock-up thường được sử dụng trong giai đoạn thiết kế và phát triển ban đầu của một sản phẩm, trước khi sản phẩm được triển khai hoàn chỉnh. Nó giúp các nhà thiết kế và phát triển có thể thử nghiệm và đánh giá các ý tưởng, tính năng và thiết kế khác nhau, từ đó có thể xác định được những gì cần được cải thiện và điều chỉnh.

Planguage là một ngôn ngữ được thiết kế để giúp các nhà phát triển và quản lý dự án thể hiện rõ ràng và chính xác các thuộc tính chất lượng và mục tiêu dự án khác. Ngôn ngữ này cung cấp một bộ từ khóa phong phú cho phép người dùng tạo ra các tuyên bố chính xác về các thuộc tính chất lượng và mục tiêu dự án. Điều này giúp cho việc quản lý dự án trở nên dễ dàng hơn và giảm thiểu khả năng xảy ra sai sót. Planguage được sử dụng rộng rãi trong các dự án phần mềm và công nghệ để đảm bảo rằng các mục tiêu và yêu cầu của dự án được thực hiện một cách chính xác và hiệu quả.

Extent of reuse là một khái niệm quan trọng trong thiết kế và phát triển phần mềm, đặc biệt là trong lĩnh vực tái sử dụng mã nguồn. Nó đề cập đến mức độ mà một yêu cầu chức năng hoặc một phần của yêu cầu chức năng có thể được tái sử dụng trên một dự án mới. Trong thực tế, tái sử dụng không chỉ giới hạn ở việc sao chép và dán một yêu cầu chức năng đơn lẻ mà còn bao gồm cả việc tái sử dụng các yêu cầu chức năng phức tạp hơn như các trường hợp sử dụng, yêu cầu hiệu suất, yêu cầu sử dụng người dùng và các quy tắc kinh doanh. Mức độ tái sử dụng có thể khác nhau tùy thuộc vào tính chất của yêu cầu chức năng và mức độ phức tạp của dự án.

Risk assessment là quá trình đánh giá và xác định các rủi ro tiềm ẩn trong một dự án. Quá trình này bao gồm việc phân tích và xác định các mối đe dọa, xác định mức độ nghiêm trọng của rủi ro và xác định các biện pháp phòng ngừa và giảm thiểu rủi ro. Mục tiêu của risk assessment là giúp dự án tránh được các rủi ro tiềm ẩn và giảm thiểu tác động của chúng khi chúng xảy ra. Quá trình này thường được thực hiện bởi các chuyên gia trong lĩnh vực dự án và rủi ro.

Một dự án cải tiến (enhancement project) là một loại dự án trong đó các khả năng mới được thêm vào một hệ thống hiện có. Điều này có nghĩa là dự án cải tiến không thay thế hệ thống hiện có hoàn toàn, mà thay vào đó, nó bổ sung thêm các tính năng hoặc khả năng mới để cải thiện hiệu suất, tính năng hoặc trải nghiệm người dùng của hệ thống hiện có. Dự án cải tiến thường được thực hiện để đáp ứng nhu cầu mới của khách hàng, cải thiện hiệu suất hệ thống hoặc bổ sung thêm các tính năng mới để cạnh tranh với các đối thủ trong ngành. Ví dụ, một công ty có thể thực hiện dự án cải tiến để thêm tính năng mới vào hệ thống quản lý khách hàng của mình, chẳng hạn như khả năng theo dõi và phân tích dữ liệu khách hàng. Điều này sẽ giúp công ty có thể hiểu rõ hơn về nhu cầu và hành vi của khách hàng, từ đó có thể cung cấp dịch vụ tốt hơn và tăng cường mối quan hệ với khách hàng.

Requirements baseline là một khái niệm quan trọng trong quy trình phát triển hệ thống, nó đại diện cho một tập hợp các yêu cầu mà các bên liên quan đã đồng ý, thường xác định nội dung của một phiên bản cụ thể hoặc một vòng lặp phát triển. Requirements baseline giúp đảm bảo rằng hệ thống được phát triển đáp ứng được nhu cầu và kỳ vọng của các bên liên quan, đồng thời giúp giảm thiểu rủi ro và tăng cường hiệu suất phát triển. Khi tạo ra một requirements baseline, các nhà phát triển cần xem xét kỹ lưỡng các yêu cầu của hệ thống, bao gồm cả các tính năng, chức năng, và đặc điểm kỹ thuật. Điều này giúp đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu của các bên liên quan và đáp ứng được nhu cầu của người dùng cuối cùng. Requirements baseline cũng giúp các nhà phát triển theo dõi và quản lý các yêu cầu của hệ thống, từ đó giúp cải thiện hiệu suất phát triển và giảm thiểu rủi ro. Tóm lại, requirements baseline là một khái niệm quan trọng trong quy trình phát triển hệ thống, giúp đảm bảo rằng hệ thống được phát triển đáp ứng được nhu cầu và kỳ vọng của các bên liên quan.

Change Control Board (CCB) là một nhóm người có trách nhiệm quyết định xem một thay đổi dự án có được chấp thuận hay không. Họ chịu trách nhiệm xem xét và đánh giá các đề xuất thay đổi, sau đó quyết định có chấp thuận hay không. CCB thường bao gồm các thành viên quan trọng như nhà quản lý dự án, nhà phát triển, người kiểm tra chất lượng và khách hàng. Mục tiêu của CCB là đảm bảo rằng các thay đổi được thực hiện một cách có trách nhiệm và không ảnh hưởng đến chất lượng dự án. Họ cũng đảm bảo rằng các thay đổi được thực hiện một cách hợp lý và không gây ra bất kỳ sự cố nào. Trong quá trình làm việc, CCB thường phải xem xét các yếu tố như tác động của thay đổi đến dự án, chi phí của thay đổi, thời gian thực hiện và khả năng thành công của thay đổi. Nếu CCB chấp thuận một thay đổi, họ sẽ tạo ra một bản ghi chép chi tiết về thay đổi đó, bao gồm lý do thay đổi, tác động của thay đổi và kế hoạch thực hiện. Điều này giúp đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về thay đổi và có thể thực hiện nó một cách hiệu quả.

Pre-Condition trong Use case là một điều kiện hoặc trạng thái mà hệ thống phải đáp ứng trước khi một Use case có thể bắt đầu. Nó là một phần quan trọng trong việc xác định yêu cầu và chức năng của hệ thống. Pre-Condition giúp đảm bảo rằng hệ thống được đặt trong một trạng thái nhất định trước khi thực hiện một Use case, từ đó giúp tránh các lỗi và sai sót có thể xảy ra. Ví dụ, trong một Use case về việc đăng ký tài khoản, Pre-Condition có thể là 'Người dùng chưa có tài khoản trên hệ thống' hoặc 'Người dùng đã cung cấp thông tin đăng ký đầy đủ'. Điều này giúp hệ thống xác định xem người dùng có thể thực hiện Use case này hay không và đảm bảo rằng quá trình đăng ký được thực hiện một cách chính xác và an toàn.

Trong quá trình thu thập yêu cầu (elicitation phase), rủi ro của việc yêu cầu không đầy đủ có thể dẫn đến nhiều hậu quả nghiêm trọng. Thứ nhất, việc thiếu thông tin về yêu cầu có thể dẫn đến chậm trễ trong dự án (project delays). Điều này xảy ra khi các nhà phát triển phải dành nhiều thời gian hơn để hiểu và xác định lại yêu cầu, dẫn đến việc hoàn thành dự án muộn hơn dự kiến. Thứ hai, việc thiếu thông tin về yêu cầu cũng có thể dẫn đến tăng chi phí (increased costs). Khi các nhà phát triển phải làm lại hoặc sửa đổi các phần của dự án, chi phí sẽ tăng lên. Cuối cùng, việc thiếu thông tin về yêu cầu cũng có thể dẫn đến sự không hài lòng của các bên liên quan (reduced stakeholder satisfaction). Khi các bên liên quan không hài lòng với kết quả cuối cùng, dự án có thể không đạt được mục tiêu như mong đợi. Vì vậy, việc thu thập yêu cầu đầy đủ và chính xác là rất quan trọng trong quá trình phát triển dự án.

Để chuyển đổi sang vị trí phân tích kinh doanh, một cách tiềm năng là tham gia chương trình học việc dưới sự hướng dẫn của một mentor. Điều này cho phép cá nhân đó có thể học hỏi từ kinh nghiệm và kiến thức của mentor, đồng thời áp dụng kiến thức vào thực tế. Chương trình học việc cũng giúp cá nhân đó có thể hiểu rõ hơn về các quy trình và quy định trong công ty, từ đó có thể đưa ra quyết định sáng suốt hơn. Ngoài ra, chương trình học việc cũng giúp cá nhân đó có thể xây dựng mối quan hệ với các đồng nghiệp và cấp trên, từ đó có thể tạo ra một mạng lưới quan hệ mạnh mẽ. Điều này rất quan trọng trong việc chuyển đổi sang vị trí phân tích kinh doanh, vì nó giúp cá nhân đó có thể hiểu rõ hơn về các yêu cầu và kỳ vọng của công ty.

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 (requirements management) của một dự án phần mềm. RTM giúp theo dõi mối quan hệ giữa các yêu cầu và các tài liệu khác của dự án, chẳng hạn như thiết kế, mã nguồn, và tài liệu thử nghiệm. Mục đích chính của RTM là đảm bảo rằng tất cả các yêu cầu được thực hiện và đáp ứng được các yêu cầu của dự án. RTM cũng giúp xác định các yêu cầu nào cần được ưu tiên và các yêu cầu nào có thể được loại bỏ hoặc thay thế. Ngoài ra, RTM còn giúp theo dõi tiến độ của dự án và đảm bảo rằng tất cả các yêu cầu được thực hiện đúng hạn. Tóm lại, RTM là một công cụ quan trọng trong quá trình quản lý yêu cầu và giúp đảm bảo rằng dự án phần mềm được thực hiện một cách hiệu quả và chính xác.

Một công cụ quản lý yêu cầu (requirements management tool) là một phần mềm được thiết kế để giúp quản lý và theo dõi yêu cầu của dự án. Một trong những lợi ích chính của việc sử dụng một công cụ này là đảm bảo tính theo dõi và giảm thiểu lỗi trong tài liệu yêu cầu. Điều này có nghĩa là công cụ sẽ giúp bạn theo dõi và quản lý các yêu cầu từ khi bắt đầu dự án cho đến khi hoàn thành, giảm thiểu khả năng xảy ra lỗi hoặc bỏ sót yêu cầu quan trọng. Ngoài ra, công cụ này cũng giúp giảm thiểu thời gian và công sức cần thiết để quản lý yêu cầu, cho phép bạn tập trung vào việc phát triển và thực hiện dự án. Tóm lại, sử dụng một công cụ quản lý yêu cầu là một cách hiệu quả để đảm bảo tính theo dõi và giảm thiểu lỗi trong tài liệu yêu cầu.

Tracing requirements 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 một cách chính xác và hiệu quả. Motivation chính cho việc tracing requirements 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 tracing requirements, các nhà phát triển có thể xác định rõ ràng các yêu cầu của dự án, từ đó tạo ra các sản phẩm đáp ứng được nhu cầu của khách hàng. Điều này giúp giảm thiểu các lỗi và sai sót trong quá trình phát triển, đồng thời tăng cường độ tin cậy và ổn định của sản phẩm. Ngoài ra, tracing requirements cũng giúp giảm chi phí bảo trì và hỗ trợ, vì các nhà phát triển có thể dễ dàng cập nhật và sửa đổi các yêu cầu của dự án mà không cần phải thay đổi toàn bộ sản phẩm. Cuối cùng, tracing requirements giúp hỗ trợ tái sử dụng, vì các nhà phát triển có thể tái sử dụng các yêu cầu và mã nguồn đã được chứng minh là hiệu quả trong dự án trước đó.