Table of Content
Trong post trước mình đã giới thiệu về BR và tầm quan trọng của BR. Trong bài này, mình sẽ nói về cách xác định BR, và làm thế nào để mô tả BR trong tài liệu SRS. Xác định đầu vào của BR:
Việc xác định BR chủ yếu bắt đầu từ bước elicitation. Khi các bạn tiếp xúc với business user để lấy thông tin, cần phải chú ý đến các công thức, quy tắc xử lý nghiệp vụ của khách hàng.
Ví dụ như các bạn lấy yêu cầu của phòng kinh doanh thì các quy tắc (rules) có thể là công thức tính KPI doanh số cho mỗi bạn sales hay công thức để tính doanh thu/doanh số cho mỗi đơn bán.
Lưu ý: thông tin được lấy ở bước này mới chỉ là Business requirement chứ chưa phải là business rule.
Đưa ra solution: Sau khi đã có được requirement là các công thức, quy tắc rồi, việc tiếp theo là đưa ra solution cho các quy tắc này khi đưa lên hệ thống.
Các solution ở bước này thường được thể hiện dưới dạng các chức năng hệ thống. Các bạn có thể tham khảo trong post này về thiết kế chức năng hệ thống.
Ví dụ:
Công thức tính KPI được áp dụng khi đơn bán được chốt hay, doanh số được tính cho sales theo công thức và cập nhật vào KPI tương ứng của sales --> Chức năng chốt đơn bán chứa các BR về việc tính doanh số, cập nhật KPI…
Chức năng "Xem" bộ KPI cần được phân quyền theo nghiệp vụ thực tế như: Sales xem KPI của chính mình, trưởng phòng sales được xem KPI tổng cả phòng và KPI cá nhân của các bạn nhân viên…
Tất cả những solution như trên cần "gán" với một chức năng cụ thể hay nói chính xác là 1 use case (trường hợp sử dụng) cụ thể của phần mềm.
Mô tả chi tiết Sau giai đoạn elicitation và có trong tay solution, việc tiếp theo các bạn cần làm là viết mô tả chi tiết. Trong trường hợp này mình chỉ nói đến việc mô tả cho use case trong tài liệu SRS. Các yếu tố cần xác định trong 1 use case bao gồm:
Objective: Mục tiêu của use case, ví dụ đặt hàng trên web ecommerce
Actor: Các đối tượng thực hiện được use case này. Trong ví dụ này là người mua hàng.
Pre-condition: Điều kiện tiền đề để có thể thực hiện được use case. Ví dụ người dùng phải có tài khoản và đăng nhập thành công.
Business rules: Các quy tắc nhằm đảm bảo use case mua hàng được thực hiện đúng nghiệp vụ của bên cung cấp ecommerce và dữ liệu được xử lý 1 cách đúng đắn.
Mô tả business rule bao gồm:
Các happy case hay luồng chính của nghiệp vụ: từ bước bắt đầu của use case cho đến khi hoàn thành. Ví dụ như mua hàng bắt đầu từ lúc user click vào nút "Check-out" trong giỏ hàng chẳng hạn (các bước tìm kiếm, thêm hàng vào giỏ… là các use case khác). Sau đó, hệ thống cần xử lý việc thanh toán của khách hàng và tạo đơn hàng rồi gửi thông tin đến người bán hoặc đơn vị vận chuyển …
Các failure case: chủ yếu từ các bước validation như kiểm tra xem tại thời điểm đặt hàng thì mặt hàng còn đủ trong kho hay không, thông tin thanh toán, giao hàng có được điền và điền có đúng hay không… nếu sai thì thông báo lại cho user như thế nào (1 message lỗi chẳng hạn)…
Thông thường, khi mô tả use case các bạn hay tập trung nhiều hơn vào các happy case mà quên hoặc thiếu phần mô tả cho các failure case.
Ví dụ với trường hợp mua hàng bên trên:
BR về hiển thị: màn hình nào được hiển thị sau khi người dùng chọn "Check-out". Thông tin trên màn hình gồm những gì..
BR về xác minh thông tin (validation): Có thông tin bắt buộc nào đang bị để trống hay không? Có thông tin nào sai format hay không? Các mặt hàng có đủ tồn kho tại thời điểm đặt hay không? Nếu có lỗi thì hiển thị các thông báo tương ứng với lỗi. Nếu không có thì xử lý thanh toán.
BR về xử lý thanh toán: yêu cầu thanh toán cho đơn hàng được chuyển đến ví, ngân hàng hoặc 1 bên thanh toán quốc tế (visa/master...). Hệ thống nhận phản hồi thanh toán từ bên thứ 3 và xử lý báo lỗi nếu thanh toán không thành công. Hoặc xử lý tạo mới đơn hàng nếu thành công.
BR về tạo mới đơn hàng: Tạo đơn với các thông tin người dùng nhập hoặc chọn (như thông tin giao hàng, số lượng hàng, thông tin thanh toán...). Bên cạnh đó còn các thông tin mà hệ thống tự động tạo ra như mã đơn hàng (BA phải đưa ra quy tắc đặt mã sau khi lấy y/c và phân tích), hay là trạng thái đơn hàng mới tạo (trạng thái phụ thuộc vào luồng nghiệp vụ mua bán của doanh nghiệp)... Các thông tin sau khi được tạo xong được lưu xuống cơ sở dữ liệu (database) và thông báo cho user biết là đơn được tạo thành công. Các email hoặc notification cần thiết được gửi đi, đơn vừa tạo ra được hiển thị cho khách hàng xem...
Đến đây là kết thúc mô tả cho use case mua hàng. Tất nhiên, tuỳ nghiệp vụ của các bên khác nhau mà các mô tả bên trên cần phải được viết theo các rules tương ứng với nghiệp vụ đó.
Lưu ý khi mô tả BR trong tài liệu:
Sử dụng bộ câu hỏi 5w1h trong quá trình phân tích để viết BR.
Luôn đặt câu hỏi về input/output của từng bước. Ví dụ: input của việc đặt hàng là gì? (số lượng hàng, số tiền đặt, thông tin giao hàng, thông tin thanh toán...)
Chú ý đến các failure case: Nếu user không làm như này thì sao? Nếu thông tin sai thì sao? Nếu chỗ này không thành công thì sao?...
Mô tả ngắn gọn: tránh việc viết văn (như phần mình viết ở trên là văn rồi :). Đoạn ở trên mình có thể ví dụ lại thành như sau cho 1 BR cụ thể:
Nếu [Địa chỉ giao hàng] = "", hệ thống hiển thị thông báo lỗi "Đây là thông tin bắt buộc".
Với mỗi mặt hàng trong đơn, hệ thống kiểm tra số lượng tồn kho. Nếu <tồn kho> < [Số lượng] : Hệ thống hiển thị thông báo "Mặt hàng [tên hàng] không đủ tồn kho, vui lòng chọn lại" ...
Sắp xếp thứ tự các business rules:
Ưu tiên sắp xếp lần lượt theo luồng happy case.
Các logic xử lý đơn giản như hiển thị màn hình, kiểm tra thông tin trống, sai format... nên được nêu ra trước.
Các thông tin cần xử lý phức tạp hơn về nghiệp vụ hoặc liên kết với các hệ thống khác cần làm sau.
Đưa ra thứ tự ưu tiên dựa vào ràng buộc của các BR như các BR 1 phải được hoàn thành thì BR 2 mới có thể thực hiện được. Ví dụ ở bước tạo đơn: đơn hàng không thể tạo nếu mã đơn, trạng thái chưa được tạo. Thông báo đơn hàng mới hoặc email về đơn không thể gửi đi được nếu đơn hàng chưa được tạo...
Trên đây là các bước để có thể viết mô tả BR cho các use case trong tài liệu SRS của BA. Hy vọng post này sẽ giúp ích cho các bạn trong quá trình làm việc và giảm thiểu sai sót trong tài liệu.
Post liên quan:
Comments