Hế lô anh em! Ai cũng biết là requirement là 1 thứ rất quan trọng. Và hầu như được quan tâm nhiều nhất trong các dự án.
Đối với BA thì requirement là một trong những yếu tố thể hiện được performance của mình. Requirement có rõ ràng hay không, có sát thực tế hay không, có đảm bảo được đúng scope hay không, bla bla…
Đối với requirement, đầu tiên thì chúng ta phải lấy nó về, hay nói thực tế là phải “moi móc, gợi mở” nó về.
Requirement sau khi được lấy về, chúng ra sẽ phải xử lý nó. Lấy như thế nào và xử lý như thế nào? Bài này mình sẽ chia sẻ về những gì mình hiểu và đã áp dụng thực tế.
Ngoài ra bài này mình cũng sẽ chém gió về cái gọi là Requirement thực sự của khách hàng. Nó tồn tại như thế nào? Và làm thế nào để nhận biết được đó có phải thật sự là requirement của khách hàng hay không?
Trạng thái và các bước xử lý requirement trong Business Analyst được thể hiện ở hình dưới đây. Toàn bộ bài viết mình sẽ dựa vào hình này.

1. Requirement trong Elicitation và Analysis
Như hình trên, requirement trong Business Analyst tồn tại ở 2 giai đoạn: giai đoạn moi móc thông tin (elicitation) và giai đoạn phân tích (analysis). Ở mỗi giai đoạn, requirement sẽ có những đặc tính riêng và có cách xử lý riêng.
1.1. Ở giai đoạn Elicitation
Giả dụ có một công ty đang gặp vấn đề. Team triển khai sẽ xuất hiện để giải quyết vấn đề của họ. Khi đó BA cần phải hiểu được họ đang gặp vấn đề gì để biết đường mà giải quyết đúng không nào.
Đương nhiên là công ty khách hàng sẽ không tuôn ra tất tần tật những vấn đề của họ. Không phải vì họ không muốn, mà là vì họ không thể.
Cụ thể hơn là vì họ chưa hệ thống hóa được hiện trạng và vấn đề của họ. Do đó, BA cần phải elicit – tức là moi móc thông tin để lấy được requirement từ họ.
Qua nhiều lần trao đổi, workshop hoặc làm việc với khách hàng, BA sẽ nắm được yêu cầu cụ thể từ phía khách hàng (lẫn các stakeholders). Để rồi từ đó, chúng ta sẽ hệ thống hóa lại và cung cấp cho khách hàng một góc nhìn tổng quan hơn về thông tin cũng như các requirements của họ.
Điều này có nghĩa là requirement ban đầu chưa được khách hàng nói ra, chưa được phát biểu ra (unstated). Sau khi BA moi móc, requirement đó mới được nói ra và phát biểu ra bởi khách hàng (stated).
Đó là mục đích của việc moi móc thông tin (elicitation). Và requirement sẽ từ trạng thái unstated chuyển sang trạng thái stated 🙂
Mình nghĩ đây là một cách nghĩ rộng và tổng quan cho mọi vấn đề. Nó kích thích câu hỏi: “Tại sao khách hàng lại muốn như vậy?”. Đây là một câu hỏi cực kỳ quan trọng. Không phải requirement nào cũng nên ôm vào. Và không phải requirement nào cũng đáp ứng được mức độ hài lòng của khách hàng.
Khi tiếp nhận một requirement, cái đầu tiên mình nên nghĩ là khách hàng họ có thực sự họ cần cái này hay không? Hay chỉ đơn thuần chỉ là… cơn mưa ngang qua thôi.
Câu chuyện requirement từ unstated sang stated là cả một quá trình. Sẽ có lý do để khách hàng nói ra yêu cầu của họ cho mình nghe. Do đó, cần phải nhận diện đúng để biết đâu mới là requirement thật sự. Và trong những requirement thực sự đó thì cái gì nên ưu tiên hàng đầu :3

1..2..3, requirement… hô biến :3
Nguồn: Modern Analyst
1.2. Ở giai đoạn Analysis
Requirement sau khi được anh em khai thác về sẽ được làm gì tiếp? Requirement sau khi thu thập về rất lộn xộn và hỗn tạp nhiều loại.
Có thể là biên bản họp. Có thể là 1 tấm hình sketch lại quy trình kinh doanh. Có thể là một vài tấm hình chụp những gì đã thống nhất trên bảng. Hoặc thậm chí có thể là file ghi âm quá trình moi móc thông tin từ phía khách hàng. Nói chung là nhiều. Rất đa dạng và thường rất hỗn độn để anh em hệ thống lại.
Do đó, quá trình phân tích – Analysis sẽ giúp BA làm chuyện này. Nói nôm na Analysis không phải là phân tích, suy luận gì ghê gớm hết. Mà đơn thuần, Analysis chỉ là đi hệ thống lại thông tin một cách phù hợp mà thôi. Cụ thể nó là chuỗi các hoạt động như cái hình lúc nãy, mà là đoạn 3, 4, 5 và 6:

Các bước xử lý requirement trong Business Analyst
(3) Organized: Sắp xếp và tổ chức lại dữ liệu một cách có cấu trúc.
Hình ra hình, file word ra file word, excel ra excel. Đoạn ghi âm cũng cần phải tài liệu hóa lại. Những phần nào là nháp thì note riêng ra. Những phần nào để chốt, quan trọng thì phải ghi nhận kỹ.
Thông tin sắp xếp theo chiều nào? Đi theo quy trình kinh doanh hay đi theo hành vi của người dùng? Bước Organized cần phải xác định rõ những điều này.
(4) Specified: Trả lời câu hỏi các dữ liệu này được xác định và phân loại dùng để làm gì, dùng như thế nào và dùng cho đối tượng nào?
Đối với end-user thì họ quan tâm cái gì? Họ liên quan đến thông tin nào, chức năng nào? Các stakeholders còn lại thì sao? Khách hàng họ quan tâm gì, cần theo dõi thông tin gì? Trả lời càng rõ ràng thì việc specify tài liệu sẽ dễ thở hơn. Sau này khi cần anh em cũng dễ lục lại.
(5) Verified: Bước này nhằm mục đích: đảm bảo các tài liệu mình hệ thống được đã ĐÚNG hay chưa.
Nhưng bước này là để verify với team nội bộ, chứ không phải khách hàng. Dữ liệu sẽ được internal team kiểm tra xem thử đã chính xác và đảm bảo đúng logic hay chưa. Ví dụ các tài liệu đặc tả đã viết đúng trình tự hay chưa? Đã thể hiện đầy đủ nội dung cần truyền tải hay chưa? Đảm bảo tất cả mọi thứ ok trước khi deliver cho khách hàng.
(6) Validated: Bước này thì lại nhằm mục đích: confirm các thông tin trao đổi với khách hàng đã chính xác, có sự ĐỒNG THUẬN giữa cả team phần mềm và phía khách hàng.
Dữ liệu sẽ được xác nhận với các stakeholder là đã đúng như yêu cầu của người ta hay chưa. Mỗi cái meeting đều cần 1 người chốt lại biên bản họp. Thường thì vô họp chém ghê lắm, mà họp xong cũng thường là quên hết bà.
Nói thêm về bước Specify, anh em BA cần phải làm tài liệu rất nhiều để gửi cho stakeholders. Mình note lại mấy điều sau nên chú ý:
- Biết Stakeholder là ai để bàn giao tài liệu cho phù hợp. Mình chỉ nói cái người khác muốn nghe. Không ai đi gửi tài liệu kỹ thuật cho end-users xem cả. Giống như không ai đưa bản vẽ thiết kế đường ống nước cho thợ điện xem hết.
- Anh em nên nắm vững ngôn ngữ của mình, đó là Modelling. Modelling vẫn là một phương thức truyền đạt thông tin vô cùng bá đạo. Nói bằng lời khó diễn tả quá thì mình vẽ ra, mô hình hóa nó lại rồi lưu lại thành tài liệu. Mai mốt bà con có ai hỏi thì có hàng mà show liền. Đỡ mắc công giải thích dài dòng, rườm rà.
2. Ví dụ phát là hiểu ra liền
Lý thuyết suông quá, ví dụ nhé anh em.
Có một cô gái mới ra trường cần mua một cái túi xách tay để đi làm.
Cô này có 300.000đ tiền để dành để mua một cái túi LV. Cô đến 1 cửa hàng chuyên bán túi thời trang nữ.
Người bán hàng hỏi cô gái: “Chị có cần em tư vấn gì không ạ?”
Cô gái trả lời: “Dạ em đang muốn mua 1 cái túi xách tay để đi làm, em có xem mấy mẫu LV trên website của mình…”.
Giả sử cô gái là khách hàng còn người bán hàng là BA (vì người bán hàng đang đóng vai trò là người giải quyết vấn đề cho cô gái).
Vậy thì vấn đề của cô gái là gì? Hay nói cách khác, requirement của cô gái là gì?
Đó là cần mua một túi xách tay đi làm đúng không nào. Ngay lúc đầu, requirement này của cô gái có được nói ra, hay được phát biểu ra không?
Không, vì chỉ có mỗi cô gái mới hiểu được nhu cầu của cô mà thôi. Khi cô bước vào tiệm bán túi, người bán hàng hỏi thì cô mới trả lời là tôi cần mua một cái túi LV. Đó là khi requirement được phát biểu ra.
Và người BA (ở đây là người bán hàng) đã hỏi cô gái để có được thông tin: à, cô này đang cần 1 cái túi đi làm và cô muốn mua túi LV. Đây đúng là requirement của cô gái, do cô phát biểu ra. Nhưng thường thì nó đâu có dễ ăn như vậy :)) Với trường hợp này thì mọi thứ không dừng lại ở đó.
Anh em nghĩ 300.000đ có thể mua được một cái túi LV không. Mình không rành túi nhưng cũng biết chắc chắn là không rồi. Hàng đểu chắc cũng trên 300.
Với 300.000đ trong tay và đang cần 1 cái túi đi làm, nhu cầu thật sự của cô gái (requirement thật sự của cô gái) là: mua một cái túi xách tay hàng Việt Nam, bền chắc và chất lượng, với mức giá tối đa là 300.000đ.
Đó mới thật sự là requirement phù hợp nhất với cô gái!
Và requirement này không chỉ đơn giản là từ unstated, hỏi một cái, chuyển thành stated là thôi. Mà người BA (hay người bán hàng) cần phải tiếp tục elicit thêm thông tin. Như hỏi thêm: túi LV ở chỗ em có 3 mức giá, 850.000đ, trên 1.550.000đ và trên 4.200.000đ. Chị muốn xem mức giá nào. Lúc này, cô gái cảm thấy không đủ ngân sách thì sẽ chuyển hướng sang một mẫu túi xách khác. Rẻ và phù hợp với mình hơn.
Elicitation không chỉ đơn thuần là lấy thông tin từ khách hàng mà còn phải khơi gợi và hướng khách hàng đi đúng hướng họ cần, gãi đúng chỗ họ ngứa. Và đó phải là hướng đi phù hợp với họ nhất trong thời điểm hiện tại. Đâu đó sẽ có thêm hàm lượng business consultant vào quá trình này nữa.

Một cái túi ít tiền hơn chắc chắn sẽ là một giải pháp phù hợp hơn với cô gái lúc này
Thực tế là nhiều khách hàng cũng không biết mình đang muốn gì. Hay trớ trêu hơn, cái thực sự họ muốn là quả táo, nhưng khi elicitation thì họ lại nói họ muốn quả chanh. Vì đơn giản, họ đang không thực sự nhận thức được là họ đang cần quả táo chứ không phải quá chanh.
Họ chưa nhận thức ngay được điều đó và BA sẽ giúp họ hệ thống lại toàn bộ mọi thứ. Khi đó, chính khách hàng sẽ tự trả lời được họ muốn gì một cách rõ ràng nhất.
Do đó, việc elicit thông tin để ra được requirement từ trạng thái unstated sang trạng thái stated là không hề đơn giản chút nào. Đòi hỏi kinh nghiệm lão luyện mấy năm trời thì làm mới êm được.
Tóm gọn, requirement trong Business Analyst sẽ có 2 trạng thái: chưa được phát biểu và đã được phát biểu.
Nhiệm vụ của người BA là phải thật cẩn thận trong việc MOI MÓC (ELICIT) thông tin. Để biến những requirement từ trạng thái chưa đươc phát biểu thành trạng thái đã được phát biểu. Requirement chính xác thì làm ra cái phần mềm mới chính xác, mới khớp với nhu cầu sử dụng của người ta. Không thì cũng banh chành.
Tiếp đến, BA cần PHÂN TÍCH (ANALYSIS) những requirement này. Ý là hệ thống, sắp xếp lại thôi.
Quy trình analysis cứ lặp đi lặp lại cho đến khi nào đã đầy đủ các loại requirement cần có trong dự án thì thôi. Bao gồm: Business Objective Requirement (cái này quan trọng), Stakeholder Requirement (cái này cũng rất quan trọng), Solution Requirement (cái này thì lại càng quan trọng) và Transition Requirement (cái này cũng quan trọng nốt).
Anh em tham khảo bài Business Analyst là gì mình có nói về 4 giai đoạn này.
Hú hú. Bài này vầy là xong. Để lại bình luận bên dưới cùng trao đổi nhé anh em!
15/09/2018 at 6:47 sáng
Tuyệt vời, có cả ví dụ dễ hiểu nữa anh ơi. Anh làm thành trang học BA online luôn đi anh, mở nhiều bài tập cho ae thực hành 😀
23/06/2019 at 3:14 chiều
Hi, Thịnh,
Mình đang học để trở thành BA. Cách giải thích của các bài giảng của Udemy khá là vòng vo và khó hiểu. Blog của Thịnh viết rất hay và văn chương ko cầu kỳ lại gần gũi.
Bạn có Skype không? Thi thoảng mình ping để chém tí gió : )
23/06/2019 at 5:06 chiều
Cảm ơn Phoebe nhé 🙂 Bạn cứ add Skype mình theo email [email protected] nhé!
15/09/2019 at 6:09 sáng
Rất dễ hiểu. ví dụ trực quan. cám ơn anh nhiều. chúc anh thành công nhé!!!
15/09/2019 at 1:17 chiều
Cảm ơn em nhé 🙂
14/09/2022 at 10:17 chiều
Cảm ơn anh về bài viết, nếu được không biết anh có thể cho em thêm 1 ví dụ về elicit được không ạ. Trong tình huống khách hàng yêu cầu là một phần mềm (APP) thì những câu hỏi nào sẽ khai thác tối đa thông tin từ khách hàng ạ.
Cảm ơn anh nhiều.
15/09/2019 at 12:13 chiều
tuyet voi….rất cám ơn anh
15/09/2019 at 11:44 sáng
Cảm ơn bạn
14/09/2020 at 6:19 sáng
Anh viết rất dễ hiểu và thú vị ạ :)))) Cảm ơn anh!!!! ^^
14/09/2020 at 3:22 sáng
Cảm ơn em 🙂
10/05/2021 at 2:32 chiều
Hi Thịnh,
Mình đã gặp blog của Thịnh khi đang quay cuồng để hiểu & làm tốt về công việc của mình.
Có rất nhiều điều mình muốn hỏi, muốn định hướng rõ ràng hơn…
Nhưng có lẽ là khi mình tích lũy nhiều hơn.
Cảm ơn Thịnh nhiều.
22/05/2021 at 12:22 chiều
Cảm ơn Thảo, có vấn đề gì cần trao đổi cứ email mình nhé 🙂
13/07/2021 at 4:24 sáng
những điều a chia sẻ rất hay và dễ hiểu. Cảm ơn a nhiều ^.^
31/08/2021 at 3:20 chiều
Cảm ơn em nhé
20/07/2021 at 8:14 chiều
Bài viết hay. Thank you!
31/08/2021 at 2:53 sáng
Thanks bạn
31/08/2021 at 4:20 sáng
bổ ích lắm ạ, tks anh !
31/08/2021 at 10:47 chiều
Cảm ơn em
07/09/2021 at 7:59 sáng
Bổ ích quá, những bài note của anh luôn đơn giản và dễ hiểu, cảm ơn anh nhiều. Chúc anh luôn mạnh khỏe và hạnh phúc ^^
14/09/2021 at 4:19 sáng
Cảm ơn em. Stay safe nhé e!
14/09/2021 at 8:43 chiều
gất bổ ích <3
17/10/2021 at 8:13 sáng
Mình đang chuyển hướng từ Technical sang BA. Các tài liệu về BA khiến mình hơi rối và chưa thấy ổn áp lắm. Blog của bạn viết khá gần gũi và dễ hiểu. Cám ơn bạn rất nhiều nhé.
05/12/2021 at 1:41 sáng
Thanks, hi vọng blog support được cho bạn 🙂
01/02/2022 at 10:37 chiều
Cảm ơn anh vì những chia se e đã đọc hết k sót chữ nào.
Trong bài em thấy a có nhắc tới “Minutes of Meeting”. Cho e hỏi là bình thường a hay gửi mail liên quan tới những giai đoạn nào trong quá trình phát triển dự án mà BA hay lm ạ?
Nếu dc mong a có bài về chia sẻ về form báo cáo ý ạ.
Em cảm ơn anhieeuf
14/02/2022 at 6:44 chiều
Hi em, cái này là biên bản họp thôi chứ k có gì phức tạp hết. Họp xong thì phải có 1 người note lại những nội dung đã trao đổi >> actions là gì >> để follow up tiếp sau đó.
Thường MM ghi dạng bảng có các cột: STT, Vấn đề, Thống nhất, PIC, Due date nếu có… Note lại theo dạng bảng vầy trực quan & dễ follow up về sau hơn. E tham khảo thêm nhé!
02/06/2022 at 11:30 chiều
Em chào anh.
Đọc BABOK đôi khi em cũng chưa hiểu rõ, nhưng khi anh giải thích thì em thấy khá thấm ạ.
Em xin phép được nhờ anh tư vấn về tiếng anh đối với BA ạ. Em rất phân vân là nếu apply vào vị trí intern tại công ty chuyên về sản phẩm công nghệ hay những cty về lĩnh vực khác nhưng có bộ phận phát triển web, app riêng ạ. Mục tiêu quá trình thực tập của em là nắm bắt quy trình cốt lõi BA ạ.
Em cảm ơn anh rất nhiều ạ.
19/07/2022 at 8:13 chiều
Bài viết rất dễ hiểu cho 1 novice. Nhưng Elicit dịch là gợi mở nghe hay hơn moi móc.
09/08/2022 at 10:23 chiều
thanks bạn
20/07/2022 at 10:22 sáng
Trong bài viết “Quy trình dự án, BA làm gì ở trỏng? (P1)”, em thấy anh có đề cập thứ tự 2 bước cuối là Validate (Do the thing right), và Verify (Do the right thing). Tuy nhiên trong bài này anh có đề cập về hai bước này như sau:
Verify = do the thing right (làm mọi việc đúng, một cách chính xác đi cái đã)
Validate = do the right thing (làm đúng việc mà khách hàng yêu cầu, đúng chức năng mà họ mong muốn).
Vậy thứ tạo nào mới đúng ạ? Mong anh giải đáp giúp em. Chúc anh một ngày tốt lành!
09/08/2022 at 10:31 chiều
Hi Phương, đoạn này a đọc lại thấy ko cần thiết nữa nên anh bỏ rồi em nhé 🙂