Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA của một dự án xây dựng hệ thống core banking cho một ngân hàng tầm trung ở Việt Nam. Dự án kéo dài 18 tháng, có hơn 40 lập trình viên, ba nhà thầu phụ, và một đối tác công nghệ từ Singapore. Câu hỏi sống còn là: làm sao để tất cả những con người đó hiểu chính xác phần mềm cần làm gì — không phải hiểu đại khái, mà hiểu đến mức một tester ở Đà Nẵng và một dev ở Singapore đọc cùng một tài liệu lại viết ra cùng một hành vi hệ thống?
Đó chính là lý do SRS — Software Requirements Specification — tồn tại. Trong các bài trước bạn đã học cách viết User Stories (Bài 6, Bài 46 cho PRD Agile), BRD (Bài 43), FRD (Bài 44). Mỗi loại tài liệu phục vụ một mục đích. SRS theo chuẩn IEEE 830 là tài liệu kỹ thuật, đầy đủ và chặt chẽ nhất — nó gói trọn functional requirements, non-functional requirements, external interfaces và constraints vào một bản đặc tả duy nhất, đủ để một đội kỹ thuật xây dựng phần mềm mà gần như không cần hỏi lại.
Ở các dự án có hợp đồng cứng (fixed-bid), dự án thầu công, dự án ngân hàng/bảo hiểm/y tế nơi yêu cầu tuân thủ và kiểm toán rất khắt khe, SRS không phải là "nên có" — nó là bắt buộc. Một BA không biết viết SRS chuẩn sẽ bị giới hạn nghiêm trọng về loại dự án có thể nhận. Bài này dạy bạn bộ khung IEEE 830 và cách áp dụng nó cho thật, không phải học vẹt mục lục.
Khái niệm cốt lõi
SRS là gì và IEEE 830 nói gì
SRS là tài liệu mô tả đầy đủ và chính xác những gì phần mềm phải làm — what, không phải how. IEEE 830 (tên đầy đủ: IEEE Std 830-1998, "Recommended Practice for Software Requirements Specifications") là chuẩn quốc tế quy định cấu trúc và đặc tính chất lượng của một SRS tốt. Dù năm 2011 chuẩn này đã được thay thế chính thức bởi ISO/IEC/IEEE 29148, bộ khung IEEE 830 vẫn là ngôn ngữ chung mà ngành phần mềm Việt Nam và thế giới dùng hàng ngày, vì nó rõ ràng và dễ áp dụng.
Điểm cốt lõi cần nhớ: SRS là complete spec — đặc tả hoàn chỉnh. Nó phải bao trùm bốn nhóm nội dung:
- Functional requirements: hệ thống làm gì — các chức năng, hành vi, xử lý dữ liệu, phản hồi với input.
- Non-functional requirements (NFR): hệ thống phải tốt đến mức nào — hiệu năng, bảo mật, độ sẵn sàng, khả năng mở rộng, khả năng bảo trì.
- External interfaces: hệ thống kết nối với cái gì — giao diện người dùng, phần cứng, phần mềm khác, giao thức truyền thông.
- Constraints: những ràng buộc không thể thương lượng — pháp lý, công nghệ bắt buộc, chuẩn tuân thủ, giới hạn ngân sách/thời gian ảnh hưởng kỹ thuật.
Tám đặc tính của một SRS tốt theo IEEE 830
Đây là phần nhiều người bỏ qua nhưng lại là tinh hoa của chuẩn. Một SRS đạt chất lượng phải:
- Correct (Đúng) — mọi yêu cầu phản ánh đúng nhu cầu thực.
- Unambiguous (Không nhập nhằng) — mỗi câu chỉ có một cách hiểu. Tránh từ mơ hồ như "nhanh", "thân thiện", "tối ưu".
- Complete (Đầy đủ) — không thiếu chức năng, không thiếu xử lý lỗi, không bỏ trống "TBD".
- Consistent (Nhất quán) — không có hai yêu cầu mâu thuẫn nhau.
- Ranked / Prioritized (Có ưu tiên) — đánh dấu yêu cầu nào bắt buộc, nào tùy chọn.
- Verifiable (Kiểm chứng được) — có thể viết test case để chứng minh đạt hay không.
- Modifiable (Dễ sửa) — cấu trúc tốt, đánh số rõ, sửa một chỗ không vỡ chỗ khác.
- Traceable (Truy vết được) — mỗi yêu cầu có ID, lần ngược về nguồn và lần xuôi tới test (xem Bài 55 về traceability matrix).
Cấu trúc chuẩn IEEE 830 (template 3 phần lớn)
IEEE 830 đề xuất bộ mục lục ba phần:
Phần 1 — Introduction: Purpose (mục đích tài liệu), Scope (phạm vi sản phẩm), Definitions/Acronyms (thuật ngữ — rất quan trọng ở VN vì lẫn lộn Anh-Việt), References, Overview.
Phần 2 — Overall Description: Product Perspective (sản phẩm nằm ở đâu trong bức tranh lớn), Product Functions (tóm tắt chức năng chính), User Characteristics (đặc điểm người dùng), Constraints, Assumptions and Dependencies.
Phần 3 — Specific Requirements: đây là phần "nặng" nhất, chứa chi tiết External Interface Requirements, Functional Requirements, Performance Requirements, Design Constraints, Software System Attributes (security, reliability, availability, maintainability, portability) và các yêu cầu khác. Phần 3 thường chiếm 70-80% độ dày tài liệu.
Tình huống thực tế
Ví dụ 1 — Ngân hàng TMCP và module chuyển khoản liên ngân hàng
Một ngân hàng TMCP cỡ vừa tại TP.HCM thuê một công ty phần mềm theo hợp đồng fixed-bid 6,2 tỷ đồng để xây module chuyển khoản 24/7 qua hệ thống NAPAS. Vì là fixed-bid, mọi thứ ngoài SRS đã ký đều bị tính là change request có phí. BA của bên ngân hàng viết SRS với yêu cầu chức năng đánh số rõ:
- FR-TRF-012: "Hệ thống phải (shall) hoàn tất một giao dịch chuyển khoản liên ngân hàng dưới 250.000.000 VND trong vòng tối đa 5 giây tính từ lúc khách hàng xác nhận OTP."
- NFR-PERF-003: "Hệ thống phải xử lý đồng thời tối thiểu 1.500 giao dịch/giây vào giờ cao điểm với độ sẵn sàng (availability) 99,95% theo tháng."
- CON-REG-001: "Hệ thống phải tuân thủ Thông tư của Ngân hàng Nhà nước về hạn mức xác thực giao dịch và lưu nhật ký giao dịch tối thiểu 5 năm."
Bài học: Trong dự án fixed-bid, SRS chính là hợp đồng kỹ thuật. Một câu mơ hồ như "giao dịch phải nhanh" có thể khiến ngân hàng mất hàng trăm triệu khi tranh chấp, vì nhà thầu sẽ lập luận "1 phút cũng là nhanh". Con số cụ thể bảo vệ cả hai bên.
Ví dụ 2 — Startup logistics và sai lầm bỏ trống "TBD"
Một startup giao hàng chặng cuối ở Hà Nội (giả định tên Giao Tốc) thuê đội outsource viết hệ thống điều phối tài xế. BA non kinh nghiệm viết SRS nhưng để hơn 20 chỗ ghi "TBD — sẽ chốt sau" ở phần xử lý lỗi: chuyện gì xảy ra khi tài xế mất GPS giữa đường, khi đơn bị hủy lúc đang giao, khi hai tài xế cùng nhận một đơn.
Đội dev tự suy diễn mỗi chỗ một kiểu. Khi tích hợp, hệ thống cho phép hai tài xế nhận trùng đơn, gây ra 320 đơn trùng trong tuần thử nghiệm đầu, khách hàng phàn nàn ầm ĩ. Chi phí làm lại và xử lý sự cố ước tính 480 triệu đồng, dự án trễ 7 tuần.
Diễn giải: Vi phạm trực diện tính Complete. SRS không cho phép "TBD" tồn tại đến lúc ký. Phần xử lý ngoại lệ (exception flow) thường bị BA bỏ quên vì khó nghĩ hơn happy path, nhưng đó lại là nơi phần mềm thực sự gãy.
Bài học: Trước khi ký SRS, hãy quét toàn bộ tài liệu tìm chữ "TBD", "sẽ chốt sau", "tùy". Mỗi cái còn sót là một quả bom nổ chậm. Với mỗi chức năng, luôn hỏi: "Nếu thất bại thì sao? Nếu input sai thì sao? Nếu hai người làm cùng lúc thì sao?".
Ví dụ 3 — Hệ thống bệnh án điện tử và external interfaces
Một bệnh viện ở Đà Nẵng triển khai hệ thống bệnh án điện tử cần tích hợp với máy xét nghiệm (qua chuẩn HL7) và hệ thống bảo hiểm y tế của BHXH Việt Nam (qua API). BA viết riêng một mục External Interface Requirements rất kỹ:
- IF-LAB-001: "Hệ thống phải nhận kết quả xét nghiệm từ máy phân tích sinh hóa qua giao thức HL7 v2.5, định dạng message ORU^R01, qua cổng TCP/IP 6661."
- IF-BHXH-002: "Hệ thống phải gửi hồ sơ đề nghị thanh toán BHYT tới cổng giám định BHXH qua REST API theo định dạng XML chuẩn 4210, mã hóa TLS 1.2 trở lên."
Bài học: Với mọi điểm hệ thống nói chuyện với thế giới bên ngoài, đặc tả phải trả lời: giao thức gì, định dạng dữ liệu gì, ai khởi tạo, tần suất, và xử lý lỗi kết nối ra sao.
Hướng dẫn từng bước
Đây là quy trình thực chiến để viết một SRS chuẩn IEEE 830:
Bước 1 — Xác định phạm vi và đối tượng đọc. Hỏi rõ: SRS này phục vụ dự án fixed-bid hay agile? Người đọc là đội nội bộ hay nhà thầu ngoài? Câu trả lời quyết định độ chi tiết. Dự án thầu ngoài cần SRS chặt hơn nhiều.
Bước 2 — Dựng khung tài liệu theo 3 phần IEEE 830. Tạo sẵn mục lục Introduction / Overall Description / Specific Requirements. Đừng viết tự do rồi nhét vào sau — dựng khung trước giúp bạn thấy chỗ nào còn trống.
Bước 3 — Viết phần Overall Description trước. Mô tả bối cảnh sản phẩm, người dùng, giả định và phụ thuộc. Phần này định khung tư duy cho toàn bộ phần chi tiết phía sau.
Bước 4 — Liệt kê và đánh số functional requirements. Mỗi yêu cầu một ID (ví dụ FR-001), một câu "shall", một mức ưu tiên (Must/Should/Could). Nhóm theo module hoặc theo use case. Luôn kèm exception flow.
Bước 5 — Đặc tả non-functional requirements bằng con số. Với mỗi nhóm (performance, security, availability, scalability), viết yêu cầu đo được. "Trang chủ tải dưới 2 giây với 95% request khi có 5.000 user đồng thời" thay vì "trang phải nhanh".
Bước 6 — Đặc tả external interfaces. Liệt kê mọi điểm tích hợp: UI, hardware, software khác, giao thức truyền thông. Với mỗi cái nêu định dạng, giao thức, hướng dữ liệu.
Bước 7 — Ghi rõ constraints và assumptions. Ràng buộc pháp lý, công nghệ bắt buộc, chuẩn tuân thủ. Giả định nào nếu sai sẽ làm vỡ thiết kế thì phải ghi ra.
Bước 8 — Rà chất lượng theo 8 đặc tính. Đọc lại tự hỏi: có nhập nhằng không? có đầy đủ không? có mâu thuẫn không? có verifiable không? Đặc biệt quét sạch "TBD".
Bước 9 — Review với stakeholder và playback. Cho cả phía nghiệp vụ lẫn kỹ thuật đọc, tổ chức buổi walkthrough (liên hệ Bài 18 về playback và sign-off), rồi lấy chữ ký baseline (Bài 56).
Lỗi thường gặp & mẹo
Lỗi 1 — Mô tả "how" thay vì "what". BA hay sa đà vào chỉ định cách lập trình ("dùng bảng tạm để lưu...", "viết hàm đệ quy..."). SRS nói cái gì hệ thống làm; cách làm là của đội thiết kế/dev. Lấn sân khiến tài liệu cứng nhắc và mất giá trị.
Lỗi 2 — Dùng từ mơ hồ. "Thân thiện", "nhanh", "ổn định", "tối ưu", "linh hoạt" — đây là kẻ thù của tính unambiguous. Mỗi từ này phải được thay bằng tiêu chí đo được.
Lỗi 3 — Bỏ quên non-functional requirements. Rất nhiều SRS Việt Nam chỉ có chức năng, không có một dòng về hiệu năng hay bảo mật. Đến lúc hệ thống lên production gặp 10.000 user thì sập. NFR phải được viết ngay từ đầu, không phải vá sau.
Lỗi 4 — Để "TBD" sống tới lúc ký. Như ví dụ Giao Tốc. Mỗi TBD là một lỗ hổng đầy đủ tính.
Lỗi 5 — Không đánh số / không truy vết được. Requirement viết thành đoạn văn dài không ID thì không thể tham chiếu trong test case hay change request. Luôn một-yêu-cầu-một-ID.
Mẹo vàng: Sau khi viết xong mỗi functional requirement, tự đặt câu hỏi "Tôi viết được test case nào để chứng minh điều này đúng/sai không?". Nếu không viết được test case, yêu cầu đó chưa đạt tính verifiable và cần viết lại.
Mẹo về độ dày: SRS không phải càng dày càng tốt. Dày mà nhập nhằng còn tệ hơn mỏng mà rõ. Mục tiêu là đủ để xây mà không cần hỏi lại, không phải gây ấn tượng bằng số trang.
Mẹo bối cảnh VN: Phần Definitions/Acronyms cực kỳ quan trọng ở Việt Nam vì đội ngũ trộn lẫn tiếng Anh và tiếng Việt. Hãy chốt thuật ngữ ngay từ đầu: "đơn hàng" là order hay invoice? "khách hàng" là customer hay user? Một bảng thuật ngữ tốt ngăn được rất nhiều hiểu lầm tốn kém.
Bài tập thực hành
Bài 1 — Sửa câu mơ hồ. Cho ba câu sau, viết lại thành requirement verifiable, có ID và mức ưu tiên:
- "Hệ thống đăng nhập phải nhanh."
- "Giao diện phải thân thiện với người dùng lớn tuổi."
- "Dữ liệu khách hàng phải được bảo mật."
- 5 functional requirements (kèm ít nhất 2 exception flow: hết ghế, thanh toán thất bại).
- 3 non-functional requirements có con số (hiệu năng, bảo mật, availability).
- 2 external interface requirements (cổng thanh toán VNPay/Momo, gửi SMS xác nhận).
Bài 4 — Săn TBD. Tìm một tài liệu yêu cầu cũ (của bạn hoặc mẫu trên mạng), liệt kê mọi chỗ thiếu, mơ hồ, hoặc bỏ trống xử lý lỗi. Với mỗi chỗ, viết câu hỏi bạn sẽ hỏi stakeholder để lấp đầy.
Tóm tắt
SRS theo chuẩn IEEE 830 là tài liệu đặc tả hoàn chỉnh nhất trong bộ công cụ của BA, gói trọn functional requirements, non-functional requirements, external interfaces và constraints. Nó đặc biệt thiết yếu trong dự án fixed-bid, dự án thầu, và các lĩnh vực tuân thủ cao như ngân hàng, bảo hiểm, y tế — nơi SRS đóng vai trò hợp đồng kỹ thuật.
Bộ khung gồm ba phần: Introduction, Overall Description, Specific Requirements. Nhưng quan trọng hơn cấu trúc là tám đặc tính chất lượng: correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, traceable. Hai nguyên tắc thực chiến cần khắc cốt ghi tâm: dùng "shall" với con số đo được để mọi yêu cầu kiểm chứng được, và quét sạch mọi "TBD" trước khi ký baseline. Một câu mơ hồ hôm nay là một tranh chấp hàng trăm triệu ngày mai. Viết SRS giỏi không phải viết dài, mà viết rõ đến mức không ai phải đoán.