Spec của dự án là do ai viết?'
Nếu bạn làm trong các dự án outsourcing (gia công phần mềm) thì thường spec (viết tắt của từ specification - tài liệu mô tả kỹ thuật, tài liệu mô tả chi tiết) là do phía khách hàng viết và chuyển sang nhóm phát triển. Thường là tài liệu mô tả chi tiết các màn hình của hệ thống.
Còn nếu bạn làm trong các công ty, hay nhóm phát triển sản phẩm (product) thì tài liệu do PM hoặc BA viết. Nhưng cũng có nhiều công ty, do UX designer góp phần thiết kế nội dung các màn hình (Wireframe hoặc Prototype) và các luồng nghiệp vụ, kịch bản sử dụng chức năng và phi chức năng (ví dụ usability - tính khả dụng) của hệ thống.
Nhưng cũng có công ty gia công phần mềm ở Việt Nam, thì QC kiêm luôn việc đi lấy yêu cầu và viết tài liệu SRS/Spec.
Các thuật ngữ
To be determined - TBD: Những vấn đề chưa quyết định
Mục này sẽ viết những vấn đề hiện tại chưa thể giải quyết, quyết định được ngay, trong quá trình phát triển hệ thống rất hay nảy sinh ra những vấn đề như thế này. Để tránh việc bị thiếu trong quá trình viết thì khi nhận thấy vấn đề cần viết ngay lại chứ không chờ sau này mới tổng hợp lại.
Pending Point - PP: Các chức năng đang treo
PP là các chức năng lớn, thường là 1 sub-module hoặc 1 nhóm các tính năng rời rạc được gom lại dưới một tên chung. PP có thể ảnh hưởng trực tiếp tới báo giá (chi phí) và lộ trình triển khai (timeline).
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.
Kinh nghiệm viết requirement tốt
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 các thông tin:
- 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ó
- Tiêu chí khách quan để đánh giá requirement
- Phạm vi đánh giá, đo lường trong bối cảnh của một tình huống cụ thể
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 .
22 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 giống như một câu chuyện (user story) dẫn dắt đi từ nỗi đau (pain point) đến kỳ vọng trong tương lai (to-be)
- 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).
- Phân loại các yêu cầu càng logic và khoa học càng tốt.
- Tránh mô tả cách hệ thống làm việc chi tiết 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 hoặc các yêu cầu cấp thấp (low-level requirements). Thông thường, khi bạn đề cập đến tên trường dữ liệu, ngôn ngữ lập trình, các thiết kế đối tượng, mô hình dữ liệu..., 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 viết trùng lặp Requirement hoặc User Case.
- Tránh phân tích requirement không đủ tới, dẫn đến tình trạng phát sinh luồng con, luồng phụ.
- Tránh phân tích nửa vời, dẫn đến tình trạng requirement "chân trong, chân ngoài" (in-scope, out-scope).
- 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.
- Khô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.
- Đảm bảo phải có ít nhất một sơ đồ tổng thể (BPMN) về Business Case, Business Blueprint
- 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 xa các cụm từ buông bỏ như nhưng, ngoại trừ và chỉ khi cần thiết.
- 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 - TBD (To be defined).Nếu có, nên tách ra 1 danh sách các Pending Points để thảo luận bên lề.
- Sử dụng câu khẳng định như “Hệ thống sẽ…” thay vì “Hệ thống sẽ không…”
- Tập trung trọng tâm bằng cách loại bỏ các cụm từ lan man, dài dòng và tham chiếu đến các bài viết lỗi thời.
TIGO PMO - Quản lý và đánh giá chất lượng phần mềm
