Business Process Analysis contribution to the Requirements Definition Document

Business Process Analysis (BPA) guides the organization and stimulates the content of the functional requirements portion of the Requirements Definition Document (RDD). A separate post will describe how the "to be" process model serves as the shared reference throughout the project life cycle for business, technical, and management participants to address status, issues, and the impact of proposed changes -- and to actually understand what the proposed system is doing and how it impacts the enterprise, business partners, organizational units, and staff.

The RDD should have six major artifacts:
AS IS Business Process Model
TO BE BPA (at least an early version of it that will be revised following the technical architecture decisions that may impact the process)
Functional Requirements
Technical Requirements
Business Interactioon Model
Business Use Cases
Subject Data Model
Policies
Alignment of the Project proposal to the Enterprise Business/Operational Architecture and Enterprise Technical Architecture.

The Business Process Model triangulates with the Functional Requirements and Business Use Cases.

Triangulation means that each artifact is interdependent with at least two other artifacts. Therefore all three artifacts must be compared against one another to ensure consistency. This assessment will invariably identify gaps and inconsistencies to resolve. This triangulation will ensure that each artifact has greater value in future phases.

the purpose of any artifact is at least two fold:
Verify a shared understanding of the work that has been done to date;
provide the guidance for the work that lies ahead.

All artifacts are work products. An artifact may be a deliverable but that is not essential. Deliverables have a more formal review process and may be associated with "go-no go" decisions. too often, too much formality goes in to the presentation and precision of deliverables.

Deliverables should be measured by do they provide sufficient affirmation of understanding and sufficient guidance. Subsequent phases will identify issues and information that can enhance a previously approved deliverable.

Most work products (and deliverables) have sufficient substance and guidance when sixty percent complete to enable the next phase to begin. work on the next phase enables identification of issues and information to include in the work in progress work products. Approval may occur when the next phase is already 30-50 percent completed.

This overlap enables the next phase to serve as a "scouting party" to ensure the work products provide the needed guidance, to avoid putting too much into a work product when the extra resources can contribute to the next steps. Formal approvals have greater certainty when already "field tested" by the guidance the work product has given the next phases scouting party.

Summary:
The Requirements Definition Document has multiple artifacts, not just a list of functional and technical requirements. The Atlantic Systems Group got RDDs pointed in the right direciton but did not take requirements far enough.

Each artifact is compared against at least two other artifacts in a process called triangulation.

The purpose of artifacts is to verify a shared understanding on the project and to provide guidance for the next phase.

Artifacts are work products and may be deliverables. Even deliverables need not be more than sixty percent complete b efore providinng sufficient understanding and guidance for the next phase to begin. The next phase may be up to fifty percent complete before the prior phase's formal deliverables are approved.

All work products (including deliverables) will need modification based on findings and issues revealed in subsequent phases.