Site icon Ký sự BrSE

Bàn về định nghĩa yêu cầu (要件定義)

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 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 🙂

要求分析

要件分析

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.

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 …

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

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

Kết

Đầu ra

Phương thức

Mẹo

BrSE cần :

Đây là phần 2 về 要件定義/

4.6/5 - (9 votes)
Exit mobile version