Cách xác định yêu cầu tích hợp hệ thống

Một bộ yêu cầu tích hợp có thể xem là đủ dùng khi trả lời được bốn nhóm vấn đề: dữ liệu nào được trao đổi, chức năng nào phải xảy ra, các hệ thống giao tiếp với nhau bằng cách nào và những ràng buộc nào phải được đáp ứng. Bốn nhóm này cần gắn với từng luồng nghiệp vụ cụ thể thay vì được mô tả độc lập.

ISO/IEC/IEEE 29148:2018 định nghĩa requirement là sự thể hiện một nhu cầu cùng các ràng buộc và điều kiện liên quan; tiêu chuẩn cũng đặt requirements engineering trong quá trình khám phá, phân tích, xác minh, xác nhận, truyền đạt và quản lý yêu cầu. Điều đó có nghĩa yêu cầu tích hợp không chỉ là danh sách tính năng mà phải đủ rõ để kiểm tra xem giải pháp cuối cùng có thực sự đáp ứng nhu cầu ban đầu hay không.

Bắt đầu từ quy trình nghiệp vụ và ranh giới tích hợp

Doanh nghiệp trước hết cần mô tả tình huống thực tế khiến hai hoặc nhiều hệ thống phải trao đổi với nhau. Một tình huống tích hợp nên xác định được sự kiện khởi phát, hệ thống nguồn, hệ thống nhận, thông tin cần truyền, kết quả mong đợi và cách xử lý khi giao dịch thất bại.

Ví dụ, thay vì ghi “tích hợp CRM với ERP”, yêu cầu nên đi đến mức: khi đơn hàng được xác nhận trên CRM, thông tin khách hàng và đơn hàng phải được chuyển sang ERP để tạo chứng từ tương ứng; nếu ERP từ chối dữ liệu, CRM cần nhận trạng thái lỗi để người phụ trách có thể xử lý. Mô tả này tạo ra ranh giới rõ hơn cho việc xác định dữ liệu, chức năng và giao tiếp ở các bước tiếp theo.

Cách tiếp cận này cũng giúp phân biệt nhu cầu nghiệp vụ với giải pháp kỹ thuật. “Đơn hàng đã xác nhận phải xuất hiện trong ERP” là nhu cầu; “gọi REST API ngay khi người dùng bấm xác nhận” đã chứa quyết định thiết kế. Nếu chốt công nghệ quá sớm, doanh nghiệp có thể bỏ qua những lựa chọn phù hợp hơn như xử lý bất đồng bộ, hàng đợi thông điệp hoặc đồng bộ theo lô.

SEBoK mô tả quá trình xác định yêu cầu hệ thống là việc chuyển nhu cầu và năng lực mong muốn của stakeholder thành cách diễn đạt kỹ thuật mà hệ thống phải đáp ứng; các yêu cầu này cũng là cơ sở cho hoạt động kiến trúc, tích hợp và xác minh hệ thống.

Làm rõ dữ liệu phải trao đổi giữa các hệ thống

Yêu cầu dữ liệu không dừng ở việc liệt kê tên trường. Với mỗi luồng tích hợp, doanh nghiệp cần xác định dữ liệu gì được truyền, nguồn nào chịu trách nhiệm về dữ liệu đó, cấu trúc ra sao và dữ liệu được xử lý thế nào khi không hợp lệ.

Các nội dung cần làm rõ thường gồm:

·         Đối tượng dữ liệu như khách hàng, đơn hàng, sản phẩm, hóa đơn hoặc trạng thái giao dịch

·         Trường bắt buộc và trường tùy chọn

·         Kiểu dữ liệu, định dạng ngày giờ, đơn vị đo và quy tắc mã hóa

·         Mapping giữa trường dữ liệu của hệ thống nguồn và hệ thống đích

·         Khóa hoặc định danh dùng để nhận diện cùng một thực thể giữa các hệ thống

·         Quy tắc kiểm tra, chuyển đổi và chuẩn hóa dữ liệu

·         Hệ thống nào là nguồn dữ liệu có thẩm quyền đối với từng thuộc tính

·         Cách xử lý dữ liệu thiếu, sai định dạng, trùng lặp hoặc không tìm thấy đối tượng tương ứng

Điểm dễ bị bỏ sót là ngữ nghĩa của dữ liệu. Hai hệ thống cùng có trường status không có nghĩa chúng hiểu trạng thái theo cùng một cách. Hệ thống bán hàng có thể dùng “completed” khi khách đã đặt xong, trong khi hệ thống kế toán chỉ xem giao dịch hoàn tất sau khi ghi nhận thanh toán. Vì vậy mapping cần xác định cả ý nghĩa và quy tắc chuyển đổi, không chỉ ghép tên trường.

Doanh nghiệp cũng cần xác định vòng đời dữ liệu: dữ liệu được tạo ở đâu, thay đổi ở đâu, hệ thống nào được phép cập nhật và khi có xung đột thì giá trị nào được ưu tiên. Đây là cơ sở để tránh tình trạng nhiều hệ thống cùng tự xem mình là nguồn dữ liệu chính.

Xác định chức năng mà tích hợp phải thực hiện

Yêu cầu chức năng mô tả điều gì phải xảy ra khi các hệ thống phối hợp với nhau. Mỗi chức năng nên gắn với một sự kiện, điều kiện xử lý và kết quả có thể quan sát được.

Một yêu cầu như “đồng bộ khách hàng giữa CRM và ERP” còn quá rộng. Có thể phải tách thành các hành vi cụ thể: tạo khách hàng mới, cập nhật thông tin, khóa khách hàng, phát hiện bản ghi đã tồn tại và phản hồi lỗi khi dữ liệu không hợp lệ.

Đối với từng hành vi, cần làm rõ:

Trigger: Điều gì khởi động quá trình tích hợp, chẳng hạn người dùng thao tác, trạng thái nghiệp vụ thay đổi, lịch chạy định kỳ hoặc một hệ thống phát sự kiện.

Processing: Hệ thống phải kiểm tra, chuyển đổi, đối chiếu hoặc bổ sung thông tin gì trước khi gửi tiếp.

Outcome: Kết quả thành công phải được thể hiện ở hệ thống nào và bằng trạng thái nào.

Failure handling: Nếu một bước thất bại, giao dịch được thử lại, đưa vào hàng đợi, hoàn tác hay chuyển cho người vận hành xử lý.

Phân tách như vậy giúp tránh một hiểu nhầm phổ biến: coi “có kết nối được” là “tích hợp đã hoạt động đúng”. Một endpoint có thể phản hồi thành công nhưng nghiệp vụ vẫn sai nếu bản ghi được tạo trùng, trạng thái không được cập nhật hoặc một phần giao dịch thất bại mà không được phát hiện.

Mô tả rõ cách các hệ thống giao tiếp

Sau khi biết dữ liệu và hành vi cần thiết, doanh nghiệp mới xác định yêu cầu đối với giao tiếp giữa các hệ thống. Đây là nơi làm rõ kênh trao đổi, hợp đồng giao tiếp, thứ tự xử lý và cách hai phía xác nhận kết quả.

Các quyết định cần được ghi thành yêu cầu hoặc ràng buộc khi chúng thực sự cần thiết gồm giao tiếp đồng bộ hay bất đồng bộ, API hay message/event, trao đổi file, đồng bộ theo lịch, định dạng payload, cơ chế xác thực, phiên bản giao diện và quy ước mã lỗi.

Cần đặc biệt làm rõ bốn vấn đề.

Thời điểm trao đổi

Doanh nghiệp phải xác định dữ liệu cần xuất hiện ở hệ thống đích ngay sau giao dịch hay có thể chậm một khoảng thời gian. “Đồng bộ nhanh” không phải yêu cầu kiểm thử được; “95% đơn hàng phải xuất hiện tại hệ thống đích trong vòng 60 giây kể từ khi được xác nhận” tạo ra tiêu chí có thể đo.

Thứ tự và tính nhất quán

Nếu một quy trình gồm nhiều thông điệp, doanh nghiệp cần xác định thứ tự có quan trọng hay không. Khi cùng một thông điệp được gửi lại do timeout, hệ thống đích cũng cần có quy tắc để tránh tạo giao dịch trùng nếu nghiệp vụ yêu cầu tính idempotent.

Phản hồi và xử lý lỗi

Cần phân biệt lỗi tạm thời như timeout với lỗi nghiệp vụ như mã khách hàng không tồn tại. Hai loại lỗi thường cần cách xử lý khác nhau: một trường hợp có thể retry, trường hợp còn lại cần sửa dữ liệu hoặc can thiệp nghiệp vụ.

Hợp đồng giao tiếp

Hai phía phải thống nhất cấu trúc request, response hoặc event; trường bắt buộc; schema; mã lỗi; quy tắc tương thích phiên bản và điều kiện thay đổi interface. Nếu hợp đồng này không rõ, một thay đổi hợp lệ đối với hệ thống nguồn vẫn có thể làm hệ thống nhận ngừng hoạt động.

Đặt các ràng buộc phi chức năng thành tiêu chí đo được

Một tích hợp đúng chức năng vẫn có thể không đáp ứng nhu cầu vận hành nếu quá chậm, dễ gián đoạn, không đủ khả năng xử lý tải hoặc không bảo vệ dữ liệu phù hợp. Vì vậy yêu cầu cần bao gồm các ràng buộc phi chức năng có ảnh hưởng trực tiếp đến luồng tích hợp.

Thay vì sử dụng các từ như “nhanh”, “ổn định”, “bảo mật cao” hoặc “chịu tải tốt”, doanh nghiệp nên xác định chỉ tiêu có thể kiểm thử.

Ví dụ:

·         Thời gian phản hồi ở percentile hoặc ngưỡng nghiệp vụ đã thống nhất

·         Số giao dịch tối đa cần xử lý trong một khoảng thời gian

·         Độ trễ đồng bộ chấp nhận được

·         Khoảng thời gian timeout và chính sách retry

·         Mức độ sẵn sàng cần thiết trong khung thời gian vận hành

·         Thời gian lưu log và thông tin tối thiểu phải có để truy vết giao dịch

·         Yêu cầu mã hóa, xác thực, phân quyền và bảo vệ dữ liệu nhạy cảm

·         RTO hoặc RPO nếu luồng tích hợp thuộc quy trình cần khả năng khôi phục được xác định trước

Không có một con số chuẩn áp dụng cho mọi tích hợp. Ngưỡng phải xuất phát từ hậu quả nghiệp vụ. Nếu dữ liệu tồn kho chậm năm phút đã làm phát sinh bán vượt tồn, độ trễ cho phép phải thấp hơn trường hợp dữ liệu chỉ dùng để tổng hợp báo cáo cuối ngày.

Vì thế, chỉ tiêu kỹ thuật nên luôn có quan hệ với một nhu cầu thực tế thay vì được chọn vì “hệ thống khác cũng dùng con số đó”.

Chuyển từng yêu cầu thành điều kiện có thể kiểm thử và truy vết

Một yêu cầu tích hợp chỉ thực sự hữu ích khi đội triển khai và đội nghiệm thu có thể xác định khách quan nó đã được đáp ứng hay chưa. Điều này đòi hỏi doanh nghiệp gắn yêu cầu với tiêu chí chấp nhận.

Có thể kiểm tra từng yêu cầu bằng bốn câu hỏi:

1.    Chủ thể nào phải thực hiện hành vi?

2.    Trong điều kiện nào hành vi xảy ra?

3.    Kết quả quan sát được là gì?

4.    Dùng dữ liệu hoặc phép đo nào để xác nhận kết quả?

Ví dụ, “hệ thống phải tự động đồng bộ đơn hàng nhanh chóng” khó kiểm thử vì “nhanh chóng” không có ngưỡng. Một yêu cầu kiểm thử được sẽ chỉ rõ sự kiện bắt đầu, dữ liệu cần chuyển, thời hạn hoàn thành, trạng thái thành công và cách xử lý trường hợp thất bại.

Yêu cầu cũng cần được truy vết ngược về nhu cầu nghiệp vụ và xuôi tới thiết kế, interface, test case tương ứng. Khi một yêu cầu thay đổi, doanh nghiệp nhờ đó có thể nhận biết những thành phần nào chịu tác động thay vì sửa từng hệ thống một cách rời rạc.

Điều quan trọng là tiêu chí nghiệm thu phải được xác định trước khi tích hợp hoàn tất. Nếu chỉ thống nhất cách đánh giá ở cuối dự án, một câu như “đồng bộ thành công” có thể được đội nghiệp vụ, đội phát triển và nhà cung cấp hiểu theo ba cách khác nhau.

Một yêu cầu tích hợp hoàn chỉnh cần trả lời những gì?

Trước khi chuyển sang thiết kế kỹ thuật, doanh nghiệp có thể kiểm tra mỗi luồng tích hợp theo một tập câu hỏi thống nhất:

Nếu một luồng chưa trả lời được các câu hỏi thuộc nhóm dữ liệu, chức năng, giao tiếp hoặc ràng buộc có liên quan, việc chọn công nghệ và bắt đầu triển khai thường còn quá sớm. Ngược lại, không nhất thiết phải tạo tài liệu dài cho mọi dự án: mức chi tiết nên tương ứng với độ phức tạp, rủi ro và số bên tham gia, miễn mỗi yêu cầu quan trọng vẫn rõ nghĩa, kiểm thử được và có thể truy vết.

Doanh nghiệp xác định yêu cầu tích hợp hệ thống hiệu quả bằng cách đi từ quy trình nghiệp vụ → dữ liệu → chức năng → giao tiếp → ràng buộc → tiêu chí nghiệm thu. Trình tự này giữ công nghệ ở đúng vai trò: giải pháp phục vụ nhu cầu đã được xác định, thay vì trở thành điểm xuất phát làm lệch bài toán.

Một yêu cầu tốt không chỉ nói hệ thống “cần kết nối”. Nó phải cho biết dữ liệu và hành vi nào đi qua ranh giới hệ thống, điều kiện vận hành nào cần được duy trì, ngoại lệ nào phải xử lý và bằng tiêu chí nào doanh nghiệp biết rằng tích hợp đã hoạt động đúng.