Ôn tập cuối kỳ SWR302 Spring 2023

Khái niệm Yêu cầu chức năng (Functional Requirement) được định nghĩa như sau: Một hoặc nhiều khả năng liên quan logic của hệ thống cung cấp giá trị cho người dùng và được mô tả bởi một bộ yêu cầu chức năng. Yêu cầu chức năng là những yêu cầu liên quan đến chức năng của hệ thống, bao gồm những gì hệ thống cần làm, những gì hệ thống cần cung cấp cho người dùng. Ví dụ, yêu cầu chức năng có thể bao gồm yêu cầu hệ thống phải có khả năng nhập liệu, xuất dữ liệu, tính toán, lưu trữ dữ liệu v.v. Yêu cầu chức năng thường được mô tả bằng các yêu cầu chức năng cụ thể, chẳng hạn như yêu cầu hệ thống phải có khả năng nhập liệu dữ liệu khách hàng, yêu cầu hệ thống phải có khả năng xuất báo cáo doanh số hàng tháng v.v.

Để điền vào chỗ trống trong câu sau, chúng ta cần tìm từ ngữ phù hợp. Câu đó 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. Trong các lựa chọn trên, "A event list" là lựa chọn phù hợp nhất. Điều này là vì danh sách sự kiện (event list) là một danh sách các sự kiện có thể xảy ra trong hệ thống, bao gồm cả các sự kiện được kích hoạt bởi người dùng, thời gian hoặc tín hiệu từ các thành phần bên ngoài.

Khi áp dụng yêu cầu tái sử dụng dựa trên quan điểm của người dùng, lợi ích chính là cải thiện sự nhất quán chức năng giữa các ứng dụng kinh doanh liên quan. Điều này có nghĩa là các ứng dụng sẽ có giao diện và chức năng tương tự nhau, giúp người dùng dễ dàng sử dụng và hiểu biết. Ngoài ra, yêu cầu tái sử dụng cũng giúp giảm thiểu sự lặp lại và cải thiện hiệu suất phát triển. Từ đó, các ứng dụng sẽ được phát triển nhanh chóng hơn và có chất lượng cao hơn.

Mô tả và phạm vi (Vision và Scope) là những khái niệm quan trọng trong quá trình phát triển sản phẩm. Mô tả (Vision) là một bức tranh tổng thể về sản phẩm mà chúng ta muốn tạo ra, trong khi phạm vi (Scope) xác định các yêu cầu và chức năng chính của sản phẩm. Các hoạt động của người ủng hộ sản phẩm (Product Champions) trong giai đoạn này nên tập trung vào việc thu thập thông tin và yêu cầu từ khách hàng và các bên liên quan. Điều này được gọi là Elicitation. Quá trình Elicitation giúp chúng ta hiểu rõ hơn về nhu cầu và mong muốn của khách hàng, từ đó có thể xây dựng một sản phẩm đáp ứng được nhu cầu của họ.

Các câu sau có đúng hay sai? Câu 1: Ở bất kỳ đâu có các hàm (function), thì đều có dữ liệu. Câu 2: Tính năng phần mềm được chỉ định để tạo, sửa đổi, hiển thị, xóa, xử lý và sử dụng dữ liệu. Câu 1 đúng vì bất kỳ chương trình nào cũng cần sử dụng dữ liệu để thực hiện các chức năng của nó. Dữ liệu có thể là các biến, mảng, đối tượng, tệp tin,... Câu 2 cũng đúng vì các chức năng phần mềm thường liên quan đến việc tạo, sửa đổi, hiển thị, xóa, xử lý và sử dụng dữ liệu. Ví dụ, một chương trình quản lý khách sạn có thể tạo mới, sửa đổi, hiển thị thông tin khách hàng, xóa thông tin khách hàng,... Tóm lại, các câu trên đều đúng.

Mô tả về cơ hội tái sử dụng yêu cầu bảo mật: Trong nhiều trường hợp, yêu cầu bảo mật và xác thực người dùng thường giống nhau trên các hệ thống khác nhau. Ví dụ, các hệ thống có thể có yêu cầu chung rằng tất cả sản phẩm phải có đăng nhập đơn giản sử dụng Active Directory cho xác thực người dùng. Điều này cho phép tái sử dụng yêu cầu bảo mật và giảm thiểu thời gian và chi phí phát triển. Ngoài ra, việc tái sử dụng yêu cầu bảo mật cũng giúp đảm bảo tính nhất quán và bảo mật trên toàn hệ thống.

Khu vực cơ hội kinh doanh trong bản mẫu tài liệu tầm nhìn và phạm vi mô tả lý do và ngữ cảnh cho sản phẩm mới hoặc thay đổi đối với sản phẩm hiện có. Nó mô tả 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. Điều này giúp xác định rõ mục tiêu và hướng đi của dự án. Trong phần này, bạn cần giải thích lý do tại sao cần xây dựng sản phẩm mới hoặc thay đổi sản phẩm hiện có, bao gồm cả tình huống dẫn đến quyết định này. Điều này sẽ giúp bạn và các thành viên trong dự án hiểu rõ hơn về mục tiêu và hướng đi của dự án.

Trong quá trình phát triển yêu cầu, bạn cần xác định vai trò của mình. 'The research specialist' là lựa chọn đúng vì nó mô tả người thực hiện nghiên cứu và thu thập thông tin để xác định nhu cầu của khách hàng. Người này sẽ tìm kiếm và phân tích dữ liệu để hiểu rõ hơn về yêu cầu của khách hàng, từ đó giúp phát triển yêu cầu chính xác và hiệu quả. Vai trò này đòi hỏi sự chuyên môn và kỹ năng nghiên cứu để thu thập và phân tích dữ liệu một cách chính xác.

Khi không có tiếp xúc với khách hàng trong quá trình phát triển phần mềm, khoảng cách mong đợi (expectation gap) thường sẽ tăng lên. Điều này là vì các nhà phát triển phần mềm không thể trực tiếp nhận được phản hồi và yêu cầu từ khách hàng, dẫn đến sự hiểu lầm về nhu cầu và mong đợi của họ. Kết quả là, phần mềm có thể không đáp ứng được nhu cầu thực sự của khách hàng, dẫn đến sự chênh lệch giữa mong đợi và thực tế. Ngoài ra, việc thiếu tiếp xúc với khách hàng cũng có thể dẫn đến sự chậm trễ trong việc nhận ra và sửa lỗi các vấn đề, khiến khoảng cách mong đợi tiếp tục tăng lên.

Quá trình lập kế hoạch dự án bao gồm các hoạt động liên quan đến việc lập kế hoạch và quản lý dự án. Trong các lựa chọn trên, có một hoạt động không thuộc về quá trình lập kế hoạch dự án. Đó là "Có các nhà phát triển xem xét các yêu cầu". Hoạt động này không phải là một phần của quá trình lập kế hoạch dự án, mà là một phần của quá trình kiểm tra và xác minh các yêu cầu. Quá trình lập kế hoạch dự án bao gồm các hoạt động như sử dụng yêu cầu để ước tính kích thước dự án, cập nhật kế hoạch khi yêu cầu thay đổi, sử dụng ưu tiên yêu cầu để điều khiển vòng lặp quá trình, v.v. Vì vậy, hoạt động "Có các nhà phát triển xem xét các yêu cầu" không thuộc về quá trình lập kế hoạch dự án.

Các yêu cầu kinh doanh mô tả tại sao tổ chức đang triển khai hệ thống, lợi ích kinh doanh mà tổ chức hy vọng đạt được. Fokus là trên các mục tiêu kinh doanh của tổ chức hoặc khách hàng yêu cầu hệ thống. Các yêu cầu kinh doanh giúp xác định được mục tiêu và lợi ích mà hệ thống cần đạt được. Nó giúp cho việc triển khai hệ thống trở nên hiệu quả hơn và đáp ứng được nhu cầu của tổ chức. Các yêu cầu kinh doanh cũng giúp cho việc đo lường hiệu suất của hệ thống trở nên dễ dàng hơn. Nó giúp cho việc đánh giá và cải thiện hệ thống trở nên hiệu quả hơn.

Trong tài liệu yêu cầu, giả định về người dùng của phần mềm được mô tả ở phần mô tả đặc điểm của người dùng. Đây là phần quan trọng để hiểu rõ về đối tượng sử dụng phần mềm, bao gồm cả đặc điểm cá nhân, kỹ năng và kinh nghiệm của họ. Thông tin này sẽ giúp các nhà phát triển tạo ra phần mềm phù hợp với nhu cầu và khả năng của người dùng, từ đó đảm bảo rằng phần mềm được sử dụng một cách hiệu quả và an toàn.

Kỹ năng của một nhà phân tích kinh doanh bao gồm nhiều yếu tố khác nhau. Trong số đó, kỹ năng điều phối (facilitation skills) giúp họ tổ chức và dẫn dắt các cuộc họp, thảo luận và các hoạt động nhóm một cách hiệu quả. Kỹ năng quan sát (observational skills) giúp họ thu thập thông tin và dữ liệu cần thiết. Kỹ năng tổ chức (organizational skills) giúp họ quản lý và sắp xếp công việc một cách khoa học. Kỹ năng lãnh đạo (leadership skills) giúp họ đưa ra quyết định và dẫn dắt nhóm. Tuy nhiên, kỹ năng lập trình và kỹ thuật (coding and technical skills) không phải là kỹ năng cần thiết cho một nhà phân tích kinh doanh. Họ có thể không cần phải lập trình hoặc có kiến thức kỹ thuật sâu rộng, nhưng họ cần phải có khả năng hiểu và làm việc với các công nghệ và hệ thống hiện có.

Tỷ lệ nhà phát triển đến phân tích kinh doanh trong dự án thông thường (default) thường được coi là 3:1. Điều này có nghĩa là một nhà phân tích kinh doanh có thể tạo ra đủ yêu cầu để giữ bảy nhà phát triển bận rộn. Tuy nhiên, tỷ lệ này có thể thay đổi tùy thuộc vào quy mô và phức tạp của dự án. Trong một số trường hợp, tỷ lệ có thể cao hơn hoặc thấp hơn 3:1. Ví dụ, trong dự án nhỏ, tỷ lệ có thể là 1:1, trong khi trong dự án lớn, tỷ lệ có thể là 6:1 hoặc thậm chí 9:1. Vì vậy, tỷ lệ 3:1 chỉ là một ước tính chung và có thể không áp dụng được cho mọi dự án.

Hoạt động thu thập yêu cầu (requirements elicitation) là bước quan trọng trong quy trình phát triển phần mềm. Để chuẩn bị cho hoạt động này, chúng ta cần thực hiện một số bước quan trọng. Trong các lựa chọn dưới đây, có một lựa chọn không thuộc về việc chuẩn bị cho hoạt động thu thập yêu cầu. Lựa chọn đó là "Prepare resource:". Điều này có nghĩa là việc chuẩn bị nguồn lực không phải là một bước quan trọng trong việc chuẩn bị cho hoạt động thu thập yêu cầu. Thay vào đó, chúng ta cần quyết định phạm vi và chương trình thu thập yêu cầu, chuẩn bị các câu hỏi và mô hình thử nghiệm, và lưu giữ các vấn đề mở.

Khái niệm yêu cầu người dùng (User Requirement) được định nghĩa là một mô 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ủ. Điều này có nghĩa là yêu cầu người dùng xác định những gì hệ thống phải làm hoặc không làm để đáp ứng nhu cầu và mong muốn của người dùng. Ví dụ, một yêu cầu người dùng có thể là hệ thống phải có khả năng lưu trữ dữ liệu một cách an toàn hoặc hệ thống phải có khả năng xử lý thông tin một cách nhanh chóng. Yêu cầu người dùng là một phần quan trọng trong quá trình phát triển hệ thống, vì nó giúp đảm bảo rằng hệ thống đáp ứng được nhu cầu và mong muốn của người dùng.

Loại phân tích dự đoán (predictive analytic) thường liên quan đến việc tạo ra các kịch bản 'nếu - thì' để so sánh dự đoán tương lai. Điều này cho phép các nhà phân tích và quản lý đưa ra quyết định sáng suốt hơn về các chiến lược kinh doanh và đầu tư. Ví dụ, một công ty có thể sử dụng phân tích dự đoán để dự đoán doanh số bán hàng trong tương lai dựa trên các yếu tố như xu hướng thị trường, giá cả và nhu cầu của khách hàng. Từ đó, họ có thể đưa ra quyết định về việc tăng hoặc giảm sản xuất, mở rộng hoặc thu hẹp các kênh phân phối, hoặc thậm chí là thay đổi chiến lược tiếp thị.

Các thuật ngữ sau có thể được sử dụng thay thế cho nhau. Dưới đây là giải thích về các thuật ngữ này và thuật ngữ tiêu chuẩn trong ngành công nghiệp.

Ví dụ về yêu cầu tương tự cho các nền tảng đa dạng là cơ hội tái sử dụng yêu cầu. Điều này xảy ra khi một ứng dụng được triển khai trên nhiều nền tảng khác nhau, chẳng hạn như Mac và Windows hoặc iOS và Android. Mặc dù có thể có một số khác biệt về yêu cầu chi tiết và/hoặc thiết kế giao diện người dùng dựa trên nền tảng, nhưng vẫn sử dụng một bộ yêu cầu cốt lõi. Điều này cho phép tái sử dụng các yêu cầu và giảm thiểu sự lặp lại trong quá trình phát triển phần mềm.

Kỹ thuật Workshop là một phương pháp thu thập yêu cầu hiệu quả trong quy trình thu thập yêu cầu. Để thực hiện một Workshop thành công, cần có một số bước quan trọng. Đầu tiên, cần lên kế hoạch một chương trình (Plan an agenda), đặt thời gian giới hạn cho các cuộc thảo luận (Time box discussions), đảm bảo có đủ số lượng thành viên tham gia nhưng chỉ bao gồm các bên liên quan quan trọng (Keep the team small but include the right stakeholders), giữ cho tất cả mọi người đều tham gia và tập trung (Keep everyone engaged), chuẩn bị các câu hỏi và mô hình giả (Prepare questions and straw man models ahead of time). Tuy nhiên, một số kỹ thuật không thuộc về phương pháp Workshop, chẳng hạn như 'Fill all of the team roles' (Điền đầy đủ các vai trò của đội ngũ), tức là cố gắng mời đủ mọi người tham gia mà không cần xem xét kỹ lưỡng về vai trò và tính cần thiết của họ.