Software Requirements - SWR302

External quality attributes là những tính chất của một hệ thống hoặc sản phẩm mà không phụ thuộc vào nội dung hoặc chức năng của nó. Chúng thường liên quan đến cách hệ thống hoặc sản phẩm được sử dụng, bảo trì và sửa chữa. Các ví dụ về external quality attributes bao gồm Availability, Integrity và Safety. Availability ám chỉ khả năng hệ thống hoặc sản phẩm luôn sẵn sàng sử dụng, Integrity ám chỉ tính toàn vẹn của dữ liệu và Safety ám chỉ khả năng hệ thống hoặc sản phẩm không gây hại cho người sử dụng. Reusability, mặt khác, ám chỉ khả năng hệ thống hoặc sản phẩm có thể được sử dụng lại trong nhiều tình huống khác nhau, điều này không phải là một external quality attribute mà là một internal quality attribute. Do đó, Reusability không phải là một external quality attribute.

Khi ưu tiên yêu cầu, một trong những lợi ích chính là tập trung vào các tính năng có giá trị cao hơn. Điều này có nghĩa là các nhà phát triển và quản lý dự án có thể tập trung vào các tính năng quan trọng nhất, những tính năng có thể mang lại giá trị lớn nhất cho người dùng và doanh nghiệp. Bằng cách ưu tiên yêu cầu, các dự án có thể tránh được sự lan tràn (scope creep) và tập trung vào việc hoàn thành các tính năng quan trọng nhất. Điều này cũng giúp cải thiện quản lý dự án, vì các nhà phát triển và quản lý dự án có thể theo dõi tiến độ dự án và đảm bảo rằng các tính năng quan trọng nhất được hoàn thành trước. Ngoài ra, ưu tiên yêu cầu cũng giúp giảm thiểu sự tham gia của các bên liên quan (stakeholder), vì các bên liên quan có thể tập trung vào các tính năng quan trọng nhất và giảm thiểu sự tham gia không cần thiết. Tuy nhiên, ưu tiên yêu cầu không phải là một lợi ích tuyệt đối, và các dự án cần phải cân nhắc các yếu tố khác như thời gian, ngân sách và nguồn lực khi quyết định ưu tiên yêu cầu.

Software Requirements Specification (SRS) là một tài liệu quan trọng trong quy trình phát triển phần mềm, mô tả các yêu cầu chức năng và không chức năng của hệ thống. SRS thường bao gồm các phần sau: Quality Attributes, External interface, Data requirements, System features. Tuy nhiên, Design features không phải là một phần của SRS template. Design features thường được mô tả trong tài liệu thiết kế phần mềm, nơi mô tả các chi tiết về kiến trúc và cấu trúc của hệ thống. Trong khi đó, SRS tập trung vào việc mô tả các yêu cầu của hệ thống, bao gồm cả các yêu cầu chức năng và không chức năng. Vì vậy, Design features không phải là một phần của SRS template.

Quá trình đánh giá một sản phẩm dự án để xác định xem nó có đáp ứng được nhu cầu của khách hàng hay không được gọi là Verification. Đây là quá trình kiểm tra xem sản phẩm dự án có đáp ứng được các yêu cầu kỹ thuật và chức năng như đã được định nghĩa trong tài liệu yêu cầu hay không. Validation là quá trình xác định xem sản phẩm dự án có đáp ứng được nhu cầu của khách hàng hay không, dựa trên các yêu cầu và kỳ vọng của họ. Checklist là một công cụ giúp xác định xem sản phẩm dự án có đáp ứng được các yêu cầu kỹ thuật và chức năng hay không, nhưng nó không phải là quá trình đánh giá chính thức. Testing là quá trình kiểm tra xem sản phẩm dự án có hoạt động đúng như mong đợi hay không, dựa trên các kịch bản thử nghiệm được thiết kế.

Quá trình phát triển yêu cầu là một phần quan trọng của quy trình phát triển phần mềm. Nó bao gồm các bước sau: Elicitation (xác định yêu cầu), Analysis ( phân tích yêu cầu), Validation (kiểm tra tính hợp lệ của yêu cầu) và Documentation (độcument yêu cầu). Design là một bước trong quy trình phát triển phần mềm, nhưng nó không phải là một bước trong quá trình phát triển yêu cầu. Design liên quan đến việc tạo ra một bản thiết kế chi tiết cho phần mềm, trong khi yêu cầu phát triển liên quan đến việc xác định và xác minh các yêu cầu của khách hàng. Vì vậy, Design không phải là một bước trong quá trình phát triển yêu cầu.

Evolutionary prototype là một loại prototyping trong đó người dùng tạo ra một mẫu ban đầu để làm rõ yêu cầu của người dùng, sau đó xây dựng và thêm các tính năng mới vào mẫu nàyIncremental, và cuối cùng là phát hành sản phẩm cuối cùng dựa trên nó. Quá trình này liên tục và có thể được lặp lại nhiều lần cho đến khi sản phẩm cuối cùng được phát hành. Evolutionary prototype cho phép người dùng thử nghiệm và đánh giá sản phẩm trong suốt quá trình phát triển, giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng được yêu cầu và mong muốn của người dùng.

Khi một yêu cầu không được hiểu rõ hoặc quyết định, vấn đề xảy ra là do sự không chắc chắn về yêu cầu. Điều này có thể dẫn đến sự không thống nhất trong việc thực hiện yêu cầu, gây ra sự khó khăn trong việc xác định các yêu cầu chính xác. Trong kỹ thuật lập trình, yêu cầu thường được xác định trước khi bắt đầu phát triển phần mềm. Tuy nhiên, trong quá trình phát triển, có thể có những yêu cầu không được hiểu rõ hoặc quyết định, dẫn đến sự không chắc chắn về yêu cầu. Điều này có thể gây ra sự khó khăn trong việc xác định các yêu cầu chính xác và dẫn đến sự không thống nhất trong việc thực hiện yêu cầu. Vì vậy, việc xác định rõ ràng và quyết định các yêu cầu là rất quan trọng để tránh sự không chắc chắn về yêu cầu.

Functional Requirements là loại yêu cầu tốt nhất để mô tả hành vi và thông tin mà giải pháp sẽ quản lý, bao gồm các chức năng và tính năng của hệ thống. Chúng thường được mô tả bằng cách xác định các yêu cầu chức năng cụ thể, chẳng hạn như 'Hệ thống phải cho phép người dùng đăng ký tài khoản' hoặc 'Hệ thống phải hiển thị thông tin sản phẩm chi tiết'. Functional Requirements thường được sử dụng để mô tả yêu cầu của người dùng cuối và được sử dụng để xác định các yêu cầu kỹ thuật của hệ thống. Chúng thường được viết bằng ngôn ngữ tự nhiên và được sử dụng để mô tả các yêu cầu cụ thể của hệ thống.

Walkthrough approach là một phương pháp đánh giá yêu cầu liên quan đến việc tác giả mô tả một sản phẩm và yêu cầu ý kiến từ các thành viên khác. Trong quá trình này, tác giả sẽ trình bày chi tiết về sản phẩm, bao gồm cả chức năng, yêu cầu kỹ thuật và các hạn chế. Sau đó, các thành viên khác sẽ có cơ hội để đặt câu hỏi, đưa ra ý kiến và đề xuất cải thiện. Phương pháp này cho phép tác giả nhận được phản hồi kịp thời và có thể điều chỉnh sản phẩm theo yêu cầu của nhóm. Walkthrough approach thường được sử dụng trong các dự án yêu cầu sự tham gia của nhiều thành viên và cần sự đồng thuận cao.

Một mock-up và một prototype thường được sử dụng đồng nghĩa, nhưng chúng có một số khác biệt quan trọng. Một mock-up thường được sử dụng để mô tả một ý tưởng hoặc một thiết kế, trong khi một prototype thường được sử dụng để tạo ra một phiên bản thực tế của một sản phẩm hoặc một dịch vụ. Một proof of concept, mặt khác, là một phiên bản đơn giản của một sản phẩm hoặc một dịch vụ để kiểm tra tính khả thi của nó. Nó không phải là một phiên bản hoàn chỉnh, nhưng nó có thể giúp xác định xem ý tưởng có tiềm năng hay không. Vì vậy, một proof of concept không phải là một prototype, mà là một bước tiền đề để tạo ra một prototype.

Khi yêu cầu thu thập thông tin (requirements elicitation), khách hàng cho biết 'Lưu $X mỗi năm về điện năng bây giờ bị lãng phí bởi các thiết bị không hiệu quả'. Là một nhà phân tích, yêu cầu này thuộc loại yêu cầu nào?

Một tập hợp định nghĩa cho các phần tử dữ liệu và cấu trúc dữ liệu liên quan đến miền vấn đề. Trong lập trình và thiết kế hệ thống, một data dictionary là một tài liệu quan trọng giúp xác định và mô tả các phần tử dữ liệu và cấu trúc dữ liệu được sử dụng trong hệ thống. Nó cung cấp thông tin chi tiết về các phần tử dữ liệu, bao gồm định nghĩa, loại dữ liệu, quy tắc xác định và các mối quan hệ giữa các phần tử dữ liệu. Data dictionary giúp đảm bảo tính nhất quán và chính xác của dữ liệu trong hệ thống, đồng thời giúp các nhà phát triển và người sử dụng hệ thống hiểu rõ về cấu trúc dữ liệu và cách sử dụng nó. Nó cũng giúp giảm thiểu sai sót và lỗi trong quá trình thiết kế và triển khai hệ thống.

Một mô hình phân tích quá trình thể hiện dòng chảy quá trình từ một hoạt động sang hoạt động khác. Trong lĩnh vực phân tích quy trình kinh doanh, mô hình này được sử dụng để thể hiện các hoạt động và dòng chảy dữ liệu giữa chúng. Nó giúp các chuyên gia phân tích hiểu rõ hơn về quy trình kinh doanh và xác định các điểm cần cải thiện. Mô hình này thường được sử dụng trong các dự án cải tiến quy trình kinh doanh và quản lý dự án.

Một mô hình phân tích mà thể hiện các trạng thái khác nhau trong đó một hệ thống hoặc một đối tượng trong hệ thống có thể tồn tại, cũng như các chuyển đổi được phép giữa các trạng thái. Mô hình này giúp xác định các trạng thái hiện tại và tương lai của hệ thống, cũng như các quy tắc chuyển đổi giữa chúng. Nó thường được sử dụng trong thiết kế và phát triển hệ thống để đảm bảo rằng hệ thống hoạt động một cách chính xác và hiệu quả.

Trong Agile và Scrum, Product Owner là người đại diện cho một lớp người dùng cụ thể, chịu trách nhiệm cung cấp yêu cầu của người dùng cho nhóm mà họ đại diện. Họ là người có trách nhiệm chính trong việc xác định và ưu tiên các yêu cầu của người dùng, đảm bảo rằng các yêu cầu này được thực hiện một cách hiệu quả và đáp ứng được nhu cầu của người dùng. Product Owner cũng chịu trách nhiệm trong việc duy trì và cập nhật Product Backlog, một danh sách các yêu cầu và tính năng cần được thực hiện trong dự án. Họ phải có khả năng giao tiếp tốt, hiểu rõ về nhu cầu của người dùng và có thể giải thích rõ ràng về các yêu cầu và tính năng của dự án.

Trong ngữ cảnh kinh doanh, khách hàng (customers) là một phần quan trọng của doanh nghiệp. Họ là những người mua hàng hóa hoặc dịch vụ từ công ty. Trong thuật toán và học thuật, khách hàng có thể được coi là một phần của tập hợp khách hàng (customer set) hoặc một phần của tập hợp mục tiêu (target market). Trong trường hợp này, khách hàng được coi là một phần của tập hợp khách hàng, vì họ là những người có nhu cầu và khả năng mua hàng hóa hoặc dịch vụ từ công ty. Do đó, khách hàng là một phần của tập hợp khách hàng, hoặc một phần của tập hợp con (subset) của tập hợp khách hàng.

Câu hỏi trắc nghiệm này liên quan đến việc phân loại một lead (khách hàng tiềm năng) dựa trên hành vi của họ. Cụ thể, nếu một lead không phản hồi lại sau 30 ngày kể từ khi liên hệ lần đầu tiên, thì nó được coi là một lead lạnh (cold lead) và có thể được đánh dấu như vậy. Điều này là một ví dụ về quy tắc kinh doanh (business rule) được gọi là 'Inferences'. Inferences là quy tắc kinh doanh mà dựa trên dữ liệu và kinh nghiệm để đưa ra kết luận hoặc quyết định. Trong trường hợp này, quy tắc kinh doanh là: 'Nếu một lead không phản hồi lại sau 30 ngày, thì nó phải là một lead lạnh'.

Câu hỏi trắc nghiệm này liên quan đến phân tích yêu cầu hệ thống. Yêu cầu 'Tất cả màn hình trong hệ thống phải tải nhanh chóng' ban đầu có vẻ rõ ràng, nhưng khi phân tích kỹ lưỡng, nó lại không rõ ràng và không thể kiểm tra được. Điều này là vì thuật ngữ 'nhanh chóng' không được định nghĩa cụ thể, có thể có nhiều cách hiểu khác nhau về tốc độ tải màn hình. Ngoài ra, yêu cầu này không thể kiểm tra được vì không có tiêu chí cụ thể nào để đánh giá xem màn hình đã tải nhanh hay chưa. Do đó, đáp án đúng là 'Ambiguous and Non-Testable', tức là yêu cầu này không rõ ràng và không thể kiểm tra được.

Định nghĩa tầm nhìn và phạm vi, chọn người ủng hộ sản phẩm hoạt động nên được thực hiện ở giai đoạn thu thập yêu cầu. Ở giai đoạn này, người phát triển sản phẩm sẽ tham gia vào các hoạt động thu thập yêu cầu từ khách hàng, người dùng và các bên liên quan khác. Mục tiêu của giai đoạn này là xác định rõ yêu cầu và mục tiêu của sản phẩm, cũng như xác định các hạn chế và thách thức mà sản phẩm cần phải giải quyết. Người phát triển sản phẩm sẽ thu thập thông tin từ các nguồn khác nhau, bao gồm cuộc phỏng vấn, khảo sát, phân tích dữ liệu và quan sát. Sau khi thu thập thông tin, người phát triển sản phẩm sẽ phân tích và xác định các yêu cầu và mục tiêu chính của sản phẩm. Điều này sẽ giúp người phát triển sản phẩm tạo ra một bản thiết kế sản phẩm chính xác và đáp ứng được nhu cầu của khách hàng.

Một data model là một bản đồ hoặc mô hình hóa dữ liệu của hệ thống, bao gồm các đối tượng dữ liệu và các tập hợp dữ liệu mà hệ thống sẽ xử lý cũng như mối quan hệ giữa chúng. Nó cung cấp một cách nhìn tổng quan về cấu trúc dữ liệu và cách dữ liệu được tổ chức và liên kết. Data model thường được sử dụng trong thiết kế cơ sở dữ liệu và phát triển phần mềm để đảm bảo rằng dữ liệu được quản lý và xử lý một cách hiệu quả và chính xác. Nó giúp các nhà phát triển hiểu rõ về dữ liệu và cách dữ liệu được sử dụng trong hệ thống, từ đó có thể tạo ra các ứng dụng và hệ thống thông tin tốt hơn.