PMI-PBA Gaps
Bài viết “PMI-PBA Gaps” nhằm chia sẻ kiến thức và bí kíp quan trọng trong bài thi PMI-PBA®. Bài viết này hy vọng có thể giúp ích cho bạn đạt kết quả cao trong bài thi PMI-PBA®.
Bài viết được xuất bản lần đầu vào 07/03/2024.
Lý do chọn chứng chỉ PMI-PBA®
Như có đề cập trong lesson learned trước đó, mình có chia sẻ 03 lý do chính vì sao mình lựa chọn chứng chỉ PMI-PBA® thay vì các chứng chỉ khác:
- Tầm ảnh hưởng quốc tế: PMI là một tổ chức toàn cầu phục vụ hơn 5 triệu chuyên gia bao gồm khoảng 680.000 thành viên tại 217 quốc gia và vùng lãnh thổ trên thế giới, và chứng chỉ PMI-PBA® được công nhận rộng rãi trên toàn cầu. Điều này tạo điều kiện thuận lợi cho bạn trong việc xây dựng sự nghiệp không chỉ ở quốc gia mình mà còn ở nhiều nơi trên thế giới.
- Sự kết hợp giữa phân tích kinh doanh và quản lý dự án: Chứng chỉ PMI-PBA® không chỉ hướng đến phân tích kinh doanh mà còn tập trung vào quản lý dự án. Điều này giúp bạn hiểu rõ hơn về cách phân tích kinh doanh ảnh hưởng đến toàn bộ quá trình dự án, giúp bạn trở thành một BA chuyên nghiệp toàn diện, có khả năng hiểu và tương tác với các khía cạnh khác nhau của dự án cùng với PM.
- Khả năng chuyển đổi chứng chỉ & level-up: Nếu bạn đã có các chứng chỉ khác của PMI như PMP® (Project Management Professional), việc thêm PMI-PBA® vào hồ sơ của bạn có thể tạo ra một hồ sơ mạnh mẽ và đa dạng hơn, tăng khả năng cạnh tranh trong việc tìm kiếm cơ hội nghề nghiệp. Hơn nữa, kiến thức của PMI-PBA®, PMP®, PMI-ACP®,… có thể bổ trợ qua lại tạo lợi thế cạnh tranh cho mình khá nhiều.
Xem thêm: PMI Certification Framework
Nên bắt đầu từ đâu?
Sau khi xác định chứng chỉ PMI-PBA® là phù hợp với lộ trình cá nhân thì mình có thể bắt đầu hành trình chinh phục PMI-PBA của mình bằng 02 hình thức:
- Tự ôn tập
- Tham gia khoá luyện thi PMI-PBA của Atoha hoặc các trung tâm khác phù hợp với từng cá nhân.
Tìm hiểu yêu cầu, khung kiến thức và tài liệu ôn tập
- Đọc kỹ PMI-PBA® Handbook để hiểu rõ yêu cầu, quy trình đăng ký, lịch thi, và quy định của kỳ thi.
- Nắm vững nội dung kiến thức trong bộ đề cương khung kiến thức (PBA® Examination Content Outline) của PMI. Đây sẽ là nền tảng cho việc học tập và ôn tập.
- Các tài liệu “MUST READ” được đề xuất bởi đội ngũ Atoha:
- BA For Practitioners Practice Guide
- PMI-PBA® Exam Content Outline
- The PMI Guide to Business Analysis (2017)
(*) Lưu ý cập nhật 24/01/2024: Hiện tại PMI đã phát hành Business Analysis for Practitioners: A Practice Guide – Second Edition (cần là thành viên PMI để truy cập link này), tuy nhiên chưa có cập nhật mới về thay đổi nội dung đề thi (PMI-PBA® Exam Content Outline). Do đó chúng ta vẫn sử dụng BA For Practitioners Practice Guide, hoặc bạn có thể kết hợp cả hai phiên bản nếu có thời gian.
PMI-PBA Gaps - Mọi kiến thức cần biết về PMI-PBA®
A/ Business Analysis và Business Analyst trong phạm vi PBA
- Business Analysis (Phân tích kinh doanh) là việc áp dụng kiến thức, kỹ năng, công cụ và kỹ thuật để:
- Xác định các vấn đề và cơ hội.
- Xác định nhu cầu kinh doanh và đề xuất các giải pháp khả thi để đáp ứng những nhu cầu kinh doanh và hỗ trợ việc ra quyết định chiến lược.
- Khơi gợi, phân tích, xác định, truyền đạt và quản lý các yêu cầu cũng như thông tin sản phẩm khác.
- Xác định lợi ích và cách tiếp cận để đo lường và hiện thực hóa giá trị cũng như phân tích các kết quả đó.
>> Nói tóm lại, phân tích kinh doanh là tập hợp các hoạt động được thực hiện để hỗ trợ cung cấp các giải pháp phù hợp với mục tiêu kinh doanh và mang lại giá trị liên tục cho tổ chức.
- Business Analyst được sử dụng theo nghĩa rộng và đại diện cho tất cả các vai trò chịu trách nhiệm thực hiện các hoạt động phân tích kinh doanh trong nhiều ngành hoặc trong tổ chức, bất kể công việc có được thực hiện để hỗ trợ danh mục (Portfolio), chương trình (Program), hoặc dự án (Project).
B/ Vai trò của Business Analyst
Phân tích kinh doanh là tập hợp các hoạt động được thực hiện để hỗ trợ cung cấp các giải pháp phù hợp với mục tiêu kinh doanh và mang lại giá trị liên tục cho tổ chức. Dựa vào định nghĩa, phạm vi của Business Analysis là rất rộng và bao hàm. Điều này có thể hơi khác so với thực tế đối với vai trò Business Analyst trong các lĩnh vực, ví dụ là lĩnh vực công nghệ thông tin, khi Business Analyst được phân công vào dự án và chỉ tập trung vào việc phát triển, quản lý yêu cầu.
Trong phạm vi PMI-PBA®, chúng ta cần nắm rõ phân tích kinh doanh:
- Liên quan đến nỗ lực trong nhiều lĩnh vực khác nhau: từ xác định nhu cầu kinh doanh đến triển khai giải pháp, chứ không chỉ riêng về quản lý yêu cầu.
- Được tiến hành để hỗ trợ nhiều sáng kiến kinh doanh, bao gồm các chương trình và dự án, cũng như các hoạt động vận hành đang diễn ra, như giám sát, lập mô hình và dự báo. Mặc dù trọng tâm chính của PBA là phân tích hoạt động kinh doanh để hỗ trợ các chương trình và dự án, nhưng các thực tiễn trong hướng dẫn này có thể được áp dụng ở bất kỳ nơi nào tiến hành phân tích kinh doanh.
Hiểu được các lưu ý trên chúng ta sẽ rất dễ để có thể hiểu các Miền (Knowledge Areas), Nhóm quy trình (Process Group), và Process (Quy trình) theo chuẩn PMI-PBA®.
Mục tiêu của The PMI Guide to Business Analysis (2017) và BA For Practitioners Practice Guide của PMI là để thiết lập sự hiểu biết về phân tích kinh doanh chứ không phải về các chức danh công việc, vì:
- Những người thực hiện phân tích kinh doanh thông thường được gọi là “Business Analyst", nhưng vẫn có rất nhiều chức danh khác không phải là “Business Analyst" nhưng họ vẫn thực hiện các hoạt động phân tích kinh doanh, ví dụ: Strategic Business Analyst, Data Analyst, Process Analyst, Enterprise Analyst hoặc Systems Analyst,… Trong phạm vi hướng dẫn này, “Business Analyst” được sử dụng theo nghĩa rộng và đại diện cho tất cả các vai trò chịu trách nhiệm thực hiện các hoạt động phân tích kinh doanh trong nhiều ngành hoặc trong tổ chức, bất kể công việc có được thực hiện để hỗ trợ danh mục, chương trình, hoặc dự án.
- Phân tích kinh doanh liên quan đến việc lựa chọn các quy trình, công cụ, kỹ thuật, đầu vào và đầu ra để sử dụng cho một danh mục đầu tư, chương trình hoặc dự án cụ thể. Business Analyst thực hiện hoạt động lựa chọn này bằng cách cộng tác với giám đốc dự án, nhà tài trợ, người quản lý chức năng, nhà phân tích kinh doanh khác (Tailoring). Dưới đây là cách nhân tố ảnh hưởng đến Business Analysis:
- Project life cycle: Predictive, Adaptive, Hybrid → Yếu tố tác động lớn nhất đến các hoạt động phân tích kinh doanh
- Kinh nghiệm và trải nghiệm của các bên liên quan
- Vị trí địa lý của các bên tham gia dự án
- Kinh nghiệm phân tích kinh doanh của nhóm
- Độ trưởng thành của tổ chức trong việc phân tích kinh doanh
- Văn hoá doanh nghiệp,…
C/ Requirements (Yêu cầu)
a/ Phân loại yêu cầu
REQUIREMENTS | MÔ TẢ |
| Business Requirements |
Ví dụ: “I don't know much about requirements. I just know we want to capture 30% more of the market with this new product we're talking about” |
| Stakeholder Requirements |
|
Solution Requirements | - “To-be, future state”.
Ví dụ của yêu cầu phi chức năng: “The system shall allow 100 users concurrently without a degradation of system response time.” Technical Requirements không phải là một phần của business analysis work, tuy nhiên BA cần làm việc sát sao với các bên liên quan kỹ thuật để phục vụ yêu cầu kinh doanh |
| Transition Requirements | Mô tả các khả năng tạm thời, chẳng hạn như các yêu cầu đào tạo và chuyển đổi dữ liệu, và những thay đổi vận hành cần thiết để chuyển từ trạng thái hiện tại sang trạng thái tương lai. Ví dụ: All data that is less than 3 years old should be migrated to the new system. |
Một vài lưu ý về yêu cầu: Số lượng yêu cầu có mối quan hệ trực tiếp với quy mô của dự án và sản phẩm.
Ví dụ:
- Dự án A: 100 yêu cầu
- Dự án B: 1000 yêu cầu
→ Quy mô dự án B > A.
b/ Requirement Dependency
| DẠNG PHỤ THUỘC | MÔ TẢ | VÍ DỤ/HÌNH MINH HỌA |
Sub-sets | Một yêu cầu có thể là một phần của một yêu cầu khác. |  |
Implementation dependency | Một số yêu cầu phụ thuộc vào việc thực hiện của các yêu cầu khác trước khi chúng có thể được thực hiện. | Nếu yêu cầu A phụ thuộc vào yêu cầu B, thì A không thể được thực hiện cho đến khi B được thực hiện. |
Benefit hoặc value dependency | Lợi ích của một yêu cầu không thể được thực hiện nếu không có yêu cầu khác được thực hiện trước. | Yêu cầu A có thể được thực hiện, nhưng lợi ích từ việc này có thể không được đạt được cho đến khi yêu cầu C cũng được thực hiện. Mối quan hệ này có vẻ tương tự như phụ thuộc thực hiện, nhưng không phải là về việc liệu A có thể được thực hiện; mà là liệu giá trị từ A có thể được nhận ra hay không. Ví dụ: An organization is interested in improving wait times for customers calling into their phone reservation center. They identify a requirement to add a new phone line as a high-priority feature. However, they discover that the existing phone system is unable to accommodate any additional phone lines. In this case, the value of the requirement to add a new phone line will not be achieved until a new phone system is implemented. |
c/ Một vài lưu ý về yêu cầu: Baselined requirements: Requirements that are verified, validated, and approved
D/ KA: Need Assessment (Đánh giá nhu cầu)
a/ Một vài lưu ý chính
- Business needs (nhu cầu kinh doanh) và Situation statement (Tuyên bố tình huống hay Mô tả tình huống) có từ quy trình “Identify Problem or Opportunity” (Xác định vấn đề hay cơ hội).
- Business case và Product scope có từ quy trình “Assemble Business Case” (Lập kế hoạch kinh doanh).
- Mục tiêu kinh doanh (business goals) ở mức thấp hơn so với mục tiêu tổ chức (organizational goals).
- Bên liên quan mà BA làm việc rất sát sao khi phát triển business case: Sponsor.
- Bất kỳ business case nào cũng có thể được xem xét và cập nhật khi dự án, chương trình hoặc danh mục phát triển theo thời gian.
- Các câu hỏi về Weighted Ranking khá nhiều → Cần tập trung ôn.
b/ Chi phí cơ hội (Opportunity Cost)
- Định nghĩa từ PMI: A concept applied to quantify the missed opportunity when deciding to use a resource (e.g., investment dollars) for one purpose versus another. Alternately opportunity cost is the loss of potential future return from the second-best unselected project. In other words, it is the opportunity (potential return) that will not be realized when one project is selected over another
>> Chi phí cơ hội (Opportunity Cost) đại diện cho những lợi ích tiềm năng mà cá nhân hay doanh nghiệp có thể bỏ lỡ khi lựa chọn phương án này thay vì một phương án khác.
Ví dụ:
Bạn đang phân tích hai dự án trong khi phát triển business case. Benefit của dự án A là $100,000, benefit của dự án B là $150,000.
- Chi phí cơ hội của dự án B là: $100,000
- Chi phí cơ hội của dự án A là: $150,000
→ Chi phí cơ hội của dự án A lớn hơn chi phí cơ hội của dự án B.
c/ Weighted ranking (hay weighted criteria)
- multi-criteria weighted ranking models to objectively compare solution options.
- đây là đánh giá định lượng (quantitative assessment).
- đây là công cụ để “prioritizing”, không phải công cụ để “assessing feasibility”
Các bước để thực hiện weighted ranking:
(1) xác định tiêu chí đánh giá và trọng số
(2) scoring các lựa chọn dựa trên tiêu chí
(3) nhân số điểm từ bước (2) với trọng số → Output: điểm tổng của từng sự lựa chọn
(4) sắp xếp theo độ ưu tiên giảm dần
Ví dụ:
Lưu ý: thuật ngữ đúng cho kỹ thuật này là Weighted ranking (hay weighted criteria), đề hay đưa các made-up terms (từ bịa) như: weighted prioritization, weighted requirements, …
E/ KA: Stakeholder Engagement
| CHIẾN LƯỢC CHUYỂN GIAO | MÔ TẢ | VÍ DỤ |
| Massive one-time cutover | Chuyển đổi một lần sang trạng thái tương lai. | Tổ chức triển khai một hệ thống quản lý tài nguyên doanh nghiệp (ERP) mới quyết định chuyển từ hệ thống cũ sang hệ thống mới vào cuối tuần. Tất cả người dùng chuyển đổi sang hệ thống mới cùng một lúc. |
Target segment | Chuyển giao theo từng giai đoạn của trạng thái tương lai, chẳng hạn như theo khu vực hoặc theo loại khách hàng hoặc loại nhân viên. | Một công ty phần mềm giới thiệu một phiên bản mới của ứng dụng theo từng giai đoạn. Ban đầu, họ phát hành nó cho một khu vực cụ thể hoặc một nhóm người dùng thử nghiệm, thu thập phản hồi, và sau đó mở rộng dần phạm vi phát hành đến các khu vực khác hoặc các nhóm người dùng dựa trên sự thành công cũng như phản hồi của người dùng. |
Time-boxed coexistence | Thời gian tồn tại song song được giới hạn (time-boxed) giữa trạng thái hiện tại và trạng thái tương lai, với việc chuyển đổi cuối cùng vào một ngày cụ thể trong tương lai.. | Một tổ chức tài chính giới thiệu một nền tảng ngân hàng trực tuyến mới nhưng cho phép khách hàng sử dụng cả hai nền tảng cũ và mới trong một khoảng thời gian cụ thể (ví dụ, sáu tháng). Sau thời gian tồn tại song song được giới hạn, họ chuyển toàn bộ người dùng sang nền tảng mới và đóng nền tảng cũ. |
Permanent coexistence | Tồn tại song song vĩnh viễn của trạng thái hiện tại và trạng thái tương lai | Một công ty sản xuất triển khai một hệ thống sản xuất mới nhưng quyết định duy trì vĩnh viễn một số khía cạnh của hệ thống cũ do yêu cầu cụ thể từ khách hàng hoặc khả năng tương thích với hệ thống cũ. Hai hệ thống tiếp tục tồn tại song song để phục vụ các nhu cầu khác nhau trong tổ chức. |
F/ KA: Elicitation - Khơi gợi yêu cầu
- 04 giai đoạn:
- Introduction.
- Body.
- Close.
- Follow-Up.
- Tools & Techniques để thực hiện Elicitation
| TOOLS & TECHNIQUES | MÔ TẢ | VÍ DỤ/LƯU Ý |
| Brainstorming | - Keywords: Generate ideas - Mục tiêu của Brainstorming là thu thập càng nhiều ý kiến càng tốt. Việc phân tích các ý kiến có lợi ích, khả thi, … hay không thì sẽ để sau. - Thường sử dụng kết hợp với các kỹ thuật: Workshops, Collaborative games, Focus Group. | “Affinity Diagram” là công cụ bổ trợ cho Brainstorming nhằm gom nhóm các ý kiến có cùng nhóm với nhau. Affinity Diagram:  |
Collaborative games |
| Spider Web: Product Box:  Speed Boat:  |
Document analysis |
Nhược điểm:
| |
| Facilitated workshops & Focus groups | - Facilitated workshops: Use a structured meeting led by a skilled, neutral facilitator and a carefully selected group of stakeholders to collaborate and work toward a stated objective. - Focus groups:
| Có thể nói rất dễ nhầm lẫn giữa Facilitated workshops & Focus group. Tuy nhiên đây là hai ý chính để phân biệt giữa hai kỹ thuật này:
|
Interviews | Xem Types of Interview (Dạng phỏng vấn) bên dưới | - Interview có thể giúp người được phỏng vấn dễ dàng chia sẻ hơn nếu có nhiều thông tin “sensitive". - Có thể thực hiện 1-1 hoặc 1-n |
| Observation | - Uncover information that stakeholders are not able or willing to provide and to use the information in the formulation of product requirements. - CHỈ dùng để phân tích Current state. Nhược điểm: - Người được quan sát có thể cảm thấy như đang bị “dự giờ". - Mất nhiều thời gian để lên kế hoạch cũng như thực thi. | |
Prototyping | Xem Interface Model | |
| Questionnaires and surveys | - Ưu điểm: Giúp thu thập phản hồi từ số lượng lớn người tham gia trong thời gian ngắn. - Nhược điểm: Nếu bài khảo sát thiết kế chưa tốt, dữ liệu có thể không có giá trị và chất lượng. |
a/ Types of Interview (Dạng phỏng vấn)
- Structured interviews (Phỏng vấn có cấu trúc): Danh sách câu hỏi được chuẩn bị trước và thời gian phỏng vấn được lên kế hoạch rõ ràng, chi tiết.
Ví dụ:
- Câu hỏi 1: "Bạn có kinh nghiệm làm việc trong môi trường đa văn hóa không?"
- Câu hỏi 2: "Làm thế nào bạn quản lý sự đa dạng văn hóa trong nhóm làm việc?"
- Unstructured interviews (Phỏng vấn không cấu trúc): Bắt đầu với một danh sách các câu hỏi chuẩn bị, nhưng chỉ có một câu hỏi chắc chắn được đặt là câu hỏi đầu tiên. Sau đó, các câu hỏi tiếp theo dựa trên các câu trả lời của các câu hỏi trước. Phỏng vấn này có tính chất riêng và yêu cầu kỹ năng để giữ thông tin tập trung vào việc đạt được mục tiêu.
Ví dụ:
- Câu hỏi 1: "Bạn có kinh nghiệm làm việc trong môi trường đa văn hóa không?" >> Câu trả lời: "Có, tôi đã từng làm việc trong một công ty quốc tế."
- Câu hỏi 2 (dựa trên câu trả lời của câu hỏi 1): "Bạn gặp những thách thức gì khi làm việc trong môi trường quốc tế?"
- Synchronous Interviews (Phỏng vấn đồng bộ): Là quá trình phỏng vấn mà trong đó người phỏng vấn và ứng viên tương tác trực tiếp vào cùng một thời điểm. Điều này có nghĩa là cả hai bên tham gia vào cuộc trò chuyện cùng một lúc, thông qua cuộc gọi video trực tiếp hoặc hội thảo trực tuyến.
Ví dụ: Cuộc gặp trực tuyến qua video call giữa nhà tuyển dụng và ứng viên, nơi họ thảo luận về kỹ năng, kinh nghiệm và mục tiêu nghề nghiệp của ứng viên.
- Asynchronous interviews (Phỏng vấn không đồng bộ): Là quá trình phỏng vấn mà trong đó ứng viên gửi câu trả lời cho các câu hỏi được đặt trước mà không cần tương tác trực tiếp với người phỏng vấn. Trái với phỏng vấn đồng bộ, ở đây ứng viên có thể viết, ghi âm hoặc quay video trả lời câu hỏi và gửi lại sau đó.
Ví dụ: Khi nhà tuyển dụng gửi danh sách câu hỏi cho ứng viên, và ứng viên có thể trả lời các câu hỏi đó bằng cách ghi âm hoặc quay video và gửi lại cho nhà tuyển dụng.
b/ Types of Questions (Dạng câu hỏi)
- Open-ended question (Câu hỏi mở): là dạng câu hỏi không có câu trả lời cố định, đòi hỏi người trả lời phải suy nghĩ và đưa ra câu trả lời của riêng mình. Câu hỏi mở thường bắt đầu bằng các từ để hỏi như "ai", "cái gì", "ở đâu", "khi nào", "tại sao", "như thế nào",...
Câu hỏi mở trong tình huống người hỏi muốn:
- Cho phép người trả lời bày tỏ quan điểm, ý kiến, suy nghĩ và cảm xúc của mình.
- Kích thích sự sáng tạo và tư duy của người trả lời,…
Ví dụ: Bạn cảm nghĩ như thế nào khi kết thúc khoá học PBA tại Atoha?
- Closed-ended question (Câu hỏi đóng): Đặt câu hỏi đóng khi bạn muốn câu trả lời có thể được tạo thành biểu đồ và được sử dụng để hiển thị xu hướng và tỷ lệ phần trăm.
Ví dụ: Bạn có thích làm bài tập trên SEW của Atoha không?
- Contextual question (Câu hỏi ngữ cảnh) và Context-free question (Câu hỏi không ngữ cảnh):
Câu hỏi ngữ cảnh thường yêu cầu người trả lời cung cấp thông tin cụ thể về một tình huống hoặc ngữ cảnh cụ thể, trong khi câu hỏi không ngữ cảnh có thể được đặt trong bất kỳ tình huống nào mà không yêu cầu ngữ cảnh cụ thể.
- Câu hỏi ngữ cảnh: "Tại sao bạn chọn ngành học này?", "Khi nào bạn đã gặp tình huống tương tự trước đây?"
- Câu hỏi không ngữ cảnh: "Bạn thích môn học nào nhất?", "Bạn đã từng tham gia hoạt động nào trong thời gian nghỉ hè vừa qua?"
G/ KA: Analysis
a/ Models
Models hỗ trợ uncover gaps, and simplify and summarize complex information - nên sẽ được sử dụng bất kể delivery approach của dự án là gì.
Nhóm models:
- Scope models
- Process models
- Rules models
- Data models
- Interface models
Scope models là model là “most likely" chúng ta sẽ sử dụng đầu tiên.
b/ Keywords để nhận biết các dạng models:
MODELS | KEYWORDS | VÍ DỤ |
Scope Models | ||
Goal and business objectives model | Goal models and business objective models are diagrams for organizing and reflecting goals, business problems, business objectives, success metrics, and high-level features. | |
Ecosystem map | An ecosystem map is a diagram that shows all the relevant systems, the relationships between them, and optionally, any data objects passed between them. | |
Context diagram | Context diagram shows all of the direct system and human interfaces to systems within a solution. | |
Feature model | A feature model is a visual representation of all of the features of a solution arranged in a tree or hierarchical structure. The structure can be horizontal or vertical. | |
Organizational chart | An organizational chart helps with stakeholder discovery. | |
Use case diagram | A use case diagram shows all of the in-scope use cases for a system. | |
Decomposition model |
| |
Fishbone diagram | Analyzing root cause, synonyms: Ishikawa, why-why | |
Interrelationship diagram | This special type of cause-and-effect diagram is helpful for visualizing complex problems that have seemingly unwieldy relationships among multiple variables. | |
SWOT diagram |
| |
Process Models | ||
Process flow | Synonyms: swimlane diagrams, process maps, process diagrams, or process flow charts, visually depict the tasks that people perform in their jobs. | |
Use case |
| |
User story | - A user story is a statement, written from the point of view of the user, and describes the functionality needed in a solution. - Elements that are typically included: Actor, function, and benefit. | |
Rule Models | ||
Business rules catalog | A business rules catalog is a table of business rules and related attributes. | |
Decision tree | Decision trees and decision tables depict a series of decisions and the outcomes they lead to. Decision trees and tables are often used to model business rules. | |
Decision table |
| |
Data Models | ||
Entity relationship diagram | The entity relationship diagram (ERD), also called a business data diagram, shows the business data objects or pieces of information of interest in a project and the cardinality relationship between those objects. | |
Data flow diagram | A data flow diagram illustrates the relationships between systems, actors, and the data that is exchanged and manipulated over the course of one or many processes. | |
Data dictionary | A data dictionary is a tabular format and shows data fields and attributes of those fields. | |
State table | State tables and state diagrams model the valid states of an object and any allowed transitions between those states. | |
State diagram | ||
Interface Models | ||
Report table | A report table is a model that captures the detailed level requirements for a single report. | |
System interface table | A system interface table is a model of attributes that captures all of the detailed level requirements for a single system interface. | |
User interface flow | A user interface flow displays specific pages or screens within a functional design and plots out how to navigate the screens according to various triggers. | |
Wireframes | The display-action-response model is used in conjunction with wireframes or screen mockups to identify page elements and the functions, if any, they are attached to.
Wireframe: A prototype that provides a static blueprint of a user interface.
Có hai dạng high-fidelity prototypes:
| |
Display-action-response | ||
H/ KA: Traceability & Monitoring
a/ Requirements traceability matrix (RTM)
A traceability matrix is a grid that allows for the linkage of product requirements from the source to the deliverables that satisfy them throughout the project life cycle.
Một vài thuộc tính chính có thể có trong RTM: ID, Title, Priority, Source, Status, and Author, …
Predictive projects use traceability matrices, and adaptive projects use interaction matrices.
Nếu dự án là Predictive projects, stakeholders có thể xem Business Analysis Plan để xem RTM trong dự án được quản lý như thế nào.
Requirements traceability matrix
b/ Phân biệt Configuration Management System, Version Control System, Change Control System và Work Authorization System.
Configuration Management System (CMS) is used to - ensure that the product or service being built conforms to its approved requirements. - make sure the requirements and related information are accessible to the project team. | Version Control System (VCS) is a type of Configuration Management System (CMS) that tracks the history of revisions of any type of work product. | Change Control System is used to manage change requests and the resulting decisions, and | Work Authorization System is used to ensure that work is performed at the right time and in the right sequence. |
I/ KA: Solution Evaluation
- Mục đích của việc đánh giá giải pháp là xác định xem giải pháp có thực sự đạt được kết quả kinh doanh mong đợi hay chưa. Từ đó đưa ra quyết định rằng có nên tiếp tục hay kết thúc dự án/chương trình/danh mục trước khi tất cả chức năng được xây dựng nhằm giải phóng tài nguyên cho các dự án có mức độ ưu tiên cao hơn và có giá trị cao hơn.
- Solution evaluation được thực hiện khi:
sau khi solution được “released", hoặc
cần ra quyết định go/no-go
- Sự khác biệt giữa “validating the test results” và “evaluating the solution”:
Validating the test results is done to make sure the solution meets the requirements.
Evaluating the solution is making sure it satisfies the value proposition.
- Tần suất, hoạt động, thời điểm đánh giá giải pháp có thể khác nhau giữa predictive & adaptive. Tuy nhiên mục đích cuối cùng của quá trình này vẫn là xác định xem giải pháp có thực sự đạt được kết quả kinh doanh mong đợi hay chưa.
- “The solution can't be evaluated as to whether or not it is delivering value until it is deployed.” → Chúng ta không thể đánh giá giải pháp của mình có mang lại giá trị hay không khi giải pháp chưa đi vào hoạt động (deployed).
- Solution evaluation
J/ Các kiến thức khác
a/ Business Analysis Plan
- A business analysis plan:
is created to document how the business analysis process will be performed, including the plan decisions agreed to by the project team.
set expectations around the amount of business analysis work that will be required.
- Dự án Adaptive “rarely" có Business Analysis Plan.
- The business analyst plan encompasses more than the requirements management plan.
- Business Analysis Planning & Project Management Planning là hai hoạt động độc lập. Nhiều tổ chức chọn cách tích hợp kế hoạch phân tích kinh doanh vào kế hoạch tổng thể của dự án.
- Một Business Analysis Plan tốt: enough guidance to ensure quality, good management practices, and enough flexibility to perform effectively.
b/ Others
The weighted shortest job first (WSJF) technique: Business value, time criticality, risk reduction or opportunity enablement, and effort.
Requirement architecture: describe how requirements, models, and other product information relate to each other.
DEEP (Product Backlog): Detailed, Estimated, Emergent, Prioritized.
Giảng viên Lâm Thu Nguyên