Phân tích yêu cầu là gì? Bước đầu để phát triển đúng hướng

Phân tích yêu cầu là quá trình thu thập, làm rõ, kiểm tra và sắp xếp những gì một hệ thống cần đáp ứng. Hoạt động này có thể diễn ra trước và tiếp tục trong quá trình thiết kế, phát triển, tùy phương pháp triển khai. Mục tiêu không phải là tạo ra tài liệu càng dài càng tốt, mà là giảm khoảng cách giữa nhu cầu nghiệp vụ và cách đội kỹ thuật hiểu, thiết kế và xây dựng hệ thống.

Một yêu cầu đủ rõ thường giúp trả lời các câu hỏi như: ai sẽ sử dụng, họ cần làm gì, quy trình diễn ra ra sao, dữ liệu nào được sử dụng, điều kiện nào ảnh hưởng đến kết quả và thế nào được xem là đúng.

Khi những điểm này được thống nhất, yêu cầu trở thành cơ sở cho việc ước tính, thiết kế, phát triển, kiểm thử và nghiệm thu thay vì chỉ là một danh sách mong muốn.

Giả sử doanh nghiệp yêu cầu “hệ thống cần có chức năng quản lý tồn kho”. Câu này nghe khá cụ thể, nhưng vẫn còn nhiều cách hiểu khác nhau.

Tồn kho được quản lý theo một kho hay nhiều địa điểm? Số lượng được cập nhật khi tạo đơn, khi giao hàng hay khi giao dịch hoàn tất? Ai được phép điều chỉnh bằng tay? Hệ thống có cần cảnh báo khi tồn kho xuống thấp hay không?

Nếu những câu hỏi này chưa được làm rõ, đội phát triển có thể phải dựa vào giả định cho phần thông tin còn thiếu. Rủi ro xuất hiện khi sản phẩm được xây theo một cách hiểu khác với kỳ vọng của phía doanh nghiệp.

Đó là lý do một yêu cầu không nên được đánh giá chỉ bằng việc “đã có tên chức năng hay chưa”. Điều cần kiểm tra là hai bên có đang hiểu giống nhau về cách chức năng đó hoạt động hay không.

Trước hết là mục tiêu kinh doanh. Hệ thống được xây để cải thiện điều gì: giảm thao tác thủ công, rút ngắn thời gian xử lý, giảm lỗi hay tạo một dịch vụ mới cho khách hàng?

Tiếp theo là người dùng và quy trình thực tế. Ai sử dụng hệ thống? Họ bắt đầu công việc từ đâu? Có bước phê duyệt, ngoại lệ hoặc xử lý thủ công nào cần tính đến không?

Dữ liệu và quy tắc nghiệp vụ cũng cần được làm rõ. Dữ liệu đến từ đâu, ai được xem hoặc chỉnh sửa, điều kiện nào làm thay đổi trạng thái và những trường hợp đặc biệt được xử lý thế nào?

Cuối cùng là những giới hạn ảnh hưởng đến cách phát triển như thời gian, ngân sách, bảo mật, hệ thống cần tích hợp hoặc yêu cầu về hiệu năng.

Khi các yếu tố này được kết nối với nhau, yêu cầu không còn là những chức năng rời rạc mà trở thành mô tả có cấu trúc về cách hệ thống cần hỗ trợ công việc.

Giả sử doanh nghiệp nói: “Chúng tôi muốn quản lý tồn kho tốt hơn.”

Bước đầu tiên là làm rõ vấn đề hiện tại. Có thể nhân viên đang phải kiểm tra nhiều file, số lượng không được cập nhật kịp thời hoặc các chi nhánh đang sử dụng dữ liệu khác nhau.

Sau đó, cần xác định người dùng và tình huống sử dụng. Nhân viên kho cần cập nhật số lượng, bộ phận bán hàng cần kiểm tra tồn trước khi xác nhận đơn, còn quản lý có thể cần theo dõi biến động theo từng địa điểm.

Từ đó, nhu cầu ban đầu có thể được chuyển thành những yêu cầu cụ thể hơn, chẳng hạn hiển thị tồn kho theo địa điểm, cập nhật số lượng theo một sự kiện đã xác định, giới hạn quyền chỉnh sửa hoặc cảnh báo khi tồn kho xuống dưới ngưỡng quy định.

Những thông tin này tạo thêm cơ sở để đội dự án thảo luận kiến trúc, ước tính công việc, thiết kế giao diện và xác định cách kiểm thử. Mức độ chi tiết cần có ở từng thời điểm phụ thuộc vào phạm vi và phương pháp phát triển.

Làm sao biến bài toán kinh doanh thành giải pháp phần mềm?

Mức độ đặc tả cần có trước khi trao đổi với đội phát triển phụ thuộc vào loại dự án, phương pháp triển khai và các ràng buộc liên quan. Doanh nghiệp cũng không nhất thiết phải tự xây dựng toàn bộ đặc tả; các tài liệu đang được sử dụng trong công việc thực tế có thể là nguồn đầu vào để tiếp tục phân tích.

Excel, biểu mẫu, báo cáo, ảnh chụp màn hình, quy trình nội bộ hoặc dữ liệu mẫu có thể giúp đội dự án hiểu cách công việc đang diễn ra thay vì chỉ nghe mô tả ở mức tổng quát.

Tùy phạm vi dự án, việc có đại diện hiểu mục tiêu kinh doanh và đại diện người dùng thực tế tham gia có thể cung cấp các góc nhìn khác nhau. Nhóm quản lý có thể làm rõ mục tiêu và ưu tiên, trong khi người trực tiếp thực hiện công việc có thể cung cấp thông tin về các bước, ngoại lệ và khó khăn trong vận hành.

Một thông tin quan trọng là lý do doanh nghiệp cần hệ thống này và những điểm nào vẫn chưa chắc chắn. Đây là đầu vào để tiếp tục làm rõ yêu cầu, không phải điều kiện duy nhất để dự án có thể bắt đầu.

Chuẩn bị gì trước khi bắt đầu một dự án phát triển phần mềm?

Không phải dự án nào cũng cần một giai đoạn phân tích dài. Nếu phạm vi nhỏ, quy trình đơn giản và yêu cầu đã khá rõ, việc làm rõ có thể diễn ra trực tiếp trong quá trình chuẩn bị phát triển.

Ngược lại, một giai đoạn phân tích riêng thường hữu ích khi dự án liên quan đến nhiều bộ phận, quy trình có nhiều ngoại lệ, cần tích hợp với hệ thống hiện có hoặc doanh nghiệp mới chỉ biết mình muốn cải thiện điều gì nhưng chưa rõ hệ thống nên hoạt động như thế nào.

Đây cũng là lựa chọn nên cân nhắc khi các bên liên quan đang có cách hiểu khác nhau hoặc báo giá giữa các phương án phát triển chênh lệch lớn vì phạm vi chưa đủ rõ.

Tại Fenix, những thông tin được làm rõ ở giai đoạn này được tiếp tục sử dụng cho ước tính, thiết kế, phát triển và kiểm thử. Điều này giúp hạn chế việc mỗi giai đoạn lại phải diễn giải lại cùng một yêu cầu theo một cách khác.

Xem dịch vụ tư vấn CNTT của Fenix

Phân tích yêu cầu không nhằm loại bỏ mọi thay đổi khỏi một dự án phần mềm. Thay đổi vẫn có thể xuất hiện khi doanh nghiệp hiểu thêm về sản phẩm hoặc khi điều kiện kinh doanh thay đổi.

Một giá trị quan trọng của phân tích yêu cầu là tạo ra cách hiểu chung cho những quyết định liên quan đến phạm vi và cách hệ thống hoạt động. Yêu cầu được làm rõ ở các điểm cốt lõi có thể hỗ trợ việc ước tính, theo dõi phạm vi và đánh giá tác động của thay đổi trong dự án.

Nếu doanh nghiệp vẫn khó mô tả chính xác hệ thống cần làm gì, các điểm chưa rõ có thể được ghi nhận thành câu hỏi để tiếp tục phân tích. Cách xử lý tiếp theo phụ thuộc vào phạm vi, mức độ rủi ro và phương pháp triển khai của dự án.