Software Requirements - SWR302

Requirements reuse là một kỹ thuật quan trọng trong quản lý yêu cầu phần mềm, giúp cải thiện hiệu suất và tính nhất quán trong các dự án. Mục tiêu chính của requirements reuse là tận dụng các yêu cầu đã tồn tại trong các dự án trước đó để áp dụng vào các dự án mới. Điều này giúp giảm thiểu thời gian và công sức cần thiết để thu thập và xác định các yêu cầu, đồng thời đảm bảo rằng các dự án mới tuân thủ các tiêu chuẩn và quy trình đã được thiết lập. Requirements reuse cũng giúp cải thiện tính nhất quán trong các dự án, bởi vì các yêu cầu được sử dụng lại từ dự án trước đó đã được kiểm tra và xác minh trước đó. Điều này giúp giảm thiểu khả năng xảy ra lỗi và đảm bảo rằng các dự án mới đáp ứng được các yêu cầu của khách hàng. Ngoài ra, requirements reuse cũng giúp cải thiện hiệu suất của các dự án, bởi vì các yêu cầu đã được sử dụng lại không cần phải được thu thập và xác định lại từ đầu. Điều này giúp giảm thiểu thời gian và công sức cần thiết để hoàn thành dự án.

Trong quá trình thu thập yêu cầu (requirements elicitation), việc xác định ranh giới hệ thống (system boundaries) là một thách thức chính. Hệ thống là một tập hợp các thành phần và mối quan hệ giữa chúng, và ranh giới hệ thống xác định giới hạn của hệ thống đó. Thách thức chính trong việc xác định ranh giới hệ thống là đảm bảo tất cả các bên liên quan (stakeholders) đồng ý về phạm vi và tránh sự lan rộng (scope creep) của phạm vi. Scope creep xảy ra khi phạm vi của hệ thống được mở rộng không ngừng, dẫn đến sự phức tạp và khó khăn trong việc quản lý và phát triển hệ thống. Để tránh scope creep, các bên liên quan cần phải thống nhất về phạm vi và mục tiêu của hệ thống, và đảm bảo rằng tất cả các yêu cầu được thu thập và xác định rõ ràng. Điều này đòi hỏi sự hợp tác và giao tiếp hiệu quả giữa các bên liên quan, cũng như sự hiểu biết rõ ràng về yêu cầu và mục tiêu của hệ thống.

Quản lý rủi ro trong các dự án phần mềm là một phần quan trọng của quy trình phát triển phần mềm. Mục tiêu chính của quản lý rủi ro là xác định và đánh giá các rủi ro tiềm ẩn, sau đó đề xuất các chiến lược để giảm thiểu hoặc loại bỏ chúng. Điều này giúp dự án phần mềm tránh được những thiệt hại tiềm ẩn và đảm bảo rằng dự án được thực hiện một cách hiệu quả và an toàn. Trong quá trình quản lý rủi ro, các chuyên gia thường sử dụng các công cụ và kỹ thuật như phân tích rủi ro, đánh giá mức độ nghiêm trọng của rủi ro, và đề xuất các biện pháp phòng ngừa hoặc giảm thiểu rủi ro. Mục tiêu chính của quản lý rủi ro là đề xuất các chiến lược để giảm thiểu hoặc loại bỏ rủi ro, chứ không phải là loại bỏ hoàn toàn tất cả các rủi ro hoặc tập trung vào các rủi ro có mức độ nghiêm trọng thấp.

Một business case trong yêu cầu phần mềm là một tài liệu quan trọng giúp xác định giá trị của dự án và đảm bảo nó phù hợp với mục tiêu và mục đích của tổ chức. Mục đích chính của một business case là để thuyết phục các bên liên quan về giá trị và lợi ích của dự án, đồng thời giúp xác định các mục tiêu và mục đích cụ thể của dự án. Đ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à đạt được mục tiêu mong muốn. Một business case thường bao gồm các thông tin như mục tiêu và mục đích của dự án, giá trị và lợi ích dự kiến, các rủi ro và thách thức, và kế hoạch thực hiện dự án. Việc xây dựng một business case tốt sẽ giúp đảm bảo rằng dự án được thực hiện một cách hiệu quả và đạt được mục tiêu mong muốn.

Một tài liệu Vision và Scope là một tài liệu quan trọng trong quy trình phát triển dự án, đặc biệt là trong các dự án lớn và phức tạp. Mục đích chính của tài liệu này là để định nghĩa ranh giới và mục tiêu của dự án. Nó giúp xác định phạm vi của dự án, bao gồm các yêu cầu, hạn chế và mục tiêu cần đạt được. Tài liệu này cũng giúp các thành viên trong dự án hiểu rõ về mục tiêu và ranh giới của dự án, từ đó có thể tập trung vào việc đạt được mục tiêu và tránh các sai sót có thể xảy ra. Ngoài ra, tài liệu Vision và Scope cũng giúp các nhà quản lý dự án có thể theo dõi tiến độ và đánh giá hiệu suất của dự án một cách hiệu quả. Nó cũng giúp các nhà phát triển có thể xác định các yêu cầu kỹ thuật và thiết kế hệ thống một cách chính xác.

Trong quá trình thu thập thông tin (elicitation), việc phỏng vấn các bên liên quan (stakeholder interviews) là một bước quan trọng để thu thập yêu cầu chi tiết từ những người có ảnh hưởng trực tiếp đến dự án. Mục đích chính của việc này là để thu thập thông tin cụ thể và chính xác về yêu cầu của dự án từ những người có kiến thức và kinh nghiệm liên quan. Điều này giúp đảm bảo rằng yêu cầu được thu thập một cách đầy đủ và chính xác, giảm thiểu khả năng xảy ra sai sót hoặc hiểu lầm. Quá trình này cũng giúp xây dựng mối quan hệ tốt đẹp giữa các bên liên quan và đội ngũ phát triển dự án, tạo điều kiện thuận lợi cho việc thực hiện dự án.

Requirements validation và verification là hai khái niệm quan trọng trong quy trình phát triển sản phẩm. Validation là quá trình xác minh rằng sản phẩm đáp ứng nhu cầu của người dùng, trong khi verification là quá trình xác minh rằng sản phẩm đáp ứng các yêu cầu kỹ thuật và tiêu chuẩn. Validation tập trung vào việc đảm bảo rằng sản phẩm đáp ứng nhu cầu của khách hàng, trong khi verification tập trung vào việc đảm bảo rằng sản phẩm đáp ứng các yêu cầu kỹ thuật và tiêu chuẩn. Điều này có nghĩa là validation là quá trình xác minh rằng sản phẩm đáp ứng nhu cầu của người dùng, trong khi verification là quá trình xác minh rằng sản phẩm đáp ứng các yêu cầu kỹ thuật và tiêu chuẩn. Ví dụ, khi phát triển một sản phẩm phần mềm, validation có thể bao gồm việc hỏi người dùng về nhu cầu của họ và xác minh rằng sản phẩm đáp ứng nhu cầu đó. Trong khi đó, verification có thể bao gồm việc kiểm tra mã nguồn và đảm bảo rằng sản phẩm đáp ứng các yêu cầu kỹ thuật và tiêu chuẩn. Tóm lại, validation và verification là hai khái niệm quan trọng trong quy trình phát triển sản phẩm và cần được thực hiện đồng thời để đảm bảo rằng sản phẩm đáp ứng nhu cầu của người dùng và đáp ứng các yêu cầu kỹ thuật và tiêu chuẩn.

Sử dụng prototyping trong các giai đoạn dự án sớm mang lại nhiều lợi ích. Một trong những lợi ích chính là xác minh các yêu cầu và giảm thiểu rủi ro thay đổi tốn kém sau này. Khi tạo một bản mẫu hoặc mô hình của dự án, các bên liên quan có thể xem xét và phản hồi về các yêu cầu, giúp đảm bảo rằng dự án được thực hiện đúng hướng. Điều này giúp giảm thiểu khả năng xảy ra sai sót hoặc thay đổi yêu cầu sau này, từ đó tiết kiệm thời gian và chi phí. Ngoài ra, prototyping cũng cho phép các nhà phát triển xác định và giải quyết các vấn đề sớm, giúp dự án được triển khai nhanh chóng và hiệu quả hơn.

Fostering một mối quan hệ hợp tác giữa đội phát triển và các bên liên quan khác trong quá trình yêu cầu là rất quan trọng. Khi các bên liên quan hợp tác chặt chẽ, họ có thể đạt được sự đồng thuận về nhu cầu kinh doanh, kỹ thuật và người dùng. Điều này giúp tránh hiểu lầm và đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về dự án. Trong quá trình yêu cầu, việc hợp tác giữa các bên liên quan giúp xác định rõ các yêu cầu của dự án, từ đó giúp đội phát triển xây dựng được sản phẩm đáp ứng được nhu cầu của khách hàng. Ngoài ra, việc hợp tác cũng giúp giảm thiểu rủi ro và tăng cường hiệu suất của dự án. Vì vậy, đáp án đúng là 'To align business, technical, and user needs and avoid misunderstandings'.

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 đáp ứng nhu cầu của khách hàng và thích nghi với thay đổi. Một trong những đặc điểm chính của Agile là khả năng thích nghi với các yêu cầu và ưu tiên thay đổi liên tục. Điều này cho phép các dự án Agile phản ứng nhanh chóng với các thay đổi trong thị trường, công nghệ hoặc nhu cầu của khách hàng. Trong khi các dự án truyền thống thường tuân thủ một kế hoạch chi tiết, Agile cho phép các đội phát triển linh hoạt và thích nghi với các thay đổi. Điều này giúp tăng cường hiệu suất và chất lượng của dự án, đồng thời giảm thiểu rủi ro và tăng cường sự hài lòng của khách hàng.

Khi duy trì dữ liệu theo dõi trong một hệ thống hiện có, một trong những thách thức chính là dữ liệu theo dõi trở nên cũ kỹ rất nhanh chóng. Điều này có thể do nhiều lý do khác nhau, chẳng hạn như hệ thống được thiết kế để lưu trữ dữ liệu theo dõi trong một khoảng thời gian ngắn, hoặc dữ liệu theo dõi được tạo ra trong một môi trường không ổn định. Trong cả hai trường hợp, dữ liệu theo dõi có thể trở nên không chính xác hoặc không đầy đủ sau một thời gian ngắn, khiến cho việc duy trì và phân tích dữ liệu trở nên khó khăn hơn. Ngoài ra, dữ liệu theo dõi cũ kỹ cũng có thể gây ra các vấn đề về bảo mật, vì chúng có thể chứa thông tin nhạy cảm hoặc bí mật. Do đó, việc duy trì dữ liệu theo dõi trong một hệ thống hiện có đòi hỏi sự cẩn thận và sự hiểu biết về các thách thức liên quan.

Functional và non-functional là hai loại yêu cầu quan trọng trong thiết kế và phát triển hệ thống. Functional requirements mô tả những gì hệ thống cần làm, bao gồm các chức năng và tính năng mà hệ thống cần cung cấp. Ví dụ, một hệ thống quản lý khách sạn có thể có yêu cầu chức năng như: 'Hệ thống cần cho phép khách hàng đặt phòng trực tuyến', 'Hệ thống cần cho phép nhân viên quản lý phòng và khách hàng'. Non-functional requirements, mặt khác, mô tả cách hệ thống thực hiện các chức năng này, bao gồm các tiêu chí như hiệu suất, độ tin cậy, bảo mật và khả năng mở rộng. Ví dụ, một hệ thống quản lý khách sạn có thể có yêu cầu non-functional như: 'Hệ thống cần có khả năng xử lý 1000 yêu cầu đồng thời', 'Hệ thống cần có độ tin cậy cao để tránh mất dữ liệu'. Tóm lại, functional requirements mô tả những gì hệ thống cần làm, trong khi non-functional requirements mô tả cách hệ thống thực hiện các chức năng này.

Câu hỏi này liên quan đến thách thức thường gặp trong các dự án nâng cấp và thay thế hệ thống. Dự án nâng cấp và thay thế hệ thống thường liên quan đến việc thay đổi hoặc thay thế toàn bộ hoặc một phần của hệ thống hiện có. Một trong những thách thức phổ biến mà cả hai loại dự án này thường gặp phải là sự phản đối của người dùng. Người dùng thường quen thuộc với cách hệ thống hoạt động hiện tại và có thể không thích những thay đổi mà họ sắp phải đối mặt. Điều này có thể dẫn đến sự kháng cự và khó khăn trong việc chấp nhận các thay đổi mới. Ngoài ra, sự phản đối của người dùng cũng có thể ảnh hưởng đến hiệu suất và hiệu quả của dự án. Vì vậy, việc hiểu và giải quyết vấn đề này là rất quan trọng để đảm bảo thành công của dự án.

Non-functional requirements (NFRs) là những yêu cầu không liên quan trực tiếp đến chức năng của hệ thống. Chúng thường liên quan đến các tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc các hạn chế mà hệ thống phải tuân thủ. Ví dụ, một hệ thống có thể cần phải đáp ứng các yêu cầu về bảo mật, tính ổn định, khả năng mở rộng, hiệu suất, độ tin cậy, tính dễ sử dụng, khả năng tương thích với các hệ thống khác, v.v. Những yêu cầu này không phải là chức năng chính của hệ thống nhưng lại rất quan trọng để đảm bảo rằng hệ thống hoạt động một cách hiệu quả và đáp ứng được nhu cầu của người dùng.

Các công ty thường hợp tác với tổ chức outsourcing phần mềm để tiết kiệm chi phí và tăng tốc độ phát triển dự án. Việc outsourcing cho phép công ty tiếp cận chuyên môn và kỹ năng đặc biệt mà họ không thể có được trong nội bộ. Điều này giúp họ hoàn thành dự án nhanh hơn và hiệu quả hơn. Ngoài ra, outsourcing cũng cho phép công ty tập trung vào các hoạt động kinh doanh cốt lõi và giảm thiểu rủi ro liên quan đến dự án. Tuy nhiên, một số công ty cũng có thể chọn outsourcing để tăng cường kiểm soát và giám sát dự án, nhưng điều này không phải là lý do chính yếu. Tóm lại, hợp tác với tổ chức outsourcing phần mềm là một chiến lược thông minh giúp công ty tiết kiệm chi phí, tăng tốc độ phát triển và tiếp cận chuyên môn đặc biệt.

Requirements management là một phần quan trọng của quy trình phát triển phần mề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 một cách chính xác. Các hoạt động chính trong quản lý yêu cầu bao gồm: - Version control: Quản lý các phiên bản của yêu cầu, giúp theo dõi và kiểm soát các thay đổi trong quá trình phát triển. - Change control: Quản lý các thay đổi trong yêu cầu, giúp đảm bảo rằng các thay đổi được thực hiện một cách có hệ thống và được kiểm tra kỹ lưỡng. - Requirements status tracking: Theo dõi tình trạng của yêu cầu, giúp đảm bảo rằng các yêu cầu được thực hiện một cách hiệu quả và kịp thời. - Requirements tracing: Theo dõi mối quan hệ giữa các yêu cầu, giúp đảm bảo rằng các yêu cầu được thực hiện một cách toàn diện và không bỏ sót bất kỳ yêu cầu nào. Các hoạt động này 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 một cách chính xác, giúp giảm thiểu rủi ro và tăng cường hiệu suất của quy trình phát triển phần mềm.

MoSCoW là một phương pháp được sử dụng trong việc phân loại và ưu tiên yêu cầu trong quy trình phát triển phần mềm. Phương pháp này được đặt theo tên của các chữ cái đầu tiên trong các từ 'Must', 'Should', 'Could', và 'Won't'. Các chữ cái này đại diện cho các mức độ ưu tiên khác nhau của yêu cầu. 'Must' là những yêu cầu bắt buộc phải được thực hiện, 'Should' là những yêu cầu nên được thực hiện nhưng không bắt buộc, 'Could' là những yêu cầu có thể được thực hiện nếu có đủ thời gian và tài nguyên, và 'Won't' là những yêu cầu không được thực hiện. Phương pháp MoSCoW giúp các nhà phát triển phần mềm phân loại và ưu tiên các yêu cầu một cách hiệu quả, từ đó tạo ra sản phẩm phần mềm đáp ứng được nhu cầu của khách hàng.

Trong ngữ cảnh của yêu cầu xuất sắc, 'verifiable' ám chỉ rằng yêu cầu có thể được kiểm tra và chứng minh để đảm bảo chúng được đáp ứng. Điều này có nghĩa là yêu cầu phải cụ thể, rõ ràng và có thể đo lường được. Yêu cầu verifiable cho phép người phát triển xác định được liệu sản phẩm hoặc dịch vụ có đáp ứng được yêu cầu hay không, và cho phép người dùng đánh giá được liệu sản phẩm hoặc dịch vụ có đáp ứng được nhu cầu của họ hay không. Ví dụ, yêu cầu 'sản phẩm phải có tốc độ tải trang dưới 3 giây' là một yêu cầu verifiable vì nó có thể được đo lường và kiểm tra. Ngược lại, yêu cầu 'sản phẩm phải đẹp mắt' là một yêu cầu không verifiable vì nó phụ thuộc vào quan điểm cá nhân và không thể được đo lường.

Trong quá trình quan sát thụ động (passive observation) cho việc thu thập thông tin về nhiệm vụ (task elicitation), người quan sát sẽ không tham gia vào quá trình mà họ đang quan sát. Điều này có nghĩa là họ sẽ không đưa ra bất kỳ câu hỏi nào, không can thiệp vào quá trình của người dùng và không tham gia vào công việc của họ. Thay vào đó, họ sẽ chỉ quan sát và ghi lại những gì người dùng đang làm, bao gồm cả những hành động và quyết định của họ. Điều này cho phép người quan sát thu thập thông tin chính xác và khách quan về cách người dùng thực hiện nhiệm vụ, mà không gây ra bất kỳ ảnh hưởng nào đến quá trình của họ. Trong trường hợp này, lựa chọn đúng là 'Silently watch the user perform their tasks', vì nó mô tả chính xác quá trình quan sát thụ động mà không tham gia vào quá trình.

Khi bắt đầu quá trình thu thập thông tin (elicitation process), việc hỏi những câu hỏi phù hợp là rất quan trọng để viết được câu hỏi trắc nghiệm tốt. Câu hỏi mở (open-ended questions) là loại câu hỏi phù hợp để hỏi ở đầu quá trình này. Những câu hỏi này cho phép người tham gia cung cấp thông tin đầy đủ và có ý nghĩa, giúp bạn hiểu rõ hơn về vấn đề đang nghiên cứu. Ví dụ, câu hỏi như 'Bạn có thể mô tả một tình huống cụ thể khi bạn gặp phải vấn đề này không?' hoặc 'Bạn nghĩ nguyên nhân của vấn đề này là gì?' sẽ giúp bạn thu thập thông tin chi tiết và có ý nghĩa. Câu hỏi mở không có đáp án cố định, cho phép người tham gia thể hiện suy nghĩ và quan điểm của mình, giúp bạn thu thập thông tin đa dạng và phong phú. Vì vậy, câu hỏi 'Open-ended questions are asked at the beginning to obtain full and meaningful answers' là câu trả lời đúng.