Bạn đang thực hiện dự án đầu tiên của mình với tư cách là một nhà phân tích kinh doanh (BA)? Bạn đã bao giờ tự hỏi chính xác những tài liệu yêu cầu nào mà một BA tạo ra để nhóm kinh doanh và kỹ thuật xem xét chưa? Các tài liệu yêu cầu được tạo cho bất kỳ dự án cụ thể nào sẽ phụ thuộc nhiều vào loại dự án, nhu cầu và sở thích của các bên liên quan về kinh doanh và kỹ thuật cũng như các tiêu chuẩn phân tích kinh doanh của tổ chức bạn. Dưới đây là 10 loại đặc tả yêu cầu khác nhau mà bạn nên cân nhắc.

Business Analyst có thể tạo nhiều loại tài liệu yêu cầu

1. Stakeholder Analysis (phân tích các bên liên quan)

Điều đầu tiên chúng ta cần tìm hiểu với tư cách là một BA là các bên liên quan là ai, nghĩa là chúng ta thực sự cần nói chuyện với ai để hiểu vấn đề kinh doanh và đưa ra các yêu cầu.

Ngay cả khi BA không tạo ra đặc tả phân tích các bên liên quan chính thức, bạn sẽ cần xác định ai là nhà tài trợ và các bên liên quan kinh doanh chính cho dự án, các quan điểm đa dạng mà bạn sẽ muốn đưa vào các yêu cầu và khám phá bất kỳ ai khác cần được tham gia. Trong một dự án công nghệ, các bên liên quan thường bao gồm các chuyên gia về chủ đề từ các nhóm kinh doanh và IT.

2. Business Analysis Plan (kế hoạch phân tích kinh doanh)

Tiếp theo trong danh sách là tạo một kế hoạch phân tích kinh doanh. Một BA thường sẽ tạo một kế hoạch phác thảo các nỗ lực khơi gợi, phân tích yêu cầu và xác nhận hoặc xác minh cũng như chỉ rõ ai chịu trách nhiệm về những gì trong bối cảnh nỗ lực phân tích kinh doanh.

Kế hoạch phân tích kinh doanh thường sẽ được định hướng bởi phương pháp phân tích kinh doanh của tổ chức, phương pháp này có thể chính thức hoặc không chính thức.

3. Current State Analysis (phân tích tình trạng hiện tại)

Hiểu được tình trạng hiện tại là một bước quan trọng trong quá trình phân tích kinh doanh. Nếu quy trình kinh doanh hoặc lĩnh vực kinh doanh hiện tại không được hiểu rõ, có thể cần phải phân tích và ghi lại trạng thái hiện tại trước khi xác định phạm vi dự án để cải thiện nó. Điều này có thể liên quan đến tài liệu quy trình “nguyên trạng” hoặc đánh giá các khả năng hiện tại.

4. Scope Statement Specification (tuyên bố phạm vi đặc điểm kỹ thuật)

Đây là điều cơ bản nhất có thể bàn giao cho bất kỳ dự án nào, một định nghĩa rõ ràng về phạm vi của dự án hoặc sản phẩm. Thông số kỹ thuật này cũng có thể được gọi là Business Case (trường hợp kinh doanh), Vision Document (Tài liệu tầm nhìn) hoặc Business Requirements Document (Tài liệu yêu cầu kinh doanh) (mặc dù trên thực tế, BRD thường bao gồm nhiều phần bổ sung có thể bao gồm Functional Requirements (Yêu cầu chức năng). Trong đặc tả yêu cầu này, về cơ bản bạn đang trả lời các câu hỏi sau:

• Chúng ta đang giải quyết vấn đề gì hoặc nhu cầu kinh doanh là gì?
• Phạm vi của giải pháp cho vấn đề là gì?
• Đầu tư vào việc giải quyết vấn đề có đáng không?

Trong một môi trường agile, những loại câu hỏi này có thể được trả lời ở dạng sử thi.

5. Functional Requirements Specification (đặc tả 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 như vậy), thì nhà phân tích nghiệp vụ sẽ chỉ định các yêu cầu chức năng cho dự án. Các đặc tả yêu cầu này cũng có thể được gọi là yêu cầu phần mềm, yêu cầu kỹ thuật hoặc yêu cầu hệ thống.

Các yêu cầu chức năng xác định những gì hệ thống thực hiện, cách thức hoạt động của hệ thống và thường được viết ở cấp độ mà một “người dùng” nhất định có thể yêu cầu hệ thống thực hiện. Các yêu cầu chức năng có thể được nắm bắt trong nhiều loại sản phẩm chuyển giao yêu cầu.

• Các use case là một cách rất phổ biến để nắm bắt các yêu cầu chức năng.
• Những lần khác, use case được ghi lại cùng nhau trong đặc tả yêu cầu phần mềm (SRS), cũng có thể bao gồm các yêu cầu phi chức năng.
• Trong một môi trường agile, các yêu cầu chức năng được nắm bắt trong các user stories được sắp xếp trong một hồ sơ tồn đọng của sản phẩm.

Đối với các BA không có nền tảng về IT, đây là cấp độ mà bạn cần học để hiểu và nói một cách thông minh về “IT”. Đó là về những gì hệ thống có thể làm cho doanh nghiệp, chứ không phải về cách hệ thống đó được xây dựng. Nếu ngay cả khi mức độ hiểu biết về các hệ thống công nghệ này không hấp dẫn, thì có lẽ tốt hơn hết bạn nên tập trung vào các vai trò BA tập trung vào quy trình kinh doanh.

6. Wireframes and Other Visual Documentation (wireframes và tài liệu trực quan khác)

Thông thường, các yêu cầu chức năng đi kèm với kết xuất của giao diện người dùng, phổ biến nhất là trong các wireframe có độ trung thực thấp. Một BA đồng thời là nhà thiết kế trải nghiệm người dùng cũng có thể chịu trách nhiệm tạo nguyên mẫu có độ trung thực cao.

Và nếu các quy tắc đằng sau giao diện người dùng là quan trọng, thì đặc tả giao diện người dùng có thể là một thông số hữu ích để tập hợp tất cả các chi tiết lại với nhau theo ngữ cảnh cho nhóm phát triển của bạn. Sơ đồ quy trình làm việc cũng thường được sử dụng để mô tả quy trình chức năng hoặc quy trình kinh doanh theo cách trực quan, tạo điều kiện thuận lợi cho quy trình phê duyệt yêu cầu hiệu quả hơn.

7. Information or Data Model Documentation (thông tin và tài liệu mô hình dữ liệu)

Ngoài chức năng hướng tới người dùng của phần mềm, BA cũng có thể xác định các yếu tố của mô hình thông tin. Điều này có thể ở cấp độ khái niệm hoặc cấp độ chi tiết hơn bằng cách sử dụng từ điển dữ liệu hoặc đặc tả ánh xạ dữ liệu.

8. Test Plans, Test Cases, or User Acceptance Test Plans (kế hoạch kiểm tra, trường hợp kiểm tra, hoặc kế hoạch kiểm tra chấp nhận của người dùng)

Nếu BA tham gia kiểm thử ứng dụng phần mềm, họ cũng có thể tạo một kế hoạch kiểm thử và các trường hợp kiểm thử chi tiết để xác nhận rằng các yêu cầu chức năng được đáp ứng.

Nhiệm vụ này thường được xử lý bởi một kỹ sư đảm bảo chất lượng chuyên dụng. Trong trường hợp đó, BA có thể được yêu cầu xem xét kế hoạch của họ. Ngay cả khi kiểm tra chức năng cơ bản được thực hiện bởi QA, BA cũng có thể tham gia vào quá trình kiểm tra do các chuyên gia về chủ đề kinh doanh thực hiện.

Điều này thường được gọi là Thử nghiệm chấp nhận của người dùng (UAT). BA có thể liệt kê các tình huống để các bên liên quan trong kinh doanh xem xét và thực sự có thể tạo điều kiện thuận lợi cho các yếu tố của thử nghiệm.

9.  Change Management (thay đổi cách quản lý)

Mặc dù User Acceptance Testing (Thử nghiệm mức độ chấp nhận của người dùng) giúp cộng đồng doanh nghiệp bắt đầu đi theo con đường đón nhận những thay đổi sắp tới, nhưng có thể cần đến các sản phẩm chuyển giao khác. Chúng có thể bao gồm các thủ tục kinh doanh hoặc quy trình kinh doanh được cập nhật, danh sách kiểm tra hoặc hỗ trợ công việc hoặc tài liệu đào tạo mới.

Một lần nữa, đôi khi các sản phẩm và quy trình này được bao phủ bởi các nhóm khác. Khi kết thúc dự án, BA cũng có thể cập nhật các sản phẩm bàn giao yêu cầu để phản ánh chức năng được xây dựng để nhóm có thể bắt đầu dự án tiếp theo làm việc cho tài liệu hệ thống cập nhật.

10. Throughout the Project (xuyên suốt dự án)

Mặc dù lý tưởng nhất là vai trò BA và PM (quản lý dự án) được thực hiện bởi hai cá nhân khác nhau, BA chịu trách nhiệm quản lý quy trình yêu cầu và đóng góp vào kế hoạch dự án.

Thông thường, điều này có nghĩa là duy trì danh sách các vấn đề về yêu cầu, đóng góp vào kế hoạch triển khai dự án và cung cấp các cập nhật trạng thái thường xuyên. Bạn cũng sẽ tạo chương trình họp và nhập ghi chú cuộc họp để nắm bắt kết quả thảo luận về yêu cầu của mình và có thể tham gia vào việc quản lý các yêu cầu thay đổi khi các bên liên quan khám phá các bản cập nhật đối với yêu cầu.

Không có nghĩa là một BA tạo ra tất cả các thông số kỹ thuật yêu cầu này cho từng dự án. Hầu hết các BA chọn các thông số kỹ thuật phù hợp nhất dựa trên bản chất dự án của họ và tùy chỉnh các mẫu của họ dựa trên nhu cầu của các bên liên quan và những cân nhắc của dự án.

Nguồn tham khảo:https://www.bridging-the-gap.com/