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

Để giúp các nhà phê bình tìm kiếm các loại lỗi thông thường trong sản phẩm họ đánh giá, hãy tạo một danh sách kiểm tra cho mỗi loại tài liệu yêu cầu mà các dự án của bạn tạo ra. Điều này sẽ giúp họ có thể nhanh chóng xác định và khắc phục các lỗi trong sản phẩm. Ví dụ, nếu dự án của bạn tạo ra tài liệu yêu cầu chức năng, thì danh sách kiểm tra có thể bao gồm các lỗi như lỗi logic, lỗi nhập dữ liệu, lỗi giao diện người dùng v.v. Điều này sẽ giúp các nhà phê bình có thể tập trung vào các lỗi cụ thể và đánh giá sản phẩm một cách hiệu quả hơn.

Tính chất xuất sắc của yêu cầu là tính nhất quán. Tính nhất quán trong yêu cầu có nghĩa là các yêu cầu không xung đột với nhau hoặc với các yêu cầu ở cấp cao hơn như yêu cầu kinh doanh, yêu cầu người dùng hoặc yêu cầu hệ thống. Điều này đảm bảo rằng các yêu cầu được thống nhất và không mâu thuẫn với nhau, giúp cho việc triển khai và thực hiện dự án trở nên dễ dàng hơn. Ví dụ, nếu một yêu cầu yêu cầu một chức năng cụ thể, thì các yêu cầu khác không nên yêu cầu chức năng đó. Tính nhất quán giúp đảm bảo rằng các yêu cầu được rõ ràng và dễ hiểu, giảm thiểu khả năng xảy ra sai sót trong quá trình triển khai.

Story point là một khái niệm quan trọng trong Agile và Scrum, được sử dụng để đo lường mức độ khó khăn của một User story. Mục đích của story point là giúp đội ngũ phát triển dự án có thể ước tính thời gian và công sức cần thiết để hoàn thành một User story. Story point thường được biểu diễn bằng một số điểm (points) và có thể được sử dụng để tạo ra một bảng xếp hạng các User story dựa trên mức độ khó khăn của chúng. Điều này giúp đội ngũ phát triển dự án có thể ưu tiên và sắp xếp các User story một cách hiệu quả hơn. Story point không liên quan trực tiếp đến mã code, chức năng hoặc kiến trúc của dự án, mà chỉ liên quan đến mức độ khó khăn của một User story.

Câu 'Every order has a shipping charge' là một 'fact' vì nó mô tả một thực tế hoặc một sự kiện cụ thể trong hệ thống. Nó không phải là một 'constraint' vì nó không quy định một điều kiện nào cho hệ thống. Nó cũng không phải là một 'action enabler' vì nó không cho phép thực hiện một hành động nào. Cuối cùng, nó cũng không phải là một 'inference' vì nó không được rút ra từ một tập hợp dữ liệu nào. Thay vào đó, nó là một 'fact' vì nó mô tả một thực tế cụ thể về hệ thống.

Một Business analyst (BA) là người chịu trách nhiệm thu thập, phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. Các nhiệm vụ chính của một BA bao gồm: - Communicate requirements: Truyền đạt yêu cầu của khách hàng hoặc tổ chức đến các thành viên khác trong dự án. - Document requirements: Lưu trữ và quản lý yêu cầu của khách hàng hoặc tổ chức. - Analyze requirements: Phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. - Elicit requirements: Thu thập và xác định nhu cầu của khách hàng hoặc tổ chức. - Assurance requirements: Đây là một nhiệm vụ không phải là trách nhiệm chính của một BA. Assurance requirements thường liên quan đến việc đảm bảo rằng các yêu cầu đã được thực hiện đúng và đáp ứng được nhu cầu của khách hàng hoặc tổ chức. Điều này thường là trách nhiệm của các chuyên gia khác như kiểm toán viên hoặc chuyên gia đảm bảo chất lượng. Vì vậy, Assurance requirements là một nhiệm vụ không phải là trách nhiệm chính của một Business analyst.

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.

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.

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ả.

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.

Trong sơ đồ trường hợp sử dụng, mũi tên từ người dùng đến trường hợp sử dụng thể hiện rằng người dùng đó là người dùng cho trường hợp sử dụng. Điều này có nghĩa là người dùng đó sẽ tương tác với hệ thống để đạt được mục tiêu của trường hợp sử dụng. Ví dụ, nếu một người dùng là người đặt hàng trực tuyến, thì mũi tên từ người dùng đến trường hợp sử dụng 'Đặt hàng trực tuyến' thể hiện rằng người dùng đó là người dùng cho trường hợp sử dụng này. Điều này giúp xác định rõ ràng vai trò của người dùng trong hệ thống và đảm bảo rằng hệ thống đáp ứng được nhu cầu của người dùng.

Kỹ thuật thang đo ba mức (Three-level scale technique) là một phương pháp phân loại yêu cầu dựa trên mức độ quan trọng và cấp độ khẩn cấp. Theo kỹ thuật này, các yêu cầu có mức độ quan trọng cao và cấp độ khẩn cấp cao được coi là yêu cầu có mức độ ưu tiên cao. Ngược lại, các yêu cầu có mức độ quan trọng thấp và cấp độ khẩn cấp thấp được coi là yêu cầu có mức độ ưu tiên thấp. Câu trả lời sai về kỹ thuật thang đo ba mức là: 'Yêu cầu có mức độ ưu tiên trung bình là quan trọng (khách hàng cần khả năng này) nhưng không khẩn cấp (họ có thể chờ đợi cho bản phát hành sau).'

Tính chất chất bên ngoài (External quality attributes) mô tả các đặc điểm được quan sát khi phần mềm đang được thực thi. Trong các đặc điểm này, tính toàn vẹn (Integrity) được định nghĩa là khả năng ngăn chặn mất mát thông tin và bảo toàn tính chính xác của dữ liệu được nhập vào hệ thống. Điều này có nghĩa là hệ thống phải đảm bảo rằng dữ liệu được nhập vào và lưu trữ trong hệ thống luôn chính xác và không bị thay đổi hoặc xóa bỏ không mong muốn. Tính toàn vẹn là một trong những đặc điểm quan trọng của phần mềm, giúp đảm bảo rằng hệ thống hoạt động một cách ổn định và đáng tin cậy.

Một yêu cầu được định nghĩa tốt nhất là một nhu cầu hoặc mong muốn của doanh nghiệp để giải quyết một vấn đề hoặc đạt được một mục tiêu. Yêu cầu là một khái niệm quan trọng trong quản lý dự án và phát triển sản phẩm, giúp xác định rõ những gì cần được thực hiện để đáp ứng nhu cầu của khách hàng hoặc đạt được mục tiêu kinh doanh. Một yêu cầu thường bao gồm các yếu tố như: mục tiêu, yêu cầu chức năng, yêu cầu không chức năng, và các ràng buộc khác. Việc định nghĩa rõ ràng và chính xác yêu cầu giúp đảm bảo rằng dự án được thực hiện đúng hướng và đạt được kết quả mong muốn.

Để tìm kiếm các quy tắc kinh doanh, bạn có thể tham khảo các nguồn sau: Thứ nhất, kiến thức phổ biến từ tổ chức, thường được thu thập từ những người đã làm việc với doanh nghiệp trong một thời gian dài và hiểu rõ chi tiết về cách thức hoạt động của nó. Điều này giúp bạn hiểu được quy trình và quy tắc kinh doanh của tổ chức. Thứ hai, hệ thống di sản (Legacy systems) chứa các quy tắc kinh doanh trong yêu cầu và mã nguồn của chúng. Điều này cho phép bạn hiểu được cách thức hoạt động của hệ thống và các quy tắc kinh doanh được áp dụng. Thứ ba, phân tích tài liệu hiện có, bao gồm các yêu cầu kỹ thuật từ dự án trước, quy định, tiêu chuẩn ngành, tài liệu chính sách doanh nghiệp, hợp đồng và kế hoạch kinh doanh. Điều này giúp bạn hiểu được quy tắc kinh doanh và cách thức hoạt động của doanh nghiệp. Tóm lại, việc tìm kiếm quy tắc kinh doanh là một quá trình phức tạp và đòi hỏi sự tham gia của nhiều nguồn lực khác nhau.

Câu hỏi này yêu cầu bạn xác định thông tin không đúng về khách hàng phần mềm. Các lựa chọn bao gồm: một phần của các bên liên quan, một cá nhân hoặc tổ chức nhận được lợi ích trực tiếp hoặc gián tiếp từ sản phẩm, họ có thể yêu cầu, trả tiền, chọn, chỉ định, sử dụng hoặc nhận được đầu ra được tạo bởi sản phẩm phần mềm. Tuy nhiên, 'như vậy là nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp' không phải là khách hàng phần mềm. Khách hàng phần mềm thường là người sử dụng cuối cùng hoặc tổ chức có nhu cầu sử dụng sản phẩm phần mềm. Nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp có thể là các bên liên quan khác nhau nhưng không phải là khách hàng phần mềm.

Trong câu hỏi này, chúng ta đang được hỏi về loại quy tắc kinh doanh được thể hiện trong một tuyên bố cụ thể. Tuyên bố này cho rằng nếu một khách hàng tiềm năng không phản hồi lại sau 30 ngày kể từ khi liên hệ lần đầu tiên, thì đó phải là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó. Loại quy tắc kinh doanh được thể hiện ở đây là quy tắc suy luận (inference). Quy tắc suy luận là quy tắc kinh doanh cho phép hệ thống đưa ra kết luận hoặc quyết định dựa trên dữ liệu và thông tin đã có. Trong trường hợp này, hệ thống sẽ suy luận rằng khách hàng tiềm năng không phản hồi lại sau 30 ngày là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó.

Khi có mâu thuẫn giữa phát triển sản phẩm và khách hàng, cách giải quyết vấn đề này là rất quan trọng. Trước hết, chúng ta cần hiểu rằng khách hàng là người sử dụng sản phẩm và họ có nhu cầu, mong muốn cụ thể. Tuy nhiên, phát triển sản phẩm cũng cần phải đảm bảo rằng sản phẩm đó đáp ứng được các mục tiêu kinh doanh của công ty. Vì vậy, khi có mâu thuẫn, chúng ta cần phải cân nhắc và tìm ra giải pháp phù hợp nhất. Giải pháp tốt nhất là khách hàng được ưu tiên, nhưng phải đảm bảo rằng ưu tiên đó vẫn nằm trong phạm vi mục tiêu kinh doanh của công ty. Điều này giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu của khách hàng và vẫn đạt được mục tiêu kinh doanh.

Các tiêu chí chấp nhận (Acceptance Criteria) là một phần quan trọng trong quy trình phát triển phần mềm. Nó bao gồm các điều kiện cần được đáp ứng để một yêu cầu của người dùng được coi là đã được thực hiện đúng. Các tiêu chí chấp nhận thường bao gồm các yếu tố sau: - Đảm bảo phần mềm đáp ứng được các yêu cầu chức năng (functional requirements) của người dùng. Điều này có thể được thực hiện thông qua việc chạy các thử nghiệm chấp nhận (acceptance tests) được định nghĩa dựa trên các yêu cầu của người dùng. - Đảm bảo phần mềm đáp ứng được các yêu cầu không chức năng (nonfunctional requirements) như hiệu suất, bảo mật, độ tin cậy, v.v. - Theo dõi các lỗi và vấn đề mở (open defects and issues) để đảm bảo rằng phần mềm được phát triển và thử nghiệm một cách hiệu quả. - Các tiêu chí chấp nhận không bao gồm việc có giao diện người dùng (user interface) hiện đại hoặc theo xu hướng.

Trong Agile, Epic là một khái niệm quan trọng giúp định nghĩa mục tiêu và yêu cầu của dự án. Nó đại diện cho một nhu cầu của người dùng hoặc yêu cầu kinh doanh ở mức độ cao, có thể được chia nhỏ thành các câu chuyện người dùng (user stories) nhỏ hơn và dễ quản lý hơn. Ví dụ, một Epic có thể là 'Tăng cường trải nghiệm khách hàng' và được chia nhỏ thành các user stories như 'Tạo trang web mới', 'Tối ưu hóa quá trình thanh toán trực tuyến', v.v. Mục đích của Epic là giúp nhóm phát triển hiểu rõ yêu cầu và mục tiêu của dự án, từ đó có thể lập kế hoạch và triển khai các công việc cần thiết.

Trong các dự án Agile, một epic là một khái niệm quan trọng trong quản lý dự án. Nó được định nghĩa là một tập hợp các user story liên quan đến nhau, thường quá lớn để hoàn thành trong một chu kỳ phát triển (iteration) duy nhất. Điều này có nghĩa là epic có thể bao gồm nhiều user story khác nhau, và nó có thể được thực hiện trong nhiều chu kỳ phát triển khác nhau. Epic cũng có thể được coi là một trong những tính năng quan trọng nhất của dự án, vì nó thường liên quan đến các yêu cầu chính của khách hàng.