Tiếp tục sê ri công đoạn phát triển phần mềm, hôm nay mời quí bạn và các vị đến với “định nghĩa yêu cầu” 要件定義 – Requirements Definition. Đáng lẽ nó được viết trước basic design và detail design (cho đúng thứ tự) nhưng thấy khó ăn quá nên mình phải viết cái dễ trước khó sau. Quả thật là những BrSE được có cơ hội làm công đoạn này không nhiều. Một phần vì kỹ năng nghe, thứ 2 là nó rất khó. Mình thì may mắn được đi hóng hớt suốt 2 tháng trời, hằng ngày muối mặt ở shinjuku (ngay khu phố trong bộ phim Đại Náo Shinjuku – Thành Long) nghe khách hàng nói trên trời dưới đất. Dạo ấy đi cùng mình là 1 bác đồng nghiệp người Nhật, người sau này mình gọi là shisho (師匠 – sư phụ). Bác ấy nghe chính còn mình chỉ phụ hoạ chứ hồi đó mới nứt mắt thì bít cái đếu j mà hear vs chả ring. Đến tận mấy dự án sau này, ngồi đọc các tài liệu nên cũng thấm dần, đầu đất mà mưa dầm thì nó cũng nhão ra 😀

Giải thích thuật ngữ

Hẳn là các bạn đã từng nghe đến “phân tích yêu cầu” – “tài liệu định nghĩa yêu cầu” –  要件分析 – 要求分析 – 要求定義書 – 要件定義書 và không hiểu nó là cái ếu gì và khác vẹo gì nhau, bày ra lắm cho rắc rối. Nói thật ra tụi Nhật họ cũng loạn cả lên chứ đừng nói là mình. Vô tình lượm được bí kíp nên chia sẻ cho các bạn đỡ bực 🙂

要求分析

• Khách hàng muốn làm gì
• Bao gồm cả những yêu cầu mâu thuẫn nhau
• Làm rõ những yêu cầu của khách hàng
• Kết quả phân tích được tổng hợp lại gọi là 要求定義書

要件分析

• System cần những cái gì
• Phân tích và loại bỏ những yêu cầu mâu thuẫn
• Làm rõ những yêu cầu hệ thống
• Kết quả phân tích được tổng hợp lại gọi là 要件定義書

Và trên thực tế 2 công đoạn phân tích này cũng sẽ được tiến hành đồng thời. Và cái để BrSE cần để làm design đó là 要件定義書.

Để lấy thêm 1 ví dụ cho dễ hiểu về “những yêu cầu mâu thuẫn”. Khách : xây dựng cho tụi ta 1 hệ thống quản lý mà nó vận hành liên tục 24/24. Sau 1 hồi nghĩ ra thêm : à, mà nếu có lỗi thì phải khôi phục lại được nên hằng ngày tụi bây cho back up hệ thống vào khung giờ 0 đến 1h đêm dùm với được không ? đau chưa. Cái vận hành 24/24 gọi là “yêu cầu chức năng” 機能要求, còn cái back up định kỳ gọi là “yêu cầu phi chức năng”　非機能要求. Và nhiệm vụ của mình là giải quyết hoặc … giải thích để họ bỏ mấy cái điên điên đi :D.

Các bước tiến hành

Thu thập thông tin

Họp – hỏi – trả lời – lên danh sách câu hỏi – họp…Vòng lặp (while : khách chưa bực mình). Giỡn chứ hỏi đến khi nào sáng tỏ thì thôi. Để việc thu thập thông tin có hiệu quả thì người phân tích yêu cầu phải làm việc với các bên am hiểu hệ thống để biết cái mà hỏi, ngoài ra còn khuyên khách hàng làm như thế nào cho tốt.

Khách đưa yêu cầu : tôi muốn có 1 màn hình để xuất hoá đơn. Cái cần hỏi : hoá đơn bao gồm những gì, giới hạn bao nhiêu record, xuất dạng nào – pdf hay image…, tổng tiền có cần làm tròn không, role gì có quyền xuất … vv…

Phản hồi thông tin

Sau khi làm việc với người có chuyên môn để tham khảo những vấn đề mà mình không rõ hoặc không chắc thì lên danh sách câu trả lời, cái nào làm được, cái nào không, lý do, nên thêm cái gì. Và lên 1 danh sách câu hỏi khác để tiếp tục làm việc trong các buổi họp kế tiếp.

Tổng hợp thông tin

Đến bước này mình sẽ chia nhỏ ra thành các tài liệu riêng để nhóm nội dung lại. Cần có những tài liệu để mô tả hệ thống, danh sách chức năng, flow nghiệp vụ, use case, quản lý issue …

Làm sao cho tốt

Các bạn có thể tham khảo bài viết bên dưới để biết các mẹo trong công đoạn này. Vì lười dịch nên mình chỉ đưa vào 1 phần nhỏ trong phạm vi bài viết này là 5W2H

http://www.atmarkit.co.jp/ait/articles/1507/02/news009.html

Kết

Đầu ra

• 要件定義書 (Bản định nghĩa yêu cầu)：Phải đầy đủ để có thể create được basic design mà không cần hỏi lại khách hoặc hạn chế hỏi nhất. Đảm bảo tính khả thi, cái gì làm được với không được thì điều tra và nói ngay từ đầu, sau này đỡ mất công chỉnh sửa, thậm chí … cãi nhau

Phương thức

• Thu thập thông tin
• Phản hồi thông tin
• Tổng hợp thông tin

Mẹo

• Sử dụng 5W2H : nằm ngay trên nè

BrSE cần :

• Chịu khó đọc tài liệu
• Rèn kỹ năng nghe và hỏi, đặc biệt là hỏi sao cho đỡ mất công hỏi nhiều lần
• Rèn kỹ năng mềm : để kiềm chế với các thượng đế đòi hỏi trên trời