Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng
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. 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à một 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ì biết gì 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 gì và khác gì nhau, bày ra lắm cho rắc rối. Nói thật ra 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.
Q&A
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.
Đế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 …
Document List of Requirements Definition
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
いつ(When)
Thời hạn – start – end, và status từng giai đoạn
どこから(Where)
Sử dụng nội bộ hay có liên kết với cả hệ thống bên ngoài công ty
誰が(Who)
Ai là người dùng, đối với từng role thì quyền hạn như nào
何の情報を(What)
giải quyết những thông tin gì
どういう理由で(Why)
Tại sao lại cần “cái ấy”
どれぐらいで(How Much/Many)
1 ngày 1 lần hay 1 năm. Bao nhiêu thì tốt. Ví dụ : backup system, 1 tuần 1 lần hay hàng ngày, mỗi lần backup toàn bộ hay chỉ phần quan trọng
どうするのか(How)
KH muốn gì, và với cái đó tui phải làm như thế nào
要件定義書 (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