Software Requirements - SWR302

Khi ưu tiên các yêu cầu, nó giúp cho các dự án được quản lý một cách hiệu quả hơn. Điều này được thực hiện bằng cách tập trung vào các tính năng quan trọng nhất, giảm thiểu các yêu cầu không cần thiết và tránh sự lan rộng không kiểm soát được của dự án. Việc ưu tiên yêu cầu giúp cho các nhà phát triển và các bên liên quan có thể tập trung vào các mục tiêu chính của dự án, từ đó dẫn đến việc hoàn thành dự án một cách nhanh chóng và hiệu quả hơn. Ngoài ra, việc ưu tiên yêu cầu cũng giúp cho các dự án tránh được sự phức tạp không cần thiết, giảm thiểu các rủi ro và tăng cường sự linh hoạt trong việc điều chỉnh dự án theo nhu cầu của các bên liên quan.

Để trở thành một Business Analyst hiệu quả, người ta thường yêu cầu các kỹ năng phân tích cơ bản như Analytical skills, Leadership skills, Organizational skills và Creativity. Tuy nhiên, ngoài những kỹ năng này, một Business Analyst còn cần phải có các kỹ năng khác như Listening skills, Systems thinking skills, Interviewing and questioning skills, Learning skills, Interpersonal skills, Thinking on your feet, Facilitation skills, Observational skills và Communication skills. Những kỹ năng này giúp Business Analyst thu thập thông tin chính xác, xây dựng mối quan hệ tốt đẹp với các thành viên trong nhóm, giải quyết vấn đề một cách hiệu quả và đưa ra quyết định sáng suốt. Ngoài ra, Business Analyst cũng cần phải có khả năng học hỏi nhanh chóng, thích nghi với môi trường làm việc mới và có thể điều chỉnh chiến lược phù hợp với tình hình thực tế. Vì vậy, tất cả các kỹ năng được đề cập đều là quan trọng và cần thiết cho một Business Analyst.

Khi xây dựng một prototype, mục tiêu chính là tạo ra một mô hình cơ bản để kiểm tra ý tưởng và thu thập phản hồi từ các bên liên quan. Tuy nhiên, có một số rủi ro mà các nhà phát triển cần phải xem xét. Một trong những rủi ro đó là các bên liên quan có thể mong đợi một prototype được xây dựng với chất lượng sản phẩm cuối cùng, điều này có thể dẫn đến sự thất vọng và lãng phí thời gian khi họ nhận ra rằng prototype không đáp ứng được yêu cầu của họ. Để giảm thiểu rủi ro này, một chiến lược quan trọng là tạo ra một prototype có vẻ ngoài không được hoàn thiện, không giống như sản phẩm cuối cùng. Điều này giúp các bên liên quan hiểu rõ rằng prototype chỉ là một mô hình cơ bản và không phải là sản phẩm cuối cùng. Bằng cách này, họ sẽ không đặt ra những kỳ vọng không thực tế và sẽ có thể cung cấp phản hồi hữu ích để giúp hoàn thiện sản phẩm.

Trong Agile project, Epic là một khái niệm quan trọng giúp mô tả một nhu cầu hoặc yêu cầu kinh doanh ở mức độ cao. Nó đại diện cho một mục tiêu hoặc một nhóm mục tiêu liên quan đến một yêu cầu kinh doanh cụ thể. Epic thường được sử dụng để mô tả một yêu cầu kinh doanh lớn và phức tạp, cần được chia nhỏ thành các yêu cầu nhỏ hơn và dễ quản lý hơn. Những yêu cầu nhỏ hơn này được gọi là User Story. Mục đích chính của Epic là giúp các nhà phát triển và quản lý dự án hiểu rõ hơn về yêu cầu kinh doanh và cách thức thực hiện nó. Nó cũng giúp xác định các yêu cầu chính và ưu tiên của dự án. Trong Agile, Epic thường được sử dụng như một công cụ để giúp các đội phát triển và quản lý dự án làm việc hiệu quả hơn và đạt được mục tiêu của dự án một cách nhanh chóng và hiệu quả.

Khi tạo một nhân vật (persona) cho mỗi lớp người dùng, điều quan trọng nhất là nhân vật đó phải đại diện cho lớp người dùng đó. Điều này có nghĩa là nhân vật phải phản ánh được đặc điểm, hành vi và nhu cầu của người dùng trong lớp đó. Nhân vật không cần phải là một người thật sự, mà chỉ cần là một đại diện cho lớp người dùng đó. Ví dụ, nếu bạn đang thiết kế một ứng dụng cho người dùng trẻ vị thành niên, nhân vật của bạn có thể là một người trẻ tuổi với những đặc điểm và nhu cầu tương tự. Điều quan trọng là nhân vật phải phản ánh được thực tế và có thể giúp bạn hiểu rõ hơn về người dùng của mình. Nhân vật không cần phải giàu có hay đẹp đẽ, mà chỉ cần là một đại diện cho lớp người dùng đó.

Khi có mâu thuẫn giữa phát triển và khách hàng, cách giải quyết vấn đề này rất quan trọng. Trước hết, cần phải hiểu rằng mục tiêu chính của bất kỳ dự án nào là đáp ứng nhu cầu của khách hàng. Tuy nhiên, cũng cần phải đảm bảo rằng các yêu cầu của khách hàng không đi ngược lại với mục tiêu kinh doanh của công ty. Vì vậy, trong trường hợp có mâu thuẫn, khách hàng nên được ưu tiên, nhưng điều này phải được thực hiện một cách có sự cân nhắc và phù hợp với mục tiêu kinh doanh của công ty. Điều này có nghĩa là các yêu cầu của khách hàng cần phải được xem xét và đánh giá một cách cẩn thận để đảm bảo rằng chúng không gây ra bất kỳ hậu quả tiêu cực nào cho công ty. Nếu các yêu cầu của khách hàng không thể được đáp ứng mà không gây ra bất kỳ hậu quả tiêu cực nào, thì cần phải tìm kiếm giải pháp thay thế hoặc giải thích rõ ràng cho khách hàng về lý do tại sao yêu cầu của họ không thể được đáp ứng.

Regularly reassessing và updating prioritization dựa trên mục tiêu kinh doanh đang phát triển là rất quan trọng vì nó giúp đảm bảo rằng nỗ lực phát triển vẫn phù hợp với bối cảnh kinh doanh hiện tại. Khi mục tiêu kinh doanh thay đổi, yêu cầu của khách hàng cũng có thể thay đổi, và việc ưu tiên không phù hợp có thể dẫn đến việc lãng phí nguồn lực và thời gian. Bằng cách thường xuyên đánh giá và cập nhật ưu tiên, các tổ chức có thể đảm bảo rằng họ đang tập trung vào những việc quan trọng nhất và đạt được mục tiêu kinh doanh của mình. Điều này cũng giúp các tổ chức linh hoạt và sẵn sàng thích nghi với những thay đổi trong môi trường kinh doanh.

Khi yêu cầu từ nhiều người dùng được nhập vào, việc tích hợp chúng lại với nhau có thể trở nên khó khăn do một số lý do chính. Thứ nhất, người dùng thường không đồng ý về các đặc điểm kỹ thuật. Điều này có thể dẫn đến sự không chắc chắn và khó khăn trong việc xác định yêu cầu chính xác. Thứ hai, các phương pháp tổ chức có cấu trúc thường không có sẵn, điều này có thể khiến việc phân tích và sắp xếp yêu cầu trở nên phức tạp hơn. Cuối cùng, yêu cầu nhập vào thường đa dạng và không có cấu trúc, điều này có thể khiến việc xác định yêu cầu chính xác trở nên khó khăn hơn. Trong trường hợp này, đáp án đúng là 'Requirements input is often diverse and unstructured.' vì nó phản ánh chính xác khó khăn trong việc tích hợp yêu cầu từ nhiều người dùng.

Khi thực hiện quy trình thu thập yêu cầu (requirements elicitation), việc tham gia của người dùng là rất quan trọng vì nó giúp thu thập thông tin về nhu cầu và mong đợi của họ. Điều này đảm bảo rằng các yêu cầu được phát triển phù hợp với nhu cầu thực tế của người dùng, từ đó giúp hệ thống được thiết kế và triển khai một cách hiệu quả. Việc tham gia của người dùng cũng giúp xác định các yêu cầu chức năng và phi chức năng, đồng thời đảm bảo rằng các yêu cầu được ưu tiên và thực hiện một cách hợp lý. Ngoài ra, việc tham gia của người dùng cũng giúp xác định các yêu cầu không chức năng, chẳng hạn như hiệu suất, độ tin cậy và bảo mật, từ đó giúp hệ thống được thiết kế và triển khai một cách an toàn và đáng tin cậy.

Khi yêu cầu chức năng cho một hệ thống phần mềm, việc xác định các bên liên quan (stakeholders) là rất quan trọng. Các bên liên quan bao gồm những người, nhóm hoặc tổ chức đang tham gia tích cực vào dự án, bị ảnh hưởng bởi kết quả của dự án hoặc có khả năng ảnh hưởng đến kết quả của dự án. Việc xác định các bên liên quan giúp bạn hiểu rõ về tầm nhìn và chiến lược của dự án, từ đó có thể đưa ra quyết định chiến lược và loại bỏ các rào cản chính trị và tài chính.

Khi một dự án phần mềm được triển khai, phạm vi dự án (scope) là một khái niệm quan trọng cần được xác định rõ ràng. Phạm vi dự án xác định những gì được thực hiện và những gì không được thực hiện trong dự án. Mục đích của phạm vi dự án là để đảm bảo rằng tất cả các bên liên quan (stakeholder) hiểu rõ về dự án và tránh những hiểu lầm không cần thiết. Việc xác định phạm vi dự án rõ ràng 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), khi mà các yêu cầu mới được thêm vào dự án mà không được xem xét kỹ lưỡng. Điều này có thể dẫn đến sự chậm trễ, tăng chi phí và giảm chất lượng của dự án. Ngoài ra, phạm vi dự án cũng giúp đảm bảo rằng dự án tập trung vào mục tiêu chính và tránh bị phân tán vào các hoạt động không liên quan. Vì vậy, việc xác định phạm vi dự án rõ ràng trong tài liệu phạm vi dự án (scope document) là rất quan trọng để đảm bảo rằng dự án được triển khai một cách hiệu quả và đạt được mục tiêu mong muốn.

Khi xây dựng một hệ thống thông tin, việc xác định yêu cầu dữ liệu là một bước quan trọng. Để đảm bảo rằng hệ thống này hoạt động hiệu quả và chính xác, cần phải hiểu rõ về nhu cầu và phức tạp của dữ liệu. Điều này có thể đạt được bằng cách tham gia của các bên liên quan, bao gồm các chuyên gia dữ liệu, trong quá trình xác định yêu cầu dữ liệu. Họ có thể cung cấp kiến thức và kinh nghiệm chuyên môn để giúp xác định chính xác các yêu cầu dữ liệu và đảm bảo rằng hệ thống này đáp ứng được nhu cầu của người dùng. Việc tham gia của các bên liên quan cũng giúp tránh được các sai sót và lỗi trong quá trình xây dựng hệ thống, từ đó giảm thiểu chi phí và thời gian phát triển. Ngoài ra, việc tham gia của các chuyên gia dữ liệu cũng giúp đảm bảo rằng hệ thống này có thể thích nghi với các thay đổi trong dữ liệu và nhu cầu của người dùng, từ đó giúp hệ thống này trở nên linh hoạt và dễ dàng duy trì.

Khi xây dựng một sản phẩm hoặc giải pháp, việc hiểu được nhu cầu và yêu cầu của người dùng là rất quan trọng. Tuy nhiên, nếu chỉ dựa vào một đại diện duy nhất, có thể dẫn đến việc bỏ qua hoặc không hiểu đúng nhu cầu của người dùng khác. Điều này có thể dẫn đến việc sản phẩm không đáp ứng được nhu cầu của người dùng, từ đó ảnh hưởng đến sự thành công của sản phẩm. Việc tham gia với nhiều đại diện người dùng khác nhau giúp đảm bảo rằng sản phẩm được thiết kế để đáp ứng nhu cầu đa dạng của người dùng. Điều này giúp đảm bảo rằng sản phẩm được thiết kế để đáp ứng nhu cầu của nhiều người dùng khác nhau, từ đó tăng cường sự thành công của sản phẩm. Ngoài ra, việc tham gia với nhiều đại diện người dùng khác nhau cũng giúp giảm thiểu rủi ro liên quan đến việc thiết kế sản phẩm. Khi chỉ dựa vào một đại diện duy nhất, có thể dẫn đến việc bỏ qua hoặc không hiểu đúng rủi ro liên quan đến sản phẩm. Vì vậy, việc tham gia với nhiều đại diện người dùng khác nhau là rất quan trọng để đảm bảo rằng sản phẩm được thiết kế để đáp ứng nhu cầu đa dạng của người dùng và giảm thiểu rủi ro liên quan đến sản phẩm.

Requirements modeling là một quá trình quan trọng trong việc phát triển phần mềm, giúp các nhà phát triển và các bên liên quan hiểu rõ và thống nhất về yêu cầu của dự án. Khi có nhiều bên liên quan tham gia vào dự án, các yêu cầu và kỳ vọng có thể khác nhau, dẫn đến xung đột. Requirements modeling có thể giúp giải quyết các xung đột này bằng cách cung cấp một hình ảnh rõ ràng và trực quan về các yêu cầu, giúp các bên liên quan đạt được sự đồng thuận. Điều này được thực hiện bằng cách tạo ra một mô hình yêu cầu, bao gồm các thành phần như yêu cầu chức năng, yêu cầu không chức năng, và các mối quan hệ giữa chúng. Mô hình này giúp các bên liên quan hiểu rõ về các yêu cầu và mối quan hệ giữa chúng, từ đó có thể đạt được sự thống nhất về các yêu cầu của dự án. Ngoài ra, requirements modeling cũng giúp các nhà phát triển xác định và giải quyết các xung đột sớm, giảm thiểu thời gian và chi phí cần thiết để sửa chữa các vấn đề sau này.

Trong quản lý dự án, việc xác định và ưu tiên rủi ro là một phần quan trọng để đảm bảo dự án được thực hiện một cách hiệu quả và an toàn. Có nhiều phương pháp để xác định rủi ro, nhưng phương pháp phổ biến nhất là sử dụng phương pháp phân tích rủi ro (Risk Analysis). Phương pháp này bao gồm việc xác định, phân tích và ưu tiên rủi ro dựa trên mức độ nghiêm trọng và khả năng xảy ra của chúng. Để ưu tiên rủi ro, chúng ta cần xem xét cả khả năng xảy ra và tác động tiềm ẩn của rủi ro. Khả năng xảy ra của rủi ro được đo lường bằng mức độ xác suất xảy ra, trong khi tác động tiềm ẩn được đo lường bằng mức độ ảnh hưởng đến dự án. Bằng cách xem xét cả hai yếu tố này, chúng ta có thể xác định rủi ro nào cần được ưu tiên xử lý đầu tiên. Phương pháp này giúp đảm bảo rằng chúng ta tập trung vào những rủi ro có khả năng gây thiệt hại lớn nhất và có thể thực hiện các biện pháp phòng ngừa hoặc giảm thiểu rủi ro một cách hiệu quả.

Câu nói 'Yêu cầu ngầm định cũng có thể là những điều chưa biết' (Implicit requirements can also be unknown unknowns) ám chỉ rằng trong quá trình thu thập yêu cầu (SRS process), có thể có những yêu cầu quan trọng mà khách hàng chưa thể nhận ra hoặc chưa thể thể hiện rõ ràng. Những yêu cầu này được gọi là 'yêu cầu chưa biết' (unknown unknowns). Họ không chỉ là những điều mà khách hàng biết nhưng chưa thể thể hiện, mà còn là những điều mà cả khách hàng và nhà phát triển cũng không biết. Những yêu cầu này có thể ảnh hưởng đến chất lượng và hiệu suất của sản phẩm. Để tránh những yêu cầu ngầm định và unknown unknowns, khách hàng và nhà phát triển cần phải có một quá trình thu thập yêu cầu cẩn thận và chi tiết, bao gồm cả việc hỏi hỏi và thảo luận kỹ lưỡng.

Modeling là một quá trình quan trọng trong việc phân tích yêu cầu phức tạp. Nó giúp các nhà phát triển và các bên liên quan khác hiểu rõ hơn về yêu cầu và chức năng của hệ thống. Quá trình này bao gồm việc tạo ra các mô hình và bản đồ để thể hiện các mối quan hệ giữa các yêu cầu và chức năng. Điều này giúp các nhà phát triển xác định các điểm không nhất quán hoặc thiếu sót trong yêu cầu, từ đó có thể điều chỉnh và cải thiện hệ thống. Ngoài ra, modeling còn giúp các nhà phát triển xác định các yêu cầu quan trọng và ưu tiên chúng, giúp việc phát triển hệ thống trở nên hiệu quả hơn. Tóm lại, modeling là một công cụ quan trọng trong việc phân tích yêu cầu phức tạp và giúp các nhà phát triển tạo ra hệ thống tốt hơn.

Kano model là một công cụ giúp phân tích yêu cầu của người dùng bằng cách phân loại các tính năng thành ba loại: cơ bản, hiệu suất và hạnh phúc. Các tính năng cơ bản là những tính năng cần thiết để sản phẩm hoạt động, chẳng hạn như khả năng lưu trữ dữ liệu. Các tính năng hiệu suất là những tính năng giúp sản phẩm hoạt động tốt hơn, chẳng hạn như tốc độ tải dữ liệu. Các tính năng hạnh phúc là những tính năng giúp người dùng cảm thấy hài lòng, chẳng hạn như khả năng tùy chỉnh giao diện. Bằng cách phân loại các tính năng theo cách này, Kano model giúp các nhà phát triển xác định những tính năng quan trọng nhất và ưu tiên phát triển chúng.

Prototyping là một kỹ thuật quan trọng trong kỹ thuật yêu cầu (requirements engineering) giúp giảm thiểu rủi ro bằng cách cung cấp cho các bên liên quan một hình ảnh trực quan để xác minh các yêu cầu không rõ ràng. Khi thực hiện prototyping, các kỹ sư yêu cầu và các bên liên quan có thể tạo ra một mô hình hoặc phiên bản thử nghiệm của hệ thống, giúp họ hiểu rõ hơn về các yêu cầu và xác định các điểm không rõ ràng. Điều này cho phép họ xác định và sửa đổi các yêu cầu trước khi bắt đầu phát triển hệ thống, giảm thiểu rủi ro và đảm bảo rằng hệ thống đáp ứng được các yêu cầu của khách hàng. Prototyping cũng giúp giảm thiểu rủi ro bằng cách cho phép các kỹ sư thử nghiệm và đánh giá các ý tưởng khác nhau, giúp họ chọn ra giải pháp tốt nhất cho hệ thống. Tóm lại, prototyping là một công cụ quan trọng trong kỹ thuật yêu cầu giúp giảm thiểu rủi ro và đảm bảo rằng hệ thống đáp ứng được các yêu cầu của khách hàng.

MoSCoW là một phương pháp được sử dụng để xác định và ưu tiên các yêu cầu dựa trên mục tiêu kinh doanh. Phương pháp này được đặt tên theo bốn loại yêu cầu chính: Must-haves, Should-haves, Could-haves và Won't-haves. Must-haves là những yêu cầu bắt buộc phải có, Should-haves là những yêu cầu nên có nhưng không bắt buộc, Could-haves là những yêu cầu có thể có nhưng không cần thiết và Won't-haves là những yêu cầu không cần có. Bằng cách phân loại các yêu cầu theo cách này, MoSCoW giúp các nhà phát triển và quản lý dự án xác định ưu tiên của các yêu cầu và tập trung vào những yêu cầu quan trọng nhất.