Tạo data dictionary và quy tắc kiểm tra dữ liệu bằng AI
Hướng dẫn dùng AI để chuẩn hóa ghi chú họp, user story và quy trình thành data dictionary cùng quy tắc kiểm tra dữ liệu, phục vụ review và viết acceptance criteria trên Jira hoặc Confluence.
Một buổi refinement thường kết thúc bằng những câu như: “Mã khách hàng phải hợp lệ”, “Số tiền không được âm”, “Khách mới cần kiểm tra thêm”.
Ai cũng hiểu đại ý. Nhưng khi BA viết user story, dev sẽ hỏi “hợp lệ là thế nào?”, QA hỏi “kiểm tra ở bước nào?”, còn đội dữ liệu cần biết trường nào là nguồn chuẩn.
Vấn đề không hẳn là thiếu yêu cầu. Vấn đề là yêu cầu nằm rải rác trong biên bản họp, ticket cũ, sơ đồ quy trình và trí nhớ của từng người.
AI có thể hỗ trợ BA và PO gom các mảnh này thành data dictionary — từ điển dữ liệu — kèm quy tắc kiểm tra rõ ràng hơn để review, đưa vào Jira hoặc lưu trên Confluence. Mục tiêu không phải để AI thiết kế dữ liệu thay đội kỹ thuật, mà là biến mô tả nghiệp vụ thành đầu vào có cấu trúc và dễ truy vết.
Data dictionary giúp gì cho backlog?
Data dictionary là một kho thông tin tập trung về dữ liệu. Theo cách hiểu phổ biến, nó có thể mô tả ý nghĩa, quan hệ với dữ liệu khác, nguồn gốc, cách sử dụng và định dạng của từng thành phần dữ liệu.
Ở mức BA thường cần, mỗi dòng trong data dictionary có thể mô tả một trường dữ liệu với các nội dung như:
Tên trường: tên nghiệp vụ và, nếu đã có, tên kỹ thuật.
Ý nghĩa: trường biểu thị điều gì.
Kiểu hoặc định dạng: chữ, số, ngày hoặc tập giá trị được phép.
Tính bắt buộc: có cần nhập không, và trong điều kiện nào.
Nguồn dữ liệu: người dùng nhập, hệ thống tự sinh hoặc nhận từ hệ thống khác.
Quy tắc kiểm tra: điều kiện dữ liệu cần thỏa.
Quan hệ/phụ thuộc: trường liên quan hoặc tham chiếu tới dữ liệu nào.
Data dictionary cũng có thể tồn tại dưới hai dạng:
Thụ động: được cập nhật thủ công, độc lập với thay đổi trong cấu trúc cơ sở dữ liệu.
Chủ động: gắn với hệ quản trị cơ sở dữ liệu; việc cập nhật dictionary có thể dẫn tới thay đổi tự động trong cơ sở dữ liệu.
Với BA và PO, bản thụ động có thể là điểm tham chiếu chung giữa nghiệp vụ, phát triển và kiểm thử. Bạn không cần chờ thiết kế database hoàn chỉnh mới bắt đầu: ngay khi requirement xuất hiện, đã có thể chuẩn hóa thuật ngữ và quy tắc dữ liệu.
Quy trình: từ ghi chú họp đến bảng dữ liệu
AI hữu ích nhất ở bước trích xuất và chuẩn hóa. AI không nên tự quyết định chính sách nghiệp vụ.
Một quy trình đơn giản:
Gom đầu vào: ghi chú họp, user story, acceptance criteria, biểu mẫu hiện tại hoặc mô tả quy trình.
Khoanh phạm vi: nêu rõ chức năng, vai trò người dùng và thời điểm xử lý dữ liệu.
Yêu cầu AI tạo bản nháp dictionary theo cấu trúc cố định.
Review với SME, dev và QA.
Lưu kết quả tại nơi nhóm cùng sử dụng, chẳng hạn một trang Confluence, rồi liên kết với Epic, story và ticket kiểm thử.
Cập nhật khi thay đổi: mọi thay đổi về quy tắc nên có lịch sử quyết định rõ ràng.
Dùng prompt sau để chuyển requirement tự do thành bảng chuẩn hóa:
text
Bạn là Business Analyst hỗ trợ chuẩn hóa yêu cầu dữ liệu.
Bối cảnh nghiệp vụ: <bối cảnh>
Chức năng: <tên chức năng>
Nguồn yêu cầu:
<dán ghi chú họp, user story, acceptance criteria hoặc mô tả quy trình>
Hãy tạo data dictionary ở dạng bảng Markdown với các cột:
Tên trường nghiệp vụ
Tên kỹ thuật đề xuất
Mô tả nghiệp vụ
Nguồn dữ liệu
Kiểu/định dạng cần xác nhận
Bắt buộc/có điều kiện
Giá trị hoặc trạng thái hợp lệ
Quan hệ/phụ thuộc
Quy tắc kiểm tra
Điểm còn mơ hồ hoặc cần SME xác nhận
Nguyên tắc:
Không tự tạo chính sách nghiệp vụ.
Phân biệt rõ nội dung được nêu trong yêu cầu và nội dung cần xác nhận.
Nếu yêu cầu mâu thuẫn, nêu mâu thuẫn thay vì tự chọn cách hiểu.
Viết bằng ngôn ngữ phù hợp để dán vào tài liệu dự án.
Điểm quan trọng không phải là yêu cầu AI “viết thật đầy đủ”, mà là buộc đầu ra có cột cần xác nhận. Cột này giúp nhóm nhìn thấy khoảng trống trong requirement thay vì để AI lấp bằng suy đoán.
Ví dụ: mở hồ sơ khách hàng
Giả sử ghi chú nghiệp vụ có nội dung:
> Nhân viên tạo hồ sơ khách hàng. Cần có mã khách hàng, họ tên và ngày sinh. Khách hàng dưới độ tuổi theo chính sách thì không tự hoàn tất đăng ký. Mã khách hàng không được trùng. Khi chọn loại khách hàng doanh nghiệp thì cần mã số thuế.
Một bản nháp hợp lý không nên tự đoán ngưỡng tuổi hoặc cấu trúc mã số thuế:
| Tên trường nghiệp vụ | Bắt buộc/có điều kiện | Quy tắc kiểm tra | Điểm cần xác nhận |
|---|---|---|---|
| Mã khách hàng | Bắt buộc | Không được trùng với hồ sơ khách hàng đã tồn tại | Mã do người dùng nhập hay hệ thống tự sinh? |
| Họ tên | Bắt buộc | Chưa có quy tắc chi tiết trong yêu cầu | Có giới hạn ký tự hoặc quy ước chuẩn hóa tên không? |
| Ngày sinh | Bắt buộc | Dùng để xác định khách hàng có được tự hoàn tất đăng ký hay không | Ngưỡng độ tuổi và luồng xử lý khi chưa đạt ngưỡng |
| Loại khách hàng | Bắt buộc | Nếu chọn doanh nghiệp thì yêu cầu mã số thuế | Danh sách giá trị hợp lệ là gì? |
| Mã số thuế | Bắt buộc có điều kiện | Bắt buộc khi loại khách hàng là doanh nghiệp | Quy tắc định dạng và kiểm tra trùng đã được xác định chưa? |
Các ô “cần xác nhận” chính là agenda tốt cho buổi làm việc với SME. Chúng cụ thể hơn nhiều so với câu hỏi chung chung: “Anh/chị còn yêu cầu gì thêm không?”
Chuyển quy tắc kiểm tra thành acceptance criteria
Dictionary mô tả dữ liệu, nhưng dev và QA còn cần biết hệ thống xử lý thế nào khi dữ liệu thiếu, sai hoặc mâu thuẫn.
Bạn có thể dùng AI để chuyển từng quy tắc thành acceptance criteria theo cấu trúc Given–When–Then:
Given: bối cảnh.
When: hành động hoặc sự kiện kích hoạt kiểm tra.
Then: kết quả hệ thống cần đạt.
text
Dựa trên data dictionary dưới đây:
<dán bảng data dictionary>
Hãy tạo acceptance criteria cho Jira theo Given–When–Then.
Với mỗi quy tắc:
Nêu điều kiện áp dụng.
Nêu thao tác hoặc sự kiện kích hoạt kiểm tra.
Nêu kết quả hệ thống cần xử lý.
Chỉ dùng thông tin có trong data dictionary.
Nếu chưa có nội dung thông báo lỗi hoặc hành vi xử lý, ghi “cần xác nhận”, không tự tạo.
Sau đó tạo mục “Câu hỏi mở cho refinement” gồm các điểm mơ hồ,
mâu thuẫn hoặc thiếu quy tắc kiểm tra.
Với trường “mã số thuế”, một acceptance criterion có thể là:
text
Given nhân viên đang tạo hồ sơ khách hàng
And loại khách hàng là doanh nghiệp
When nhân viên để trống mã số thuế và gửi hồ sơ
Then hệ thống không cho hoàn tất thao tác
And nội dung thông báo cần xác nhận với nghiệp vụ
AI không nên tự đặt thông báo lỗi, tự suy ra định dạng hay khẳng định có tích hợp với nguồn dữ liệu bên ngoài nếu requirement chưa nêu.
Review đầu ra AI: tìm thiếu, mơ hồ và mâu thuẫn
Trước khi đưa nội dung vào Jira hoặc Confluence, BA nên kiểm tra nhanh:
Có thiếu trường nào không? Đối chiếu với biểu mẫu, quy trình và các bước nhập liệu.
Mỗi trường có một nghĩa duy nhất không? Ví dụ, “ngày hiệu lực” có thể là ngày bắt đầu hợp đồng, ngày kích hoạt hoặc ngày cập nhật.
Quy tắc có đo được không? Các từ như “hợp lệ”, “đầy đủ”, “bình thường” cần được định nghĩa.
Điều kiện có đủ không? Cụm “bắt buộc khi...” phải chỉ rõ khi nào.
Có mâu thuẫn giữa story và quy trình không? Chẳng hạn một tài liệu cho phép lưu nháp, tài liệu khác lại yêu cầu chặn thao tác.
Nguồn dữ liệu đã rõ chưa? Người dùng nhập, hệ thống sinh hay nhận từ dịch vụ khác là những trách nhiệm khác nhau.
Quan hệ dữ liệu đã rõ chưa? Ví dụ, loại khách hàng quyết định việc mã số thuế có bắt buộc hay không.
Bạn cũng có thể dùng AI để phản biện chính bản nháp vừa tạo:
text
Hãy đóng vai trò người review BA và QA.
Kiểm tra data dictionary cùng acceptance criteria dưới đây:
<dán nội dung>
Chỉ ra theo các nhóm:
thiếu yêu cầu
thuật ngữ mơ hồ
quy tắc mâu thuẫn
điều kiện chưa đầy đủ
giả định không có căn cứ
Với mỗi điểm, nêu một câu hỏi ngắn để BA hỏi SME.
Không tự đề xuất chính sách mới.
AI hữu ích như một người phản biện bản nháp. Tuy nhiên, quyết định cuối cùng về chính sách, ngoại lệ và mức chấp nhận rủi ro vẫn thuộc về PO, SME và đội triển khai.
Duy trì data dictionary như một tài liệu sống
Không đưa dữ liệu khách hàng, số định danh, thông tin giao dịch, bí mật kinh doanh hoặc nội dung hợp đồng chưa được phép vào công cụ AI công khai. Thay vào đó, dùng placeholder như <mã khách hàng> hoặc <số tiền>, và sử dụng môi trường AI đã được tổ chức phê duyệt nếu có.
Hãy coi data dictionary là tài liệu sống:
Gán người chịu trách nhiệm cập nhật.
Liên kết với Epic, story và tài liệu liên quan.
Đánh dấu rõ các mục “cần xác nhận”.
Cập nhật dictionary, acceptance criteria và test case khi quy tắc thay đổi.
Checklist trước khi chuyển ticket sang trạng thái sẵn sàng:
[ ] Trường dữ liệu có định nghĩa nghiệp vụ rõ ràng.
[ ] Điều kiện bắt buộc được nêu theo đúng ngữ cảnh.
[ ] Quy tắc kiểm tra có thể chuyển thành acceptance criteria.
[ ] Các giả định đã được đánh dấu để SME xác nhận.
[ ] Jira, Confluence và test case không dùng các định nghĩa mâu thuẫn.
[ ] Prompt không chứa dữ liệu nhạy cảm chưa được phép sử dụng.
Một data dictionary tốt không làm backlog dài hơn vô ích. Nó giúp cả nhóm ngừng tranh luận về nghĩa của từ ngữ và tập trung vào những quyết định nghiệp vụ cần chốt.