Bài viết gốc được xuất bản tại ITPrep - Cẩm nang & Cheat Sheet Phỏng vấn IT.

Trong thế giới code dạo, có một sự thật đau lòng: Code sai logic sửa rất nhanh, nhưng code sai requirement thì phải đập đi xây lại. Khi bắt đầu một dự án, anh em Dev rất cần một "bản vẽ thi công" chuẩn chỉnh để thiết kế Database và chia task. Đừng thỏa hiệp với những tin nhắn chat lộn xộn hay vài dòng text mông lung. Hai tài liệu quan trọng nhất bảo vệ bạn chính là SRS (Software Requirements Specification) và Data Dictionary.

Cùng giải mã xem tại sao hai "bảo bối" này lại giúp team Dev thoát cảnh "đoán ý khách hàng" nhé!

1. SRS (Software Requirements Specification): Hợp Đồng Bảo Vệ Dev

SRS (Đặc tả yêu cầu phần mềm) là tài liệu mô tả chi tiết chức năng, hành vi, hiệu năng và các ràng buộc của hệ thống. Nói trắng ra, nó là "hợp đồng" giữa team Tech và Business: Có trong SRS thì code, không có thì tính là Change Request (yêu cầu thay đổi).

Một cuốn SRS chuẩn thường có:

• Mô tả tổng quan: App này làm gì, ai dùng, chạy trên môi trường nào?
• Yêu cầu chức năng (FR - Functional Requirements): User bấm nút A thì hệ thống làm hành động B.
• Yêu cầu phi chức năng (NFR - Non-functional Requirements): Phần này Dev cực quan tâm. App chịu tải 100 hay 10.000 user cùng lúc? Response time API dưới bao nhiêu mili-giây?
• Các ràng buộc (Constraints): Bắt buộc xài AWS, hay bắt buộc lưu data tại server local?

2. Data Dictionary: Ngôn Ngữ Chung Cho Database

Nếu SRS bảo bạn "Làm cái nhà", thì Data Dictionary (Từ điển dữ liệu) nói cho bạn biết "Dùng gạch loại gì, kích thước bao nhiêu".

Nó là danh sách định nghĩa chi tiết mọi field dữ liệu trong hệ thống: Tên trường, kiểu dữ liệu (Data type), độ dài (Max length), Validation rules, và các bảng liên quan. Có cái này, Backend thiết kế Schema chuẩn xác, Frontend biết đường làm form validation.

Ví dụ một mục Data Dictionary "ngon lành" đưa cho Dev:

{
  "fieldName": "customer_email",
  "dataType": "VARCHAR",
  "maxLength": 255,
  "isRequired": true,
  "description": "Địa chỉ email chính của khách hàng.",
  "validationRules": "Regex email_format",
  "defaultValue": null,
  "relatedTables": ["orders", "users"]
}

3. Sự Kết Hợp Hoàn Hảo (Kịch Bản Thực Tế)

SRS và Data Dictionary phải đi đôi với nhau. Hãy xem kịch bản xây dựng tính năng Giỏ hàng (Shopping Cart):

📄 SRS yêu cầu:

• FR-CART-001: User thêm sản phẩm vào giỏ hàng.
• FR-CART-002: Hiển thị Tên, Hình ảnh, Số lượng, Đơn giá và Tổng tiền.
• NFR-PERF-001: API thêm giỏ hàng phải xử lý < 1 giây với 1000 CCU.

🗄️ Data Dictionary quy định:

Từ SRS trên, BA/Tech Lead map ra Data Dictionary để Dev thiết kế DB:

• Bảng cart_items:
  • cart_id (INT, PK): ID phiên giỏ hàng.
  • product_id (INT, FK): Trỏ tới bảng products.
  • quantity (INT): Số lượng. Ràng buộc: > 0.
  • added_at (TIMESTAMP): Thời gian thêm.
• Bảng products:
  • price (DECIMAL(10, 2)): Đơn giá.

👉 Kết quả: Nhìn vào combo này, anh em Backend biết ngay phải thiết kế bảng SQL thế nào, set index ra sao để đạt NFR dưới 1 giây. Không cần đoán mò!

4. Ma Trận Quyết Định: Dự Án Nào Mới Cần Làm Gắt?

Viết Document cũng tốn resource. Anh em tham khảo ma trận này để chọn mức độ "hành" team BA:

5. Những Cú Lừa (Anti-patterns) Cần Tránh

1. SRS dùng văn mẫu mơ hồ: "Hệ thống bảo mật tốt, chạy nhanh". 👉 Nhanh là bao nhiêu? Dev phải đòi thông số cụ thể.
2. Data Dictionary thiếu Validation Rule: Để Frontend tự bắt regex, Backend lưu thả cửa, sau này rác DB dọn không kịp.
3. Tài liệu "chết": Khách đổi requirement, Dev đổi cấu trúc DB nhưng không ai update lại vào Data Dictionary. 👉 Phải có quy trình Change Management!

6. FAQ – Hỏi Đáp Nhanh

Q1: SRS và Data Dictionary có thay thế nhau được không?
Không. SRS nói về Hành vi (hệ thống làm gì). Data Dictionary nói về Cấu trúc (dữ liệu lưu thế nào). Chúng là cặp bài trùng.

Q2: Ai là người viết 2 cái này?
Thường là Business Analyst (BA) hoặc Product Manager. Nhưng Data Dictionary ở cấp độ DB vật lý thì DBA hoặc Tech Lead sẽ là người chốt cuối cùng.

Q3: Dự án Agile (Scrum) chạy đua từng tuần thì viết lúc nào?
Tài liệu không cần viết một lúc 100 trang. Trong Agile, team sẽ viết SRS và định nghĩa Data Dictionary xoay quanh các User Stories của Sprint đó thôi (Just in time documentation).

Lời Kết

SRS và Data Dictionary không phải là "thủ tục hành chính" sinh ra để hành hạ nhau. Nó là ngôn ngữ giao tiếp giúp Business và Technical hiểu nhau. Đừng để anh em Dev phải ôm gối khóc vì thiết kế sai Database chỉ do requirement mông lung.

Lần tới họp Sprint Planning, hãy dõng dạc đòi BA cung cấp Data Dictionary nhé!

💡 Khám phá thêm: Nếu bạn muốn tìm hiểu cách viết User Story thuyết phục được mọi Dev khó tính nhất, hay gom bí kíp cẩm nang Agile/Scrum thực chiến, đừng quên ghé thăm ITPrep.com.vn nhé!