Hello anh em. Lần này mình sẽ note về các loại requirement mà anh em sẽ gặp trong suốt chặng hành trình của một BA chuyên nghiệp
Lét xờ gâu anh em eiii!
Nội dung [Hide]
Đầu tiên mình sẽ lật ngược lại BABOK để xem Requirement được định nghĩa như thế nào.
Requirement is a usable representation of a need
BABOK v3.0
Usable tức là khả năng dùng được cho một mục đích nào đó.
Representation nghĩa là sự mô tả, sự diễn đạt.
Còn Need đơn giản là nhu cầu.
Nôm na, Requirement là sự diễn đạt cho một nhu cầu nào đó, nhưng sự diễn đạt này phải rõ ràng nhé anh em, để còn được sử dụng cho nhiều mục đích sau đó, như để làm document, cho các stakeholders đọc hiểu chẳng hạn.
Thực tế là không phải anh em nào trong team nào cũng hiểu rõ bản chất của chữ “Requirement”. Nhiều góc nhìn khác nhau là tốt, nhưng khi teamwork mà không cùng nhìn chung một hướng thì dễ tèo lắm.
…
Tuy nhiên, đó cũng chỉ là lý thuyết để anh em BA nắm một cách chính xác.
Thực tế thì hầu như 96,69% những gì mà khách hàng nói đều chính là Requirement. Và đều thể hiện được một “usable representation of a need” như mình nói ở trên.
Ví dụ,
Ông CEO đi workshop bên châu Âu, thấy nhà máy người ta áp dụng IoT thứ dữ quá, ghê quá, hiệu quả quá. Về mới họp ban điều hành lại và nói rằng:
“Ô kê, tui muốn triển khai IoT cho nhà máy chúng ta, nó sẽ cắt giảm 40% chi phí nhân công và tăng 25% hiệu suất quản lý, anh em thấy thế nào”.
Một câu phát biểu rất đại khái, chung chung như vầy chính là requirement. Vì đơn giản nhu cầu của ổng đã rõ ràng, là muốn cắt giảm phí nhân công, tăng hiệu suất, với sự diễn đạt là muốn áp dụng IoT vào hoạt động của nhà máy.
Từ yêu cầu trên của CEO, ông Giám Đốc Mua Hàng mới bắt đầu liên hệ công ty Bosch để yêu cầu về giải pháp IoT.
Khi gặp team Bosch, ông Giám Đốc Mua Hàng mới phát biểu:
“Nè nha, tụi tui muốn triển khai IoT, mà phải xong trong vòng 2 năm rưỡi, ưu tiên trước mắt là Smart Metering và Asset Management, các module khác để sau cũng được…”
So với câu phát biểu của anh CEO thì câu này của anh Procurement Director có vẻ chi tiết hơn chút xíu.
Ảnh diễn đạt rõ ảnh cần gì trước, cần gì sau, cho một mục đích cụ thể nào đó (có thể là để đạt target của công ty trong vòng 5 năm tới…).
Dựa vào đó, yêu cầu cứ được dưa dần xuống các bộ phận trực tiếp làm việc, a usable representation of a need cứ thế sẽ được phát biểu rõ ràng và chi tiết hơn nữa.
Ví dụ các yêu cầu sẽ chi tiết đến mức như:
.
.
.
Anh em thấy những ví dụ trên đều là những requirement, nhưng với cấp độ chi tiết khác nhau.
Nếu cùng gom nó lại và để chung vô một document thì sẽ rất… rối vô đối. Vì những requirement này có thể sẽ overlap lên nhau, khó theo dõi được cho cả BA lẫn khách hàng.
Do đó, IIBA mới chia nồi lẩu thập cẩm requirements ra thành 4 loại để anh em dễ quản lý. 4 loại đó được chia theo vòng tròn công việc của BA như sau.
Business Requirement là những yêu cầu rất high-level từ phía khách hàng.
High-level nghĩa là nó rất TỔNG QUÁT, và thể hiện được mục tiêu của tổ chức. Một số dấu hiệu nhận biết đó là Business Requirement:
Đó là nói theo kiểu bình dân – dễ hiểu. Còn nói theo kiểu pho mồ như BABOK thì Business Requirement nghĩa là:
Business Requirement is statements of goals, objectives, and outcomes that describe why a change has been initiated.
They can apply to the whole of an enterprise, a business area, or a specific initiative.
BABOK v3.0
Một số ví dụ về Business Requirement để anh em dễ hình dung:
Cái tên cũng khá rõ ràng, Stakeholder Requirement là những yêu cầu cụ thể của từng đối tượng Stakeholder. Những yêu cầu này phải thể hiện được cái need – nhu cầu cụ thể của các Stakeholder.
Anh em hãy chú ý đến các SME – Subject Matter Expert, đặc biệt là các Domain SME.
Vì các stakeholder này họ sẽ đưa ra requirement là những thứ, mà họ sẽ tương tác với hệ thống, dựa trên vai trò cụ thể của họ trong tổ chức.
Ví dụ anh em làm hệ thống quản lý nội bộ cho một công ty du lịch cỡ bự như Expedia đi chẳng hạn. Những Domain SME có thể anh em cần chú ý là Giám đốc chăm sóc khách hàng, Giám đốc nhân sự, Trưởng bộ phận điều phối tour…
Từ đó, chúng ta có một số ví dụ cho Stakeholder Requirement:
BABOK định nghĩa Stakeholder Requirement như sau:
Stakeholder requirements describe the needs of stakeholders that must be met in order to achieve the business requirements.
BABOK v3.0
Business Requirement và Stakeholder Requirement phải rất ăn rơ và bổ trợ cho nhau. Theo nguyên tắc: Business Requirement chỉ đạt được khi Stakeholder Requirement đã đạt được.
Ví dụ Business Requirement là “tăng 10% tỉ lệ khách quay lại mua hàng”, thì Sales Team phải:
Đó rõ ràng là các Stakeholder Requirements của Domain SME là Sales Team.
Nếu chúng ta không đạt được những yêu cầu này, thì rất khó, hoặc hầu như là không thể để đạt được Business Requirement [tăng 10% tỉ lệ khách quay lại mua hàng]. Vì rõ ràng Sales Team chẳng có thông tin gì bám víu vào để ra các quyết định giúp tăng 10% tỉ lệ khách quay lại mua hàng cả.
Sau khi nắm được Business Requirement và Stakeholder Requirement, anh em sẽ đi tới bước nắm chi tiết được từng Solution Requirement.
Solution Requirement là những yêu cầu về khả năng và tiêu chuẩn mà giải pháp phải có để đạt được Business Requirement và Stakholder Requirement ở trên.
Chính xác thì các requirement này nó dây mơ rễ má, ăn nhậu và bỗ trợ cho nhau rất nhiều.
BABOK định nghĩa Solution Requirement như sau:
Solution requirements describe the capabilities and qualities of a solution that meets the stakeholder requirements
BABOK v3.0
Solution Requirement là thứ được mô tả chi tiết, kỹ càng hơn bất kỳ các loại requirement nào khác có trong dự án. Và hơn hết, nó được chia làm 2 loại rõ rệt: một nói về capability và một nói về quality.
Functional Requirement là thứ nói về capability, tức là những thứ mà hệ thống làm được, nôm na là như vậy.
BABOK v3.0 định nghĩa như sau: Functional Requirements describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage.
Mình có highlight 2 từ khóa quan trọng ở dòng trên là Behavior và Information.
Behavior tức là hành vi của hệ thống, những gì hệ thống có thể làm được.
Ví dụ:
Còn Information tức là dữ liệu của hệ thống, những gì hệ thống có thể lưu trữ được.
Ví dụ:
Chúng ta đã biết được Functional Requirement, biết được hệ thống có thể làm gì, và biết được 50% Solution Requirement.
50% còn lại chính là nằm ở Non-Functional Requirement (NFR)
Tin mình đi, sẽ có không ít những anh em BA dễ dàng bỏ qua các NFR – một thứ quan trọng không kém Functional Requirement bên trên. Đặc biệt là đối với những anh em làm Outsource hay Service, như mình hehe.
Anh em đọc thêm bài dưới đây mình có note về Non-Functional Requirements nhé.
Một ví dụ về NFR (Nguồn ảnh: CartoonStock.com)
Transition nghĩa là chuyển đổi, chuyển dịch từ một cái gì đó cũ sang một cái gì đó mới.
Transition Requirement là toàn bộ những yêu cầu của khách hàng liên quan tới việc áp dụng giải pháp vào tổ chức như thế nào cho hiệu quả. Tức là những yêu cầu liên quan tới việc chuyển đổi tổ chức từ trạng thái cũ, sang trạng thái mới.
Nguy hiểm hơn, anh em có thể nói là quá trình chuyển đổi từ As-is state thành To-be state, chuyển đổi từ lúc tổ chức chưa áp dụng hệ thống sang áp dụng hệ thống, hoặc từ lúc áp dụng hệ thống cũ sang lúc áp dụng hệ thống mới…
BABOK định nghĩa Transition Requirement như sau:
Transition requirements describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete.
BABOK v3.0
Facilitate có nghĩa là làm cho đơn giản, làm cho dễ dàng.
Facilitate, một từ rất quan trọng với anh em BA (nguồn ảnh: Cambridge Dicitonary)
Đây là một từ khóa cực kỳ quan trọng với BA, với mình nó giống như một kim chỉ nam để làm việc vậy. Càng làm thì mọi thứ phải càng đơn giản, chứ càng làm mà càng phức tạp hơn thì có vẻ công việc mình làm không hiệu quả cho lắm.
Còn cụm “but which are not needed once the change is complete” nghĩa là BABOK muốn nhấn mạnh: transition requirement chỉ quan trọng trong lúc triển khai, lúc đưa giải pháp vào sử dụng thực tế. Còn khi áp dụng xong xuôi, mọi thứ chạy êm ru rồi thì mớ transition requirement này không còn quan trọng nữa.
Một số ví dụ về Transition Requirement từ phía khách hàng cho anh em dễ hình dung:
Hi vọng qua note này anh em sẽ hình dung rõ hơn về requirement, cũng như các loại của nó.
Đây là 4 loại requirement. Theo trình tự thì thường đầu dự án anh em sẽ nhận được các yêu cầu rất sơ khởi như Business Requirement hoặc một vài Stakeholder Requirement.
Theo thời gian, anh em sẽ bắt đầu moi móc, cùng làm với team, với khách hàng để ra được những Solution Requirement sát sườn nhất, phù hợp với cả 2 bên. Khi đó mình mới có cái nhìn rõ ràng nhất về những thứ cần phải làm.
Còn Transition Requirement có thể có hoặc không. Vì thường nó sẽ được xem là “additional requirement” trong dự án.
Để hiểu rõ hơn về requirement, anh em có thể đọc thêm các notes về:
Bái baiii, hẹn gặp anh em ở các bài notes khác về requirement trong tương lai. Anh em cùng chờ nhé
See yaaaa!!!
st: https://thinhnotes.com/chuyen-nghe-ba/so-luoc-ve-requirement/
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
