Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)
1. Tổng quan
A. Định nghĩa
Hoạt động kỹ nghệ phần mềm mà, thông qua một quy trình có hệ thống gồm khơi gợi, phân tích, đặc tả, kiểm chứng và quản lý nhu cầu của các bên liên quan, định nghĩa các yêu cầu mà hệ thống mục tiêu phải đáp ứng một cách chính xác, đầy đủ và nhất quán, đồng thời kiểm soát cả sự thay đổi của chúng.
Kỹ nghệ yêu cầu là hoạt động làm rõ "làm cái gì (What)", và được phân biệt với thiết kế, hiện thực vốn xử lý "làm như thế nào (How)". Nói cách khác, định nghĩa không gian bài toán (problem space) là bản chất của kỹ nghệ yêu cầu; đó là giai đoạn thống nhất chính xác về chính bài toán trước khi bước sang không gian lời giải (solution space). Nếu ranh giới này sụp đổ và chi tiết thiết kế bị chốt sớm ngay ở giai đoạn yêu cầu, dư địa để xem xét các phương án tốt hơn sẽ biến mất và yêu cầu bị lệ thuộc vào một hiện thực cụ thể, đánh mất tính linh hoạt.
Kỹ nghệ yêu cầu không đơn thuần là hoạt động soạn thảo tài liệu mà là kỹ nghệ của giao tiếp và đồng thuận. Vì mỗi bên liên quan có kiến thức nền, thuật ngữ và lợi ích khác nhau, luôn tồn tại khoảng cách ngữ nghĩa (semantic gap) khiến cùng một từ được diễn giải khác nhau. Kỹ nghệ yêu cầu thu hẹp khoảng cách này bằng các phương tiện kỹ nghệ là mô hình, đặc tả và kiểm chứng, để đội phát triển và bên đặt hàng hình dung cùng một "hệ thống" trong đầu.
Đặc biệt, do phần mềm là sản phẩm vô hình không thể nhìn thấy nên việc đồng thuận về yêu cầu càng khó hơn. Nếu là kiến trúc xây dựng thì có thể chia sẻ trước diện mạo hoàn thiện qua bản vẽ và phối cảnh, nhưng phần mềm khó thấy thực thể cho đến khi hoàn thành, nên các bên liên quan không thể diễn đạt yêu cầu của mình một cách cụ thể. Đây chính là lý do kỹ nghệ yêu cầu nhấn mạnh các phương tiện trực quan hóa như mô hình và prototype.
B. Bối cảnh ra đời và sự cần thiết
Nguyên nhân lớn nhất khiến dự án phần mềm thất bại không phải là lỗi lập trình mà là "làm tốt một thứ sai", tức là lỗi ở yêu cầu. Trong nhiều khảo sát ngành, bao gồm báo cáo CHAOS của Standish Group, yêu cầu không đầy đủ, yêu cầu thay đổi thường xuyên và thiếu sự tham gia của các bên liên quan luôn nằm ở nhóm nguyên nhân hàng đầu gây thất bại và trễ hạn dự án. Điều này cho thấy chất lượng yêu cầu, hơn cả chất lượng mã nguồn, quyết định số phận dự án trước tiên.
Lỗi yêu cầu càng được phát hiện muộn thì chi phí sửa chữa càng tăng theo cấp số nhân. Quy luật 1:10:100 — một lỗi tốn 1 để sửa ở giai đoạn yêu cầu sẽ tốn 10 ở thiết kế và 100 khi vận hành — nói lên điều đó. Lý do là trong lúc lỗi trôi xuôi dòng (downstream), thiết kế, mã nguồn, kiểm thử và tài liệu chồng lớp lên trên lỗi đó. Nếu lỗi yêu cầu lộ ra khi đang vận hành, phải truy ngược và sửa toàn bộ các sản phẩm đã tạo, khiến phạm vi làm lại bùng nổ.
Ngoài ra, nếu yêu cầu mơ hồ, phạm vi liên tục thay đổi trong quá trình phát triển (scope creep) và việc làm lại tăng vọt. Khi các yêu cầu chưa được đồng thuận như "cũng cần cả màn hình quản trị chứ" liên tục được thêm vào giữa chừng, khối lượng công việc tăng trong khi lịch trình và ngân sách giữ nguyên, và chất lượng sụp đổ. Để ngăn những tổn thất này, kỹ nghệ yêu cầu xử lý yêu cầu như một quy trình kỹ nghệ chứ không phải cuộc trò chuyện ngẫu hứng, bảo đảm sự đồng thuận và tính truy vết giữa các bên liên quan. Đặc biệt, bằng cách chốt yêu cầu thành baseline và kiểm soát thay đổi, nó làm rõ "đâu là phạm vi đã ký kết" và giảm tranh chấp cũng như làm lại.
2. Quy trình kỹ nghệ yêu cầu
Kỹ nghệ yêu cầu là hoạt động lặp mà năm giai đoạn vừa tuần tự vừa quay lại phân tích mỗi khi có thay đổi. Sơ đồ khái niệm dưới đây thể hiện dòng chảy của toàn bộ quy trình và vòng phản hồi thay đổi.
flowchart LR
E["Khơi gợi(Elicitation)"] --> A["Phân tích(Analysis)"]
A --> S["Đặc tả(Specification)"]
S --> V["Kiểm chứng(Validation)"]
V --> M["Quản lý(Management)"]
M -.thay đổi phát sinh.-> A
Mỗi giai đoạn tinh chỉnh sản phẩm của giai đoạn trước, cuối cùng hội tụ về một đặc tả yêu cầu đáng tin cậy. Sơ đồ chi tiết dưới đây thể hiện đầu vào mà mỗi giai đoạn tiêu thụ, sản phẩm nó tạo ra, cùng tương tác với các bên liên quan và công cụ quản lý cấu hình.
flowchart TB
ST["Các bên liên quan"] -->|nhu cầu/kỳ vọng| E2["Khơi gợi"]
E2 -->|danh sách yêu cầu thô| A2["Phân tích/Mô hình hóa"]
A2 -->|yêu cầu đã tinh chỉnh & ưu tiên| S2["Đặc tả(SRS)"]
S2 -->|bản nháp SRS| V2["Kiểm chứng(review/prototype)"]
V2 -->|yêu cầu đã phê duyệt| BL["Baseline yêu cầu"]
BL --> M2["Quản lý thay đổi(CCB/RTM)"]
M2 -.phân tích tác động rồi phân tích lại.-> A2
M2 -->|liên kết truy vết| RTM["Ma trận truy vết yêu cầu"]
A. Khơi gợi (Elicitation) — giai đoạn nhận diện các bên liên quan và khơi gợi nhu cầu, kỳ vọng của họ. Bài toán cốt lõi ở đây là người dùng thường không rõ chính bản thân họ muốn gì. Điều này gọi là bài toán tri thức ẩn (tacit knowledge): những quy tắc nghiệp vụ quá hiển nhiên với người trong nghề đến mức không nói ra thường không được phản ánh vào hệ thống và về sau trở thành lỗi.
Do đó, khơi gợi phải đào lên cả những yêu cầu tiềm ẩn bằng cách kết hợp không chỉ các kỹ thuật hỏi trực tiếp như phỏng vấn, workshop, mà cả quan sát (observation) công việc thực tế tại chỗ, prototyping dùng mô hình chạy được để khơi phản ứng, và phân tích tài liệu, log sẵn có. Ví dụ, khi xây hệ thống kho vận, chỉ phỏng vấn người phụ trách sẽ không lộ ra luồng ngoại lệ "khi bận thì viết tay thay vì quét mã vạch", nhưng quan sát tại hiện trường thì nắm bắt được ngay.
Ngoài ra, ở giai đoạn khơi gợi, xung đột yêu cầu giữa các bên liên quan lần đầu lộ ra. Vì bộ phận kinh doanh ưu tiên sự đa dạng tính năng, bộ phận vận hành ưu tiên tính ổn định, bộ phận tài chính ưu tiên cắt giảm chi phí, nên khơi gợi phải là quá trình bảo đảm cân bằng các góc nhìn khác nhau chứ không chỉ là thu thập. Vì thiên lệch về một bên liên quan có tiếng nói lớn sẽ làm méo mó yêu cầu, việc nhận diện đầy đủ các bên liên quan qua bản đồ các bên liên quan (stakeholder map) phải được thực hiện trước.
B. Phân tích (Analysis) — giai đoạn giải quyết xung đột, trùng lặp và mơ hồ trong các yêu cầu đã thu thập, đồng thời cân nhắc tính khả thi và mức ưu tiên. Yêu cầu thô tồn tại ở dạng mâu thuẫn lẫn nhau ("vừa nhanh vừa rẻ"), trùng lặp (cùng một yêu cầu diễn đạt khác nhau), hoặc không thể kiểm chứng (như "phải dễ dùng"). Phân tích tinh chỉnh chúng thành dạng có thể phát triển được.
Lúc này, mô hình hóa bằng use case, DFD, UML là phương tiện cốt lõi. Ngôn ngữ tự nhiên thì mơ hồ, nhưng mô hình cấu trúc hóa yêu cầu và phơi bày một cách trực quan các thiếu sót và mâu thuẫn. Ví dụ, trong lúc vẽ sơ đồ use case, một luồng chưa định nghĩa như "nếu người dùng chưa xác thực thử thanh toán thì sao?" sẽ được phát hiện một cách tự nhiên. Mô hình cũng là công cụ đối thoại với các bên liên quan: thảo luận trước một hình vẽ sẽ giảm hiểu lầm so với văn bản.
Để quyết định mức ưu tiên, người ta dùng MoSCoW (Must/Should/Could/Won't) hoặc mô hình Kano. Nếu đối xử mọi yêu cầu như nhau thì tài nguyên sẽ thiếu cho những yêu cầu thực sự quan trọng, nên phải phân biệt cái nhất thiết cần (Must) với cái có thì tốt (Could). Mô hình Kano chia yêu cầu thành chất lượng đương nhiên, chất lượng một chiều và chất lượng hấp dẫn, giúp phân biệt "yêu cầu đương nhiên" gây bất mãn khi thiếu nhưng không tạo cảm xúc khi có, với "yêu cầu hấp dẫn" mà sự hiện diện của nó làm mức hài lòng tăng vọt. Ví dụ, trong app ngân hàng "chuyển khoản được xử lý chính xác" là yêu cầu đương nhiên nên dù làm tốt cũng không được khen, còn "đăng nhập sinh trắc học trong 3 giây" là yêu cầu hấp dẫn nên trở thành lợi thế cạnh tranh. Với ngân sách hạn chế, hợp lý là hoàn thiện các yêu cầu đương nhiên trước rồi mới đầu tư vào yêu cầu hấp dẫn.
Xem xét tính khả thi cũng là cốt lõi của phân tích. Phải loại sớm các yêu cầu bất khả thi bằng cách cân nhắc liệu có hiện thực được về mặt kỹ thuật, có đạt được trong lịch trình và ngân sách, có xung đột với ràng buộc pháp lý và tổ chức hay không. Nếu việc xem xét này sơ sài, ở nửa sau quá trình phát triển sẽ lộ ra sự thật "yêu cầu này vốn dĩ bất khả thi", gây làm lại quy mô lớn.
C. Đặc tả (Specification) — giai đoạn tài liệu hóa các yêu cầu đã đồng thuận thành SRS (đặc tả yêu cầu). Vì SRS là tài liệu mang tính hợp đồng, trở thành cơ sở chung cho phát triển, kiểm thử và nghiệm thu, nên phải tối thiểu hóa dư địa diễn giải. Để giảm sự mơ hồ của ngôn ngữ tự nhiên, người ta kết hợp đặc tả use case, user story, và khi cần cả đặc tả hình thức (Z, máy trạng thái, v.v.). Ví dụ, ở các miền quan trọng về an toàn như tài chính, hàng không, đôi khi mô tả yêu cầu bằng toán học qua đặc tả hình thức để chặn sự mơ hồ ngay từ gốc.
Khi viết đặc tả, tính nhất quán trong biểu đạt cũng quan trọng. Gọi cùng một khái niệm bằng các thuật ngữ khác nhau khắp tài liệu (ví dụ: "thành viên", "người dùng", "người đăng ký") sẽ gây hiểu lầm, nên cần lập bảng thuật ngữ (glossary) để thống nhất từ vựng miền. Ngoài ra, phải gán cho mỗi yêu cầu một định danh duy nhất (REQ-001, v.v.) thì sau này mới có thể gắn liên kết truy vết, và khi thay đổi mới chỉ ra rõ ràng yêu cầu nào đã đổi. Yêu cầu dạng tường thuật không có định danh thì không thể truy vết ở giai đoạn quản lý và thực chất nằm ngoài tầm kiểm soát.
D. Kiểm chứng (Validation) và Quản lý (Management) — Kiểm chứng là giai đoạn xác nhận, qua review, inspection và prototype, liệu đặc tả có chứa đựng nhu cầu thực tế của các bên liên quan một cách chính xác, đầy đủ và nhất quán hay không. Ở đây, sự phân biệt giữa kiểm chứng (validation, có đang làm đúng thứ cần làm không) và xác minh (verification, có làm đúng theo đặc tả không) là quan trọng. Vì lỗi yêu cầu bị bỏ sót ở khâu kiểm chứng sẽ trôi thẳng xuống hạ nguồn, kiểm chứng là tuyến phòng thủ cuối cùng của kỹ nghệ yêu cầu. Prototype là phương tiện kiểm chứng đặc biệt mạnh: khi bên liên quan xem màn hình chạy được và chỉ ra sớm rằng "cái này không phải điều tôi hình dung", có thể loại bỏ với chi phí thấp những hiểu lầm mà tài liệu không bắt được.
Quản lý là hoạt động chốt các yêu cầu đã xác nhận thành baseline, rồi kiểm soát thay đổi về sau qua quản lý cấu hình, RTM và Hội đồng kiểm soát thay đổi (CCB). Mục đích không phải ngăn chặn bản thân sự thay đổi, mà là phân tích tác động của thay đổi và chỉ phản ánh qua quy trình đã đồng thuận, để ngăn thay đổi hỗn loạn. Khi có yêu cầu thay đổi, CCB phân tích tác động lan tỏa của thay đổi đó lên lịch trình, chi phí, chất lượng và các yêu cầu khác rồi quyết định phê duyệt, giữ lại hay bác bỏ; chỉ khi có quy trình này mới có thể chặn về mặt thể chế hiện tượng scope creep — "phạm vi âm thầm phình to chỉ vì một câu yêu cầu của ai đó".
| Giai đoạn | Hoạt động | Kỹ thuật tiêu biểu | Sản phẩm chính |
|---|---|---|---|
| Khơi gợi | Nhận diện bên liên quan, thu thập yêu cầu | Phỏng vấn, workshop, quan sát, prototyping | Danh sách yêu cầu thô |
| Phân tích | Giải quyết xung đột/trùng lặp, ưu tiên | Use case, DFD/UML, MoSCoW, Kano | Mô hình yêu cầu, mức ưu tiên |
| Đặc tả | Tài liệu hóa SRS | Đặc tả ngôn ngữ tự nhiên/hình thức, đặc tả use case | SRS |
| Kiểm chứng | Kiểm tra chính xác/đầy đủ/nhất quán | Review/inspection, prototype | Yêu cầu đã phê duyệt |
| Quản lý | Quản lý thay đổi/lịch sử/truy vết | Quản lý cấu hình, RTM, CCB | Baseline, RTM |
3. Các loại yêu cầu
Lý do phân loại yêu cầu là vì phương pháp kiểm chứng và tác động thiết kế khác nhau theo từng loại. Yêu cầu chức năng định nghĩa hành vi của hệ thống nên tương đối dễ biểu đạt và kiểm chứng, còn yêu cầu phi chức năng lại tác động một cách tinh vi lên toàn hệ thống, dễ bị bỏ sót nhưng lại chi phối kiến trúc một cách căn bản.
Đặc biệt, yêu cầu phi chức năng (NFR) là động lực cốt lõi của các quyết định kiến trúc. Ví dụ, yêu cầu hiệu năng "10.000 người dùng đồng thời, đáp ứng trong 2 giây" là bất khả thi trên một máy chủ đơn và buộc phải có cân bằng tải, cache, kiến trúc phân tán ngay từ đầu. Ngược lại, nếu yêu cầu này không được đặc tả mà cứ phát triển, khi vấn đề hiệu năng bùng nổ về sau sẽ phát sinh kiểu làm lại tệ nhất là phải đại tu toàn bộ kiến trúc. Vì vậy NFR không phải "thứ để tinh chỉnh sau" mà là thứ phải chốt trước khi thiết kế.
Để khơi gợi NFR một cách có hệ thống, tham chiếu phân loại chuẩn về đặc tính chất lượng là hiệu quả. Mô hình chất lượng sản phẩm ISO/IEC 25010 đưa ra tám đặc tính — phù hợp chức năng, hiệu quả hiệu năng, khả năng tương thích, khả dụng, độ tin cậy, bảo mật, khả năng bảo trì, khả năng chuyển đổi — và dùng danh sách này như một checklist có thể ngăn những thiếu sót kiểu "đã đặt tính sẵn sàng nhưng bỏ quên mục tiêu bảo trì". Nói cách khác, nên khơi gợi NFR đầy đủ dựa trên phân loại chuẩn thay vì liệt kê theo cảm tính.
Ràng buộc là điều kiện bên ngoài mà hệ thống nhất thiết phải tuân theo, giới hạn lựa chọn của đội phát triển. Luật và quy định như Luật Bảo vệ thông tin cá nhân, quy chế giám sát tài chính điện tử, một nền tảng hay ngôn ngữ cụ thể, ngân sách và thời hạn thuộc về đây. Phải nêu rõ ràng ràng buộc tách biệt với yêu cầu thì khi xem xét phương án thiết kế mới loại được ngay từ đầu những phương án vi phạm. Vì phát hiện ràng buộc muộn nghĩa là phải hủy bỏ thiết kế đã chốt, về nguyên tắc việc nhận diện ràng buộc nên hoàn tất ở giai đoạn đầu của phân tích.
| Phân loại | Nội dung | Ví dụ |
|---|---|---|
| Yêu cầu chức năng | Chức năng/dịch vụ hệ thống thực hiện | Đăng nhập, xử lý đơn hàng |
| Yêu cầu phi chức năng | Thuộc tính chất lượng như hiệu năng/bảo mật/sẵn sàng | Đáp ứng 2 giây, sẵn sàng 99,9% |
| Ràng buộc | Ràng buộc pháp lý/chuẩn/nền tảng/ngân sách | Tuân thủ Luật Bảo vệ thông tin cá nhân |
4. Đặc tả yêu cầu (SRS) và các đặc tính chất lượng
SRS gồm mục đích và phạm vi, yêu cầu chức năng/phi chức năng, giao diện, điều kiện ràng buộc, và phải thỏa mãn các đặc tính chất lượng về "thế nào là một yêu cầu tốt". Chuẩn quốc tế ISO/IEC/IEEE 29148 đưa ra các đặc tính mà một yêu cầu tốt cần có như sự cần thiết, tính rõ ràng, tính đầy đủ, tính nhất quán, khả năng kiểm chứng và khả năng truy vết (một chuẩn đã thay thế và tích hợp IEEE 830-1998 từng được dùng rộng rãi).
Lý do các đặc tính này quan trọng là vi phạm dù chỉ một đặc tính cũng dẫn tới khác biệt diễn giải và làm lại ở giai đoạn phát triển. Ví dụ, yêu cầu "màn hình phải nhanh" là không thể kiểm chứng, nên phải viết sao cho kiểm chứng được với điều kiện và tiêu chí định lượng, như "màn hình chính tải trong vòng 2 giây trên môi trường 3G". Nếu không có khả năng kiểm chứng, tại thời điểm nghiệm thu bên đặt hàng và nhà phát triển sẽ tranh cãi quanh chuyện "nhanh/chậm".
Tính đầy đủ và tính nhất quán đặc biệt dễ bị bỏ sót. Tính đầy đủ nghĩa là liệu đã xử lý không thiếu sót cả điều kiện ngoại lệ và biên chứ không chỉ luồng bình thường. Nếu các ngoại lệ như "khi thanh toán thất bại thì sao", "nếu tồn kho âm thì sao?" bị bỏ khỏi đặc tả, lập trình viên sẽ xử lý tùy tiện và gieo mầm cho lỗi. Tính nhất quán nghĩa là không được có mâu thuẫn giữa các yêu cầu, và quy mô càng lớn thì nguy cơ các yêu cầu khác nhau va chạm càng cao, nên cần cả quản lý truy vết đi kèm.
| Đặc tính | Ý nghĩa |
|---|---|
| Tính đầy đủ | Bao gồm mọi yêu cầu cần thiết (gồm ngoại lệ/biên) |
| Tính nhất quán | Không có xung đột giữa các yêu cầu |
| Tính rõ ràng | Không mơ hồ, chỉ một cách diễn giải |
| Khả năng kiểm chứng | Xác nhận được bằng kiểm thử (tiêu chí định lượng) |
| Tính truy vết | Liên kết yêu cầu cấp trên |
5. So sánh và các trường hợp ứng dụng
Diện mạo thực tế của kỹ nghệ yêu cầu phân hóa lớn theo tính chất dự án. Bảng dưới đây so sánh quản lý yêu cầu theo phương pháp dựa trên kế hoạch (plan-driven) và phương pháp agile. Khác biệt giữa hai phương pháp không đơn thuần là chuyện khối lượng tài liệu, mà xuất phát từ khác biệt triết lý căn bản về "khi nào chốt yêu cầu".
| Góc nhìn | Dựa trên kế hoạch (thác nước) | Agile |
|---|---|---|
| Thời điểm chốt yêu cầu | Chốt trọn gói từ đầu | Chốt dần theo từng sprint |
| Hình thức biểu đạt | Tài liệu SRS | User Story·Backlog |
| Thái độ với thay đổi | Kiểm soát·tối thiểu hóa | Chấp nhận·hoan nghênh |
| Miền phù hợp | Trọng quy định·an toàn (tài chính·hàng không·y tế) | Dịch vụ có bất định thị trường lớn |
| Kiểm chứng | Review·inspection·kiểm thử nghiệm thu | DoD·điều kiện nghiệm thu·demo |
Lý do căn bản khiến khác biệt này nảy sinh là đường cong chi phí thay đổi khác nhau theo từng miền. Với hệ thống như kiểm soát không lưu, nơi một khi đã triển khai thì sửa chữa cực kỳ khó và liên quan trực tiếp đến tai nạn an toàn, chi phí chốt hoàn hảo yêu cầu từ đầu và thậm chí trải qua cả kiểm chứng hình thức là chính đáng. Ngược lại, dịch vụ thương mại điện tử của startup lại có lợi hơn khi liên tục thay đổi yêu cầu theo phản ứng thị trường, nên chốt hoàn toàn từ đầu lại thành lãng phí. Do đó điểm phán đoán của kỹ sư yêu cầu không phải "phương pháp nào đúng" mà "phương pháp nào hợp với dự án này".
Một trường hợp cụ thể: trong các dự án tin học hóa công quy mô lớn, ở giai đoạn đặt hàng người ta chốt hồ sơ mời thầu (RFP) và bản định nghĩa yêu cầu chi tiết rồi lấy đó làm phạm vi hợp đồng. Nếu yêu cầu ở đây sơ sài, tranh chấp về phạm vi công việc sẽ xảy ra thường xuyên trong lúc thực hiện, nên việc chi tiết hóa yêu cầu và bảo đảm truy vết quyết định thành bại của dự án. Ngược lại, trong phát triển dịch vụ di động nội bộ, phản hồi người dùng được đưa vào backlog theo từng sprint 2 tuần, và trong 6 tháng việc phần lớn yêu cầu khác so với định nghĩa ban đầu được xem là bình thường. Cùng là "kỹ nghệ yêu cầu" nhưng cách vận hành lại trái ngược nhau.
6. Chuyên sâu: Kỹ nghệ yêu cầu trong kỷ nguyên Agile và các xu hướng mới nhất
Kỹ nghệ yêu cầu truyền thống giả định một Big Design Up Front chốt yêu cầu một lần từ đầu quá trình phát triển, nhưng khi thay đổi thị trường, công nghệ tăng tốc thì giả định này lung lay. Yêu cầu tất yếu thay đổi theo thời gian, thế mà nỗ lực chốt tất cả từ đầu lại đối xử với thay đổi như một khiếm khuyết và gây ma sát. Đáp lại, agile đã chuyển đổi hệ hình theo hướng chấp nhận sự biến động của yêu cầu như điều tự nhiên.
Trong agile, SRS không được chốt một lần mà được biểu đạt thành User Story·Product Backlog và tinh chỉnh dần theo từng sprint lặp. Mỗi story được viết theo dạng "vai trò-chức năng-giá trị (As a … I want … so that …)", và khả năng kiểm chứng được bảo đảm qua Định nghĩa Hoàn thành (DoD) và Điều kiện nghiệm thu (Acceptance Criteria). Tuy nhiên agile không xóa bỏ kỹ nghệ yêu cầu. Khơi gợi, phân tích, kiểm chứng vẫn cần thiết; chỉ có điều thời điểm của chúng, vốn tập trung ở đầu dự án, nay được phân tán qua tất cả các sprint. Quản lý ưu tiên backlog và các buổi tinh chỉnh (refinement) story chính là kỹ nghệ yêu cầu thường trực.
Gần đây, hệ thống IREB CPRE (Certified Professional for Requirements Engineering) chứng nhận chuyên môn kỹ nghệ yêu cầu đang lan rộng trên phạm vi quốc tế, và các công cụ hỗ trợ quản lý yêu cầu (Jira, DOORS, Polarion, v.v.) đang tự động hóa truy vết và phân tích tác động. Hơn nữa, các thử nghiệm dùng AI tạo sinh để trích xuất ứng viên yêu cầu thành bản nháp từ bản ghi phỏng vấn bên liên quan, hoặc tự động rà soát sự mơ hồ, trùng lặp của đặc tả yêu cầu đang tăng lên. Tuy vậy, vì bản nháp yêu cầu do AI tạo ra rốt cuộc vẫn phải được con người kiểm chứng và đồng thuận, AI đang có xu hướng định vị như công cụ hỗ trợ giúp tạo bản nháp và rà soát chất lượng hơn là thay thế kỹ sư yêu cầu.
Một xu hướng đáng chú ý khác là kỹ nghệ yêu cầu dựa trên mô hình (model-based). Nếu thay vì SRS văn bản, ta liên kết và quản lý yêu cầu, cấu trúc, hành vi bằng một mô hình như SysML, thì có thể tự động truy vết tác động của thay đổi yêu cầu lên mô hình thiết kế, kiểm thử. Đặc biệt, cách tiếp cận dựa trên mô hình đang lan rộng ở các lĩnh vực như ô tô, hàng không, nơi hệ thống phức tạp và cần chứng nhận an toàn. Điều này cho thấy một sự thay đổi góc nhìn, trong đó yêu cầu không còn là tài liệu tĩnh chỉ nằm ở đầu quá trình phát triển, mà được xem như một tài sản sống động xuyên suốt toàn bộ vòng đời phát triển.
7. Cân nhắc và hàm ý
- Bảo đảm tính truy vết (Traceability): Nếu liên kết hai chiều yêu cầu-thiết kế-mã nguồn-kiểm thử qua RTM (ma trận truy vết yêu cầu), thì khi yêu cầu thay đổi, phân tích tác động diễn ra tức thì và kiểm thử không thiếu sót được bảo đảm. Đây là công cụ cốt lõi của bảo đảm chất lượng, và ở các ngành có quy định (thiết bị y tế, hàng không), bằng chứng truy vết là bắt buộc để được chứng nhận.
- Quản lý thay đổi và baseline: Cốt lõi là thay đổi có kiểm soát, tức không chặn thay đổi vô điều kiện mà phân tích tác động (lịch trình/chi phí/chất lượng) qua CCB và chỉ phản ánh những gì đã đồng thuận. Không có baseline thì "đâu là phạm vi hợp đồng" trở nên mơ hồ, và tranh chấp cùng scope creep phát sinh.
- Chọn chiến lược quản lý yêu cầu hợp với phương pháp luận: Với miền mà yêu cầu ổn định và quy định nghiêm ngặt thì SRS dựa trên tài liệu và kiểm chứng hình thức có lợi; với miền có bất định thị trường lớn thì tinh chỉnh dần dựa trên backlog có lợi. Không phải áp dụng đồng nhất mà phán đoán đánh đổi phù hợp với đặc tính dự án mới là năng lực của kỹ sư yêu cầu.
- Sự tham gia và đồng thuận (sign-off) của bên liên quan: Rốt cuộc, nền tảng của thành công kỹ nghệ yêu cầu là con người chứ không phải công cụ. Không có sự tham gia tích cực và đồng thuận rõ ràng (sign-off) của các bên liên quan thì dù SRS viết tốt đến đâu cũng bị vô hiệu hóa bởi việc từ chối nghiệm thu "đây không phải điều chúng tôi muốn".
- Chốt sớm yêu cầu phi chức năng: Vì các NFR như hiệu năng, bảo mật, tính sẵn sàng chi phối kiến trúc, phải chốt chúng bằng tiêu chí định lượng trước khi thiết kế. Một NFR lộ ra muộn sẽ kéo theo chi phí tệ nhất là đại tu toàn bộ kiến trúc.
- Đưa AI/tự động hóa vào và trách nhiệm kiểm chứng: Tuy AI tạo sinh giúp tăng tốc bản nháp yêu cầu và rà soát mơ hồ, phải làm rõ rằng trách nhiệm về tính chính xác và sự đồng thuận của yêu cầu cuối cùng thuộc về con người. Chấp nhận thiếu phê phán các yêu cầu tự sinh có thể khiến những yêu cầu nghe hợp lý nhưng sai khác thực tế lọt vào đặc tả, nên cần dùng AI như công cụ tăng năng suất trong khi vẫn duy trì cổng kiểm chứng.
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
- IREB (International Requirements Engineering Board): https://www.ireb.org/en/
- SWEBOK Guide V3.0, Software Requirements (Chapter 1), IEEE Computer Society: https://www.computer.org/education/bodies-of-knowledge/software-engineering
Tóm tắt một câu: Kỹ nghệ yêu cầu hệ thống hóa nhu cầu của các bên liên quan một cách kỹ nghệ qua quy trình khơi gợi→phân tích→đặc tả→kiểm chứng→quản lý, và phòng ngừa lỗi yêu cầu cùng thất bại dự án (1:10:100) bằng SRS đầy đủ, nhất quán, rõ ràng, kiểm chứng được, truy vết được cùng baseline, RTM, CCB; trong agile nó đang tiến hóa thành tinh chỉnh yêu cầu dần dựa trên backlog.