Ôn tập cuối kỳ SWR302 Fall 2025

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.

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

Swimlane diagram là một loại biểu đồ được sử dụng để minh họa các quy trình hoặc quy trình kinh doanh. Nó thường được sử dụng để hiển thị các bước trong một quy trình, cùng với các cá nhân hoặc nhóm chịu trách nhiệm thực hiện từng bước. Trong một Swimlane diagram, các bước quy trình thường được hiển thị dưới dạng hình dạng đặc biệt. Câu hỏi yêu cầu bạn xác định hình dạng nào thường được sử dụng để hiển thị các bước quy trình trong một Swimlane diagram.

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.

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.

Trong việc mô tả một trường hợp sử dụng, các điều kiện có khả năng ngăn cản trường hợp sử dụng thành công được gọi là ngoại lệ. Ngoại lệ là các điều kiện không mong muốn có thể xảy ra trong quá trình thực hiện một trường hợp sử dụng, chẳng hạn như lỗi dữ liệu, lỗi kết nối mạng, v.v. Khi xác định ngoại lệ, chúng ta cần phải xác định rõ nguyên nhân và cách giải quyết của chúng để đảm bảo rằng trường hợp sử dụng vẫn có thể hoạt động một cách hiệu quả. Ngoài ra, ngoại lệ cũng giúp chúng ta xác định các trường hợp sử dụng phụ, những trường hợp sử dụng có thể xảy ra nhưng không phải là trường hợp sử dụng chính.

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 quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng. Chúng không chỉ ảnh hưởng đến kế hoạch dự án mà còn tác động trực tiếp đến quá trình thiết kế và viết mã nguồn. Yêu cầu cũng giúp xác định các hoạt động kiểm tra và thử nghiệm, đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn và yêu cầu đã được đặt ra. Vì vậy, yêu cầu (requirements) là nền tảng quan trọng để xây dựng một sản phẩm phần mềm chất lượng cao.

Kỹ thuật MoSCoW là một phương pháp được sử dụng để xác định ưu tiên các yêu cầu trong một dự án. Mỗi chữ cái viết hoa trong MoSCoW đại diện cho một mức độ ưu tiên khác nhau. M - Must (Phải có), S - Should (Nên có), C - Could (Có thể có), W - Won't (Không có). Vì vậy, đáp án đúng là "Must, Should, Could, Won't".

Khi bạn tạo bản mẫu toàn bộ giải pháp thay vì chỉ những phần có khả năng cao nhất, rủi ro cao nhất hoặc phức tạp nhất, bạn sẽ gặp phải một số vấn đề. Đầu tiên, bạn có thể đang đầu tư quá nhiều nỗ lực vào bản mẫu, điều này có thể dẫn đến lãng phí thời gian và nguồn lực. Thứ hai, bạn có thể bị phân tâm bởi những chi tiết nhỏ nhặt, điều này có thể khiến bạn mất tập trung vào mục tiêu chính. Cuối cùng, bạn có thể gặp áp lực phải phát hành bản mẫu sớm, điều này có thể dẫn đến việc bạn phải cắt giảm các tính năng quan trọng hoặc giảm chất lượng của bản mẫu. Ngoài ra, bạn cũng có thể tạo ra những kỳ vọng không thực tế về hiệu suất của bản mẫu, điều này có thể dẫn đến thất vọng khi bản mẫu không đạt được những kỳ vọng đó.

Khi viết SRS, việc ghi nhãn các yêu cầu là rất quan trọng. Điều này cho phép chúng ta tham khảo các yêu cầu cụ thể trong yêu cầu thay đổi, lịch sử sửa đổi, liên kết, hoặc ma trận theo dõi yêu cầu. Ngoài ra, việc ghi nhãn yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong nhiều dự án khác nhau. Điều này giúp tiết kiệm thời gian và công sức trong quá trình phát triển phần mềm. Hơn nữa, việc ghi nhãn yêu cầu cũng giúp cải thiện sự hợp tác giữa các thành viên trong nhóm khi họ thảo luận về các yêu cầu.

Dưới đây là câu trả lời cho câu hỏi: 'Đâu là điều không được bao gồm trong danh sách Yêu cầu về Hóa đơn Phần mềm?'. Các lựa chọn có sẵn là: - 'Chờ BAs nói ngôn ngữ của bạn.' - 'Chờ BAs tìm hiểu về doanh nghiệp và mục tiêu của bạn.' - 'Thông báo ngay các thay đổi về yêu cầu.' - 'Nhận giải thích về thực hành và sản phẩm yêu cầu.' - 'Thay đổi yêu cầu của bạn.' - 'Chờ một môi trường tôn trọng lẫn nhau.' Câu trả lời đúng là: 'Thay đổi yêu cầu của bạn.' Vì trong danh sách Yêu cầu về Hóa đơn Phần mềm, không có yêu cầu nào nói về việc thay đổi yêu cầu của người dùng. Các yêu cầu khác đều liên quan đến việc giao tiếp, học hỏi và tôn trọng lẫn nhau.

Trong ngữ cảnh của việc theo dõi yêu cầu, một ma trận theo dõi được sử dụng để thực hiện hai chức năng chính. Thứ nhất, nó được sử dụng để ánh xạ các yêu cầu đến các yếu tố khác của hệ thống như thiết kế và mã nguồn. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện một cách chính xác và không bỏ sót bất kỳ chi tiết nào. Thứ hai, nó được sử dụng để xác định các yêu cầu bị thiếu hoặc không cần thiết. Điều này giúp giảm thiểu các yêu cầu không cần thiết và đảm bảo rằng hệ thống được phát triển một cách hiệu quả và có hiệu suất cao.

Khi xác minh yêu cầu, chúng ta có thể ngăn chặn một số vấn đề tiềm ẩn. Đầu tiên, xác minh yêu cầu giúp ngăn chặn hiện tượng 'Scope creep', khi yêu cầu thay đổi không ngừng và vượt quá phạm vi ban đầu. Điều này có thể dẫn đến lãng phí thời gian và tài nguyên. Thứ hai, xác minh yêu cầu giúp ngăn chặn 'Misaligned Expectations', khi người dùng và nhà phát triển không có cùng hiểu biết về yêu cầu. Điều này có thể dẫn đến sự thất vọng và lãng phí thời gian. Cuối cùng, xác minh yêu cầu giúp ngăn chặn 'Cost Overruns and Delays', khi dự án bị chậm tiến độ và vượt quá ngân sách. Điều này có thể dẫn đến thiệt hại tài chính và ảnh hưởng đến uy tín của công ty.

ERD (Entity-Relationship Diagram) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Để xác định câu trả lời sai, chúng ta cần hiểu rõ về các thành phần của ERD. Câu trả lời sai là 'Individual instances of an entity will have the same attribute values'. Điều này không đúng vì các bản sao riêng lẻ của một thực thể sẽ có các giá trị thuộc tính khác nhau. Ví dụ, trong một bảng khách hàng, mỗi khách hàng sẽ có một địa chỉ riêng biệt. Câu trả lời đúng về ERD bao gồm: 'The cardinality, or multiplicity, of each relationship is shown with a number or letter on the lines that connect entities and relationships', 'Each entity is described by one or more attributes' và 'The diamonds in the ERD represent relationships, which identify the logical linkages between pairs of entities'.

Một nhà phân tích kinh doanh có thể chuyển đổi tiếng nói của khách hàng thành các thành phần mô hình cụ thể bằng cách xác định các từ khóa như danh từ, động từ và các tuyên bố điều kiện có thể ánh xạ đến các thành phần mô hình phân tích tương ứng. Điều này giúp họ hiểu rõ hơn về nhu cầu và mong muốn của khách hàng, từ đó tạo ra các mô hình phân tích chính xác và hiệu quả. Ngoài ra, việc xác định các từ khóa cũng giúp nhà phân tích kinh doanh tránh được sự nhầm lẫn và đảm bảo rằng các mô hình phân tích được xây dựng dựa trên thông tin chính xác và đáng tin cậy.

Khi chọn kỹ thuật biểu diễn phù hợp cho mô hình phân tích, nên tuân theo các hướng dẫn sau. Mỗi quy trình kinh doanh có thể được biểu diễn bằng các sơ đồ lưu lượng dữ liệu ở mức cao hoặc các sơ đồ Swimlane thể hiện vai trò và trách nhiệm trong quy trình. Ngoài ra, logic phức tạp có thể được biểu diễn hiệu quả bằng các cây quyết định hoặc bảng quyết định, thể hiện các kết quả có thể xảy ra hoặc các yêu cầu chức năng độc đáo. Điều này giúp đảm bảo sự rõ ràng và tránh nhầm lẫn trong quá trình phát triển.

Một bộ yêu cầu cần phải đáp ứng các đặc điểm sau. Trước hết, chúng cần phải đảm bảo tính toàn diện (Completeness), nghĩa là mặc dù có thể thiếu một số thông tin quan trọng nhưng vẫn phải ghi nhận được các yêu cầu cơ bản. Điều này cho phép các nhà phát triển hiểu được những gì cần phải được thực hiện. Tiếp theo, tính linh hoạt (Modifiability) là rất quan trọng, giúp cho việc thay đổi yêu cầu trở nên dễ dàng mà không cần phải theo dõi lịch sử thay đổi hoặc xem xét các mối quan hệ phụ thuộc giữa các yêu cầu. Tuy nhiên, tính nhất quán (Consistency) là đặc điểm quan trọng nhất, đảm bảo rằng các yêu cầu không xung đột với các yêu cầu khác hoặc các yêu cầu cấp cao hơn liên quan đến kinh doanh, người dùng hoặc hệ thống. Cuối cùng, tính theo dõi (Traceability) giúp cho việc liên kết các yêu cầu với nguồn gốc của chúng và các yếu tố được tạo ra từ chúng trở nên dễ dàng hơn.

Prototyping trong kỹ thuật yêu cầu giúp giảm thiểu rủi ro trong quá trình thiết kế yêu cầu 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. Quá trình này cho phép các bên liên quan xem xét và phản hồi về các yêu cầu trước khi triển khai hệ thống. Điều này giúp đảm bảo rằng các yêu cầu được hiểu đúng và giảm thiểu rủi ro phát sinh từ các yêu cầu không rõ ràng. Ngoài ra, prototyping cũng giúp xác định và giải quyết các vấn đề sớm, từ đó tiết kiệm thời gian và nguồn lực cho dự án.