Software Requirements - SWR302

Một use case là mô tả cụ thể về một trường hợp sử dụng của một hệ thống hoặc ứng dụng. Để tạo ra một use case hiệu quả, cần phải xác định các yếu tố bắt buộc. Trong đó, 'Actors' và 'Name' là hai yếu tố quan trọng.

Một yêu cầu không chức năng (non-functional requirement) là một yêu cầu không liên quan trực tiếp đến chức năng của hệ thống. Yêu cầu này thường liên quan đến các tính chất của hệ thống, chẳng hạn như hiệu suất, bảo mật, độ tin cậy, khả năng mở rộng, v.v. Trong câu hỏi này, có ba lựa chọn yêu cầu liên quan đến giao tiếp giữa client và server. Lựa chọn A và C là hai yêu cầu không chức năng vì chúng liên quan đến định dạng và mã hóa dữ liệu được truyền đi, chứ không phải là chức năng chính của hệ thống. Lựa chọn B là một yêu cầu chức năng vì nó liên quan đến khả năng của người dùng trong việc chọn số khóa học.

Trong Agile development, user stories và epics là hai khái niệm quan trọng trong việc quản lý và triển khai dự án. User stories là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, thường được viết dưới dạng 'Tôi muốn làm gì để đạt được kết quả gì'. Chúng thường được sử dụng như một điểm bắt đầu cho các cuộc thảo luận chi tiết hơn về yêu cầu của người dùng. Ví dụ, 'Tôi muốn có thể xem lại lịch sử giao dịch của mình để theo dõi các giao dịch đã thực hiện'.

Requirements engineering là quá trình thiết kế và phát triển các yêu cầu của một hệ thống hoặc sản phẩm. Quá trình này có thể được chia thành các bước khác nhau, bao gồm yêu cầu phát triển, quản lý yêu cầu, thu thập yêu cầu và xác nhận yêu cầu. Yêu cầu phát triển là quá trình xác định và mô tả các yêu cầu của hệ thống hoặc sản phẩm. Yêu cầu quản lý là quá trình theo dõi và cập nhật các yêu cầu của hệ thống hoặc sản phẩm. Thu thập yêu cầu là quá trình thu thập thông tin từ các bên liên quan để xác định các yêu cầu của hệ thống hoặc sản phẩm. Xác nhận yêu cầu là quá trình xác nhận rằng các yêu cầu đã được thu thập và mô tả chính xác. Trong câu hỏi này, hai đáp án đúng là yêu cầu phát triển và quản lý yêu cầu vì chúng là hai bước quan trọng trong quá trình requirements engineering.

Để minh họa mối quan hệ giữa các đối tượng dữ liệu, cần sử dụng các loại biểu diễn sau: Entity-relationship diagram và Class diagram.

Khi viết yêu cầu, hai mục tiêu quan trọng là đảm bảo rằng bất kỳ ai đọc yêu cầu đều có thể hiểu nó một cách tương tự và mỗi người đọc đều có thể hiểu nó theo cách mà tác giả đã dự định. Điều này có nghĩa là yêu cầu phải rõ ràng, cụ thể và không có sự hiểu lầm. Điều này giúp đảm bảo rằng các nhà phát triển hiểu đúng yêu cầu và thực hiện nó một cách chính xác. Ngoài ra, khi yêu cầu được viết một cách rõ ràng và dễ hiểu, nó giúp giảm thiểu sự hiểu lầm và tăng cường sự đồng thuận giữa các bên liên quan. Điều này đặc biệt quan trọng trong các dự án lớn hoặc phức tạp, nơi mà sự hiểu lầm có thể dẫn đến các vấn đề nghiêm trọng và tốn kém.

Một nhà phân tích kinh doanh (Business Analyst) đóng vai trò quan trọng trong quá trình phát triển sản phẩm. Họ có nhiệm vụ chính là thu thập và xác định các yêu cầu kinh doanh của doanh nghiệp. Điều này bao gồm việc phân tích các yêu cầu của khách hàng, xác định các yêu cầu chức năng và không chức năng, cũng như xác định các yêu cầu về quy trình và quy định. Ngoài ra, nhà phân tích kinh doanh còn có nhiệm vụ xác định các lớp người dùng của sản phẩm, tức là xác định các nhóm người dùng khác nhau và các yêu cầu của họ đối với sản phẩm. Điều này giúp doanh nghiệp hiểu rõ hơn về nhu cầu của khách hàng và phát triển sản phẩm phù hợp với nhu cầu của họ.

Câu hỏi này liên quan đến khái niệm tái sử dụng (reuse) trong lập trình và phát triển phần mềm. Tái sử dụng là quá trình sử dụng lại các thành phần, mô-đun hoặc mã nguồn đã được phát triển trước đó trong một dự án mới. Điều này giúp giảm thiểu thời gian và công sức cần thiết để xây dựng lại các thành phần tương tự.

Một bản mẫu phần mềm (software prototype) là một phiên bản thử nghiệm của một sản phẩm phần mềm mới. Nó thường được tạo ra để kiểm tra ý tưởng, xác định tính khả thi và thu thập phản hồi từ người dùng. Bản mẫu phần mềm có thể được tạo ra bằng nhiều phương pháp khác nhau, bao gồm thiết kế, lập trình và thử nghiệm. Nó thường không hoàn chỉnh và có thể chưa có đầy đủ các tính năng và chức năng của sản phẩm cuối cùng. Tuy nhiên, nó cung cấp một cái nhìn tổng quan về sản phẩm và giúp các nhà phát triển xác định các vấn đề và cải thiện nó trước khi tạo ra phiên bản cuối cùng. Các đặc điểm chính của một bản mẫu phần mềm bao gồm: nó là một phiên bản thử nghiệm, nó có thể được tạo ra bằng nhiều phương pháp khác nhau, nó thường không hoàn chỉnh và nó cung cấp một cái nhìn tổng quan về sản phẩm. Vì vậy, ba câu trả lời đúng về bản mẫu phần mềm là: 'It is a partial implementation of a proposed new product.', 'It is a possible implementation of a proposed new product.' và 'It is a preliminary implementation of a proposed new product.'

Một nhà phân tích kinh doanh (Business Analyst) là người chịu trách nhiệm về việc thu thập, phân tích và xác định các yêu cầu kinh doanh của một dự án hoặc một tổ chức. Họ đóng vai trò quan trọng trong việc đảm bảo rằng các dự án được thực hiện một cách hiệu quả và đáp ứng được nhu cầu của các bên liên quan. Một số nhiệm vụ chính của một nhà phân tích kinh doanh bao gồm: Định nghĩa các yêu cầu kinh doanh: Nhà phân tích kinh doanh phải xác định và định nghĩa các yêu cầu kinh doanh của một dự án hoặc một tổ chức. Họ phải hiểu rõ về các mục tiêu, hạn chế và yêu cầu của các bên liên quan. Xác định các bên liên quan và lớp người dùng: Nhà phân tích kinh doanh phải xác định các bên liên quan và lớp người dùng của một dự án hoặc một tổ chức. Họ phải hiểu rõ về các nhu cầu và yêu cầu của các bên liên quan và lớp người dùng. Đánh giá và xác định ưu tiên các yêu cầu: Nhà phân tích kinh doanh phải đánh giá và xác định ưu tiên các yêu cầu của một dự án hoặc một tổ chức. Họ phải đảm bảo rằng các yêu cầu được ưu tiên dựa trên các yếu tố như tầm quan trọng, mức độ khó khăn và hạn chế. Tuy nhiên, một số nhiệm vụ không phải là nhiệm vụ chính của một nhà phân tích kinh doanh. Ví dụ, việc dẫn dắt quá trình xác định ưu tiên yêu cầu không phải là nhiệm vụ chính của một nhà phân tích kinh doanh. Thay vào đó, họ thường sẽ tham gia vào quá trình này và cung cấp thông tin và hỗ trợ cho các bên liên quan. Vì vậy, ba nhiệm vụ chính của một nhà phân tích kinh doanh là: * Định nghĩa các yêu cầu kinh doanh * Xác định các bên liên quan và lớp người dùng * Đánh giá và xác định ưu tiên các yêu cầu Những nhiệm vụ này giúp đảm bảo rằng các dự án được thực hiện một cách hiệu quả và đáp ứng được nhu cầu của các bên liên quan.

Acceptance criteria là một phần quan trọng trong quy trình phát triển phần mềm, giúp đảm bảo rằng sản phẩm đáp ứng được yêu cầu của người dùng. Nó bao gồm các tiêu chí cụ thể để đánh giá xem sản phẩm đã đáp ứng được yêu cầu của người dùng hay chưa. Các tiêu chí này thường được xác định dựa trên các yêu cầu của người dùng và được thể hiện dưới dạng các thử nghiệm chấp nhận (acceptance tests).

Trong một dự án Agile, vai trò của một nhà phân tích kinh doanh là rất quan trọng. Họ cần định nghĩa một quy trình yêu cầu nhẹ nhàng và linh hoạt, có thể được điều chỉnh theo yêu cầu của dự án. Điều này cho phép họ tập trung vào việc xác định và ưu tiên các yêu cầu quan trọng nhất của khách hàng. Họ cũng cần giúp xác minh rằng nhu cầu của khách hàng được thể hiện chính xác trong danh sách yêu cầu (backlog). Điều này đảm bảo rằng dự án được thực hiện đúng hướng và đáp ứng được nhu cầu của khách hàng. Ngoài ra, họ cần giúp khách hàng xác định và ưu tiên các yêu cầu quan trọng nhất trong danh sách yêu cầu. Điều này giúp dự án được thực hiện một cách hiệu quả và đáp ứng được nhu cầu của khách hàng.

Một bảng điều khiển (dashboard) là một công cụ quan trọng trong việc phân tích và trình bày dữ liệu. Nó là một màn hình hiển thị hoặc báo cáo in, được thiết kế để cung cấp một cái nhìn tổng quan về tình hình của một tổ chức hoặc quy trình. Bảng điều khiển thường sử dụng nhiều biểu diễn văn bản và/hoặc đồ họa của dữ liệu, giúp người dùng dễ dàng hiểu và phân tích thông tin. Mục tiêu chính của một bảng điều khiển là cung cấp một cái nhìn tổng quan, đa chiều về tình hình của tổ chức hoặc quy trình, giúp người dùng đưa ra quyết định sáng suốt. Nó không phải là một brochure để quảng cáo sản phẩm, mà là một công cụ thực sự để hỗ trợ việc phân tích và quyết định.

Quá trình thu thập yêu cầu (requirements elicitation) là một bước quan trọng trong phát triển phần mềm. Nói một cách đơn giản, quá trình này liên quan đến việc thu thập và xác định các yêu cầu của người dùng, khách hàng hoặc các bên liên quan khác. Các tín hiệu cho thấy quá trình thu thập yêu cầu đã hoàn thành bao gồm: - Người dùng lặp lại các vấn đề họ đã thảo luận trước đó trong các cuộc thảo luận trước đó. Điều này cho thấy rằng người dùng đã được nghe và hiểu các yêu cầu hiện tại và không có gì mới thêm. - Các tính năng, yêu cầu người dùng hoặc yêu cầu chức năng được đề xuất đều được coi là nằm ngoài phạm vi. Điều này cho thấy rằng người dùng đã xác định rõ các yêu cầu và không có gì mới thêm. - Các yêu cầu đề xuất đều có mức độ ưu tiên thấp. Điều này cho thấy rằng người dùng đã xác định rõ các yêu cầu và không có gì mới thêm. - Các nhà phát triển và kiểm thử viên đánh giá các yêu cầu cho một khu vực và đặt ra nhiều câu hỏi. Điều này cho thấy rằng các yêu cầu vẫn chưa rõ ràng hoặc cần được chỉnh sửa. Trong câu hỏi này, có 3 tín hiệu cho thấy quá trình thu thập yêu cầu đã hoàn thành: người dùng lặp lại các vấn đề trước đó, các yêu cầu đề xuất đều nằm ngoài phạm vi và các yêu cầu đề xuất đều có mức độ ưu tiên thấp.

Khi tìm kiếm các quy tắc kinh doanh, có nhiều nơi và cách thức khác nhau để thực hiện. Thứ nhất, 'biết bao quát' 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 nó hoạt động. Điều này có thể bao gồm kiến thức và kinh nghiệm của nhân viên, cũng như thông tin từ các dự án trước đây. Thứ hai, các hệ thống di sản đã tích hợp các quy tắc kinh doanh vào yêu cầu và mã của chúng. Những hệ thống này có thể chứa nhiều thông tin quan trọng về quy trình kinh doanh và cách thức hoạt động của doanh nghiệp. Thứ ba, phân tích tài liệu hiện có, bao gồm các yêu cầu từ dự án trước đó, cá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. Những tài liệu này có thể cung cấp thông tin chi tiết về quy tắc kinh doanh và cách thức hoạt động của doanh nghiệp.

Việc nhãn nhãn các yêu cầu trong một tài liệu yêu cầu phần mềm (SRS) là rất quan trọng vì nó giúp chúng ta dễ dàng theo dõi, quản lý và cập nhật các yêu cầu trong suốt quá trình phát triển phần mềm. Khi nhãn nhãn các yêu cầu, chúng ta có thể dễ dàng tham chiếu đến các yêu cầu cụ thể trong các yêu cầu thay đổi, lịch sử thay đổi, liên kết hoặc ma trận theo dõi yêu cầu. Điều này giúp chúng ta theo dõi và quản lý các yêu cầu một cách hiệu quả hơn. Ngoài ra, việc nhãn nhãn các yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong các dự án khác nhau, điều này giúp tiết kiệm thời gian và công sức. Cuối cùng, việc nhãn nhãn các yêu cầu cũng giúp các thành viên trong đội ngũ thảo luận và hợp tác dễ dàng hơn khi thảo luận về các yêu cầu.

Các quyền của khách hàng trong quá trình phát triển hệ thống bao gồm việc mong đợi các nhà phân tích kinh doanh học hỏi về doanh nghiệp và mục tiêu của họ. Điều này giúp đảm bảo rằng hệ thống được phát triển phù hợp với nhu cầu và mục tiêu của khách hàng. Khách hàng cũng có quyền mô tả các tính chất sẽ giúp sản phẩm dễ sử dụng. Điều này bao gồm việc thiết kế giao diện người dùng thân thiện, dễ hiểu và dễ sử dụng. Ngoài ra, khách hàng có quyền nhận được hệ thống đáp ứng nhu cầu chức năng và kỳ vọng chất lượng của họ. Điều này bao gồm việc hệ thống đáp ứng các yêu cầu chức năng và chất lượng mong đợi của khách hàng. Tuy nhiên, khách hàng không có quyền được thông báo ngay lập tức về các thay đổi trong yêu cầu. Thay vào đó, khách hàng nên được thông báo về các thay đổi và lý do đằng sau chúng một cách rõ ràng và hợp lý.

Các entry trong từ điển dữ liệu đại diện cho các loại dữ liệu cơ bản, cấu trúc và nhóm lặp lại. Các dữ liệu cơ bản là các giá trị đơn giản như số, chuỗi, boolean, v.v. Các cấu trúc là các tập hợp các dữ liệu cơ bản được tổ chức lại theo một cách nhất định, chẳng hạn như danh sách, đối tượng, v.v. Các nhóm lặp lại là các tập hợp các dữ liệu cơ bản hoặc cấu trúc được lặp lại nhiều lần trong một dữ liệu. Các dữ liệu virtaul không tồn tại trong thực tế và thường được sử dụng trong các ứng dụng như cơ sở dữ liệu quan hệ để đại diện cho các mối quan hệ giữa các bảng.

Trong quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng trong việc định hướng và điều hướng các hoạt động khác nhau. Yêu cầu là những đặc điểm và tính năng cần có của phần mềm, được xác định bởi người dùng hoặc khách hàng. Các yêu cầu này sẽ được sử dụng để tạo ra kế hoạch dự án, thiết kế và viết mã, cũng như hoạt động kiểm thử. Yêu cầu sẽ được sử dụng để xác định các tính năng và đặc điểm cần có của phần mềm, từ đó giúp các nhà phát triển tạo ra một sản phẩm đáp ứng được nhu cầu của người dùng. Trong quá trình thiết kế và viết mã, yêu cầu sẽ được sử dụng để xác định các chức năng và tính năng cần có của phần mềm, cũng như cách thức thực hiện chúng. Trong hoạt động kiểm thử, yêu cầu sẽ được sử dụng để xác định các trường hợp kiểm thử cần thực hiện, cũng như các tiêu chí đánh giá để xác định phần mềm đã đáp ứng được yêu cầu hay chưa. Tóm lại, yêu cầu là nền tảng quan trọng trong quá trình phát triển phần mềm, giúp định hướng và điều hướng các hoạt động khác nhau để tạo ra một sản phẩm đáp ứng được nhu cầu của người dùng.

Trong các dự án Agile, một epic là một tính năng hoặc yêu cầu phức tạp mà không thể được thực hiện hoàn chỉnh trong một chu kỳ phát triển (iteration) duy nhất. Nó thường được tạo thành từ nhiều user story nhỏ hơn và có thể được chia thành các phần nhỏ hơn để dễ dàng quản lý và triển khai. Epic có thể bao gồm nhiều tính năng và yêu cầu khác nhau và có thể được thực hiện trong nhiều chu kỳ phát triển khác nhau. Điều này cho phép các đội phát triển Agile có thể tập trung vào việc triển khai các tính năng quan trọng và phức tạp một cách có hệ thống và hiệu quả.