--- title: "Vai trò của BA trong quy trình Waterfall" url: "https://bahub.vn/khoa-hoc/ba-foundation/vai-tro-cua-ba-trong-quy-trinh-waterfall" author: "Hải Đăng, Phan Minh Hoàng" published: "2026-08-14" updated: "2026-08-16" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # Vai trò của BA trong quy trình Waterfall > BA trong Waterfall làm gì ở từng giai đoạn, viết những tài liệu nào, và sống với quy trình quản lý thay đổi ra sao. - Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/vai-tro-cua-ba-trong-quy-trinh-waterfall - Tác giả: Hải Đăng, Phan Minh Hoàng - Khoá học: BA Foundation (mục lục: https://bahub.vn/khoa-hoc/ba-foundation.md) - Chương: Quy trình và môi trường làm việc Trong Scrum, BA làm rõ yêu cầu dần dần qua từng Sprint và luôn có cơ hội sửa ở vòng sau. Waterfall thì không. Ở Waterfall, phần lớn công sức của BA dồn vào giai đoạn đầu, và những gì bạn viết ra sẽ được ký duyệt rồi trở thành cơ sở cho toàn bộ phần còn lại của dự án. Sót một yêu cầu ở tháng đầu, đến tháng thứ sáu mới phát hiện, thì chi phí sửa đã khác hẳn. Bài này nói về nhịp làm việc đó: BA làm gì ở từng giai đoạn, viết gì, và sống với những ràng buộc nào. > Bài này giả định bạn đã nắm cơ bản về Waterfall. Nếu chưa, đọc bài "Giới thiệu các mô hình phát triển phần mềm: Waterfall, Agile, Scrum" trước. ![BA dồn sức vào giai đoạn thu thập và phân tích yêu cầu](https://bahub.vn/uploads/2026/08/1786810188643-oo61n4-vai-tro-cua-ba-trong-quy-trinh-waterfall-1.webp "BA dồn sức vào giai đoạn thu thập và phân tích yêu cầu") ## 1. BA làm gì ở từng giai đoạn? | Giai đoạn | Vai trò của BA | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Thu thập & Phân tích yêu cầu** | Giai đoạn của BA. Phỏng vấn, khảo sát, workshop với các bên liên quan; phân tích quy trình hiện tại; làm rõ mâu thuẫn; tài liệu hoá toàn bộ vào BRD/SRS | | **Thiết kế** | Rà soát bản thiết kế xem có bám đúng yêu cầu không; giải thích cho đội thiết kế những chỗ nghiệp vụ phức tạp; duyệt wireframe từ góc độ người dùng | | **Lập trình** | Trực chờ giải đáp. Dev gặp trường hợp chưa được mô tả thì BA đi làm rõ và cập nhật tài liệu | | **Kiểm thử** | Rà test case xem có phủ hết yêu cầu chưa; hỗ trợ UAT với người dùng thật; xác nhận sản phẩm đúng với đặc tả đã duyệt | | **Triển khai** | Viết tài liệu hướng dẫn sử dụng; đào tạo người dùng cuối; hỗ trợ giai đoạn đầu vận hành | | **Bảo trì** | Tiếp nhận yêu cầu mới, phân tích tác động, đưa vào quy trình quản lý thay đổi | Nhìn bảng này sẽ thấy một hiểu lầm phổ biến cần gạt bỏ: **BA trong Waterfall không phải "làm xong tài liệu rồi ngồi chơi".** Khối lượng công việc dồn về đầu thật, nhưng BA vẫn theo dự án tới cuối. Chỉ là tính chất công việc đổi từ _tạo ra yêu cầu_ sang _bảo vệ và giải thích yêu cầu_. ## 2. Tài liệu là sản phẩm chính Ở Waterfall, tài liệu không phải thủ tục hành chính. Nó là thứ cả dự án dựa vào, và thường là một phần của hợp đồng. Những tài liệu BA hay phải viết: * **BRD (Business Requirement Document)** — mục tiêu kinh doanh, phạm vi, các bên liên quan. Trả lời câu hỏi _vì sao làm_. * **SRS (Software Requirements Specification)** — đặc tả chi tiết cho đội kỹ thuật: yêu cầu chức năng, yêu cầu phi chức năng, quy tắc nghiệp vụ, luồng xử lý. Trả lời câu hỏi _làm cái gì, đúng là thế nào_. * **Use Case hoặc mô tả luồng nghiệp vụ** — mô tả từng bước tương tác giữa người dùng và hệ thống, gồm cả luồng chính lẫn các trường hợp ngoại lệ. * **Wireframe hoặc mockup** — hình dung màn hình để các bên liên quan duyệt trước khi code. Điểm mấu chốt trong Waterfall: **những tài liệu này được ký duyệt.** Chữ ký đó biến chúng thành mốc tham chiếu. Sau này khi có tranh cãi "cái này đã thống nhất chưa", câu trả lời nằm trong tài liệu chứ không nằm ở trí nhớ của ai. Vì vậy, ba tiêu chí của một tài liệu tốt trong Waterfall là: **đầy đủ** (không sót trường hợp), **rõ ràng** (mỗi câu chỉ hiểu được một cách), và **không mâu thuẫn** (mục 3.2 không nói ngược mục 5.7). ![Ma trận truy vết yêu cầu nối yêu cầu với thiết kế và kiểm thử](https://bahub.vn/uploads/2026/08/1786810229970-b05x0g-vai-tro-cua-ba-trong-quy-trinh-waterfall-2.webp "Ma trận truy vết yêu cầu nối yêu cầu với thiết kế và kiểm thử") ## 3. Truy vết yêu cầu Khi dự án có hàng trăm yêu cầu và kéo dài nhiều tháng, câu hỏi "yêu cầu này đã được thiết kế chưa, đã code chưa, đã test chưa" trở nên rất khó trả lời bằng trí nhớ. Công cụ cho việc này là **ma trận truy vết yêu cầu (Requirements Traceability Matrix — RTM)**: một bảng nối từng yêu cầu với hạng mục thiết kế, đoạn code và test case tương ứng. | Mã YC | Yêu cầu | Tài liệu thiết kế | Test case | Trạng thái | | ------ | ------------------------------------------ | ----------------- | -------------- | ----------- | | FR-012 | Tìm nhân viên theo mã số | DD-04, mục 2.3 | TC-045, TC-046 | Đã kiểm thử | | FR-013 | Ẩn nhân viên đã nghỉ khỏi kết quả tìm kiếm | DD-04, mục 2.4 | TC-047 | Đang code | Nghe có vẻ nặng nề, nhưng nó giải quyết đúng nỗi đau của Waterfall: phát hiện sót ở giai đoạn cuối. Một yêu cầu không có test case tương ứng là một yêu cầu chưa ai kiểm tra. ## 4. Sống chung với quy trình quản lý thay đổi Yêu cầu vẫn sẽ đổi, kể cả trong Waterfall. Khác biệt là ở chỗ đổi phải đi qua một cửa chính thức: **Change Request (CR)**. Một CR thường đi qua các bước: 1. **Ghi nhận** — ai đề xuất, đổi cái gì, vì sao. 2. **Phân tích tác động** — phần việc chính của BA. Thay đổi này ảnh hưởng tới những yêu cầu nào khác, những màn hình nào, dữ liệu đang có xử lý ra sao? Tốn thêm bao nhiêu công? 3. **Ra quyết định** — thường là một hội đồng hoặc cấp quản lý dự án duyệt hay từ chối, cân nhắc chi phí và tiến độ. 4. **Cập nhật tài liệu** — nếu duyệt, mọi tài liệu liên quan phải được sửa và ký lại. Nếu bỏ qua bước này, tài liệu và sản phẩm sẽ lệch nhau, và nửa năm sau không ai biết đâu là bản đúng. Phần **phân tích tác động** là nơi một BA giỏi tạo ra khác biệt rõ nhất. Người mới thường chỉ nhìn thấy thay đổi trực tiếp; người có kinh nghiệm nhìn ra những chỗ bị kéo theo — báo cáo nào đang đếm theo trường dữ liệu sắp đổi, hệ thống nào đang nhận dữ liệu qua API, người dùng nào cần đào tạo lại. ## 5. Ví dụ Công ty trúng thầu dự án Hệ thống Quản lý Hồ sơ Nhân viên cho một cơ quan nhà nước. Đặc tả nằm trong hồ sơ mời thầu, chi tiết và không được đổi trong quá trình thực hiện hợp đồng. **Giai đoạn đầu** — phần lớn công sức phân tích dồn vào đây: BA đọc kỹ hồ sơ thầu, đối chiếu với quy định hiện hành về quản lý hồ sơ cán bộ, tổ chức các buổi làm việc với phòng tổ chức cán bộ để làm rõ những chỗ hồ sơ viết chung chung. Ví dụ hồ sơ ghi "quản lý quá trình công tác" — BA phải hỏi cho ra: gồm những trường thông tin nào, ai được sửa, có cần lưu lịch sử thay đổi không, xuất báo cáo theo mẫu nào. Toàn bộ được tài liệu hoá vào SRS theo đúng quy chuẩn của bên A, rồi trình phê duyệt chính thức. **Chỉ sau khi có chữ ký, thiết kế và lập trình mới bắt đầu.** **Ba tháng sau** — bên A muốn thêm chức năng ký số vào quyết định điều động. Yêu cầu này không có trong hồ sơ thầu. BA lập CR, phân tích tác động: cần tích hợp với hệ thống chữ ký số của đơn vị, ảnh hưởng tới luồng phê duyệt hiện tại, cần thêm khoảng sáu tuần và một hạng mục hợp đồng bổ sung. Hội đồng dự án cân nhắc rồi quyết định tách thành giai đoạn 2. Đây là kết cục rất bình thường trong Waterfall — và cũng cho thấy vì sao việc làm rõ yêu cầu ở giai đoạn đầu lại quan trọng đến vậy. ## 6. Những cạm bẫy fresher BA hay mắc * **Chép lại lời khách hàng thay vì phân tích.** Khách nói "cần báo cáo tổng hợp" mà bạn ghi đúng như vậy vào SRS thì đến lúc code, dev sẽ hỏi lại từ đầu — và lúc đó khách đã bận việc khác. * **Viết yêu cầu hiểu được nhiều cách.** "Hệ thống phải phản hồi nhanh" là một câu vô nghĩa trong SRS. Bao nhiêu giây, với bao nhiêu người dùng đồng thời? * **Bỏ qua yêu cầu phi chức năng.** Hiệu năng, bảo mật, phân quyền, sao lưu, khả năng chịu tải. Những thứ này ít khi được khách hàng nói ra, nhưng thiếu là nghiệm thu không qua. * **Không cập nhật tài liệu sau khi có CR.** Tài liệu lệch sản phẩm là mầm mống của tranh cãi ở giai đoạn nghiệm thu. * **Ngại hỏi vì sợ lộ ra mình chưa hiểu.** Trong Waterfall, một câu hỏi không dám hỏi ở tháng đầu có thể thành một CR tốn sáu tuần ở tháng thứ sáu. * **Nghĩ rằng hết giai đoạn phân tích là hết việc.** Dev và tester sẽ tìm bạn suốt dự án. ## 7. Kỹ năng cần mạnh, khác với Agile Cùng là BA, nhưng hai môi trường đòi hỏi trọng tâm khác nhau: | ​ | Waterfall cần mạnh | Agile/Scrum cần mạnh | | ----------------------- | ------------------------------------------------------ | ------------------------------------------ | | **Viết** | Rất mạnh — tài liệu là sản phẩm được ký duyệt | Vừa đủ — User Story ngắn gọn, rõ tiêu chí | | **Khai thác yêu cầu** | Đào sâu một lần cho hết, vì ít có cơ hội quay lại | Đào dần theo từng Sprint | | **Tư duy hệ thống** | Rất mạnh — phải nhìn ra tác động chéo khi phân tích CR | Cần, nhưng phạm vi mỗi lần nhỏ hơn | | **Giao tiếp trực tiếp** | Cần, nhưng nhịp thưa hơn | Rất mạnh — trao đổi hằng ngày với đội | | **Chịu được mơ hồ** | Thấp — mục tiêu là loại bỏ mơ hồ từ đầu | Cao — chấp nhận chưa rõ hết rồi làm rõ dần | Không môi trường nào dễ hơn môi trường nào. Waterfall đòi hỏi bạn kỹ lưỡng và có kỷ luật với tài liệu. Agile đòi hỏi bạn chủ động và chịu được sự chưa chắc chắn. ## Tóm lại BA trong Waterfall là người **đặt nền móng**. Bạn dồn sức ở giai đoạn đầu để dựng một bản đặc tả đầy đủ, rõ ràng, không mâu thuẫn — rồi theo nó tới cuối dự án để bảo vệ, giải thích và cập nhật khi có thay đổi được duyệt. Cái giá của Waterfall là phát hiện sai muộn. Cách phòng thủ tốt nhất của BA là hỏi cho hết ở giai đoạn đầu, và viết ra sao cho mỗi câu chỉ hiểu được một cách. --- Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/vai-tro-cua-ba-trong-quy-trinh-waterfall — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.