Process Definition Matrices
The fourth and final (4 of 4) Part in Business Process Definition (BPD) looks to the requirements traceability matrix and process summary matrix which accompany the Process Definition Diagrams. Collectively, these are known as the BPD Matrices. Basically, these extract and summarize relevant data captured during BPD Diagram development to allow further analysis for a variety of purposes.
The first BPD Matrix summarizes requirements which relate to the Process Definition. Basically, Teams use the Process Requirements Matrix to capture requires extracted from the diagrams. Moreover, they also record requirements raised during workshop discussions, even if they do not appear in the diagrams. Ideally, Teams record requirements of any type, whether Business, Non-Functional, and Technical.
The second matrix summarizes the Process Definition itself.  In short, the Process Detailing Matrix extracts relevant information from the diagrams and reformats it into table, or matrix, form. As a result, stakeholders can view, sort, and organize the extracted data in a variety of ways, to better enable subsequent Analysis & Design.
After reviewing this page, look to the following for additional information.
Diagram Summaries - Process Definition Matrices
While Process Definition Diagrams are a terrific tool for designing and defining each Process, they are not well suited to analysis of the data captured. Accordingly, the BPD Matrices are complimentary artifacts designed to accompany the diagrams.
Teams compile a requirements traceability matrix and diagram content matrix in conjunction with the development of the corresponding diagrams.  Each matrix consolidates data from multiple diagrams into manageable and referenceable formats. Moreover, these consolidations also provide additional checks and balances to validate the diagrams' content.
Initially, the matrices provide valuable information with which to complete the related Solution Approaches to conclude Solution Definition. Thereafter, they support several activities in subsequent Solution Delivery, including Feature Planning and Story Analysis.
BPD Matrices
Compiling the Process Requirements Matrix begins at the outset of diagram production. Compiling the Process Detailing Matrix can begin as soon as the Level 1 and Level 2 Diagrams provide the initial Process design. Although, it is after production of the Level 3 Diagrams, and validation of diagrams at all levels when the Detailing Matrix provides the most value.
Process Requirements Matrix
The Process Requirements Matrix is a tool to capture mid-level, process-related requirements. To clarify, higher-level requirements result from the Solution Strategy & Architecture, to which the Process Definitions provide inputs. Conversely, lower-level requirements result from the Analysis & Design which occurs during Feature Planning and Story Analysis. In making each Feature and Story "Ready", Teams gather the Acceptance Criteria, a.k.a. "Requirements", applicable to each.
This matrix provides all the values necessary to function as a requirements traceability matrix. If following the ITM's structures, then traceability extends into any Business Perspective, Technology Perspective, and Delivery Perspective.
Process Detailing Matrix
The Process Detailing Matrix summarizes key content appearing in the diagrams. For instance, rows within the matrix list Actions, Entities, Inputs, Outputs, and other objects which appear across all pages. As a result, it becomes easy to identify and organize Business Segments, Application Functions, Integrations, Reports, Data Stores and other items relevant to subsequent Solution Definition and Solution Delivery. Indeed, this is an important milestone which allows initiatives to work with hard information, rather than relying upon assumptions and wishes.
Furthermore, their structure allows for combining Detailing matrices from multiple Processes. As a result, this offers stakeholders an ability to look beyond each, individual Process. Accordingly, these aggregates become very useful when determining the Solution to which each Process aligns within the Portfolio. Similarly, aggregates helps when setting the scope of each Solution Phase.
After Defining Business Processes
Teams complete Process Definition Matrices towards the end of Process Definition. Afterwards, defined processes play an important, ongoing role in Solution Definition and Solution Delivery.
Concluding Solution Definition
Validate the resulting Requirements and Detailing matrices in conjunction with the Process Diagram Validation. At that time, finalize each matrix for review by Sponsors and Executives, Epic Owners, Business / Process Owners, Teams and other relevant stakeholders. If a Process warrants a new Epic, then define the Epic to ensure a current, accurate Solution Vision.
Validated requirements move on to further activities, including Strategy & Architecture as well as Analysis & Design. Reviewers may choose to not validate, or specifically exclude, matrix content. When that occurs, add notes to the requirements traceability matrix to record their feedback along with the source who rejected the item. In other words, identify the relevant decision maker(s). In most cases, rejected requirements warrant no further analysis.
The Solution's Strategy & Architecture relies on relevant Process Definitions to define the various Solution Strategies, Solution Diagrams and Solution Approaches. During their creation or update, stakeholders make various decisions which may affect both the diagrams and matrices. If that happens, then Business Analysts may have to make corresponding changes where appropriate to reflect the decisions made.
Beginning Solution Delivery
Iterative Planning
During Inception, participants use the BPD Diagrams and BPD Matrices to finalize the Solution Approaches. Once complete, the Approaches set the scope for the next Solution Phase. For each in-scope Process Action, Teams use the Process Definition content to add Business-, Architecture- or Tech Debt-Features, as appropriate, to the Solution Backlog. At this point, the Features they add to the backlog lack requirements.
Additionally during Inception, Roadmap Planning produces the Epic to Feature List, an Initial Rollout Plan, and the Solution Roadmap. These actions clarify the objectives to achieve during the next Phase. Furthermore, they prioritize the backlog Features. Thereafter, working from highest to lowest priority, Teams next begin Analysis & Design. In short, their goal is to make prioritized Features "Ready" for delivery.
Iterative Implementation
To begin, Teams use BPD Diagram and BPD Matrix content to define and estimate Features during Feature Planning. Amongst other things, this involves identifying applicable requirements, or Acceptance Criteria. Accordingly, Teams transfer Solution-independent requirements from the BPD Matrix to Features. Furthermore, participants are likely to identify additional requirements during the meetings and workshops in which Feature Planning occurs.
Next, Teams take a first pass at determining how to implement each Feature by conducting Story Analysis. As with Features, Teams begin by using BPD content to identify and define each Story to make each "Ready" for development. In doing so, they move Solution-dependent requirements to corresponding Story's Acceptance Criteria. Again, participants are likely to identify additional requirements during the meeting and workshops in which Story Analysis occurs.
For both Features and Stories, Teams note the Delivery Level, whether Feature or Story, and add the WMS Key value to the matrix. This ties Feature and Story Acceptance Criteria back to the requirements in the matrix. In other words, adding the WMS Key completes the requirements traceability matrix.  This approach ensures that all requirements transfer properly into backlog items. Once the transition of all requirements into the backlog is complete, Teams may discontinue use of the Matrix. From this point on, Feature and Story Acceptance Criteria take precedence.
For additional resources, refer to the BPD Templates available for use.