Software Requirements - SWR302

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.

Elicitation là một quá trình hợp tác và phân tích bao gồm các hoạt động để thu thập, khám phá, trích xuất và thu thập yêu cầu. Quá trình này giúp xác định rõ yêu cầu của dự án, sản phẩm hoặc dịch vụ. Trong quá trình này, các bên liên quan sẽ tham gia vào các hoạt động như thảo luận, phân tích và xác định yêu cầu. Mục tiêu của quá trình này là thu thập thông tin chính xác và đầy đủ về yêu cầu của dự án. Các hoạt động trong quá trình này có thể bao gồm thu thập yêu cầu từ khách hàng, phân tích yêu cầu, xác định yêu cầu và tạo ra tài liệu yêu cầu. Quá trình này giúp đảm bảo rằng dự án được thực hiện đúng yêu cầu và đáp ứng được nhu cầu của khách hàng.

Khi nói về các đội ngũ được thuê ngoài ở các quốc gia khác, thuật ngữ 'offshore' thường được sử dụng để mô tả tình huống này. 'Offshore' là một thuật ngữ kinh doanh và tài chính được sử dụng để mô tả các hoạt động kinh doanh được thực hiện ở nước ngoài, thường là ở các quốc gia có chi phí lao động thấp hơn hoặc có chuyên môn cao hơn. Trong bối cảnh thuê ngoài, 'offshore' ám chỉ việc thuê các đội ngũ lao động ở nước ngoài để thực hiện các dự án hoặc công việc. Điều này có thể giúp các công ty giảm chi phí lao động, tăng cường chuyên môn và tận dụng nguồn nhân lực đa dạng hơn. Tuy nhiên, thuê ngoài cũng có thể dẫn đến các thách thức về quản lý, giao tiếp và bảo mật dữ liệu.

Prioritization là một cách để xử lý các yêu cầu cạnh tranh cho các nguồn lực hạn chế. Khi bạn xác định được mức độ ưu tiên tương đối của mỗi khả năng sản phẩm, bạn có thể lên kế hoạch xây dựng để cung cấp giá trị theo thứ tự ưu tiên cao nhất. Điều này giúp bạn tập trung vào các khả năng sản phẩm quan trọng nhất và đạt được giá trị tối đa với nguồn lực hạn chế. Trong trường hợp này, việc ưu tiên cao nhất là để đạt được giá trị tối đa, và việc ưu tiên thấp nhất là để tiết kiệm chi phí. Do đó, đáp án đúng là 'highest, lowest', nghĩa là ưu tiên cao nhất là để đạt được giá trị tối đa và ưu tiên thấp nhất là để tiết kiệm chi phí.

Requirements development là quá trình xác định và xác minh các yêu cầu của một dự án. Quá trình này bao gồm nhiều bước khác nhau, bao gồm Analysis, Validation, Design và Elicitation. Tuy nhiên, trong các bước này, Design không phải là một bước riêng biệt trong Requirements development. Thay vào đó, Design là một phần của quá trình phát triển yêu cầu, nơi các yêu cầu được xác định và mô tả chi tiết hơn. Design không phải là một bước độc lập mà là một phần của quá trình phát triển yêu cầu. Vì vậy, đáp án đúng là Design.

Validation of requirements là một bước quan trọng trong 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 viết đúng và đầy đủ. Bước này liên quan đến việc kiểm tra và xác minh các yêu cầu đã được viết có đáp ứng được nhu cầu và mục tiêu của dự án hay không. Trong quá trình này, các yêu cầu sẽ được kiểm tra để đảm bảo rằng chúng rõ ràng, cụ thể, có thể đo lường được và không mâu thuẫn với nhau. Mục tiêu của việc xác minh yêu cầu là đảm bảo rằng các yêu cầu được viết đúng và đầy đủ, giúp tránh được các sai sót và lỗi trong quá trình phát triển phần mềm. Điều này giúp đảm bảo rằng phần mềm cuối cùng được phát triển sẽ đáp ứng được nhu cầu và mục tiêu của khách hàng.

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.

Trong một dự án, người chịu trách nhiệm chính về việc truyền đạt thông tin dự án là người quản lý dự án. Họ là người có trách nhiệm đảm bảo rằng tất cả các bên liên quan đều nhận được thông tin cần thiết và cập nhật về tiến độ dự án. Điều này bao gồm việc thông báo cho các thành viên trong đội ngũ, khách hàng, và các bên liên quan khác về các thay đổi, cập nhật, và tiến độ dự án. Người quản lý dự án cũng chịu trách nhiệm về việc giải quyết các vấn đề và thắc mắc của các bên liên quan, và đảm bảo rằng tất cả các bên đều hiểu rõ về mục tiêu, phạm vi, và tiến độ dự án. Trong khi các nhà phân tích kinh doanh, đội ngũ phát triển phần mềm, và cộng đồng khách hàng đều đóng vai trò quan trọng trong dự án, thì người quản lý dự án là người chịu trách nhiệm chính về việc truyền đạt thông tin dự án.

Trong một ERD (Entity-Relationship Diagram), một thực thể (entity) thường được đại diện bằng một hình dạng đặc biệt. Trong các lựa chọn đã cho, hình dạng phổ biến nhất để đại diện cho một thực thể là hình chữ nhật (rectangle). Hình chữ nhật được sử dụng vì nó có thể đại diện cho một thực thể có các thuộc tính và mối quan hệ với các thực thể khác. Hình chữ nhật cũng dễ dàng thể hiện các mối quan hệ giữa các thực thể, chẳng hạn như mối quan hệ một-một, một-nhiều hoặc nhiều-nhiều. Ngoài ra, hình chữ nhật cũng giúp phân biệt rõ ràng giữa các thực thể và các mối quan hệ giữa chúng. Vì vậy, trong một ERD, một thực thể thường được đại diện bằng một hình chữ nhật.

Trong một tài liệu yêu cầu chức năng phần mềm, phần thuộc về giao diện người dùng (User Interface) thuộc về phần yêu cầu giao diện bên ngoài (External interface requirements). Đây là phần mô tả các yêu cầu về giao diện người dùng, bao gồm cả giao diện đồ họa và giao diện nhập xuất dữ liệu. Phần này giúp xác định rõ ràng các yêu cầu về giao diện người dùng, bao gồm cả các yêu cầu về thiết kế, chức năng và khả năng tương tác của giao diện người dùng. Điều này giúp đảm bảo rằng giao diện người dùng được thiết kế và triển khai một cách phù hợp với yêu cầu của người dùng và các yêu cầu chức năng khác của phần mềm.

Trong một sơ đồ trường hợp sử dụng (use case diagram), mũi tên từ một người tham gia (actor) đến một trường hợp sử dụng (use case) chỉ ra rằng người tham gia đó là người tham gia chính (primary actor) cho trường hợp sử dụng đó. Người tham gia chính là người hoặc nhóm người có liên quan trực tiếp đến trường hợp sử dụng và thường là người thực hiện hành động để đạt được mục tiêu của trường hợp sử dụng. Họ có thể là khách hàng, người dùng, hoặc bất kỳ ai có liên quan đến quá trình sử dụng hệ thống. Mũi tên từ người tham gia chính đến trường hợp sử dụng thể hiện mối quan hệ giữa họ và trường hợp sử dụng, giúp xác định rõ vai trò và trách nhiệm của người tham gia trong quá trình sử dụng hệ thống.

Trong hệ thống theo dõi hóa chất, use case 'Play a bill' và 'Write a check' có mối quan hệ 'include'. Điều này có nghĩa là 'Play a bill' bao gồm các hành động được mô tả trong 'Write a check'. Khi một người chơi hóa đơn, họ cũng cần viết một hóa đơn. Vì vậy, 'Play a bill' không chỉ đơn giản là chơi hóa đơn mà còn bao gồm cả việc viết hóa đơn. Điều này thể hiện mối quan hệ 'include' giữa hai use case. Mối quan hệ 'extend' chỉ áp dụng khi một use case mở rộng các hành động của một use case khác, nhưng không bao gồm tất cả các hành động. Mối quan hệ 'generalization' chỉ áp dụng khi một use case là một trường hợp đặc biệt của một use case khác. Trong trường hợp này, 'Play a bill' không phải là một trường hợp đặc biệt của 'Write a check', mà là một hành động bao gồm cả việc viết hóa đơ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 chặn một trường hợp sử dụng từ thành công được gọi là ngoại lệ. Ngoại lệ là những điều kiện không mong muốn hoặc không thể dự đoán được có thể xảy ra trong quá trình thực hiện một trường hợp sử dụng. Chúng có thể bao gồm các sự kiện như lỗi hệ thống, dữ liệu không chính xác, hoặc các yêu cầu không hợp lệ. Ngoại lệ có thể ngăn chặn một trường hợp sử dụng từ đạt được mục tiêu của nó và cần được xử lý một cách thích hợp để đảm bảo rằng hệ thống vẫn hoạt động đúng cách. Ví dụ, trong một trường hợp sử dụng mua hàng trực tuyến, ngoại lệ có thể bao gồm việc khách hàng không có đủ tiền trong tài khoản ngân hàng hoặc việc sản phẩm không có sẵn. Trong trường hợp này, hệ thống cần được thiết kế để xử lý ngoại lệ một cách thích hợp và cung cấp thông tin cho khách hàng về tình trạng của đơn hàng.

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

Trong bối cảnh của sơ đồ ngữ cảnh, các thực thể bên ngoài được minh họa bằng hình dạng và đường nét cụ thể. Các thực thể bên ngoài thường được thể hiện bằng hình dạng hình chữ nhật (rectangles) và đường nét có mũi tên (lines/arcs with arrows). Điều này giúp phân biệt chúng với các thực thể bên trong, thường được thể hiện bằng hình dạng hình oval (ovals). Đường nét có mũi tên (lines/arcs with arrows) được sử dụng để thể hiện các luồng dữ liệu giữa các thực thể bên ngoài và bên trong. Việc sử dụng hình dạng hình chữ nhật và đường nét có mũi tên để minh họa các thực thể bên ngoài giúp tạo ra một sơ đồ ngữ cảnh rõ ràng và dễ hiểu.

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 hỏi này liên quan đến khái niệm stakeholder trong quản lý dự án. Stakeholder là những cá nhân hoặc tổ chức có lợi ích hoặc ảnh hưởng đến dự án. Trong câu hỏi, các stakeholder được liệt kê bao gồm nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp, nhà thầu và nhà đầu tư mạo hiểm. Tuy nhiên, không phải tất cả các stakeholder đều là khách hàng. Ví dụ, nhân viên pháp lý và kiểm toán viên tuân thủ không phải là khách hàng của dự án, mà là những người có trách nhiệm đảm bảo dự án tuân thủ các quy định và pháp luật. Nhà cung cấp và nhà thầu cũng không phải là khách hàng, mà là những người cung cấp dịch vụ hoặc sản phẩm cho dự án. Nhà đầu tư mạo hiểm cũng không phải là khách hàng, mà là những người đầu tư vào dự án để kiếm lợi nhuận. Vì vậy, câu trả lời đúng là 'False', vì không phải tất cả các stakeholder đều là khách hàng.

Swimlane diagrams là một công cụ giúp đại diện hóa các bước trong quy trình kinh doanh hoặc hoạt động của một tổ chức. Chúng thường được sử dụng để minh họa và phân tích các quy trình kinh doanh phức tạp. Mục đích chính của swimlane diagrams là giúp người dùng hiểu rõ hơn về các bước trong quy trình kinh doanh và cách chúng tương tác với nhau. Điều này giúp tổ chức cải thiện hiệu suất và giảm thiểu sai sót trong quy trình kinh doanh. Ngoài ra, swimlane diagrams cũng có thể được sử dụng để phân tích và cải thiện các quy trình quản lý, chẳng hạn như quy trình quản lý dự án hoặc quy trình quản lý chất lượng.

Một checklist lỗi là một danh sách các lỗi phổ biến mà người đánh giá có thể tìm kiếm trong sản phẩm họ đánh giá. Để giúp người đánh giá tìm kiếm các loại lỗi thông thường trong các tài liệu yêu cầu của dự án, cần phát triển một checklist lỗi cho từng loại tài liệu yêu cầu mà dự án tạo ra. Ví dụ, nếu dự án tạo ra tài liệu yêu cầu chức năng, checklist lỗi có thể bao gồm các lỗi như: chức năng không hoạt động đúng, chức năng không đáp ứng yêu cầu, chức năng không tương thích với các chức năng khác v.v. Nếu dự án tạo ra tài liệu yêu cầu kỹ thuật, checklist lỗi có thể bao gồm các lỗi như: mã nguồn không chính xác, cấu trúc dữ liệu không đúng, giao diện người dùng không thân thiện v.v. Bằng cách phát triển checklist lỗi, người đánh giá có thể dễ dàng tìm kiếm và xác định các lỗi trong sản phẩm, giúp dự án cải thiện chất lượng và hiệu suất.

Kỹ thuật ưu tiên MoSCoW là một phương pháp được sử dụng để xác định và sắp xếp các yêu cầu hoặc nhiệm vụ theo mức độ quan trọng và ưu tiên. Mỗi chữ cái trong MoSCoW đại diện cho một mức độ ưu tiên khác nhau. 'M' đại diện cho 'Must', nghĩa là yêu cầu hoặc nhiệm vụ này phải được thực hiện. 'S' đại diện cho 'Should', nghĩa là yêu cầu hoặc nhiệm vụ này nên được thực hiện nhưng không bắt buộc. 'C' đại diện cho 'Could', nghĩa là yêu cầu hoặc nhiệm vụ này có thể được thực hiện nếu có đủ thời gian và nguồn lực. 'W' đại diện cho 'Won't', nghĩa là yêu cầu hoặc nhiệm vụ này không nên được thực hiện.