Các mục mô tả trong Đặc tả yêu cầu phần mềm (SRS)
1. Tổng quan
A. Định nghĩa
Đặc tả yêu cầu phần mềm (SRS, Software Requirements Specification) là sản phẩm đầu ra văn bản hóa một cách rõ ràng, đầy đủ và có thể kiểm chứng việc hệ thống phải làm gì (chức năng) và phải thỏa mãn những ràng buộc, chất lượng nào (phi chức năng). Đây là căn cứ cho sự đồng thuận giữa các bên liên quan như bên đặt hàng, nhà phát triển, người kiểm thử, đồng thời là đường cơ sở (baseline) cho thiết kế, cài đặt và kiểm chứng; các tiêu chuẩn tiêu biểu gồm IEEE Std 830-1998 và ISO/IEC/IEEE 29148 (2011, sửa đổi 2018) thay thế nó.
Lý do căn bản khiến SRS được coi trọng trong công nghệ phần mềm nằm ở quan sát thực nghiệm lâu đời rằng 'yêu cầu không rõ ràng, không đầy đủ và thay đổi thường xuyên là một trong những nguyên nhân lớn nhất gây thất bại dự án'. Nếu điều hệ thống phải làm không được xác lập rõ ràng bằng văn bản, bên đặt hàng, người hoạch định, nhà phát triển và người kiểm thử sẽ diễn giải cùng một câu theo những cách khác nhau, và khoảng cách diễn giải đó lớn dần như quả cầu tuyết theo tiến độ phát triển, rồi bùng nổ thành việc làm lại (rework) quy mô lớn ở giai đoạn kiểm thử tích hợp và nghiệm thu. SRS chính là cơ chế niêm phong khoảng cách diễn giải này ngay từ đầu.
Đặc biệt, sức mạnh của SRS nằm ở việc chuyển ngôn ngữ tự nhiên mơ hồ thành các phát biểu đo lường được. Những câu như "màn hình phải nhanh", "phải dễ sử dụng" gợi lên hình ảnh khác nhau ở mỗi người, nhưng nếu định lượng thành "thời gian phản hồi truy vấn trong điều kiện tải bình thường không quá 2 giây theo phân vị thứ 95", thì không ai có thể diễn giải khác đi, và sau khi hoàn thành có thể xác định bằng kiểm thử liệu yêu cầu có được đáp ứng hay không. Tức là SRS không chỉ là một tài liệu đơn thuần mà mang tính chất của một hợp đồng có thể kiểm chứng làm nền tảng cho thiết kế, phát triển, nghiệm thu và quyết toán về sau.
B. Bối cảnh ra đời và sự cần thiết
Bối cảnh khiến SRS trở thành một sản phẩm đầu ra chính thức là kinh tế học về khiếm khuyết: 'khiếm khuyết được phát hiện càng muộn thì chi phí sửa càng tăng theo cấp số nhân'. Kể từ quan sát kinh điển do Boehm đưa ra, việc một khiếm khuyết lẽ ra có thể bắt được ở giai đoạn yêu cầu mà để đến giai đoạn vận hành mới sửa sẽ làm chi phí tăng từ vài chục đến vài trăm lần đã trở thành hiểu biết phổ thông trong công nghệ phần mềm. Xác lập rõ ràng yêu cầu ngay từ đầu rốt cuộc là phương tiện bảo đảm chất lượng rẻ nhất.
Một sự cần thiết khác là thiết lập ranh giới trách nhiệm và phạm vi. Trong các dự án SI và phần mềm khu vực công, phần lớn tranh chấp giữa bên đặt hàng và bên thực hiện bắt nguồn từ tranh cãi về phạm vi (scope) kiểu "chẳng phải cái này vốn đã nằm trong yêu cầu sao". Nếu SRS xác lập đầy đủ chức năng, phi chức năng và ràng buộc, các thay đổi yêu cầu về sau sẽ được nhận diện là 'yêu cầu mới ngoài phạm vi' và trở thành đối tượng của thủ tục kiểm soát thay đổi (Change Control) và tính toán chi phí. Nếu đặc tả sơ sài, ranh giới này mờ đi và sự phình to vô hạn của yêu cầu (scope creep) sẽ gặm nhấm dự án.
2. Cấu thành và các mục mô tả của SRS
SRS phải chứa đầy đủ các khía cạnh của hệ thống mà không thiên lệch về một góc nhìn cụ thể nào. Sơ đồ cấu trúc dưới đây tổng hợp các mục tiêu biểu được họ IEEE 830/29148 khuyến nghị thành sáu trục: tổng quan, chức năng, phi chức năng, giao diện, ràng buộc và dữ liệu.
flowchart TB
S["SRS (Đặc tả yêu cầu)"] --> I["Tổng quan·mục đích·phạm vi·thuật ngữ"]
S --> F["Yêu cầu chức năng"]
S --> N["Yêu cầu phi chức năng"]
S --> IF["Yêu cầu giao diện"]
S --> C["Ràng buộc"]
S --> D["Yêu cầu dữ liệu"]
F --> F1["Đầu vào→xử lý→đầu ra"]
N --> N1["Hiệu năng·bảo mật·sẵn sàng·khả dụng"]
IF --> IF1["Người dùng·HW·SW·truyền thông"]
style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
Mục tổng quan·mục đích·phạm vi là phần mở đầu của SRS, định nghĩa vì sao cần hệ thống, muốn giải quyết vấn đề gì, đối tượng đến đâu và cái gì không thuộc đối tượng (phạm vi và ngoài phạm vi), đồng thời quy định rõ các thuật ngữ, từ viết tắt dùng trong toàn bộ tài liệu. Nếu phần này sơ sài, dù các yêu cầu chi tiết phía sau có tinh vi đến đâu thì do thiếu hiểu biết chung về 'hệ thống này để làm gì', định hướng sẽ lệch lạc. Ví dụ, với hệ thống thẩm định tín dụng của ngân hàng, phải xác định rõ trong phần tổng quan các ranh giới như nhóm sản phẩm đối tượng, công ty xếp hạng tín dụng cần liên kết, phạm vi hạn mức phê duyệt tự động.
Yêu cầu chức năng (Functional Requirements) mô tả các hành vi cụ thể mà hệ thống phải cung cấp theo dạng 'đầu vào→xử lý→đầu ra'. Phải mô tả theo đơn vị hành vi quan sát được, như "khi người dùng yêu cầu chuyển khoản (đầu vào), hệ thống xác minh số dư, hạn mức, giao dịch bất thường (xử lý), rồi trả về kết quả thành công/thất bại và lịch sử giao dịch (đầu ra)". Yêu cầu chức năng thường được biểu diễn dưới dạng use case, danh sách chức năng, hoặc user story của Agile, và mỗi chức năng được gán định danh duy nhất (FR-001...) để bảo đảm khả năng truy vết.
Yêu cầu phi chức năng (Non-Functional Requirements, thuộc tính chất lượng) quy định hệ thống phải hoạt động 'tốt đến mức nào'. Hiệu năng (thời gian phản hồi, thông lượng, TPS), tính sẵn sàng (ví dụ: 99,9% mỗi năm, tức thời gian ngừng hoạt động hằng năm khoảng 8,76 giờ trở xuống), bảo mật, tính khả dụng, khả năng mở rộng, khả năng bảo trì thuộc nhóm này. Yêu cầu phi chức năng ảnh hưởng tới toàn bộ hệ thống chứ không phải một màn hình cụ thể, và trên thực tế quyết định kiến trúc, nên việc xác lập định lượng ngay từ đầu đặc biệt quan trọng. Không phải "phải nhanh" mà phải chốt bằng con số như "với 10.000 người dùng đồng thời, phản hồi truy vấn trong vòng 2 giây, thông lượng từ 500 TPS trở lên".
Yêu cầu giao diện·ràng buộc·dữ liệu quy định môi trường mà hệ thống được đặt vào. Yêu cầu giao diện định nghĩa điểm tiếp xúc với giao diện người dùng (UI), phần cứng, phần mềm khác (API hệ thống bên ngoài) và giao thức truyền thông. Ràng buộc là các điều kiện bên ngoài như luật pháp phải tuân thủ (ví dụ: Luật Bảo vệ Thông tin Cá nhân, Quy định Giám sát Tài chính Điện tử của Hàn Quốc), tiêu chuẩn ngành, stack công nghệ, ngân sách, tiến độ. Yêu cầu dữ liệu quy định cấu trúc, các mục, quy tắc toàn vẹn và thời hạn lưu giữ của dữ liệu cần xử lý. Ba mục này thường bị xem nhẹ, nhưng trong thực tế, chậm trễ tích hợp và rủi ro vi phạm quy định lại phát sinh chính tại đây.
| Mục | Nội dung | Định danh·ví dụ tiêu biểu |
|---|---|---|
| Tổng quan·mục đích·phạm vi | Mục đích hệ thống, đối tượng, phạm vi/ngoài phạm vi, định nghĩa thuật ngữ | Bối cảnh dự án, phạm vi nghiệp vụ đối tượng |
| Yêu cầu chức năng | Chức năng·hành vi cần cung cấp (đầu vào·xử lý·đầu ra) | FR-001 xử lý chuyển khoản |
| Yêu cầu phi chức năng | Chất lượng như hiệu năng·bảo mật·sẵn sàng·khả dụng | NFR-P-01 phản hồi trong 2 giây |
| Yêu cầu giao diện | Giao diện người dùng·HW·SW·truyền thông | Liên kết REST API của công ty xếp hạng tín dụng |
| Ràng buộc | Ràng buộc pháp luật·tiêu chuẩn·công nghệ·ngân sách·tiến độ | Tuân thủ Luật Bảo vệ Thông tin Cá nhân |
| Yêu cầu dữ liệu | Quy tắc cấu trúc·mục·toàn vẹn·lưu giữ dữ liệu | Lưu giữ log giao dịch 5 năm |
3. Thuộc tính chất lượng của một yêu cầu tốt
Không chỉ toàn bộ tài liệu SRS mà từng yêu cầu chứa trong đó cũng phải đạt những tiêu chuẩn chất lượng nhất định. ISO/IEC/IEEE 29148 đưa ra các đặc tính cho cả yêu cầu riêng lẻ lẫn tập hợp yêu cầu (set); ở đây trình bày bằng văn xuôi năm đặc tính thường được nhấn mạnh trong thực tế.
Thứ nhất, tính đầy đủ (Completeness) nghĩa là các yêu cầu cần thiết phải được bao gồm không sót, và trong mỗi yêu cầu cũng phải nêu rõ điều kiện ngoại lệ và điều kiện biên. Nếu chỉ viết luồng bình thường mà bỏ sót xử lý lỗi, nhà phát triển sẽ tự ý diễn giải phần đó hoặc không cài đặt luôn. Thứ hai, tính rõ ràng/không mơ hồ (Unambiguity) nghĩa là một câu chỉ được diễn giải theo đúng một nghĩa. Các cách diễn đạt như "và/hoặc", "một cách thích hợp", "khi cần" để lại dư địa diễn giải nên phải loại bỏ.
Thứ ba, tính nhất quán (Consistency) là giữa các yêu cầu không được mâu thuẫn nhau. Nếu một chỗ ghi "xử lý mọi giao dịch theo thời gian thực" còn chỗ khác ghi "quyết toán bằng batch ban đêm" thì đó là xung đột, và những mâu thuẫn như vậy thường phát sinh khi có nhiều bên liên quan. Thứ tư, tính có thể kiểm chứng (Verifiability) nghĩa là việc đáp ứng yêu cầu phải có thể được xác định khách quan bằng kiểm thử, kiểm tra, phân tích hoặc trình diễn. Thứ năm, khả năng truy vết (Traceability) là mỗi yêu cầu phải được liên kết hai chiều với nguồn gốc (yêu cầu của bên liên quan, yêu cầu cấp trên) và sản phẩm đầu ra cấp dưới (thiết kế, mã nguồn, ca kiểm thử) để có thể truy vết tác động lan truyền của thay đổi.
Trong đó, chìa khóa giảm tranh chấp trong thực tế là tính có thể kiểm chứng. Yêu cầu không đo được như "phải dễ sử dụng" khiến bên đặt hàng và bên thực hiện tranh cãi bất tận sau khi hoàn thành về chuyện "thế này đã là dễ chưa". Ngược lại, nếu viết "người dùng mới phải hoàn thành chuyển khoản trong 5 phút mà không cần đào tạo, và trong kiểm thử khả dụng có từ 90% đối tượng trở lên thành công" thì việc đánh giá sẽ được khách quan hóa.
| Thuộc tính | Nội dung | Ví dụ vi phạm → ví dụ cải thiện |
|---|---|---|
| Tính đầy đủ | Bao gồm đầy đủ yêu cầu·điều kiện ngoại lệ cần thiết | Thiếu xử lý lỗi → ghi rõ thử lại 3 lần khi thất bại |
| Tính rõ ràng | Chỉ diễn giải theo một nghĩa (không mơ hồ) | "Phải nhanh" → "phản hồi trong 2 giây" |
| Tính nhất quán | Không mâu thuẫn giữa các yêu cầu | Loại bỏ xung đột thời gian thực vs batch |
| Tính có thể kiểm chứng | Có thể xác nhận đáp ứng bằng kiểm thử·kiểm tra | "Phải dễ" → "hoàn thành trong 5 phút, tỷ lệ thành công 90%" |
| Khả năng truy vết | Liên kết hai chiều với nguồn·thiết kế·mã·kiểm thử | Ánh xạ yêu cầu–kiểm thử bằng RTM |
4. Quy trình kỹ thuật yêu cầu và vị trí của SRS
SRS không phải là tài liệu được viết một lần tại một thời điểm, mà là sản phẩm đầu ra của một quy trình lặp gọi là kỹ thuật yêu cầu (Requirements Engineering). Sơ đồ dưới đây thể hiện luồng khai thác (Elicitation)→phân tích (Analysis)→đặc tả (Specification)→thẩm định (Validation), trong đó SRS được phê duyệt sẽ được đặt dưới quản lý cấu hình và sau đó chịu kiểm soát thay đổi.
flowchart LR
E["Khai thác<br/>(phỏng vấn·workshop bên liên quan)"] --> A["Phân tích<br/>(giải quyết xung đột·ưu tiên)"]
A --> S["Đặc tả<br/>(viết SRS)"]
S --> V["Thẩm định<br/>(review·prototype)"]
V -->|Phát hiện khiếm khuyết| E
V --> B["Xác lập baseline<br/>(quản lý cấu hình)"]
B --> CC["Kiểm soát thay đổi<br/>(CCB xem xét)"]
style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style B fill:#fef3c7,stroke:#d97706,stroke-width:2px
Ở giai đoạn khai thác, nhu cầu thực sự của các bên liên quan được đào ra thông qua phỏng vấn, workshop, quan sát, phân tích tài liệu hiện có. Khi đó, cốt lõi là phân biệt 'giải pháp' mà bên liên quan nói ra với 'vấn đề thực sự' ẩn phía sau. Ở giai đoạn phân tích, giải quyết xung đột giữa các yêu cầu đã khai thác, đánh giá tính khả thi và xếp hạng ưu tiên theo giá trị kinh doanh và rủi ro (ví dụ: MoSCoW — Must/Should/Could/Won't).
Đến giai đoạn đặc tả, SRS mới được viết thành tài liệu chính thức, và ở giai đoạn thẩm định, thông qua review của các bên liên quan, inspection và prototype để xác nhận đồng thời "chúng ta đã đặc tả đúng thứ cần làm chưa (Validation)" và "đặc tả đã được viết đúng quy tắc chưa (Verification)". SRS vượt qua thẩm định và được phê duyệt sẽ được đăng ký vào quản lý cấu hình như đường cơ sở (baseline), và mọi thay đổi sau đó phải qua xem xét của Hội đồng kiểm soát thay đổi (CCB). Nếu không có cấu trúc phản hồi này, SRS bắt đầu lỗi thời ngay khi được viết xong.
5. Tình huống — Thất bại do yêu cầu mơ hồ và hiệu quả của định lượng hóa
Giá trị của SRS thể hiện rõ nhất khi đối chiếu với các trường hợp thất bại. Thất bại điển hình được quan sát lặp đi lặp lại trong các dự án SI lớn thuộc khu vực công và tài chính là khi các câu định tính như "người dân phải sử dụng được một cách thuận tiện" hay "phải vận hành ổn định" được xác lập làm yêu cầu. Những yêu cầu này khiến bên đặt hàng và bên thực hiện tranh cãi vô tận vào thời điểm kết thúc dự án về chuyện "đã đủ thuận tiện chưa", "như thế này đã ổn định chưa", dẫn đến chậm trễ giám sát, nghiệm thu và phát sinh chi phí. Gốc rễ vấn đề không nằm ở năng lực phát triển mà ở chỗ tiêu chí đánh giá không có trong đặc tả.
Khi định lượng hóa, tình hình sẽ khác. Nếu đổi "phải thuận tiện" thành "3 nghiệp vụ cốt lõi được người dùng mới hoàn thành trong vòng 3 phút mà không cần đào tạo riêng, từ 90% đối tượng kiểm thử khả dụng trở lên thành công", và "phải ổn định" thành "tính sẵn sàng 99,9% mỗi năm (thời gian ngừng hằng năm khoảng 8,76 giờ trở xuống), thời gian khôi phục mục tiêu (RTO) 30 phút, điểm khôi phục mục tiêu (RPO) 5 phút", thì sau khi hoàn thành có thể xác định khách quan bằng kiểm thử liệu yêu cầu đã được đáp ứng hay chưa. Chỉ cần chuyển cùng một câu thành chỉ số định lượng là dư địa tranh chấp biến mất.
Một trường hợp khác lặp lại trong thực tế là phát hiện muộn yêu cầu phi chức năng. Nếu sau khi phát triển đã tiến triển đáng kể mới lộ ra yêu cầu hiệu năng "phải chịu được 10.000 truy cập đồng thời", thì phải thiết kế lại kiến trúc vốn đã được xây theo kiểu máy chủ đơn và ghép nối chặt thành cấu trúc có thể mở rộng, khiến chi phí làm lại bùng nổ. Trường hợp này cho thấy vì các yêu cầu phi chức năng như hiệu năng, tính sẵn sàng, bảo mật trên thực tế quyết định kiến trúc, việc xác lập chúng thành mục tiêu định lượng ngay ở giai đoạn SRS là cực kỳ quan trọng.
6. Chuyên sâu — Thay đổi của tiêu chuẩn và đặc tả gọn nhẹ trong môi trường Agile
Theo truyền thống, khung của SRS do IEEE Std 830-1998 cung cấp, nhưng tiêu chuẩn này đã được hợp nhất và thay thế bởi ISO/IEC/IEEE 29148 ("Requirements engineering") vào năm 2011, và bản sửa đổi ra đời năm 2018. 29148 không chỉ bao quát SRS mà còn cả đặc tả yêu cầu của bên liên quan (StRS) và đặc tả yêu cầu hệ thống (SyRS), đồng thời quy định tinh vi các đặc tính mà yêu cầu riêng lẻ và tập yêu cầu phải có (tính cần thiết, rõ ràng, đầy đủ, nhất quán, có thể kiểm chứng, khả năng truy vết...), nên toàn diện hơn 830. Trong bài làm của Kỹ sư chuyên nghiệp, thay vì chỉ viết "830 là tiêu chuẩn tiêu biểu", nếu đề cập đến "hệ thống 29148 kế thừa và thay thế 830" thì sẽ thể hiện được tính cập nhật.
Mặt khác, cùng với sự lan rộng của Agile và DevOps, xu hướng thay thế SRS nặng nề lấy tài liệu làm trung tâm bằng đặc tả gọn nhẹ đang rất rõ rệt. Thay cho SRS chi tiết, yêu cầu được biểu diễn bằng user story ("Với vai trò ~, để ~, tôi muốn ~") trong product backlog cùng tiêu chí chấp nhận (Acceptance Criteria), và xa hơn nữa là đặc tả có thể thực thi BDD (Given-When-Then). Tiêu biểu, cú pháp Cucumber·Gherkin khiến yêu cầu trở thành kiểm thử tự động, như "Given số dư 100.000 won, When chuyển 50.000 won, Then số dư là 50.000 won".
Điểm đáng chú ý là hình thức chỉ chuyển từ tài liệu sang story, kịch bản, còn bản chất của yêu cầu là tính có thể kiểm chứng và khả năng truy vết vẫn giữ nguyên. Tiêu chí chấp nhận chính là tính có thể kiểm chứng, còn liên kết giữa mục backlog với kiểm thử, commit chính là khả năng truy vết. Trong các ngành chịu quản lý chặt quy mô lớn (tài chính, y tế, hàng không), mô hình lai vẫn duy trì SRS chính thức cho kiểm toán và chứng nhận, trong khi luồng phát triển nội bộ được đồng bộ thời gian thực với sản phẩm và công cụ Agile (Jira, Confluence, ALM) là dòng chính trong thực tế. Ví dụ, phần mềm thiết bị y tế bắt buộc phải lưu ma trận truy vết yêu cầu–thiết kế–kiểm chứng làm bằng chứng tuân thủ quy định để đáp ứng IEC 62304.
7. Lưu ý và hàm ý
Từ góc độ Kỹ sư chuyên nghiệp, SRS phải được tiếp cận không như một kỹ thuật viết tài liệu đơn thuần mà như chiến lược quản lý kiểm soát rủi ro dự án ngay từ đầu. Bốn điểm sau là cốt lõi.
Lấy tính có thể kiểm chứng và khả năng truy vết làm nguyên tắc thiết kế ưu tiên hàng đầu. Yêu cầu không đo được là mầm mống tranh chấp, nên cần định lượng mọi yêu cầu phi chức năng và liên kết hai chiều yêu cầu–thiết kế–mã–kiểm thử bằng ma trận truy vết yêu cầu (RTM). RTM là công cụ quản lý giúp nhận diện ngay phạm vi ảnh hưởng khi thay đổi, qua đó phòng ngừa khiếm khuyết hồi quy.
Trong Agile, gọn nhẹ hóa nhưng giữ nguyên bản chất. Dù thay SRS chi tiết bằng user story, tiêu chí chấp nhận, BDD, tính có thể kiểm chứng và khả năng truy vết vẫn được bảo đảm tự động bằng công cụ (Jira, Xray, Cucumber). Mục đích không phải là loại bỏ tài liệu mà là tạo ra đặc tả không lỗi thời và có thể thực thi.
Xây dựng hệ thống kiểm soát thay đổi trên tiền đề yêu cầu nhất định sẽ thay đổi. Đặc tả ban đầu hoàn hảo là bất khả thi, nên đặt baseline vào quản lý cấu hình và chỉ phản ánh thay đổi theo cách có kiểm soát thông qua thủ tục xem xét của CCB, phân tích tác động và phê duyệt lại. Thay đổi không kiểm soát (scope creep) chính là thủ phạm chính của vượt tiến độ và vượt chi phí.
Nhận thức rằng yêu cầu phi chức năng quyết định kiến trúc và xác lập sớm. Mục tiêu hiệu năng, tính sẵn sàng, bảo mật không thể chèn vào sau khi thiết kế, nên phải chốt các mục tiêu định lượng (TPS, thời gian phản hồi, tính sẵn sàng, RTO/RPO) ngay ở giai đoạn SRS để tạo đường cơ sở cho quyết định kiến trúc và các đánh đổi (ví dụ: nhất quán mạnh vs sẵn sàng cao).
Tài liệu tham khảo
- ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering. https://www.iso.org/standard/72089.html
- IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications. https://standards.ieee.org/ieee/830/1222/
- Tổng quan ISO/IEC/IEEE 29148 (Wikipedia). https://en.wikipedia.org/wiki/ISO/IEC/IEEE_29148
Tóm tắt một câu: SRS văn bản hóa các yêu cầu tổng quan, chức năng, phi chức năng, giao diện, ràng buộc, dữ liệu, phải có tính đầy đủ, rõ ràng, nhất quán, có thể kiểm chứng và khả năng truy vết, và dưới hệ thống ISO/IEC/IEEE 29148 kế thừa IEEE 830, nó định lượng hóa các yêu cầu mơ hồ và truy vết bằng RTM để kiểm soát từ sớm lỗi yêu cầu — nguyên nhân lớn nhất gây thất bại dự án.