Skip to Main Content
Module 10 · Phân tích Requirement

Làm việc với đội kỹ thuật khi phân tích Requirement

Hiểu cách BA phối hợp với Developer, Architect, Tester và DevOps để kiểm tra tính khả thi, dữ liệu, tích hợp, rủi ro kỹ thuật và giải pháp phù hợp.

9 phút đọcBeginner

Requirement Analysis không phải việc của BA một mình

BA chịu trách nhiệm làm rõ requirement, nhưng BA không nên phân tích trong một mình. Nhiều requirement cần góc nhìn kỹ thuật từ Developer, Architect, Tester, DevOps, Security hoặc Database Admin.

Làm việc sớm với đội kỹ thuật giúp BA phát hiện rủi ro, giới hạn hệ thống, phụ thuộc dữ liệu, vấn đề tích hợp và phương án triển khai phù hợp.

BA nên hỏi đội kỹ thuật điều gì?

Developer

  • Requirement này có khả thi không?
  • Cần dữ liệu hoặc rule nào rõ hơn?
  • Có cách triển khai đơn giản hơn không?

Architect

  • Requirement ảnh hưởng đến hệ thống nào?
  • Có tích hợp hoặc phụ thuộc kỹ thuật không?
  • Thiết kế có phù hợp kiến trúc tổng thể không?

Tester

  • Requirement có kiểm thử được không?
  • Cần acceptance criteria nào?
  • Có case ngoại lệ nào cần bổ sung không?

Security / DevOps

  • Có rủi ro bảo mật không?
  • Có yêu cầu về log, audit hoặc phân quyền không?
  • Có ảnh hưởng đến deployment hoặc vận hành không?

Đừng chờ đến lúc phát triển mới hỏi kỹ thuật

Nếu requirement chỉ được review bởi đội kỹ thuật sau khi đã chốt tài liệu, nhiều vấn đề có thể phát hiện quá muộn. Ví dụ, dữ liệu cần dùng không tồn tại, hệ thống tích hợp không hỗ trợ API, rule quá phức tạp hoặc yêu cầu hiệu năng không khả thi.

BA nên mời đội kỹ thuật tham gia review sớm ở mức phù hợp.

BA là cầu nối

Khi đội kỹ thuật đặt câu hỏi, BA cần chuyển câu hỏi đó thành ngôn ngữ business để xác nhận với stakeholder. Ngược lại, khi stakeholder mô tả nhu cầu, BA cần làm rõ đủ để đội kỹ thuật hiểu được điều cần xây.

Ghi nhớ

BA không cần biết mọi câu trả lời kỹ thuật, nhưng cần biết khi nào phải hỏi đội kỹ thuật và hỏi câu gì để giảm rủi ro.

Liên hệ Oracle APEX

Trong dự án Oracle APEX, BA nên trao đổi sớm với Developer về bảng dữ liệu, form, report, dynamic action, validation, authorization, email, workflow, REST API và hiệu năng. Nhiều requirement nhìn đơn giản trên giao diện nhưng có thể cần rule dữ liệu hoặc phân quyền khá rõ phía sau.

Kết luận

Làm việc tốt với đội kỹ thuật giúp Requirement Analysis thực tế hơn. Requirement không chỉ đúng về nghiệp vụ mà còn cần khả thi, kiểm thử được và phù hợp với hệ thống.