4 loại requirement quan trọng mà business analyst thường hay làm việc.

4 loại requirement quan trọng mà business analyst thường hay làm việc.

Hi các bạn

Mình lại quay lại với chủ đề Business Analyst. Hầu hết khi đọc các yêu cầu tuyển dụng BA thì nhiều nội dung liên quan requirement. Có thể nói công việc người BA sẽ xoay quanh khá nhiều liên quan đến việc khơi gợi, phân tích, quản lý yêu cầu.

Một JD tuyển dụng Business Analyst

Sự quan trọng của requirement?

Như ở bài viết trước về vai trò của Business Analyst. BA là người sẽ tìm hiểu nhu cầu của tổ chức, phân tích hiện trạng, xác định mục tiêu và đưa ra giải pháp giúp tổ chức thay đổi theo hướng tích cực.

Giải pháp đó có thể ở tầm chiến lược (strategic), chiến thuật (Initiatives) hoặc hoạt động (Operational). Một trong những giải pháp BA và doanh nghiệp thường đưa ra đó chính là phần mềm. Về bản chất một phần mềm nào đó được phát triển là để giải quyết một bài toán nào đó của doanh nghiệp.

Ví dụ app Grab chúng ta thường sử dụng có tính năng đặt đồ ăn nhanh. Trước đây tính năng này không có, nhưng sau khi nhà hàng, quán ăn phát triển nhiều lên, nhu cầu của khách hàng có thể đặt đồ ăn online mà không cần đến trực tiếp. Grab food ra đời để giải quyết bài toán business đó từ phía doanh nghiệp và người dùng.

Có thể nói việc phần mềm được phát triển có giải quyết được bài toán của doanh nghiệp hay không sẽ phụ thuộc rất nhiều vào yêu cầu đầu vào, tức là requirement. Requirement rõ ràng, chi tiết và quan trọng nhất là mô tả đúng cái mà doanh nghiệp đang cần sẽ là tiền đề để đội phát triển phần mềm đưa ra giải pháp phù hợp. Nếu đầu vào sai thì khúc sau có vô cùng tai hại. Phần mềm có thể sử dụng được nhưng nó không giải quyết vấn đề của tổ chức đang gặp phải thì cũng coi là thất bại. Tức sản phẩm bạn làm ra mà không có ai dùng.

Vì vậy vai trò của người BA, vai trò của yêu cầu là rất quan trọng. Đầu vào mà tốt sẽ tạo nhiều điều kiện để sản phẩm đầu ra tốt. BA cần nắm rõ yêu cầu là gì và có bao nhiêu loại để có thể làm việc tốt với các stakeholder khác nhau.

Requirement là gì?

Sẽ có nhiều định nghĩa khác nhau nhưng ở đây mình sẽ lấy định nghĩa của IIBA trong tài liệu hướng dẫn của Babok v3 như sau:

A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled.”

Mình dịch nôm na thế này: Một yêu cầu là một đại diện khả dụng của một nhu cầu người dùng. Yêu cầu tập trung vào việc hiểu giá trị mà yêu cầu đó mang lại sau khi được đáp ứng.

Có 4 loại requirement Business Analyst cần biết?

4 loại requirement

Business requirement

Đây là yêu cầu ở tầng cao nhất, phổ quát nhất. Business requirement sẽ mô tả về yêu cầu ở tầng business, đưa ra lí do cần sự thay đổi. Business requirement có thể áp dụng ở tầng chiến lược của toàn bộ tổ chức và doanh nghiệp. Đây là cơ sở cốt lõi nhất phát triển các tầng yêu cầu tiếp theo.

Ví dụ về một Business requirement: Ở bài viết trước về Business analyst là gì mình có nói đến ví dụ về tình hình kinh doanh của một chuỗi trà sữa. Trong mùa dịch nên không có khách hàng thường xuyên, kinh doanh thua lỗ.

ông CEO đặt ra yêu cầu như sau: Giải pháp chuyển từ bán hàng offline tại các của hàng thành bán hàng online qua hệ thống web, app và bên thứ 3 trong quý 2/2020. Cắt giảm cửa hàng offline để giảm chi phí vận hành và mặt bằng.

Đây là một ví dụ về Business requirement. Yêu cầu này mang tính chiến lược kinh doanh, các giải pháp đưa ra phải dõi theo yêu cầu này. Đáp ứng tốt yêu cầu này. Tức là kim chỉ nam cho việc phát triển các loại yêu cầu phía sau. Là một người BA thực sự, bạn cần tìm hiểu và đặt câu hỏi why? Tại sao lại cần sự thay đổi này? tại sao lại cần yêu cầu này? Stakeholder requirement

Stakeholder requirement

Stakeholder requirement tức là yêu cầu của các bên liên quan. Ở bài tổng quan về Business Analyst mình có nói trước khi bắt đầu một dự án BA bắt buộc phải liệt kê hết tất cả những bên liên quan đến dự án. Vì khi có đủ các bên liên quan rồi thì bạn mới có yêu cầu của họ được.

Stakeholder requirement mô tả nhu cầu của các bên liên quan phải được đáp ứng để đạt được các yêu cầu kinh doanh (Business requirement). Đây có thể được cho là cầu nối giữa yêu cầu kinh doanh và yêu cầu mặt giải pháp.

Ví dụ: Bên liên quan rất quan trọng đối với một product đó chính là khách hàng. Có thể nói ông này là ông quyết định mang tính sống còn của sản phẩm.

Bạn có thể khảo sát khách hàng là các nhân viên trong công ty, các người quen để biết yêu cầu của họ khi muốn đặt trà sửa online là gì? Kĩ thuật card sorting sẽ nói nhiều đến đoạn này.

Ví dụ họ yêu cầu dưới dạng user story: Là người mua trà sữa tôi muốn chọn trực tiếp được loại trà sữa với mức độ ngọt khác nhau.

Căn cứ vào user story trên chúng ta sẽ có cơ sở thêm về yêu cầu chức năng của hệ thống.

Solution requirement

Solution requirement miêu tả chức năng và phẩm chất cần có của hệ thống. Nó sẽ có 2 mục quan trọng chính mà bạn cần phải đề cập đến đó là functional requirement và non-funtionrequirement. Tức là yêu cầu chức năng và yêu cầu phi chức năng.

Mình sẽ chia sẻ về 2 loại yêu cầu này trong một bài viết tới. Solution requirement sẽ cung cấp những thông tin chi tiết nhất để đội phát triển sản phẩm triển khai giải pháp.

  • Funtional requirement: Tức là yêu cầu về mặt chức năng của hệ thống. Tức là hệ thống làm được gì.
  • Non-Funtional requirement: Yêu cầu phi chức năng, là những yêu cầu mang lại giá trị tăng thêm cho hệ thống. Ví dụ như hiệu suất, bảo mật, tính dễ dùng.

Ví dụ:

Funtional: Khách hàng có thể đăng ký tài khoản trực tiếp bằng tài khoản facebook.

Non-funtional: Tốc độ load của website: trasua.onlie là 3 giây khi lượng người dùng truy cập tối đa l00 thiết bị cùng lúc ở đường truyền mạng ổn định.

4 loại requirement quan trọng

Transition requirement

Yêu cầu chuyển đổi mô tả các khả năng mà giải pháp phải có và các điều kiện mà giải pháp phải đáp ứng để tạo điều kiện chuyển đổi từ trạng thái hiện tại sang trạng thái tương lai. Sự khác biệt của yêu cầu này đó là mang tính tạm thời.

Ví dụ: Khi hệ thống website chuyển từ v1 sang một v2 hệ thống mới thì sẽ xuất hiện các yêu cầu như: Giao diện tạm thời sẽ xuất hiện như thế nào? Rồi dữ liệu chuyển đổi từ hệ thống v1 sang v2 như thế nào, điểm tích lũy của thành viên cũ có được tính sang hệ thống mới v2 không…?

Tóm lại: Business analyst cần nắm vững 4 loại yêu cầu trên. Việc nắm vững các loại yêu cầu giúp BA có thể phân tích và đưa ra giải pháp từ tổng quan đến chi tiết. Giúp BA giao tiếp tốt hơn với các bên liên quan khác nhau để mang lại giải pháp hiệu quả.


Note: Trích bài viết vui lòng để nguồn: www.blaoman.com/

Facebook Comments

Cảm ơn bạn đã ghé thăm website Blaoman. Đây là nơi mình chia sẽ những trải nghiệm trong cuộc sống và công việc IT BA đang làm, phát triển product trong lĩnh vực công nghệ. Một chút về lối sống tối giản, sách, kinh doanh và phát triển bản thân. Mình bắt đầu với Blaoman với mục tiêu giúp mình tốt hơn mỗi ngày. Và biết đâu đó những chia sẻ này cũng giúp ích đến những bạn đã tình cờ ghé thăm blog của mình! Cảm ơn các bạn đã theo dõi bài viết.

Leave a reply

Your email address will not be published. Required fields are marked *

×
error: Content is protected !!