Kinh nghiệm phân tích các yêu cầu nghiệp vụ cho hệ thống phần mềm

1. Cơ sở lý luận

Mô hình Domain Driven Design là một cách xây dựng sản phẩm phần mềm theo cách tiệm tiến, sao cho mỗi lần release một phiên bản là một lần tiếp cận được đến gần hơn với nhu cầu thực tế của người dùng, thông qua việc phân tích và hệ thống hoá các yêu cầu của người dùng.

Tuy nhiên các yêu cầu này của người dùng không được bày tỏ ra rõ ràng ngay một lúc. Trải qua các trải nghiệm sử dụng thực tế, các yêu cầu mới sẽ nảy sinh, và đôi khi các yêu cầu cũ bị loại bỏ đi. Mỗi phiên bản release tiềm ẩn nguy cơ xung đột giữa các yêu cầu mới và các yêu cầu cũ trước đây nếu không có sự phân tích thấu đáo các ảnh hưởng và sự liên quan. Cho nên trong vấn đề này sự mạch lạc trong tư duy phân tích các yêu cầu là điều quan trọng để làm cho sản phẩm phần mềm trở thành công cụ hữu ích cho người dùng thay vì một thứ gây rắc rối.

Công việc phân tích rõ ràng và hệ thống hoá một cách logic các yêu cầu giống như một chiếc cầu nối giữa hai thế giới. Một bên là thế giới trừu tượng vô hình các mong muốn của người dùng diễn đạt bằng ngôn ngữ tự nhiên của con người mang đầy vẻ định tính và ngây thơ(vì đôi khi người dùng không hiểu rõ được những giới hạn về mặt kỹ thuật không thể đáp ứng được những yêu cầu quá siêu thực tế). Và một bên là thế giới cụ thể hữu hình của một hệ thống thông tin có dữ liệu đầu vào và thông tin đầu ra hoạt động theo đúng quy luật đã được lập trình một cách chính xác.

Tôi nhận thấy tư duy toán học có ích trong việc phân tích các yêu cầu từ người dùng. Nếu ta có thể công thức hoá được các yêu cầu, biểu diễn các mong muốn trải nghiệm của người dùng dưới dạng các phương trình toán học, thì việc thấu hiểu giữa người dùng và người phát triển được nâng lên một tầm cao mới, vì lúc này họ sẽ đều cùng chung nhau nhìn thấy một sản phẩm tương lai sẽ như thế nào dưới hình dạng của một mô hình toán học.

Đến đây bạn có thể hình dung mô hình Tam Thể Nhất Vị dưới đây trong quá trình sản xuất một sản phẩm phần mềm, trong đó người phân tích yêu cầu ở đỉnh của tam giác với bên trái là người dùng với các mong muốn vô hình trừu tượng và bên phải là người phát triển với sản phẩm phần mềm hữu hình cụ thể, ở giữa là mô hình toán học biểu diễn các yêu cầu cần thực hiện.

2. Ví dụ thực tế

Tôi trình bày về cách phân tích các yêu cầu nghiệp vụ của các nhân viên trong một công ty cho một hệ thống quản lý tình hình kinh doanh.

a)Người dùng: các nhân viên kinh doanh trong công ty muốn có một phần mềm để lập kế hoạch mục tiêu doanh số đầu tháng cho mỗi mặt hàng.

Họ cũng muốn có một phần mềm khác để theo dõi tiến độ doanh thu của từng mặt hàng mỗi ngày, để hàng ngày có thể dự đoán xem mục tiêu của tháng đó có thể đạt được bao nhiêu phần trăm dựa trên tiến độ thực tế hiện tại.

b)Người phát triển: yêu cầu đưa ra quá chung chung, không biết bắt đầu từ đâu, không biết lựa chọn công nghệ gì

c)Người phân tích: trao đổi với người dùng để làm rõ Input là gì và Output muốn gì

Yêu cầu 1: Muốn có một phần mềm để lên kế hoạch kinh doanh đầu tháng.

Input: Doanh số mục tiêu(gross_target), và phần trăm lợi nhuận(margin)
Output: Chi phí mục tiêu(cost_target), và lợi nhuận mục tiêu(profit_target)

Các phương trình về các yêu cầu được rút ra từ buổi trao đổi với người dùng

①profit_target=gross_target x margin 
②cost_target=gross_target - profit_target  

Yêu cầu 2: Muốn có một phần mềm để theo dõi tiến độ doanh thu thực tế hàng ngày

Input: Chi phí thực tế phát sinh đến ngày hôm qua(cost_progress),  tỷ lệ doanh thu(ratio)
Output: Doanh thu thực tế đến ngày hôm qua(gross_progress), lợi nhuận thực tế đến ngày hôm qua(profit_progress)

Các phương trình về các yêu cầu được rút ra từ buổi trao đổi với người dùng

③ratio = 1/(1-margin)
④gross_progress=cost_progress x ratio 
⑤profit_progress=gross_progress x margin 
⑥achievement_rate=profit_progress/profit_target   

Với 6 phương trình trên chúng ta hệ thống hoá được các yêu cầu của người dùng đối với sản phẩm. Dựa trên phân tích trên chúng ta có thể tiến đến bước tiếp theo là lựa chọn các công nghệ phù hợp để hiện thực hoá các yêu cầu.

Trong thực tế dự án thì có khi yêu cầu 2 được đưa ra đầu tiên và được triển khai thực hiện, đưa vào vận hành cho người dùng trải nghiệm, sau đó họ mới nảy sinh ra Yêu cầu 1. Người phân tích lúc này mới bắt đầu nhận rõ ra mong muốn thực sự của người dùng là gì, vì ngay cả bản thân người dùng họ cũng không định nghĩa rõ được họ mong muốn sản phẩm như thế nào từ thời điểm khởi đầu.