Table of Content
Function design là gì?
Function design là quá trình đưa ra các chức năng, tính năng, luồng làm việc/hoạt động của phần mềm. Quá trình này đòi hỏi người BA phải phân tích yêu cầu từ khách hàng, tìm ra vấn đề và giải pháp trước khi đưa ra chức năng/tính năng cần thiết.
Function design thường xuất hiện vào giai đoạn đầu của dự án hoặc khi có yêu cầu từ phía khách hàng.
Trong khuôn khổ bài viết này, mình sẽ không đề cập lại quá trình thu thập yêu cầu nữa. Các bạn có thể tham khảo tại đây nhé. Để bắt đầu các bạn nên xác định các object trong hệ thống rồi mới xác định, thiết kế các chức năng tương ứng.
Object là gì?
Object trong phân tích của BA có thể chia làm 2 loại là Business object và System object:
Business object hay các đối tượng nghiệp vụ được xác định trong quá trình tìm hiểu về nghiệp vụ của khách hàng. Các object này phản ánh từ thực tế nghiệp vụ như sản phẩm, đơn bán, hoá đơn, phiếu yêu cầu…
System object là các đối tượng được sinh ra trong quá trình xây dựng hệ thống phần mềm nhằm hỗ trợ cho việc quản lý, xử lý thông tin như các loại dữ liệu chủ, tài khoản đăng nhập…
Cách xác định object
Cách đơn giản nhất để xác định object là trả lời câu hỏi "What". Tất nhiên, việc hỏi như thế nào cũng rất quan trọng, không phải cứ hỏi what thì sẽ có câu trả lời.
Đầu tiên, mỗi khi bạn bắt đầu một luồng nghiệp vụ nào đấy hoặc thậm chí là một phần mềm nào đấy ngoài việc lấy yêu cầu và phân tích yêu cầu(phần này mình có nói là sẽ không đề cập ở đây) thì bạn cần xác định trước object chính của luồng nghiệp vụ đã:
Đặt câu hỏi "Cái gì đang được nhắc đến nhiều nhất, được user tương tác nhiều nhất trong luồng?"
Luồng hoạt động của một nghiệp vụ thường xoay quanh 1 object chính nào đó. Ví dụ luồng mua hàng xoay quanh "Đơn bán".
Trong một số trường hợp, các bạn bị ảnh hưởng/điều hướng của solution dẫn đến việc "lạc lối" khi xác định object. Trường hợp này, khi mà các bạn bắt đầu thấy không tìm/xác định được object cho tính năng/module/giải pháp mà mình đưa ra thì các bạn hãy quay ngược lại về "vấn đề".
Ví dụ: trong lớp tháng 4 của mình có 1 nhóm xác định được đề bài của bài tập lớn là "Quản lý thời gian" sau khi áp dụng mô hình kim cương đôi để tìm và giải quyết vấn đề. Tới đây thì các bạn stuck luôn ở khâu xác nhận object. Mình có hỏi ngược lại là các bạn bắt đầu từ vấn đề gì mà đi đến lựa chọn quản lý thời gian. Đáp án được các bạn đưa ra bắt đầu từ việc bị chậm tiến độ hoặc quên các công việc cần phải làm. Vậy là tại lúc này thì câu hỏi "What" đã được các bạn tự trả lời, "What" của các bạn ở đây là "công việc", là "task".
Vậy main object trong trường hợp này của các bạn là "Task" nói chung. Các object khác sẽ hiện ra khi các bạn phân tích chức năng xoay quanh "Task".
Thiết kế chức năng hệ thống.
Đây là giai đoạn mà các bạn cần vận dụng các kỹ năng phân tích của BA vào việc phân tích các khía cạnh khác nhau của object. Trong khoá học của mình, 2 kỹ năng được mình giới thiệu là CRUD và I/O flow đều được/cần phải sử dụng ở bước này.
Với CRUD:
Các bạn phân tích xoay quanh 4 use case cơ bản của 1 object gồm thêm (create), đọc/xem (read), sửa (update) và xoá (delete).
Với việc sử dụng CRUD, các bạn ít nhất sẽ cho ra được 4 chức năng cơ bản như trên. Ngoài ra sẽ còn các chức năng phát sinh từ các chức năng cơ bản có thể phân tích ra được như: Thêm nhiều (import), xem danh sách (xem nhiều), tìm kiếm/lọc (phát từ xem danh sách)…
Với case study về Time management nói trên, object "Task" sẽ có thể bao gồm các chức năng như:
C: Thêm mới task, upload attachment.
R: Xem chi tiết task, xem danh sách task, tìm kiếm/lọc task.
U: Cập nhật task.
D: Xoá task, xoá nhiều task.
Với I/O Flow:
Đây là technique dựa trên việc phân tích đầu ra, đầu vào của object.
Khi sử dụng I/O flow, bênh cạnh việc xác định chức năng object thì bạn cũng có thể làm rõ hơn thông tin các thuộc tính của 1 object. Ví dụ đầu vào của task là gì?: tiêu đề, nội dung, người thực hiện, deadline…
Với câu hỏi cho đầu ra (output), một số cách hỏi mình thường dùng như: sau khi … thì chuyện gì xảy ra? Thông tin/dữ liệu sau khi… được xử lý ở đâu, xử lý tiếp bởi ai…
Kỹ thuật này mình thường sử dụng song song với CRUD để đạt hiệu quả tốt hơn.
Ví dụ:
C: Đầu vào cho việc tạo mới task gồm những gì? Task sau khi được tạo mới xong thì sẽ cần làm gì tiếp? (gửi đi thông báo cho user để họ có thể accept công việc do người khác tạo cho mình, chạy reminder khi gần đến...) --> chức năng thông báo, object thông báo. Chức năng reminder, chấp nhận, từ chối công việc
R: Đầu vào cho việc xem thông tin task là gì? (task phải tồn tại..) Khi xem xong thì người ta làm gì được với task? (với user được giao việc có thể chuyển việc, xác nhận hoàn thành, huỷ bỏ….) --> Chức năng giao việc, hoàn thành công việc, huỷ công việc…
Cứ thế, việc áp dụng song song 2 kỹ năng trên bằng cách liên tục đặt câu hỏi và trả lời sẽ giúp cho việc xây dựng các tính năng được kỹ càng hơn.
Lưu ý khi thiết kế chức năng hệ thống.
Việc áp dụng phương pháp phân tích như trên sẽ dễ dàng dẫn đến trường hợp bị trùng lặp chức năng. Vậy nên khi bạn phân tích ra một chức năng thì nên có quy tắc đặt tên để khi có danh sách mình có dễ kiểm tra trùng lặp. Bên cạnh đó trong quá trình phân tích bạn cũng sẽ dễ dàng gặp các object khác xuất hiện bên cạnh object chính. Như ví dụ bên trên xuất hiện thêm object "thông báo" chẳng hạn. Lúc này thì bạn không nên vội vàng phân tích luôn object mới mà hãy đánh dấu lại, note ra đâu đó để khi hoàn thiện object đang làm (task) thì mới quay lại. Việc này giúp quá trình phân tích không bị đi lan man.
Sau khi bạn đã có danh sách chức năng được phân tích ra ở trên bạn cần đánh giá lại để đảm bảo các chức năng được đưa ra giải quyết vấn đề của khách hàng hoặc phục vụ cho solution mà các bạn đưa ra.
Cuối cùng, trình bày gọn gàng lại danh sách chức năng theo object và confirm lại với các bên liên quan trước khi triển khai quá trình làm chi tiết.
Comments