5 loại tài liệu yêu cầu được viết bởi Business Analyst

Tài liệu hóa yêu cầu giúp các bên có ngôn ngữ chung về nghiệp vụ

 

Chìa khóa để đạt được thành công thực sự nằm ở việc hiểu biết về sức mạnh của việc tài liệu hóa. Không chỉ là một công cụ để tạo ra tất cả các tài liệu, mà còn là một công cụ phân tích và tư duy, cũng như là một công cụ giúp doanh nghiệp đưa ra quyết định tốt hơn. Hôm nay, tôi sẽ giới thiệu về năm loại tài liệu yêu cầu mà mỗi nhà phân tích nghiệp vụ cần phải biết và bắt đầu sử dụng trong hầu hết các dự án của họ.

 

Hôm nay, chúng ta sẽ nói về năm loại tài liệu yêu cầu. Loại đầu tiên tôi muốn giới thiệu với bạn là Tuyên bố Phạm vi. Đây là loại tài liệu đầu tiên bạn nên tạo ra trên hầu hết các loại dự án. Nó xác định được phạm vi của dự án.

 

• Vấn đề chúng ta đang giải quyết là gì?
• Nhu cầu nghiệp vụ là gì?
• Phạm vi của giải pháp cho vấn đề đó là gì?
• Ở mức độ cao, chúng ta giải quyết vấn đề đó như thế nào?
• Giải pháp như thế nào?

• Liệu việc đầu tư để giải quyết vấn đề đó có đáng giá không? Dự án này có mang lại lợi ích thu hồi vốn (ROI) tích cực hay không?

2.Kế Hoạch Phân Tích Nghiệp Vụ (Business Analysis Plan)

 

Kế Hoạch Phân Tích Nghiệp vụ thường sẽ được dẫn dắt bởi phương pháp phân tích Nghiệp vụ hoặc phát triển phần mềm của tổ chức. Có thể là chính thức hoặc có thể là rất không chính thức.

 

Với phạm vi đã được xác định và kế hoạch của bạn đã được đặt ra, bạn biết mình đang đi đến đâu, đến lúc bắt đầu đào sâu vào chi tiết. Mặc dù luôn có sự cám dỗ để ngay lập tức bước vào giải pháp phần mềm hoặc yêu cầu chức năng, nhưng thường thì việc bắt đầu bằng việc phân tích quy trình nghiệp vụ là lựa chọn hợp lý nhất.

 

Một phần của việc phân tích quy trình nghiệp vụ là biểu đồ luồng quy trình, cũng thường được gọi là biểu đồ luồng công việc hoặc bản đồ quy trình. Nó cho thấy bức tranh tổng quan về cách quy trình tổng thể diễn ra từ quan điểm của bên liên quan hoặc người dùng cuối. Đây là một loại mô hình trực quan là cách tuyệt vời để khai thác nhiều thông tin và tạo ra một sự hiểu biết chung về cả trạng thái hiện tại và trạng thái tương lai của quy trình một cách nhanh chóng.

 

 

Thường thì, một biểu đồ luồng quy trình là một cách tuyệt vời để hiểu bức tranh tổng quan, nhưng bạn sẽ bỏ qua một số chi tiết và sắc thái mà một mẫu văn bản sẽ giúp bạn suy nghĩ kỹ hơn. Thường những vấn đề hoặc không nhất quán này rất dễ bị bỏ sót chỉ với một biểu đồ luồng công việc đơn giản, và bạn sẽ phát hiện chúng khi bạn thực hiện phân tích sâu hơn sử dụng một mẫu quy trình nghiệp vụ như thế này.

 

Điều thực sự quan trọng trong loại tài liệu thứ ba, tài liệu quy trình nghiệp vụ, là bạn đang nhận được một quan điểm nghiệp vụ về cả trạng thái hiện tại, hay quy trình nghiệp vụ hiện tại, và trạng thái mong muốn trong tương lai, hay quy trình nghiệp vụ cần đạt được. Điều này sẽ giúp làm rõ hơn, đến từng chi tiết, các vấn đề cụ thể mà bạn cần giải quyết bằng công nghệ.

 

Tiếp theo trong danh sách, loại tài liệu thứ tư của chúng ta là tài liệu yêu cầu chức năng. Nếu giải pháp là một giải pháp phần mềm, không phải tất cả các giải pháp đều là như vậy, đôi khi bạn chỉ cần cập nhật quy trình nghiệp vụ để giải quyết vấn đề nghiệp vụ. Chúng ta không luôn cần sử dụng công nghệ, nhưng rất nhiều lần chúng ta đang tận dụng công nghệ như một phần của giải pháp. Trong trường hợp đó, nhà phân tích nghiệp vụ sẽ chỉ định yêu cầu chức năng cho dự án. Chúng cũng được biết đến với tên là yêu cầu giải pháp, yêu cầu phần mềm, đôi khi là yêu cầu kỹ thuật, hoặc yêu cầu hệ thống.

 

 

Yêu cầu chức năng xác định hệ thống làm gì, cách nó hoạt động, và chúng thường được viết ở mức độ người dùng cụ thể, như một người dùng cuối thực sự, một cá nhân, có thể làm cho hệ thống hoạt động như thế nào. Đó là những gì họ thấy trong quá trình tương tác với hệ thống đó mà là một yêu cầu chức năng.

 

Có thể có rất nhiều điều khác diễn ra phía sau cảnh. Những điều đó sẽ là yêu cầu thiết kế hệ thống kỹ thuật hơn. Một yêu cầu chức năng sẽ là điều mà một người dùng cuối có thể trải nghiệm khi tương tác với hệ thống phần mềm đó. Chúng có thể được thu thập trong nhiều loại tài liệu yêu cầu khác nhau.

 

Loại tài liệu đầu tiên là một trong những kỹ thuật mô hình hóa được gọi là các trường hợp sử dụng (use cases). Đây là một cách rất phổ biến để thu thập một yêu cầu chức năng. Phân tích trường hợp sử dụng giúp các BA, một lần nữa, xác định các yêu cầu bị bỏ sót bằng cách trở nên rõ ràng hơn trong tương tác người dùng hệ thống đó. Đó là một kỹ thuật rất quan trọng.

 

Đôi khi trường hợp sử dụng được thu thập cùng nhau trong một loại tài liệu khác gọi là một đặc tả yêu cầu phần mềm, hay SRS, hoặc một tài liệu yêu cầu chức năng, FRD, những tài liệu này cũng có thể bao gồm yêu cầu phi-chức năng. Chúng thường chỉ là một danh sách yêu cầu. Tuy nhiên, các trường hợp sử dụng, bởi vì cách chúng cho thấy tương tác giữa người dùng và hệ thống, là những công cụ phân tích mạnh mẽ giúp bạn suy nghĩ về những yêu cầu bạn có thể bỏ sót nếu không sử dụng chúng.

 

Trong một môi trường Agile, các yêu cầu chức năng thường được thu thập trong các câu chuyện người dùng, được tổ chức vào một product backlog. Bạn có thể vẫn phân tích các yêu cầu và trường hợp sử dụng để đảm bảo rằng bạn đang giữ cho tất cả những câu chuyện người dùng đó liên kết với nhau trong product backlog của mình.

 

Nhiều người lầm tưởng rằng để trở thành nhà phân tích phần mềm, bạn cần có kiến thức chuyên sâu về công nghệ. Tuy nhiên, điều này không hoàn toàn đúng. Kỹ năng quan trọng nhất mà một nhà phân tích nghiệp vụ cần có là khả năng suy luận phân tích và giao tiếp hiệu quả. Ngay cả khi mức độ hiểu biết về hệ thống công nghệ này không hấp dẫn, bạn có thể tốt hơn khi tập trung vào các vai trò nhà phân tích nghiệp vụ tập trung vào quy trình nghiệp vụ hơn.

 

 

Bạn không cần phải hiểu cách viết mã, cách chạy các truy vấn SQL, cách thiết kế hệ thống để đạt được mức độ rõ ràng này, giúp doanh nghiệp và người dùng công nghệ thực sự trên cùng một trang. Điều này là khả năng suy luận phân tích hơn là khả năng kỹ thuật.

 

Loại tài liệu yêu cầu thứ năm và cuối cùng là để thu thập yêu cầu thông tin hoặc dữ liệu. Ngoài chức năng mà người dùng nhìn thấy của phần mềm, nhà phân tích nghiệp vụ có thể xác định các yếu tố của mô hình thông tin cũng. Có một vài loại tài liệu yêu cầu dữ liệu phổ biến.

 

Một trong những loại đầu tiên là từ điển thuật ngữ. Điều này được sử dụng để định nghĩa một ngôn ngữ và thuật ngữ chung. Bạn sẽ sử dụng điều này để rõ ràng tới đâu về thuật ngữ mà doanh nghiệp của bạn đang sử dụng, đảm bảo cách bạn sử dụng một thuật ngữ như "khách hàng" hoặc "tài khoản" hoặc "đơn hàng" trong quy trình nghiệp vụ của bạn, trong trường hợp sử dụng của bạn, là nhất quán và tất cả các bên liên quan của bạn đều có cùng một hiểu biết về ý nghĩa của thuật ngữ đó.

 

Mô hình Yêu Cầu Dữ liệu tiếp theo rất phổ biến là biểu đồ mối quan hệ thực thể (Entity Relationship Diagram - ERD). Điều này cho thấy những khái niệm chính mà có thể xuất hiện trong từ điển thuật ngữ của bạn và cách chúng liên quan đến nhau, chi tiết nào được thu thập trong hệ thống thông tin về mỗi khái niệm. Ví dụ, nếu bạn có một đơn hàng, bạn có nhận được ngày đặt hàng không? Bạn có nhận được liên kết đến các sản phẩm cụ thể không? Đó sẽ là một mối quan hệ với một thực thể khác được gọi là sản phẩm. Bạn sẽ có thời gian đặt hàng, địa chỉ giao hàng, và những thứ như vậy. Và nơi nào chúng được thu thập? Đó là những gì biểu đồ mối quan hệ thực thể của bạn đang cho thấy. Chúng có thể trông rất kỹ thuật, nhưng bạn cũng có thể thực hiện chúng ở một góc độ trừu tượng nghiệp vụ để chúng thực sự cho thấy các khái niệm nghiệp vụ và sự hiểu biết nghiệp vụ về lĩnh vực thông tin.

 

 

Cuối cùng là từ điển dữ liệu (data dictionary). Nó cũng thuộc vào danh mục này của tài liệu yêu cầu dữ liệu. Nó sẽ đi vào chi tiết về các trường hoặc thuộc tính cụ thể, như trường đó có thể dài bao nhiêu? Nó chứa loại thông tin nào? Có các quy tắc kiểm tra hoặc quy tắc nghiệp vụ nào không?

 

Khi kết hợp, bạn có thể phát triển và kết hợp từ điển dữ liệu từ nhiều hệ thống khác nhau để chỉ ra cách các trường từ một hệ thống sẽ ánh xạ đến một hệ thống khác, cho cả một dự án tích hợp hệ thống một lần hoặc một dự án di chuyển hệ thống mà bạn chỉ di chuyển dữ liệu từ một nguồn sang nguồn khác. Hoặc chúng ta đang sử dụng một cái gì đó như một API để chỉ ra cách tích hợp hệ thống liên tục hoạt động và cách những trường đó ánh xạ đến nhau. Điều này được gọi là ánh xạ dữ liệu.

 

Chúng ta vừa liệt kê năm loại tài liệu và nhiều loại thông số kỹ thuật khác mà bạn có thể sử dụng trong mỗi loại đó. Tuy nhiên, không có nghĩa là một nhà phân tích nghiệp vụ sẽ tạo ra tất cả các thông số kỹ thuật này cho mỗi dự án. Hầu hết những nhà phân tích nghiệp vụ sẽ lựa chọn và sử dụng các thông số kỹ thuật phù hợp nhất dựa trên tính chất của dự án của họ, và họ sẽ tùy chỉnh các mẫu dựa trên nhu cầu của các bên liên quan và xem xét của dự án.

 

Bạn cần xem xét những gì đang diễn ra trong dự án của bạn và điều gì thực sự cần thiết để đưa ra quyết định tiếp theo. Điều quan trọng hơn nữa là bạn phải có một phương pháp phân tích nghiệp vụ rõ ràng và tập trung giúp bạn trở nên chiến lược và chủ động hơn trong cách tiếp cận dự án.

 

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.

 

 

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

• Chìa khoá thành công dành cho Business Analyst

• Công cụ & Kỹ năng dành cho Business Analyst

Khoá học Offline:

Tại Tp.HCM:

• Phân tích nghiệp vụ cơ bản 3.0

• Phân tích nghiệp vụ nâng cao 3.0

• Luyện thi chứng chỉ IIBA 3.0

Tại Hà Nội:

• Hà Nội - Phân tích nghiệp vụ 3.0

• Hà Nội - Phân tích nghiệp vụ nâng cao 3.0

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất

Ban biên tập nội dung - BAC