images
25/11/2020 03:35 am

Các bước phân tích yêu cầu nghiệp vụ

Ở bài trước chúng ta đã nắm được Requirement là gì và phân biệt được các loại requirement. Việc tiếp theo chúng ta cần biết được làm thế nào để tìm hiểu, moi móc, phân tích yêu cầu đó để ra được yêu cầu hoàn chỉnh rõ ràng.

Cơ bản thì quá trình này sẽ đi qua 4 bước: 

- Requirement discovery: Tìm hiểu, làm rõ yêu cầu

- Requirement classification and organization: Tổ chức, phân loại yêu cầu

- Requirement prioritization and negotiation: Thỏa thuận và Xếp thứ tự ưu tiên yêu cầu

- Requirement specification: Đặc tả yêu cầu

1. Requirement discovery 


Khi bắt đầu tiếp nhận một yêu cầu, câu hỏi lớn nhất mà ta cần giải là “Tại sao lại phải thực hiện yêu cầu này, có thực sự cần không, nếu không có nó thì có sao không?”. Từ đó mà chúng ta phải tìm cách moi móc thông tin, đặt câu hỏi cho phía khách hàng, các stakeholders để tìm được câu trả lời nhu cầu thực sự của họ là gì. 



Trên thực tế, khi tiếp xúc với khách hàng, các stakeholders, thường chúng ta sẽ được nghe họ nói về những vấn đề, những vướng mắc và rồi họ sẽ đưa ra những yêu cầu rất chung chung. Một số khác thì lại đưa ra yêu cầu rất cụ thể, chi tiết. Tuy nhiên, dù là những yêu cầu hoặc chung chung hay chi tiết, BA cần phải đi vào tìm hiểu nguyên nhân sâu xa vấn đề của họ là gì, yêu cầu họ đưa ra có phù hợp với điều kiện hay nguồn lực hiện tại của tổ chức hay không, có cần thiết không. Thậm chí, đôi khi chính khách hàng cũng chưa thực sự biết họ muốn gì, cần gì. Có thể họ yêu cầu cái này, nhưng sau khi tìm hiểu kỹ thì lại thấy thực chất cái họ cần lại là cái khác.


Khi đó, BA sẽ cần đứng ra tổ chức các buổi interviews, các cuộc họp, workshop, ngồi cùng họ để cùng tìm hiểu, moi móc (elicit) làm rõ yêu cầu. Như đã nêu trong bài Các kỹ năng cơ bản của một Business Analyst, việc chúng ta listen actively rất quan trọng trong bước tìm hiểu, làm rõ yêu cầu này. Bởi có những điều mà các khách hàng hay stakeholders không trực tiếp nói ra, nhưng qua những gì họ trình bày, BA có thể nắm được những điểm mấu chốt để hỏi sâu thêm, mở rộng vấn đề và tìm được mối liên kết giữa các vấn đề và từ đó tìm ra được yêu cầu thực sự của họ.


Ngoài ra, để khách hàng, stakeholders biết được yêu cầu của họ đã được hiểu đúng hay chưa, hoặc giúp họ hình dung hệ thống mới sẽ như thế nào, chúng ta có thể sử dụng một số kỹ thuật như mô hình hóa hệ thống, quy trình bằng các sơ đồ, hay sử dụng use cases, scenarios, prototypes… 


Tùy vào mức độ phức tạp của yêu cầu mà quá trình tìm hiểu làm rõ yêu cầu này diễn ra nhanh hay chậm. 


2. Requirement classification and organization


Như vậy chúng ta đã xong bước tìm hiểu, moi móc thông tin, dữ liệu để làm rõ yêu cầu. Sau khi đã hình dung được các yêu cầu từ phía khách hàng, stakeholders, việc tiếp theo chúng ta cần phải sắp xếp tổ chức lại và phân loại yêu cầu. 



Ở bước tìm hiểu, làm rõ yêu cầu, cái chúng ta thu thập được có kha khá thứ, có thể là tài liệu yêu cầu của khách hàng, của các stakeholders, có thể là các biên bản họp, rồi cũng có thể là các bức ảnh chụp quy trình vẽ trên bảng, trên giấy, v.v… Có quá nhiều tài liệu, và chúng ta cần phải sắp xếp, tổ chức lại chúng, gom những yêu cầu có liên quan lại với nhau, tổ chức sao cho có trật tự và logic, đúng quy trình. Điều này sẽ giúp chúng ta có được cái nhìn tổng thể về hệ thống, hay về quy trình sản phẩm để xác định được hướng thiết kế, kiến trúc hệ thống cho hợp lý.


3. Requirement prioritization and negotiation


Tại sao lại có bước thỏa thuận và xếp thứ tự ưu tiên yêu cầu? Với những yêu cầu đơn giản thì không sao, nhưng với những yêu cầu phát triển một hệ thống phức tạp, thì kiểu gì cũng phải thực hiện bước này. Bởi vì hệ thống như thế sẽ là tập hợp của hàng chục các yêu cầu lớn nhỏ, mà những yêu cầu đó không chỉ xuất phát từ một stakeholder đâu, mà có thể của rất nhiều ông stakeholders gộp lại. Chưa kể, có yêu cầu của ông này lại trái ngược với yêu cầu của ông kia, “choảng” nhau chan chát. Vậy phải làm sao để thỏa mãn tất cả các bên?



Làm hài lòng tất cả mọi người là việc cực khó, tuy nhiên, lúc đấy ông BA vẫn phải đứng ra giúp làm dịu xung đột này lại, cùng các stakeholders thỏa thuận với nhau để đi đến thống nhất các yêu cầu cốt yếu để phát triển hệ thống. Thống nhất xong rồi, chúng ta còn phải chấm điểm ưu tiên cho từng chức năng, yêu cầu, để cùng chốt xem làm yêu cầu nào trước, yêu cầu nào phải để lại làm sau.


Việc thống nhất và sắp xếp ưu tiên các yêu cầu này sẽ giúp team phát triển tập trung được vào các chức năng, các tính năng chính của hệ thống, từ đó thỏa mãn kỳ vọng của người dùng, giải quyết được những nhức nhối nhất của khách hàng, hay các stakeholders. 


4. Requirement specification


Đặc tả yêu cầu: đây là bước cuối cùng sau một loạt các bước tìm hiểu, làm rõ yêu cầu, tổ chức, sắp xếp phân loại yêu cầu và sắp xếp thứ tự ưu tiên cho từng yêu cầu. Ở bước này, chúng ta cần thực hiện mô tả yêu cầu của người dùng (user requirements), và yêu cầu của hệ thống (system requirements) một cách rõ ràng, súc tích và dễ hiểu. 


Về mô tả yêu cầu của người dùng, nội dung sẽ cần nêu bật được các yêu cầu về chức năng và các yêu cầu phi chức năng mà người dùng không có nền tảng về công nghệ cũng có thể hiểu được.



Với tài liệu yêu cầu hệ thống, thực chất nó là phiên bản mở rộng của tài liệu yêu cầu của người dùng, nhưng sử dụng ngôn ngữ kỹ thuật, dành cho đội ngũ kỹ thuật (developers) và sẽ là điểm khởi đầu cho việc thiết kế hệ thống. Các yêu cầu hệ thống bổ sung chi tiết và giải thích hệ thống sẽ đáp ứng các yêu cầu của người dùng như thế nào. Các yêu cầu hệ thống này không quan tâm đến việc hệ thống sẽ được thiết kế hay triển khai ra sao. 


Còn chúng ta hay nghe nói về tài liệu đặc tả yêu cầu (Software Requirement Specification - SRS), đây là tài liệu chính thức mô tả yêu cầu về hệ thống. Nó thường sẽ bao gồm cả yêu cầu của người dùng và yêu cầu hệ thống. 


Mời các bạn đọc thêm bài viết về Con đường trở thành Business Analyst”.

và bài Requirement là gì và phân biệt các loại requirement


- Tech Zone

Thư giãn chút nào!!!

Bài viết liên quan