·

Tiếng Việt: Data Modeling System Analysis

Data Modeling System Analysis

Một BA vừa nhận task: công ty fintech muốn thêm tính năng "chuyển tiền liên ngân hàng qua VietQR" vào app ví điện tử đang có 2 triệu người dùng. Trước khi viết một dòng requirement nào, BA phải trả lời được ba câu hỏi nền tảng: dữ liệu sẽ chảy qua những đâu (data flow diagram), các thực thể dữ liệu liên quan tới nhau ra sao (entity-relationship diagram), và hệ thống ví điện tử này đang kết nối với những hệ thống bên ngoài nào (system context diagram). Đây là công việc BA vẫn làm hàng ngày, nhưng theo cách truyền thống nó tốn 2-3 ngày ngồi đọc tài liệu cũ, hỏi từng dev một hệ thống con, rồi tự tay vẽ lại trong Visio hay draw.io — và bản vẽ đó thường lỗi thời ngay khi vừa xong vì scope lại đổi. AI không thay BA hiểu nghiệp vụ, nhưng nó rút ngắn đáng kể phần "dịch" từ mô tả rời rạc thành sơ đồ có cấu trúc, và quan trọng hơn, nó giúp BA đọc nhanh hàng trăm trang tài liệu hệ thống cũ (legacy system — hệ thống đang vận hành, thường thiếu tài liệu cập nhật) để tìm ra gap và integration point mà mắt người dễ bỏ sót khi đọc lướt.

Bài này đi từ việc dùng AI sinh ba loại sơ đồ nền tảng của system analysis, qua cách khai thác AI để đọc tài liệu hệ thống cũ và xác định integration point (điểm tích hợp), đến cách tạo báo cáo gap analysis (phân tích khoảng cách) so sánh as-is và to-be, và cuối cùng là bước quan trọng nhất mà nhiều BA hay bỏ lỡ: chuyển toàn bộ phân tích đó thành requirement cụ thể, có thể test được, để dev và QA thực sự dùng được.

Sinh Data Flow Diagram, Entity-Relationship Model, Và System Context Diagram Với AI

Ba loại sơ đồ này phục vụ ba câu hỏi khác nhau và không thể thay thế cho nhau. Data flow diagram (DFD — sơ đồ luồng dữ liệu) trả lời câu hỏi "dữ liệu di chuyển qua những bước nào, qua những process nào, từ nguồn tới đích". Entity-relationship diagram (ERD — mô hình quan hệ thực thể) trả lời câu hỏi "dữ liệu được cấu trúc thế nào, thực thể nào liên quan tới thực thể nào, quan hệ 1-1, 1-n hay n-n". System context diagram (sơ đồ ngữ cảnh hệ thống) trả lời câu hỏi ở tầm cao hơn: hệ thống đang phân tích là một hộp đen, xung quanh nó là những hệ thống/actor nào, và luồng thông tin trao đổi ở biên là gì. Một BA giỏi cần cả ba, vì thiếu một loại sẽ để lại một góc mù: chỉ có ERD mà không có DFD thì biết cấu trúc dữ liệu nhưng không biết dữ liệu đi qua quy trình nào; chỉ có DFD mà không có system context diagram thì dễ quên mất một bên thứ ba quan trọng đang tương tác với hệ thống.

Cách làm truyền thống — mở draw.io hoặc Lucidchart, kéo thả từng hộp, từng mũi tên — chậm không phải vì công cụ khó dùng, mà vì phần tốn thời gian thực sự là tư duy: đọc hiểu mô tả nghiệp vụ, xác định đúng thực thể, đúng luồng, đúng ranh giới hệ thống. Đây chính là chỗ AI giúp được nhiều nhất. Thay vì vẽ tay từ đầu, BA có thể mô tả nghiệp vụ bằng ngôn ngữ tự nhiên, để AI sinh ra sơ đồ dưới dạng cú pháp văn bản (Mermaid, PlantUML, hoặc DBML cho riêng ERD), rồi paste thẳng vào công cụ render như Mermaid Live Editor, dbdiagram.io, hoặc draw.io (draw.io hỗ trợ import Mermaid trực tiếp) để có bản vẽ trực quan trong vài giây. Điểm mạnh của cách này không chỉ là tốc độ mà còn là khả năng sửa cực nhanh: khi scope đổi, bạn không cần vẽ lại tay, chỉ cần sửa vài dòng text và render lại.

Ví dụ cụ thể: với tính năng chuyển tiền liên ngân hàng qua VietQR, ERD cần các thực thể như wallet (ví), transaction (giao dịch), linked_bank_account (tài khoản ngân hàng liên kết), qr_code_request (yêu cầu tạo mã QR); DFD cần thể hiện luồng: người dùng quét QR → app ví gọi service tạo lệnh chuyển tiền → service gọi cổng thanh toán liên ngân hàng (ví dụ Napas) → cổng gọi core banking của ngân hàng nhận → phản hồi trạng thái ngược về app; system context diagram cần thể hiện app ví là trung tâm, xung quanh là core banking nội bộ, cổng chuyển mạch Napas, dịch vụ eKYC, và hệ thống thông báo (SMS/push notification).

Các Bước Thực Hành

  1. Thu thập mô tả nghiệp vụ liên quan (user story, ghi chú họp với PO, tài liệu nghiệp vụ cũ nếu có) và xác định rõ phạm vi sơ đồ cần vẽ — đừng cố vẽ toàn bộ hệ thống trong một sơ đồ, chia theo tính năng hoặc theo module.
  2. Đưa mô tả nghiệp vụ vào AI, yêu cầu nó liệt kê danh sách thực thể (entity) và thuộc tính (attribute) trước khi sinh ERD, để bạn review danh sách này trước khi AI vẽ quan hệ — dễ bắt lỗi thiếu/thừa thực thể ở bước liệt kê hơn là ở bước đọc sơ đồ đã vẽ xong.
  3. Yêu cầu AI xuất ERD dưới dạng DBML (Database Markup Language, cú pháp dùng cho dbdiagram.io) hoặc Mermaid erDiagram, sau đó paste vào dbdiagram.io hoặc Mermaid Live Editor để xem bản vẽ trực quan.
  4. Với DFD và system context diagram, yêu cầu AI mô tả từng bước luồng dữ liệu bằng ngôn ngữ tự nhiên trước, sau đó mới chuyển thành cú pháp Mermaid flowchart hoặc graph — bước mô tả bằng lời giúp bạn dễ đối chiếu với hiểu biết nghiệp vụ của mình hơn là đọc thẳng cú pháp.
  5. Đưa bản vẽ (đã render) cho ít nhất một dev của hệ thống liên quan xem trong 5-10 phút, hỏi thẳng "có bước nào sai hoặc thiếu không" — AI có thể tự tin sinh ra một luồng nghe rất hợp lý nhưng sai với cách hệ thống thực tế vận hành.
  6. Lưu bản vẽ cuối cùng cùng với cú pháp text gốc (DBML/Mermaid) vào Confluence hoặc repo tài liệu, không chỉ lưu ảnh — để lần sau cần sửa, bạn sửa text và render lại thay vì vẽ tay từ đầu.

Ví Dụ Prompt

Bạn là một Business Analyst/System Analyst có kinh nghiệm thiết kế
data model cho hệ thống fintech.

Mô tả nghiệp vụ:
[PASTE MÔ TẢ TÍNH NĂNG, ví dụ: "Người dùng ví điện tử có thể chuyển
tiền tới một tài khoản ngân hàng khác thông qua quét mã VietQR.
Hệ thống cần lưu lại yêu cầu tạo QR, giao dịch chuyển tiền, và
tài khoản ngân hàng đã liên kết với ví."]

Hãy thực hiện theo 2 bước:

Bước 1: Liệt kê các entity (thực thể) cần thiết, mỗi entity kèm danh
sách attribute (thuộc tính) chính và kiểu dữ liệu gợi ý. Không vẽ
quan hệ ở bước này, chỉ liệt kê.

Bước 2: Sau khi tôi xác nhận danh sách entity ở bước 1, hãy sinh ERD
dưới dạng DBML (cú pháp dùng cho dbdiagram.io), thể hiện đầy đủ
primary key, foreign key, và loại quan hệ (1-1, 1-n, n-n) giữa các
entity, kèm chú thích ngắn gọn cho từng bảng.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật (entity,
attribute, primary key, foreign key, DBML).

Bạn là System Analyst đang vẽ system context diagram cho một tính năng
mới trong hệ thống ví điện tử.

Mô tả nghiệp vụ và các hệ thống liên quan:
[PASTE MÔ TẢ, ví dụ: "Tính năng chuyển tiền liên ngân hàng qua VietQR.
Hệ thống ví điện tử của chúng tôi cần gọi tới: cổng chuyển mạch Napas
để định tuyến giao dịch, dịch vụ eKYC bên thứ ba để xác thực người
nhận lần đầu, core banking nội bộ để trừ/cộng số dư ví, và hệ thống
gửi thông báo SMS/push notification."]

Hãy:
1. Liệt kê tất cả actor và hệ thống bên ngoài liên quan, phân loại rõ
   đâu là actor con người, đâu là hệ thống/service.
2. Mô tả bằng lời từng luồng trao đổi thông tin ở ranh giới hệ thống
   (ai gọi ai, gọi để làm gì, dữ liệu trao đổi gồm những gì).
3. Chuyển mô tả ở bước 2 thành sơ đồ Mermaid dạng flowchart, hệ thống
   ví điện tử đặt ở trung tâm, các hệ thống khác bao quanh.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ (actor, system context
diagram, core banking, gateway).

Mẹo: Luôn yêu cầu AI xuất sơ đồ dưới dạng cú pháp text (DBML, Mermaid, PlantUML) thay vì mô tả bằng ảnh hay chỉ bằng lời — cú pháp text vừa render trực quan ngay được trong dbdiagram.io/Mermaid Live Editor, vừa có thể lưu trong Git/Confluence và diff được qua từng lần sửa, giống hệt cách dev quản lý version code. Đây là khác biệt lớn nhất giữa vẽ tay và vẽ có AI hỗ trợ: bạn có một nguồn dữ liệu sống (living source), không phải một tấm ảnh chết.

Phân Tích Tài Liệu Hệ Thống Hiện Có Và Xác Định Integration Point

Trước khi đề xuất bất kỳ thay đổi nào, BA cần hiểu rõ hệ thống hiện tại đang hoạt động ra sao — đây là bước "as-is analysis" kinh điển. Vấn đề thực tế ở hầu hết công ty: tài liệu hệ thống hiện có gần như luôn lỗi thời, rải rác, và không đầy đủ. Một trang Confluence mô tả kiến trúc được viết từ 2 năm trước, một file Swagger/OpenAPI (chuẩn mô tả API phổ biến) chỉ cover 60% endpoint thực tế đang chạy, một bản export schema database chỉ có tên bảng mà không có comment giải thích nghiệp vụ. BA vẫn phải đọc hết đống này, đối chiếu với thực tế, và tự suy luận ra phần còn thiếu.

AI đặc biệt mạnh ở bước "đọc nhanh và tóm tắt". Bạn có thể đưa vào AI một file OpenAPI spec dài hàng nghìn dòng, một bản dump schema SQL, hoặc một trang Confluence cũ, và yêu cầu nó tóm tắt các entity chính, liệt kê endpoint theo nhóm chức năng, hoặc — quan trọng nhất cho system analysis — xác định integration point (điểm tích hợp: nơi hệ thống này gọi ra hoặc bị gọi vào bởi một hệ thống khác). Integration point không chỉ là API REST; nó có thể là message queue (Kafka, RabbitMQ), batch file transfer (SFTP đẩy file cuối ngày), webhook, hoặc kết nối trực tiếp vào database của hệ thống khác (một pattern cũ nhưng vẫn tồn tại nhiều ở các core banking legacy).

Ví dụ cụ thể: một ngân hàng số đang có core banking kết nối với CRM để đồng bộ thông tin khách hàng, kết nối với dịch vụ eKYC bên thứ ba để xác minh danh tính, kết nối với cổng chuyển mạch Napas để xử lý giao dịch liên ngân hàng, và kết nối với hệ thống chấm điểm tín dụng nội bộ để xét duyệt khoản vay. Khi BA được giao nhiệm vụ phân tích để thêm tính năng BNPL (mua trước trả sau), việc đầu tiên không phải là viết requirement mà là vẽ ra bản đồ đầy đủ các integration point hiện có, vì tính năng mới gần như chắc chắn sẽ chạm vào ít nhất 2-3 hệ thống trong số đó — và nếu bỏ sót một integration point, requirement sẽ thiếu case quan trọng ngay từ đầu.

Các Bước Thực Hành

  1. Tập hợp toàn bộ tài liệu hệ thống hiện có liên quan tới phạm vi phân tích: file OpenAPI/Swagger, schema database (export bằng công cụ như DBeaver hoặc pg_dump), trang Confluence kiến trúc cũ, sơ đồ mạng nếu có.
  2. Với tài liệu quá dài (ví dụ file OpenAPI hàng nghìn dòng), chia nhỏ theo nhóm endpoint hoặc theo service trước khi đưa vào AI, tránh nhồi toàn bộ vào một lần khiến AI bỏ sót chi tiết ở giữa tài liệu.
  3. Yêu cầu AI tóm tắt từng phần: danh sách endpoint/entity chính, mục đích nghiệp vụ suy luận được, và đặc biệt là bất kỳ dấu hiệu nào cho thấy endpoint/bảng này được gọi bởi hoặc gọi tới một hệ thống khác.
  4. Tổng hợp kết quả từ các phần thành một integration point register (danh sách điểm tích hợp) dạng bảng: Hệ thống nguồn | Hệ thống đích | Giao thức (REST/queue/batch/webhook) | Dữ liệu trao đổi | Tần suất | Mức độ quan trọng nghiệp vụ.
  5. Xác nhận lại register này với dev/tech lead của từng hệ thống liên quan — tài liệu cũ có thể mô tả sai hoặc thiếu so với thực tế đang chạy, cần đối chiếu với người nắm hệ thống hoặc công cụ giám sát (APM, log hệ thống) trước khi coi là chính xác.
  6. Đánh dấu rõ những integration point mà tài liệu không đủ thông tin để kết luận (ví dụ "không rõ tần suất đồng bộ") thành câu hỏi cụ thể để hỏi dev trong buổi làm việc tiếp theo, thay vì đoán.

Ví Dụ Prompt

Bạn là System Analyst đang review tài liệu API của một hệ thống ngân
hàng số để chuẩn bị phân tích tích hợp cho tính năng mới.

Dưới đây là một phần file OpenAPI/Swagger spec:

[PASTE ĐOẠN OPENAPI/SWAGGER SPEC VÀO ĐÂY]

Hãy phân tích:
1. Liệt kê các endpoint theo nhóm chức năng nghiệp vụ (ví dụ: quản lý
   khách hàng, quản lý giao dịch, xác thực).
2. Với mỗi endpoint, suy luận xem nó có khả năng được gọi bởi một hệ
   thống bên ngoài khác không (dựa trên tên, mô tả, response schema),
   và hệ thống đó có thể là gì.
3. Chỉ ra những endpoint có dấu hiệu là integration point quan trọng
   (ví dụ: liên quan callback, webhook, hoặc đồng bộ dữ liệu định kỳ).
4. Liệt kê những thông tin còn thiếu trong spec mà bạn cần hỏi thêm dev
   để hiểu đầy đủ (ví dụ: tần suất gọi, cơ chế retry khi lỗi, SLA).

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ (endpoint, webhook,
callback, SLA, OpenAPI).

Bạn đang giúp tôi xây dựng integration point register cho một hệ thống
core banking. Dưới đây là ghi chú tổng hợp từ tài liệu Confluence cũ và
trao đổi với dev:

[PASTE GHI CHÚ, ví dụ: "Core banking đồng bộ thông tin khách hàng sang
CRM mỗi đêm qua batch file SFTP. Core banking gọi trực tiếp API của
dịch vụ eKYC bên thứ ba khi mở tài khoản mới. Cổng Napas gọi webhook
vào core banking khi có kết quả giao dịch liên ngân hàng."]

Hãy tổng hợp thành bảng Markdown với các cột: Hệ thống nguồn | Hệ thống
đích | Giao thức/Cơ chế | Dữ liệu trao đổi | Tần suất | Mức độ quan
trọng nghiệp vụ (Cao/Trung/Thấp) kèm lý do ngắn gọn.

Sau bảng, liệt kê các câu hỏi tôi cần hỏi thêm dev vì thông tin trong
ghi chú chưa đủ rõ (ví dụ thiếu cơ chế xử lý lỗi, thiếu thông tin về
retry khi batch file lỗi).

Trả lời bằng tiếng Việt.

Mẹo: Đừng bao giờ coi tài liệu cũ là sự thật tuyệt đối. Sau khi AI tổng hợp integration point register từ tài liệu, luôn dành 15-20 phút đối chiếu với một nguồn "sống" hơn — log thực tế, dashboard APM, hoặc đơn giản là hỏi trực tiếp dev đang maintain hệ thống đó — vì tài liệu viết ra 2 năm trước gần như chắc chắn không còn khớp 100% với hệ thống đang chạy hôm nay.

Tạo Báo Cáo Gap Analysis Với AI

Gap analysis (phân tích khoảng cách) là việc so sánh trạng thái hiện tại (as-is — hệ thống/quy trình đang có) với trạng thái mong muốn (to-be — yêu cầu nghiệp vụ mới hoặc mục tiêu cần đạt), để chỉ ra chính xác cái gì đang thiếu, cái gì cần thay đổi, và mức độ nghiêm trọng của từng khoảng cách đó. Đây là bước bản lề nối giữa "hiểu hệ thống hiện tại" (kết quả của hai phần trước) và "biết chính xác cần làm gì tiếp theo".

Cách làm truyền thống là ngồi đối chiếu tài liệu as-is và to-be theo từng dòng, một công việc rất dễ bỏ sót vì hai tài liệu này thường được viết bởi hai nhóm người khác nhau, dùng thuật ngữ khác nhau, và không có cấu trúc song song để so sánh trực tiếp. AI giải quyết vấn đề này tốt vì nó có thể giữ cả hai tài liệu trong "đầu" cùng lúc và đối chiếu một cách nhất quán, không bị bỏ sót do mệt hay do đọc lướt ở đoạn giữa dài dòng.

Ví dụ cụ thể: một ví điện tử hiện tại chỉ hỗ trợ quét mã QR nội bộ (chỉ chuyển tiền giữa các ví cùng nền tảng), nhưng yêu cầu nghiệp vụ mới là hỗ trợ chuẩn VietQR để chuyển tiền liên ngân hàng, đa ngân hàng. Gap analysis ở đây cần chỉ ra rõ: hệ thống hiện tại thiếu khả năng định tuyến giao dịch qua cổng chuyển mạch, thiếu bảng dữ liệu lưu thông tin ngân hàng đối tác, thiếu cơ chế xử lý timeout khi ngân hàng nhận phản hồi chậm, và thiếu quy trình đối soát (reconciliation) giao dịch liên ngân hàng cuối ngày — đây đều là gap có mức độ nghiêm trọng khác nhau, cần effort khác nhau để lấp đầy.

Các Bước Thực Hành

  1. Xác định rõ phạm vi đánh giá gap analysis trước khi bắt đầu — theo tính năng, theo module, hay theo toàn bộ khả năng đáp ứng một yêu cầu compliance mới (ví dụ chuẩn PCI-DSS cho xử lý thẻ).
  2. Chuẩn bị tài liệu as-is (kết quả từ bước phân tích tài liệu hệ thống ở phần trước, hoặc mô tả capability hiện tại) và tài liệu to-be (yêu cầu nghiệp vụ mới, spec chuẩn ngành, hoặc tài liệu compliance) ở dạng có thể đưa vào AI.
  3. Đưa cả hai tài liệu vào cùng một prompt, yêu cầu AI đối chiếu theo từng nhóm capability (không đối chiếu chung chung "hệ thống có đáp ứng không" mà tách theo từng khả năng cụ thể).
  4. Với mỗi gap được xác định, yêu cầu AI trích rõ căn cứ (câu/đoạn cụ thể trong tài liệu as-is hoặc to-be làm bằng chứng) — tránh kết luận mơ hồ không truy vết được nguồn.
  5. Đưa danh sách gap cho các subject matter expert liên quan (tech lead, kiến trúc sư hệ thống, đại diện compliance nếu có) để xác nhận mức độ nghiêm trọng và effort ước tính — AI có thể đưa ra ước lượng effort nhưng đây là con số cần con người có kinh nghiệm thực tế xác nhận lại.
  6. Ưu tiên hóa danh sách gap theo ma trận impact nghiệp vụ và effort khắc phục, rồi publish báo cáo lên Confluence hoặc công cụ quản lý tài liệu chung của team, gắn link tới các item liên quan trong backlog nếu đã có.

Ví Dụ Prompt

Bạn là System Analyst thực hiện gap analysis cho một tính năng mới của
ví điện tử.

Tài liệu AS-IS (khả năng hệ thống hiện tại):
[PASTE MÔ TẢ AS-IS, ví dụ: "Hệ thống hiện chỉ hỗ trợ tạo và quét mã QR
nội bộ, chuyển tiền giữa các ví trong cùng nền tảng. Không có kết nối
tới cổng chuyển mạch liên ngân hàng. Không có bảng lưu thông tin ngân
hàng đối tác."]

Tài liệu TO-BE (yêu cầu nghiệp vụ mới):
[PASTE MÔ TẢ TO-BE, ví dụ: "Hệ thống cần hỗ trợ chuẩn VietQR, cho phép
người dùng chuyển tiền tới tài khoản ở bất kỳ ngân hàng nào tham gia
chuẩn VietQR, có cơ chế xử lý timeout và đối soát giao dịch cuối
ngày."]

Hãy thực hiện gap analysis theo các bước:
1. Chia nhỏ yêu cầu TO-BE thành các nhóm capability cụ thể (không gộp
   chung một khối).
2. Với mỗi capability, xác định hệ thống hiện tại (AS-IS) đã đáp ứng
   được ở mức nào: Đầy đủ / Một phần / Chưa có.
3. Với mỗi gap (capability chưa đầy đủ hoặc chưa có), trích dẫn căn cứ
   cụ thể từ tài liệu AS-IS và TO-BE, giải thích rõ khoảng cách là gì.
4. Đánh giá mức độ nghiêm trọng của từng gap (Cao/Trung/Thấp) dựa trên
   ảnh hưởng nghiệp vụ nếu không xử lý, và ước lượng effort sơ bộ
   (Nhỏ/Vừa/Lớn) để khắc phục.
5. Xuất kết quả dưới dạng bảng Markdown: Capability | Trạng thái AS-IS
   | Gap | Mức độ nghiêm trọng | Effort ước tính | Căn cứ.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ (gap analysis, as-is,
to-be, capability).

Đây là bảng gap analysis đã có (kết quả từ prompt trước):

[PASTE BẢNG GAP ANALYSIS]

Hãy giúp tôi ưu tiên hóa:
1. Nhóm các gap theo 4 nhóm dựa trên ma trận Impact (Cao/Thấp) x Effort
   (Cao/Thấp): (a) Impact cao - Effort thấp: làm ngay; (b) Impact cao -
   Effort cao: cần lên kế hoạch riêng; (c) Impact thấp - Effort thấp:
   làm khi có thời gian rảnh; (d) Impact thấp - Effort cao: cân nhắc
   không làm hoặc làm sau cùng.
2. Đề xuất thứ tự xử lý cụ thể cho nhóm (a) và (b), giải thích lý do.
3. Chỉ ra nếu có gap nào mang tính chặn (blocking) — nghĩa là các gap
   khác không thể xử lý nếu gap này chưa được giải quyết trước.

Trả lời bằng tiếng Việt.

Mẹo: Luôn bắt AI trích dẫn căn cứ cụ thể (câu/đoạn nguồn) cho từng gap thay vì chấp nhận một kết luận chung chung như "hệ thống chưa đáp ứng đầy đủ yêu cầu". Một gap analysis không truy vết được nguồn sẽ rất khó bảo vệ khi bị stakeholder hỏi ngược "sao anh/chị biết hệ thống thiếu cái này" trong buổi trình bày — và đây là câu hỏi gần như chắc chắn sẽ xảy ra.

Chuyển System Analysis Thành Requirement Hành Động Được Với AI

Đây là bước dễ bị bỏ quên nhất trong toàn bộ quy trình, và cũng là bước quyết định toàn bộ công sức phân tích ở trên có tạo ra giá trị thực hay không. ERD, DFD, system context diagram, integration point register, và báo cáo gap analysis đều là tài liệu phân tích (analysis artifact) — chúng mô tả hiện trạng và khoảng cách, nhưng bản thân chúng không phải là requirement mà dev có thể cầm lên implement trực tiếp. Rất nhiều dự án có những tài liệu phân tích rất tốt nằm im trong Confluence, không ai chuyển hóa thành backlog item cụ thể, và cuối cùng insight bị lãng quên khi sprint bắt đầu.

AI hỗ trợ tốt ở bước chuyển hóa này vì nó có thể đọc lại toàn bộ artifact phân tích (gap analysis, integration point register, ERD/DFD) và với mỗi phát hiện, đề xuất một câu functional requirement (yêu cầu chức năng) hoặc non-functional requirement (yêu cầu phi chức năng — về hiệu năng, độ tin cậy, bảo mật, khả năng mở rộng) cụ thể, có thể đo lường và test được, kèm draft acceptance criteria ban đầu. Việc này biến một gap mơ hồ như "hệ thống chưa hỗ trợ đối soát giao dịch liên ngân hàng" thành một requirement rõ ràng dev có thể bắt tay vào ngay.

Ví dụ cụ thể: từ gap "hệ thống chưa có cơ chế xử lý timeout khi ngân hàng nhận phản hồi chậm" (phát hiện ở bước gap analysis), có thể chuyển thành FR: "Hệ thống phải tự động đánh dấu giao dịch ở trạng thái 'Đang xử lý' nếu không nhận được phản hồi từ ngân hàng đối tác trong vòng 15 giây, và tự động gọi API tra soát trạng thái giao dịch sau 30 giây" cùng NFR đi kèm: "Toàn bộ giao dịch timeout phải được ghi log chi tiết (transaction ID, thời điểm gọi, thời điểm timeout) để phục vụ đối soát cuối ngày, log phải được lưu tối thiểu 90 ngày theo quy định nội bộ". Một ví dụ khác từ gap analysis e-commerce: phát hiện hệ thống chưa hỗ trợ hoàn tiền một phần (partial refund) chuyển thành FR "Admin có thể thực hiện hoàn tiền một phần tối đa 3 lần trên một đơn hàng, tổng số tiền hoàn không vượt quá giá trị đơn hàng gốc" kèm acceptance criteria cụ thể cho từng case (hoàn đủ, hoàn một phần, vượt quá số lần cho phép).

Các Bước Thực Hành

  1. Tập hợp toàn bộ artifact phân tích liên quan tới một phạm vi cụ thể: bảng gap analysis, integration point register, và ERD/DFD nếu có ảnh hưởng trực tiếp tới requirement.
  2. Đưa từng gap/finding vào AI, yêu cầu nó đề xuất requirement tương ứng, phân loại rõ đây là functional hay non-functional requirement.
  3. Với mỗi requirement được đề xuất, yêu cầu AI viết kèm 2-3 acceptance criteria draft ở dạng Given-When-Then hoặc checklist, đủ cụ thể để hình dung được test case sẽ trông như thế nào.
  4. Review cùng tech lead và PO — xác nhận requirement có khả thi về mặt kỹ thuật, đúng ưu tiên nghiệp vụ, và không bỏ sót ràng buộc quan trọng mà AI không biết (ví dụ giới hạn hợp đồng với đối tác ngân hàng, quy định nội bộ về audit).
  5. Gắn mỗi requirement với gap/finding gốc bằng một mã tham chiếu (ví dụ GAP-014 → REQ-045), xây dựng một traceability matrix (ma trận truy vết) đơn giản để sau này có thể trả lời câu hỏi "requirement này sinh ra từ đâu, để giải quyết vấn đề gì".
  6. Đưa các requirement đã xác nhận vào backlog dưới dạng epic/story cụ thể, không để chúng nằm rời rạc trong tài liệu phân tích riêng.

Ví Dụ Prompt

Bạn là Business Analyst chuyển kết quả phân tích hệ thống thành
requirement cụ thể cho backlog.

Dưới đây là các gap đã xác định từ gap analysis (chỉ lấy các gap mức độ
nghiêm trọng Cao và Trung):

[PASTE DANH SÁCH GAP, ví dụ: "Gap 1: Hệ thống chưa có cơ chế xử lý
timeout khi ngân hàng đối tác phản hồi chậm quá 15 giây. Gap 2: Hệ
thống chưa có quy trình đối soát giao dịch liên ngân hàng cuối ngày."]

Với mỗi gap, hãy:
1. Đề xuất 1 functional requirement (FR) cụ thể, viết theo dạng "Hệ
   thống phải...", có thể đo lường và test được (có con số cụ thể nếu
   phù hợp: thời gian, số lần, ngưỡng).
2. Đề xuất non-functional requirement (NFR) đi kèm nếu phù hợp (hiệu
   năng, độ tin cậy, khả năng audit/log).
3. Viết 2-3 acceptance criteria draft theo dạng Given-When-Then cho FR
   đã đề xuất.
4. Gắn mã tham chiếu ngược lại gap gốc (ví dụ REQ-01 <- Gap 1).

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ (functional requirement,
non-functional requirement, acceptance criteria, Given-When-Then).

Bạn đang giúp tôi xây dựng traceability matrix (ma trận truy vết) nối
giữa gap analysis, integration point, và requirement đã được viết.

Dữ liệu:
[PASTE DANH SÁCH GAP + DANH SÁCH REQUIREMENT ĐÃ VIẾT Ở BƯỚC TRƯỚC +
DANH SÁCH INTEGRATION POINT LIÊN QUAN NẾU CÓ]

Hãy tạo bảng Markdown với các cột: Gap ID | Integration Point liên
quan (nếu có) | Requirement ID | Mô tả ngắn gọn requirement | Trạng
thái (Chưa vào backlog/Đã vào backlog/Đã hoàn thành).

Sau bảng, chỉ ra nếu có gap nào CHƯA có requirement tương ứng (bị bỏ
sót trong quá trình chuyển hóa) để tôi bổ sung ngay.

Trả lời bằng tiếng Việt.

Mẹo: Xây dựng traceability matrix ngay từ requirement đầu tiên, đừng để "làm sau khi có thời gian" — một khi backlog đã có vài chục story, việc truy ngược lại "tại sao chúng ta cần requirement này" mà không có ma trận sẽ tốn nhiều giờ tìm kiếm trong lịch sử Confluence/Jira, trong khi nếu làm ngay từ đầu, AI có thể duy trì và cập nhật ma trận này chỉ trong vài phút mỗi khi có requirement mới.

Những Điểm Chính Cần Nhớ

  • DFD, ERD và system context diagram phục vụ ba câu hỏi khác nhau (luồng dữ liệu, cấu trúc dữ liệu, ranh giới hệ thống) và cần được sinh dưới dạng cú pháp text (DBML, Mermaid) thay vì ảnh tĩnh, để dễ sửa và quản lý version khi scope thay đổi.
  • Tài liệu hệ thống hiện có (API spec, schema, tài liệu kiến trúc cũ) gần như luôn lỗi thời — AI giúp đọc nhanh và tổng hợp, nhưng kết quả luôn cần đối chiếu với dev hoặc dữ liệu vận hành thực tế trước khi coi là chính xác.
  • Integration point không chỉ giới hạn ở REST API; cần xét cả message queue, batch file, webhook, và kết nối database trực tiếp — bỏ sót một integration point ở bước phân tích sẽ khiến requirement thiếu case quan trọng.
  • Gap analysis chỉ có giá trị khi mỗi gap được xác định có căn cứ trích dẫn cụ thể từ tài liệu as-is/to-be, và được ưu tiên hóa theo ma trận impact và effort, không chỉ là một danh sách liệt kê phẳng.
  • Phân tích hệ thống chỉ tạo ra giá trị thực khi được chuyển hóa thành functional/non-functional requirement cụ thể, có acceptance criteria, và có traceability matrix nối ngược lại nguồn gốc — nếu dừng lại ở tài liệu phân tích, công sức bỏ ra dễ bị lãng quên trong Confluence.
Tiếp Tiếng Việt: Acceptance Criteria Definition Of Done