Software Requirements - SWR302

Các tính chất của yêu cầu bao gồm: 1. Ngày yêu cầu được tạo ra, 2. Số phiên bản hiện tại của yêu cầu, 3. Người viết yêu cầu, 4. Độ ưu tiên và 5. Xác thực yêu cầu. Để trả lời câu hỏi này, chúng ta cần xác định các tính chất quan trọng của yêu cầu. Tính chất 1 là ngày tạo ra yêu cầu, giúp chúng ta theo dõi lịch sử của yêu cầu. Tính chất 2 là số phiên bản hiện tại của yêu cầu, giúp chúng ta biết được phiên bản nào đang được sử dụng. Tính chất 3 là người viết yêu cầu, giúp chúng ta biết được người chịu trách nhiệm về yêu cầu. Tính chất 4 là độ ưu tiên, giúp chúng ta biết được mức độ quan trọng của yêu cầu. Tính chất 5 là xác thực yêu cầu, giúp chúng ta biết được yêu cầu đã được kiểm tra và xác minh chưa. Vì vậy, các tính chất của yêu cầu bao gồm: ngày tạo ra yêu cầu, số phiên bản hiện tại của yêu cầu, người viết yêu cầu, độ ưu tiên và xác thực yêu cầu.

Sách yêu cầu phần mềm (Software Requirements Specification - SRS) là một tài liệu quan trọng trong quá trình phát triển phần mềm. Nó cung cấp thông tin chi tiết về yêu cầu của khách hàng, chức năng của sản phẩm và các ràng buộc kỹ thuật. Dưới đây là một số đối tượng chính sử dụng SRS: - Nhóm phát triển phần mềm: Họ cần biết những gì cần xây dựng. - Quản lý dự án: Họ dựa vào yêu cầu để ước tính lịch trình, nỗ lực và tài nguyên. - Khách hàng, bộ phận tiếp thị và bán hàng: Họ cần biết sản phẩm nào sẽ được giao. - Nhóm bảo trì và hỗ trợ: Họ sử dụng nó để hiểu chức năng của từng phần của sản phẩm. Tuy nhiên, đối tượng không chính thức sử dụng SRS là đối thủ cạnh tranh muốn đánh cắp dữ liệu của hệ thống phần mềm. Họ không có quyền truy cập vào SRS và không cần thông tin chi tiết về sản phẩm.

Khi thực hiện hoạt động thu thập thông tin (elicitation activities), bạn cần chuẩn bị kỹ lưỡng để đảm bảo quá trình thu thập thông tin diễn ra hiệu quả. Một trong những cách giúp bạn khi thực hiện hoạt động này là giáo dục người tham gia (stakeholders). Điều này có nghĩa là bạn cần giúp họ hiểu rõ mục đích và yêu cầu của hoạt động thu thập thông tin, từ đó họ sẽ có thể cung cấp thông tin chính xác và đầy đủ. Giáo dục người tham gia cũng giúp xây dựng sự tin tưởng và hợp tác giữa bạn và họ, tạo điều kiện thuận lợi cho quá trình thu thập thông tin. Ngoài ra, giáo dục người tham gia còn giúp bạn tránh được những hiểu lầm và sai sót trong quá trình thu thập thông tin.

Dưới đây là câu hỏi về việc sử dụng danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Câu hỏi yêu cầu người tham gia đánh giá tính chính xác của tuyên bố: 'Phát triển danh sách kiểm tra lỗi và sử dụng nó cho tất cả các loại tài liệu yêu cầu'. Để trả lời câu hỏi này, chúng ta cần xem xét vai trò của danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Danh sách kiểm tra lỗi là một công cụ quan trọng giúp đảm bảo chất lượng của sản phẩm phần mềm. Nó giúp phát hiện và sửa lỗi trong quá trình phát triển, từ đó cải thiện chất lượng của sản phẩm. Việc sử dụng danh sách kiểm tra lỗi cho tất cả các loại tài liệu yêu cầu là một thực hành tốt, giúp đảm bảo rằng tất cả các yêu cầu được kiểm tra và xác minh một cách đầy đủ. Điều này giúp giảm thiểu khả năng xảy ra lỗi và cải thiện chất lượng của sản phẩm phần mềm. Vì vậy, tuyên bố trên là đúng.

Các dự án nhỏ thường dành khoảng 5 đến 7 phần trăm tổng công sức của họ cho công việc yêu cầu. Điều này có nghĩa là khi bạn đang thực hiện một dự án nhỏ, bạn nên dành một phần nhỏ của thời gian để xác định yêu cầu của dự án. Yêu cầu là bước quan trọng trong dự án vì nó giúp bạn hiểu rõ hơn về dự án và đảm bảo rằng dự án được thực hiện đúng mục tiêu. Việc dành thời gian cho công việc yêu cầu sẽ giúp bạn tránh được những sai lầm và tiết kiệm thời gian trong quá trình thực hiện dự án. Tuy nhiên, cần lưu ý rằng việc dành thời gian cho công việc yêu cầu không phải là việc lãng phí thời gian, mà là một phần quan trọng của quá trình thực hiện dự án.

Các công cụ phát triển yêu cầu bao gồm các công cụ mô hình hóa, thu thập thông tin và tạo bản mẫu. Trong số các lựa chọn trên, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu. Công cụ kiểm soát phiên bản được sử dụng để theo dõi và quản lý các phiên bản của mã nguồn, thường được sử dụng trong quy trình phát triển phần mềm. Trong khi đó, công cụ mô hình hóa giúp tạo ra các mô hình của hệ thống, công cụ thu thập thông tin giúp xác định yêu cầu của hệ thống và công cụ tạo bản mẫu giúp tạo ra các bản mẫu của hệ thống. Vì vậy, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu.

Theo Halle và Goldberg (2010) trong cuốn sách Software Requirements, phiên bản thứ ba, có sáu loại quy tắc kinh doanh cơ bản. Chúng bao gồm: Constraints (khuyến cáo), Action Enablers (cơ chế thực hiện hành động), Inferences (xác minh), Computations (tính toán), References (chỉ dẫn) và Facts (thông tin). Tuy nhiên, References không phải là một loại quy tắc kinh doanh cơ bản. Thay vào đó, nó chỉ là một loại thông tin liên quan đến quy tắc kinh doanh.

Câu hỏi này yêu cầu bạn đánh giá tính chính xác của tuyên bố rằng tất cả các dự án công nghệ thông tin (IT) của doanh nghiệp đều chọn thay thế tất cả các quy trình kinh doanh thủ công bằng việc triển khai tự động hóa quy trình kinh doanh. Tuy nhiên, thực tế có thể không phải vậy. Một số dự án IT chỉ chọn tự động hóa một số quy trình kinh doanh nhất định, hoặc có thể không tự động hóa gì cả. Vì vậy, câu trả lời đúng là 'False'.

Các mối quan hệ giữa Use Case được định nghĩa như sau: Một mối quan hệ Include cho biết một Use Case bao gồm hành vi được mô tả trong Use Case khác. Một mối quan hệ Extend cho biết một Use Case có thể mở rộng hành vi được mô tả trong Use Case khác. Tương tự như kế thừa trong lập trình, mối quan hệ Generalization giữa Use Cases cho biết Use Case con là một dạng cụ thể hơn của Use Case cha. Use Case con thừa kế tất cả các tính năng và mối quan hệ của Use Case cha và có thể thêm mới các tính năng và mối quan hệ. Tất cả các mối quan hệ trên đều đúng và được sử dụng trong việc mô hình hóa Use Case.

Để xác định ưu tiên theo yêu cầu Prioritization dựa trên giá trị, chi phí và rủi ro, chúng ta cần xem xét các yếu tố giá trị, chi phí và rủi ro. Giá trị (value %) đại diện cho lợi ích hoặc giá trị mà dự án mang lại. Chi phí (cost %) bao gồm các chi phí liên quan đến dự án, chẳng hạn như chi phí nhân công, vật liệu, thiết bị, v.v. Rủi ro (risk %) là khả năng xảy ra sự cố hoặc thảm họa trong dự án. Để tính toán ưu tiên, chúng ta cần so sánh giá trị với chi phí và rủi ro. Formula đúng là Priority = value % / (cost % + risk %). Điều này cho phép chúng ta xác định dự án nào có giá trị cao nhất và cần ưu tiên đầu tư.

Khi cố gắng thể hiện, phân tích hoặc khám phá mô tả các nhiệm vụ người dùng, phương pháp thể hiện phù hợp nhất là sử dụng các câu chuyện người dùng, kịch bản và mô tả trường hợp sử dụng. Phương pháp này cho phép bạn mô tả các nhiệm vụ người dùng một cách chi tiết và cụ thể, đồng thời cũng giúp bạn phân tích và khám phá các yêu cầu của người dùng. Các câu chuyện người dùng giúp bạn hiểu rõ hơn về các nhu cầu và mong muốn của người dùng, trong khi các kịch bản và mô tả trường hợp sử dụng giúp bạn xác định các yêu cầu chức năng và không chức năng của hệ thống.

Các yêu cầu chức năng mô tả đầy đủ như cần thiết về hành vi mong đợi của hệ thống phần mềm. Chúng xác định các hành vi mà sản phẩm sẽ thể hiện trong các điều kiện cụ thể. Chúng mô tả những gì nhà phát triển phải thực hiện để cho phép người dùng thực hiện các nhiệm vụ của họ (yêu cầu người dùng), từ đó đáp ứng các yêu cầu kinh doanh. Ví dụ, yêu cầu chức năng có thể bao gồm các chức năng như đăng nhập, đăng ký, tìm kiếm thông tin, v.v. Mục tiêu của các yêu cầu chức năng là đảm bảo rằng hệ thống phần mềm đáp ứng được các yêu cầu của người dùng và đáp ứng được các mục tiêu kinh doanh của tổ chức.

Một số người có thể nhầm lẫn giữa các khái niệm "kỹ năng" và "kiến thức" khi nói về vai trò của một nhà phân tích kinh doanh. Tuy nhiên, "kiến thức" và "kỹ năng" là hai khái niệm khác nhau. "Kỹ năng" đề cập đến khả năng thực hiện một công việc hoặc nhiệm vụ cụ thể, trong khi "kiến thức" đề cập đến kiến thức và thông tin cần thiết để thực hiện công việc đó. "Thái độ làm việc" (working styles) không phải là một khía cạnh quan trọng trong vai trò của một nhà phân tích kinh doanh. Vì vậy, trong các lựa chọn trên, "thái độ làm việc" không phải là một trong những nhu cầu cơ bản cần có để tạo ra một nhà phân tích kinh doanh hiệu quả.

Để trả lời câu hỏi này, chúng ta cần hiểu mục đích của việc xác định yêu cầu. Các lựa chọn không đúng về động lực cho việc xác định yêu cầu bao gồm: Quản lý dự án, Bảo trì, Kiểm tra, Chế tạo lại và Chuyển đổi. Những hoạt động này không phải là động lực chính cho việc xác định yêu cầu. Thay vào đó, chúng ta có các động lực như: Tìm kiếm yêu cầu bị thiếu, Tìm kiếm yêu cầu không cần thiết, Xác thực và tuân thủ, Phân tích tác động của thay đổi, Quản lý dự án (dù không phải là động lực chính).

Điểu án ngữ cảnh là một công cụ quan trọng trong thiết kế hệ thống, giúp xác định ranh giới và các mối liên hệ giữa hệ thống đang phát triển và các hệ thống khác trong môi trường xung quanh. Nó cho phép các nhà phát triển hiểu rõ hơn về hệ thống và các yếu tố ảnh hưởng đến nó. Câu trả lời đúng về điểu án ngữ cảnh là: 'Điểu án ngữ cảnh thể hiện rõ ranh giới và các mối liên hệ giữa hệ thống đang phát triển và các hệ thống khác trong môi trường xung quanh.'

Một trong những mô hình quản lý rủi ro là mô hình chuyển thông tin rủi ro thành quyết định và hành động. Mô hình này thường được sử dụng trong các tổ chức để đưa ra quyết định dựa trên thông tin rủi ro. Trong các lựa chọn trên, 'Analyze' là một trong những mô hình quản lý rủi ro phù hợp với mô tả này. Mô hình 'Analyze' giúp tổ chức phân tích và đánh giá rủi ro, từ đó đưa ra quyết định và hành động để giảm thiểu hoặc phòng ngừa rủi ro. Điều này giúp tổ chức có thể đưa ra quyết định sáng suốt và hiệu quả hơn.

Tính chất chất lượng là một khái niệm quan trọng trong thiết kế và phát triển hệ thống. Nó được định nghĩa là một đặc tả về tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc một ràng buộc mà hệ thống phải tuân thủ. Ví dụ, một hệ thống có thể phải đáp ứng tính chất bảo mật, tính khả dụng hoặc hiệu suất. Tính chất chất lượng thường được sử dụng để mô tả các yêu cầu không chức năng của hệ thống, bao gồm cả các yêu cầu về dịch vụ và tính năng.

Mục tiêu của phần Background trong tài liệu Vision và Scope là mô tả lý do và bối cảnh cho sản phẩm mới hoặc thay đổi đối với sản phẩm hiện có. Nó giải thích lịch sử hoặc tình huống dẫn đến quyết định xây dựng sản phẩm này. Phần này giúp người đọc hiểu rõ hơn về mục tiêu và tầm quan trọng của sản phẩm. Nó cũng cung cấp thông tin về các yếu tố ảnh hưởng đến việc xây dựng sản phẩm, bao gồm cả các thách thức và cơ hội. Mục tiêu của phần Background là cung cấp bối cảnh và lý do cho việc xây dựng sản phẩm, giúp người đọc hiểu rõ hơn về tầm quan trọng và mục tiêu của sản phẩm.

Khách hàng có trách nhiệm đảm bảo rằng họ dành đủ thời gian để cung cấp và làm rõ các yêu cầu. Điều này bao gồm việc cung cấp thông tin cụ thể và chính xác về các yêu cầu. Họ cũng cần đảm bảo rằng các yêu cầu được rõ ràng và dễ hiểu. Ngoài ra, khách hàng cần phải xác định các tiêu chí chấp nhận để đánh giá sản phẩm hoặc dịch vụ cuối cùng. Điều này giúp đảm bảo rằng sản phẩm hoặc dịch vụ đáp ứng được nhu cầu và kỳ vọng của khách hàng.

Để điền vào chỗ trống trong câu sau, chúng ta cần tìm từ ngữ phù hợp. Từ ngữ đó phải mô tả các sự kiện bên ngoài có thể kích hoạt hành vi trong hệ thống. Nó mô tả ranh giới phạm vi cho hệ thống bằng cách đặt tên các sự kiện kinh doanh có thể được kích hoạt bởi người dùng, các sự kiện được kích hoạt theo thời gian (temporal) hoặc các tín hiệu được nhận từ các thành phần bên ngoài, chẳng hạn như thiết bị phần cứng.