14 mẹo để viết requirement tốt hơn

October 9, 2018

Theo IBM, làm tốt requirement giúp tiết kiệm rất nhiều công sức trong dự án. Tài liệu yêu cầu kỹ thuật (Requirements Specification Documents- RSD) là phương tiện giao tiếp chính giữa người dùng và phía phát triển nên cần được chuẩn bị cẩn thận như khi viết hợp đồng. RSD 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 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 để project tiến hành thuận lợi

Vậy, một requirement tốt là requirement 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

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:

　Vai trò người dùng được hưởng lợi từ requirement
　Trạng thái người dùng mong muốn đạt được
　Số liệu để kiểm tra requirement nếu có

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 .

14 mẹo để viết requirement tốt

Định nghĩa từng requirement một , mỗi requirement phải tối giản. Không sử dụng các từ liên hệ như “và”, “hoặc”, “đồng thời”, “tương tự” etc . Điều này đặc biệt quan trọng bởi vì những từ trên có thể khiến dev và tester đọc sót requirement. 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 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, ngôn ngữ lập trình và các object của system trong RSD , có khả năng tài liệu của bạn đang lạc đề
Tránh sự mơ hồ gây ra bởi việc sử dụng các từ viết tắt như “etc”,” khoảng ”
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”, vnv 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 ức đoán, tránh vẽ danh sách tính năng mơ ước không thể hoàn thành. Muốn một hệ thống có thể xử lý được mọi lỗi không tính trước là suy nghĩ viển vông vì không hệ thống nào có thể đạt được 100% yêu cầu mà bạn 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.
Tránh ghi requirement ghi 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 RSD của bạn cực kỳ khó đọc.
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…”