Làm tốt khâu đầu vào "Requirement Gathering/Elicitation" giúp tiết kiệm rất nhiều công sức trong dự án ở các khâu đầu ra. Tài liệu yêu cầu kỹ thuật (Requirements Specification Document - tạm gọi là Spec) là phương tiện giao tiếp chính giữa người dùng và bên phát triển nên cần được chuẩn bị cẩn thận như khi viết hợp đồng. Spec nên được coi là một thỏa thuận ràng buộc trong đó có các điều kiện về việc liệu giải pháp đề xuất có được chấp nhận hay không. Việc viết requirement không phải rất khó, có thể được cải thiện thông qua học tập liên tục và thực hành. Các BA (Business Analyst) nên chú ý đến từng chi tiết nhỏ, từ phong cách, cấu trúc, trình bày đến nội dung để dự án tiến hành thuận lợi.
Vậy, một requirement tốt là như thế nào ?
Mặc dù không có tiêu chuẩn nào rõ ràng cho tất cả các cách viết requirement tùy thuộc cách tiếp cận vấn đề, nhưng việc tuân theo các cấu trúc dưới đây sẽ giúp cải thiện chất lượng rõ rệt.
Spec là tài liệu quan trọng được cung cấp trong quản lý dự án chi phí cố định (fix-bid) hoặc dự án có độ dài xác định và mô hình lập kế hoạch cuốn chiếu (waterfall - thác nước), vì nó xác định rất rõ ràng mục tiêu của dự án là đạt được, cách thức thực hiện và tiêu chí nào sẽ được sử dụng để đo lường sự thành công của dự án.
Lý tưởng nhất, mỗi requirement được viết từ góc nhìn của người dùng nên chứa các thông tin sau:
- Vai trò người dùng được hưởng lợi từ requirement (đơn vị hưởng thụ).
- Trạng thái người dùng mong muốn đạt được .
- Số liệu để kiểm tra requirement nếu có.
- Tổng hợp kết quả từ các phân tích sơ bộ trước đó, ví dụ phân tích GAP, phân tích thực trạng (AS-IS), phân tích kỳ vọng trong tương lai (TO-BE), phân tích PoC (Proof of Concept)...
Ngoài việc đảm bảo mỗi requirement đều tuân theo cấu trúc trên, hãy xem xét tham khảo những lời khuyên dưới đây về những điều nên/ không nên làm.
Các mẹo viết requirement tốt:
- Định nghĩa từng requirement một, mỗi requirement phải tối giản và không chồng chéo, không thể chia nhỏ hơn nữa (atomic). Mỗi requirement nên giống như một câu chuyện chia sẻ của người dùng (User Story), hoặc có thể bao gồm "nỗi đau" (pain points) từ vận hành hệ thống hiện tại (hoặc một phần mềm tương đương).
- Không sử dụng các từ liên hệ như “và”, “hoặc”, “đồng thời”, “tương tự”... Điều này đặc biệt quan trọng bởi vì những từ trên có thể khiến lập trình viên (Dev) và Kiểm thử viên (Tester) đọc sót requirement, diễn dịch sai (interpretation) từ Business Requirement (các yêu cầu mô tả theo ngôn ngữ nghiệp vụ) sang Functional Requirement (là các yêu cầu được mô hình hóa lên phần mềm). Nên tách nhỏ các requirement phức tạp ra cho đến khi mỗi yêu cầu có thể được coi là một test case độc lập.
- Tránh sử dụng các mệnh đề như “ngoại trừ”, “nhưng” trừ trường hợp thật cần thiết.
- Mỗi yêu cầu phải tạo thành một câu hoàn chỉnh không có tiếng lóng hoặc từ viết tắt.
- Mỗi yêu cầu phải chứa chủ ngữ (người dùng / hệ thống) và một vị ngữ (kết quả dự định, hành động hoặc điều kiện).
- Tránh mô tả cách hệ thống làm việc như thế nào. Chỉ thảo luận hệ thống sẽ phải làm được gì, không đề cập thiết kế hệ thống. Thông thường, khi bạn đề cập đến tên trường dữ liệu (thay vì mô tả "tên trường thông tin"), hoặc "gài" ngôn ngữ lập trình và các công nghệ cụ thể trong Spec, có khả năng tài liệu của bạn đang lạc đề. Đơn vị thẩm định dễ dàng phát hiện ra các vấn đề này dù bạn vô ý hay cố ý.
- Tránh sự mơ hồ gây ra bởi việc sử dụng các từ viết tắt như “vân vân”, ”khoảng”, "giống như"...
- Quá nhiều thông tin cũng dễ gây ra sự mơ hồ, mập mờ. SDR không chứa các lập luận để khẳng định đúng/sai hay tốt/xấu ở điểm nào (dichotomies), mà chỉ là cơ sở để khoanh phạm vi phổ quát (spectrum).
- Tránh sử dụng các thuật ngữ không thể định nghĩa như “thân thiện với người dùng”,” linh hoạt”, “nhanh”, “tác động tối thiểu”,... Các thuật ngữ này thường được hiểu theo các hướng khác nhau với những người khác nhau, khiến việc xác định Test Case trở nên khó khăn.
- Tránh sử dụng các câu dài không cần thiết hoặc tham chiếu đến các tài liệu không thể truy cập được.
- Đừng suy đoán, tránh lập ra danh sách tính năng mong muốn nhưng không thể đạt được. Nói rằng bạn muốn một hệ thống xử lý tất cả các lỗi không mong muốn là điều viển vông vì sẽ không có hệ thống nào đạt 100% như bạn mong muốn.
- Tránh lặp lại hay viết những điều mâu thuẫn với những điều đã viết.
- Không thể hiện các gợi ý hoặc khả năng bằng cách tránh những từ như “có lẽ/ có thể”,”nên”, v.v.
- Không có thông tin từ điển (Project Glossary) mô tả thuật ngữ nghiệp vụ ngành (business domain) hoặc từng vai trò đối tượng, phạm vi quyền hạn của từng đối tượng tham gia tương tác với hệ thống.
- Tránh ghi requirement phân tán ở nhiều nơi, khiến người đọc phải tham khảo chéo tài liệu. Điều này có thể làm cho Spec của bạn cực kỳ khó đọc.
- Spec cũng phải theo cấu trúc, tránh biến Spec thành tài liệu chỉ thu thập (gathering) các yêu cầu vụn vặt.
- Spec mô tả các vấn đề, các giả định hơn là đưa vào các giải pháp chưa được kiểm định.
- Spec không có bất cứ sơ đồ nào ngoài chữ và các giao diện vẽ tay (wireframe), điều này mang lại rủi ro cao vì các yêu cầu phải đi từ tổng quát đến cụ thể qua một phễu lọc thông tin. Ít nhất Spec cũng phải thể hiện các sơ đồ tổng quan về nghiệp vụ như BPMN diagram.
- Không nên viết trong requirement những điều chưa xác định.
- Sử dụng câu khẳng định như “Hệ thống sẽ…” thay vì “Hệ thống sẽ không…”. Spec có thể chứa tập mờ (fuzzy) nhưng phải đảm bảo tập thông tin đó không gây ra các vấn đề leo thang phạm vi (scope creep) khi triển khai dự án.
Lưu ý: Yêu cầu mờ (fuzzy requirements) là chấp nhận được trong "Business Case", ví dụ như "Hệ thống mới phải nhanh hơn và thân thiện hơn với người dùng". Tuy nhiên, trong BRD, "nhanh hơn" và "thân thiện với người dùng" phải được lượng hóa được và kiểm định được.
Các đơn vị phân tích yêu cầu có xu hướng phân loại requirement theo cấu trúc "Bắt buộc / Mong muốn cao / Mong muốn vừa / Không bắt buộc" cho mỗi Business Requirement dạng khái quát (high-level) để đảm bảo rằng nếu vượt chi phí, sẽ cần sắp xếp lại ưu tiên, các bên liên quan có sẵn một danh sách các thông tin đầu vào để ra quyết định, bao gồm các vùng an toàn (inclusion) và vùng phạm vi loại trừ (exclusion) nhằm loại ra các Pending Points (các vấn đề đang treo).
Quản lý dự án PMO, TIGO Solutions