images
12/11/2020 10:37 am

Requirement là gì mà các Business Analyst quay cuồng đến vậy?

Là Business Analyst, ắt hẳn các bạn đã quá quen thuộc với Requirement. Requirement chính là yếu tố căn bản, tiền đề cho bất kỳ sự thay đổi nào.

REQUIREMENT LÀ GÌ? 


Hồi mới chân ướt chân ráo bước vào nghề, thấy các anh chị BA senior hàng ngày phải xử lý một loạt các yêu cầu, yêu cầu này chưa xong, ở trên đã rót xuống yêu cầu mới, đi họp đi hành liên miên, nhìn thấy sao mà quay cuồng... nhưng cũng thấy thú vị thế. Đến giờ khi cũng quay cuồng như thế, tuy mệt nhưng vẫn thực sự thích vì công việc này quá là challenge luôn, mỗi lần tiếp nhận requirement mới là lại có thêm cơ hội được làm cái mới, có thử thách và cũng được học thêm rất nhiều thứ. Thế nên, các bạn mới làm BA hoặc nhen nhóm ý định trở thành BA, chúng ta cứ thử và bắt đầu từ những điều nho nhỏ cơ bản trước nhé.



Requirement là gì nhỉ? Là Business Analyst, ắt hẳn các bạn đã quá quen thuộc với Requirement (yêu cầu). Requirement chính là yếu tố căn bản, tiền đề cho bất kỳ sự thay đổi nào.


Theo định nghĩa trong BABOK: “Requirement is a usable representation of a need or want in a specific context”. Diễn nôm ra thì Requirement là sự diễn đạt cho một nhu cầu hay một mong muốn nào đó, có thể sử dụng được trong một hoàn cảnh cụ thể.


Trong quá trình phân tích nghiệp vụ, các yêu cầu sẽ được đào xới, tổng hợp, phân tích để từ đó có thể thiết kế, xây dựng và triển khai các giải pháp nhằm đem lại giá trị cho các stakeholder.


Ví dụ: Nay thị trường chứng khoán giảm mạnh, một loạt khách hàng vay margin giờ chạm ngưỡng phải call margin. Bình thường không sao, nhưng hôm nay số người bị call margin lên tới hơn nghìn. Bên nghiệp vụ phải huy động cả bên Dịch vụ khách hàng, Quản trị rủi ro hỗ trợ mà vẫn làm không xuể. Thế nên các đồng chí kêu giời, sang vỗ vai anh công nghệ, yêu cầu làm cho cái hệ thống, làm sao cứ có khách dính chưởng là tự động gửi tin nhắn cho anh.


Đấy chính là một yêu cầu: có truyền tải rõ nhu cầu (gửi tin nhắn tự động), trong hoàn cảnh cụ thể (chạm ngưỡng call margin).


PHÂN LOẠI REQUIREMENT 


Về cơ bản chúng ta có 4 loại requirement: Business Requirements, Stakeholder Requirements, Solution Requirements và Transition Requirements.



1. Business Requirements 


“Business requirements are high level goals or objectives that need to be satisfied through a change and typically represent the reason why a project or effort has been undertaken.”


Theo đó, Business Requirements (các yêu cầu kinh doanh) là những yêu cầu, mục tiêu ở mức high-level của khách hàng, yêu cầu này thường sẽ trả lời cho câu hỏi: Tại sao chúng ta thực hiện dự án này? 


Chúng ta thường thấy những yêu cầu như này xuất phát từ các sếp bự như CEO hay Chủ tịch công ty, ví dụ họp kế hoạch đầu năm sếp phán: Chị muốn đến cuối năm công ty sẽ tăng thị phần giao dịch phái sinh từ top 10 lên top 5. Đấy chính là 1 business requirement. 


2. Stakeholder Requirements


Stakeholder Requirements là những yêu cầu từ phía các Stakeholder. 


Thế Stakeholder là ai? Để đơn giản, có thể hiểu nôm na như này: Trong 1 tổ chức, yêu cầu có thể xuất phát từ bất kỳ phòng ban nào, đại diện của mỗi phòng ban đưa ra yêu cầu đó được gọi là 1 stakeholder. 


Yêu cầu từ phía các stakeholder được diễn đạt bằng câu: “A stakeholder in the role of ... needs to be able to …”. Ở đây, stakeholder là người sẽ đưa ra yêu cầu với tư cách là người sẽ tương tác với hệ thống. 


Để cho dễ hiểu, chúng ta sẽ đi tiếp ví dụ ở trên. Sau khi CEO chỉ thị cuối năm công ty sẽ phải lên top 5 thị phần giao dịch, tức thì áp lực lúc này sẽ được đặt lên vai các giám đốc, trong đó có Giám đốc môi giới, Giám đốc Tài chính, Giám đốc Dịch vụ khách hàng, Giám đốc Khách hàng cá nhân… Những ông này phải tự vắt óc nghĩ xem phải làm gì để đạt được mục tiêu tăng thị phần nói trên.


Đứng ở góc độ từng ông giám đốc, thì chúng ta có thể có một số stakeholder requirements khác nhau như sau:


- GĐ môi giới: Tôi muốn hệ thống hỗ trợ kho phái sinh để môi giới có thêm công cụ sale khách hàng


- GĐ Tài chính: Tôi muốn hệ thống bổ sung sản phẩm cho vay phái sinh lãi suất thấp nhất thị trường để tăng cạnh tranh và lôi kéo khách hàng giao dịch


- GĐ DVKH: Tôi muốn hệ thống có thể track được mức độ active của khách hàng để đưa ra được chính sách chăm sóc phù hợp với từng đối tượng khách hàng.


- GĐ Khách hàng cá nhân: Tôi muốn bảng giá hỗ trợ đặt lệnh để khách hàng vừa theo dõi thị trường vừa có thể đặt lệnh nhanh.


Xét trên tổng thể, Stakeholder Requirements hình thành dựa trên các Business Requirements, các yêu cầu, mục tiêu của tổ chức. Business Requirement chỉ đạt được khi Stakeholder Requirement đã đạt được.


3. Solution Requirements


Không giống với Business Requirements hay Stakeholder Requirements tập trung vào nhu cầu từ phía khách hàng, Solution Requirements (các yêu cầu về giải pháp) tập trung mô tả chi tiết các yêu cầu về giải pháp sẽ được áp dụng để đáp ứng các nhu cầu đó.  


Solution Requirements được chia làm 2 loại:

3.1. Functional Requirements: là các yêu cầu chức năng, gồm các tính năng, chức năng và các đặc tính mà một giải pháp buộc phải có để đáp ứng các yêu cầu từ phía các stakeholders. 


Với ví dụ về bảng giá đặt lệnh ở trên, yêu cầu chức năng của hệ thống có thể sẽ là:

- Có chức năng đặt lệnh trên bảng giá

- Có tính năng xác thực OTP khi đặt lệnh

- Có sổ lệnh hiển thị sau khi lệnh đã được đặt thành công

- Sổ lệnh update thông tin lệnh khi có khớp, hủy, sửa...


3.2. Non-Functional Requirements: là các yêu cầu phi chức năng, là các điều kiện giúp hệ thống chạy tốt và đảm bảo chất lượng như yêu cầu. 


Theo ví dụ trên, thì yêu cầu phi chức năng ở đây có thể là các tiêu chí:

- Tốc độ update thông tin lệnh (khớp, hủy, sửa) 

- Tốc độ đẩy lệnh vào Sở chứng khoán 

- Downtime 


4. Transition Requirements


Transition Requirements là các yêu cầu liên quan tới việc chuyển dịch từ hệ thống cũ sang hệ thống mới. Đây là các yêu cầu của khách hàng liên quan tới việc áp dụng giải pháp như thế nào cho hiệu quả khi sử dụng hệ thống mới. 


Các yêu cầu này có thể là:

- Phải tổ chức ít nhất 2 buổi đào tạo các bộ phận trong công ty để đảm bảo họ biết cách sử dụng, vận hành hệ thống

- Hỗ trợ kỹ thuật 24/7 trong vòng 3 tháng kể từ khi golive hệ thống

- Bộ phận kỹ thuật trực hỗ trợ on-site 8 tiếng trong ngày golive


Trên đây là 4 loại requirements trong phân tích yêu cầu. Thông thường chúng ta sẽ nhận được những yêu cầu rất chung chung như Business Requirements hay Stakeholder Requirements. Chúng ta thường nghe mấy requirements kiểu này sau khi các lãnh đạo đi họp về :( 


Sau dần dần chúng ta sẽ phải tìm hiểu thêm, làm rõ yêu cầu, tổng hợp, phân tích để ra được những yêu cầu giải pháp phù hợp nhất.


Mời các bạn đọc thêm bài “Các kỹ năng cơ bản của một Business Analyst”.


- Tech Zone -

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

Bài viết liên quan