Requirements Management Plan & Requirement Traceability Matrix (RMP & RTM)

Một đặc trưng là trong suốt quá trình phát triển của 1 dự án, các yêu cầu nghiệp vụ sẽ được truyền đạt, phản hồi và thống nhất. Đó cũng chính là một trong những lí do khiến Requirements Management Plan(RMT) trở thành 1 tài liệu quan trọng đối với Business Analyst (BA). Công việc của người BA là làm việc với yêu cầu nghiệp vụ nên một điều hiển nhiên rằng là chúng cần được ghi chép lại và quản lý một cách khoa học. Việc quản lí yêu cầu sẽ giúp người BA có cơ sở để đánh giá, theo dõi và kiểm soát được tiến độ công việc, đảm bảo có một cái kết đẹp cho từng dự án.

Bên cạnh đó Requirement Traceability Matrix (RTM) sẽ là một điểm mà BA như bạn nên quan tâm, nó sẽ hỗ bạn rất nhiều trong qua trình quy xuất và đánh giá mức độ hoàn thành của từng yêu cầu. Cụ thể như thế nào thì mời các bạn cùng BAC tìm hiểu trong bài viết này nhé!

1. Requirements Management Plan (RMP)

Thiết lập cách quá trình các yêu cầu sẽ được thu thập, khơi gợi, tài liệu hóa, truy xuất, sắp xếp thực hiện theo thứ tự tiên với tiêu chuẩn nào, cũng như thay đổi và cập nhật yêu cầu mới như thế nào. Hay nói cách khác, RMP là một tập hợp các kế hoạch để quản lý yêu cầu nghiệp vụ. Trong dự án sẽ có nhiều kế hoạch cần làm như kế hoạch phân tích nghiệp vụ truyền thông (mô hình 3W: Who – What – When), kế hoạch quản lí rủi ro, ước tính hiệu suất và tiến độ công việc, …

Thường các BA sẽ hay gặp phải một số lỗi như sau khi lên kế hoạch yêu cầu:

• Việc thu thập yêu cầu (gathering requirements) chỉ là một phần nhỏ của quá trình khơi gợi yêu cầu để có

• Lối suy nghĩ của một số BA mới chỉ dừng trong giai đoạn ngắn hạn mà quên mất rằng cần lên một chiến lược lâu dài cho dự án. Khi bạn nghĩ đường xa cho dự án, bạn sẽ thấy có rất nhiều điều cần làm trước, trong và sau khi dự án kết thúc. Điều này sẽ giúp bạn suy nghĩa được nhiều hơn các giá trị tăng thêm mà có thể đem lại đến cho khách hàng.

• BA bỏ sót việc dự đoán và đề xuất phương án xử lý rủi ro. Có nhiều lý do khiến 1 dự án thất bại như thiếu thông tin yêu cầu người dùng, yêu cầu mơ hồ, hiểu sai yêu cầu hay yêu cầu thay đổi trong quá trình thực hiện,…

Dưới đây là một số cách mà một người BA có thể áp dụng để hạn chế những lỗi sai lầm trên và tăng giá trị mang lại cho khách hàng.

• Đứng dưới góc nhìn của các bên liên quan để thấu hiểu nhu cầu thực sự của họ, từ đó có thể thống nhất các yêu cầu của các bên một cách hợp lý và phù hợp nhất cho dự án.

• Dành thời gian để làm quen và thích nghi với cách làm việc của team nội bộ của bạn nếu bạn là người mới vào một team đã hoạt động từ trước. Vì mỗi dự án, hay từng công ty, khách hàng khác nhau sẽ có những  yêu cầu về tài liệu khác nhau. Hơn nữa, nó còn phụ thuộc vào internal team của các bạn, các bạn dev muốn đọc kiểu tài liệu gì. Vậy nên, nếu các bạn là một team mới bắt đầu của dự án thì bằng cách đưa vào kế hoạch quản lí yêu cầu của bạn những tiêu chí đường cơ sở. Cụ thể, về các loại tài liệu mà team bạn sẽ sử dụng, xác nhận lại dự đoán hiệu suất công việc của bạn trên từng thành viên trong team. Cũng dựa trên bản kế hoạch này mà bạn có thể đo lường, đánh giá và điều phối hợp lý trong quá trình làm việc của team mình.

Nhưng dù sao bạn chọn tài liệu nào thì nó cũng cần trả lời được một số câu hỏi của development team: Yêu cầu này liên quan người dùng nào?, họ sẽ đạt được gì từ yêu cầu này? và làm thế nào để yêu cầu được đáp ứng?

Các tài liệu về dự án bao gồm như Project Vision Document hay Business Requirement Document, Stakeholder Analysis Document, … sẽ giúp ích cho bạn rất nhiều trong quá trình lên kế hoạch quản lí yêu cầu cho từng giai đoạn của dự án.

Để hiểu và làm được chi tiết những công việc BA bạn có thể tham gia chương trình đào tạo đặc biệt của BAC, Khóa học: Phân tích nghiệp vụ phần mềm cơ bản – Chương trình chuẩn IIBA

Bạn có thể tham khảo mẫu sau: 

Bạn cũng có thể đọc thêm các loại tài liệu khác mà người BA cần có, như:

• Các loại requirement và output của business analyst (BA)
• Project Vision Document
• Phân biệt sự giống nhau – khác nhau giữa các tài liệu BRD, SRS và FRS
• Nhóm tài liệu cho BA: User story, Use case và Functional Specification Document
• Test case

2. Requirement Traceability Matrix (RTM)

Theo định nghĩa trong BABOK v3, khả năng truy xuất nguồn gốc yêu cầu là khả năng xác định và ghi lại lịch sử của từng yêu cầu, bao gồm nguồn gốc của nó (backward traceability – truy xuất nguồn gốc ngược), phân bổ của nó (forward traceability – truy xuất nguồn gốc phía trước) và mối quan hệ của nó với các yêu cầu khác.

Truy xuất yêu cầu giúp người BA có thể kiểm tra được nguồn gốc yêu cầu, hỗ trợ quá trình xác định tác động và mối quan hệ giữa chúng.

Một khi yêu cầu có sự thay đổi hoặc điều chỉnh, BA có thể xác định thay đổi đó tác động vào phần đặc tả kỹ thuật nào để có các sửa đổi phù hợp. Điều này rất quan trọng để đảm bảo rằng sửa đổi mới không phá vỡ bất kỳ yêu cầu hiện có nào trong hệ thống.

Dưới đây là mẫu ví dụ của RTM mà BAC sưu tầm:

Một loại ma trận có thể giúp BA hiểu vai trò của từng thành viên tham gia vào từng từng hoạt động của dự án. Đó là ma trận RACI:

• R: Responsible – trách nhiệm thực thi – người mà làm tham gia trực tiếp thực hiện nhiệm vụ và đảm bảo hoàn thành là ai? Ví dụ: Business Analyst, Application Developer or Technical Architect.
• A: Accountable -trách nhiệm giải trình – người nào sẽ chịu trách nhiệm cuối cùng cho gói công việc đó và giải trình khi nó hoàn thành. Ví dụ: Project Executive or Project Sponsor or Immediate Managers)
• C: Contributing (or Consulted) – tham vấn – những bên liên quan nào sẽ cung cấp thông tin khi cần thiết để hoàn thành gói công việc này hoặc là người sẽ tư vấn để ra quyết định cuối cùng trong dự án. Ví dụ: Subject Matter Experts
• I: Informed – thông báo – đây là nhóm đối tượng sẽ nhận được thông tin thông báo từ nhóm đối tượng khác về thông tin dự án. Ví dụ: Những người ngoài vòng trách nhiệm đối với dự án như nhân viên các phòng ban có liên quan.

Các bước tạo ma trận RACI

1. Liệt kê các đầu công việc cần hoàn thành.
2. Liệt kê những ai liên quan đến dự án và phân thành các vai trò R, A, C, I cho từng người.
3. Đảm bảo mỗi đầu công việc sẽ có đủ người chịu trách nhiệm thực thi và giải trình.
4. Không nên trong 1 task mà có hơn 1 người chịu trách nhiệm giải trình vì sẽ khó khăn trong khâu giải quyết mâu thuẫn nếu có.
5. Chia sẻ, thảo luận và thống nhất các vai trò trên ma trận với các bên liên quan trước khi dự án bắt đầu.

Dưới đây là một hình ảnh minh họa khác cho ma trận RACI.

Nếu bạn đang quan tâm đến lĩnh vực Business Analysis nhưng chưa biết nên bắt đầu từ đâu. Hay Bạn có nhiều năm kinh nghiệm trong các lĩnh vực tài chính, ngân hàng, bảo hiểm,… mong muốn tìm kiếm con đường mới. Hãy liên hệ ngay cho BAC  theo số Hotline: 0909 310 768 để được tư vấn.

Nguồn tham khảo:
projectmanagementdocs.com
batimes.com/articles 
media.modernanalyst.com
viblo.asia

Nhu cầu đào tạo doanh nghiệp

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.