1. Purpose and outcomes
Step 1 established the business problems and stakeholder priorities. Step 2 defines what the architecture initiative will address first, how success will be assessed, and which decisions remain subject to business approval.
Outcome 01
Prioritised requirements
Outcome 02
Bounded first release
Outcome 03
Testable success
2. Proposed scope boundaries
The scope below is a proposed first release based on the simulated discovery findings. It should be validated against source availability, business priorities, delivery effort, and stakeholder approval.
In scope · Proposed
Business and data design
- Prioritise Sales, Fulfilment, Inventory, and Finance requirements.
- Document source systems and source-to-target mapping assumptions.
- Define initial business entities, event relationships, and fact-table grains.
- Design conformed Customer, Product, and Location dimensions where validated.
- Draft a KPI catalogue with owner, definition status, and approval needs.
- Define data-quality, reconciliation, lineage, and semantic-layer requirements.
Out of scope · Initial release
Deferred or separately assessed
- Full enterprise rollout across every business domain and region.
- Production migration of all legacy systems.
- Formal redesign of finance or operational business processes.
- Unapproved accounting definitions or automatic reconciliation assumptions.
- Advanced predictive ML or autonomous AI decision-making.
- Full manufacturing, risk, and compliance modelling before discovery is complete.
Scope principle: Out of scope does not mean unimportant. Deferred domains remain visible in the roadmap and should be reconsidered when the first release has been validated.
3. Prioritised business requirements
These requirements are derived from the fictional discovery findings. Priority is provisional and uses MoSCoW-style categories. Requirements are not considered approved until the relevant business owner confirms the definition and acceptance criteria.
| ID | Requirement | Business value | Priority | Owner / approver |
|---|---|---|---|---|
| BR-01 | Establish a governed KPI catalogue with definitions, owners, status, and change approval. | Reduce ambiguity and improve trust in enterprise reporting. | Must | Enterprise governance; KPI owners |
| BR-02 | Define and distinguish Gross Revenue, Returned Revenue, Net Revenue, Gross Margin, and Gross Margin %. | Clarify financial and commercial reporting differences. | Must | Finance / CFO delegate |
| BR-03 | Model the order-to-fulfilment lifecycle across order lines, fulfilment allocations, shipments, and relevant delivery events. | Improve visibility of operational performance and exceptions. | Must | Sales and Supply Chain |
| BR-04 | Define appropriate fact grains and prevent measure duplication across one-to-many relationships. | Protect analytical accuracy and explainability. | Must | Data architecture; business validation |
| BR-05 | Define initial Customer, Product, and Location identity and conformance rules. | Enable cross-functional analysis across source systems. | Must | Business data owners; architecture |
| BR-06 | Document inventory movement, snapshot, status, and availability requirements. | Support inventory visibility at the correct time and location grain. | Should | Supply Chain / Warehouse |
| BR-07 | Define supplier delivery measures and the commitments used to assess performance. | Identify supplier reliability issues and dependencies. | Should | Procurement / Supply Chain |
| BR-08 | Document campaign attribution rules and distinguish attributed revenue from financial revenue. | Make campaign reporting interpretable and comparable. | Should | Marketing; Finance consulted |
| BR-09 | Define customer case metrics and a consistent root-cause taxonomy. | Support service performance and upstream issue analysis. | Should | Customer Service; process owners |
| BR-10 | Provide reusable governed semantic metrics for Power BI and future AI consumption. | Reduce duplicated business logic and improve consistent reuse. | Should | Business metric owners; data team |
| BR-11 | Define data-quality checks, lineage, and reconciliation expectations for priority data. | Expose gaps and improve traceability to source records. | Must | Data team; source owners |
| BR-12 | Complete discovery for manufacturing, risk, compliance, and remaining domains. | Ensure future enterprise coverage is not based on unvalidated assumptions. | Later | Relevant capability owners |
MUST = required for the proposed first release; SHOULD = valuable, subject to capacity and dependencies; LATER = deferred pending further discovery. These priorities are illustrative, not stakeholder-approved.
4. Proposed first-release focus
A practical initial slice connects sales transactions with fulfilment and the financial outcomes needed to explain business performance. Inventory context is included where source readiness permits.
Business slice
Sales → Fulfilment → Finance
Shared context
Customer · Product · Location
Measures
Governed metrics first
Demonstration
Synthetic data only
Release constraint: Do not commit to a final physical implementation until source availability, transaction relationships, KPI definitions, and acceptance criteria have been assessed.
5. Acceptance criteria
The first release should be considered ready for business validation when the following criteria can be demonstrated. These criteria are proposed and should be refined with the fictional business owners.
- Each priority requirement has an ID, business rationale, owner, priority, and validation method.
- Every published KPI has an approved definition or is explicitly labelled provisional.
- Fact tables have documented grain and their measures are not unintentionally duplicated by joins.
- Relationships between orders, fulfilment allocations, shipments, invoices, and returns are documented and tested against available source data.
- Customer, Product, and Location mapping rules are documented, including unmatched or ambiguous identities.
- Priority data-quality checks and reconciliation expectations are defined and results are visible.
- Business users can trace priority measures to documented definitions and underlying source records.
- The proposed first release and deferred scope have been reviewed and approved by relevant stakeholders.
- All example data used in the portfolio is synthetic or otherwise safe to publish.
6. Dependencies, risks, and decisions
Dependencies
- Access to representative source schemas or synthetic equivalents.
- Business owners available to validate definitions.
- Identifiers and timestamps to connect cross-system processes.
- Agreement on first-release priorities.
Key risks
- Conflicting definitions remain unresolved.
- Source data lacks required keys or event timestamps.
- One-to-many joins inflate metrics.
- Scope expands before the first release is validated.
Decisions still open
- Approved financial formulas and reporting boundaries.
- OTIF commitment date, completeness rule, and evaluation grain.
- Source-of-truth decisions for each entity and event.
- Exact initial deliverables based on source readiness.
Governance approach
- Business owners approve business meaning.
- Data architecture documents and implements the agreed design.
- Open decisions remain visible in a decision log.
- Changes are versioned and impact-assessed.
7. Requirement traceability
Requirements should connect the original discovery finding to the business process, data design, and eventual test. This keeps implementation decisions explainable.
| Discovery finding | Requirement | Design response | Validation |
|---|---|---|---|
| Finance and Sales report different revenue figures. | BR-01, BR-02, BR-11 | Governed KPI definitions, separate financial/commercial concepts, lineage. | Business sign-off and reconciliation against approved source logic. |
| Orders can be split across fulfilment and shipment records. | BR-03, BR-04 | Separate fact grains and explicit relationships across the lifecycle. | Test joins with multi-line orders and split shipments; verify measures do not multiply. |
| Inventory availability is difficult to interpret. | BR-05, BR-06 | Conformed Product/Location context and movement/snapshot models. | Validate status rules and compare sample balances to agreed source outputs. |
| Campaign revenue depends on attribution assumptions. | BR-08, BR-10 | Explicit attribution rules and separately named semantic measures. | Marketing approves methodology and sample results. |
| Customer cases can originate upstream. | BR-09 | Case model with root-cause categories and links to related transactions. | Review case classification and link coverage with Customer Service. |
8. Exit criteria and transition to Step 3
Step 2 establishes a proposed scope and requirement baseline. It does not imply that every business definition or source dependency is already approved.
Step 2 deliverables
- Prioritised requirements register
- Initial in-scope / out-of-scope boundaries
- Proposed first-release focus
- Acceptance criteria and traceability
- Dependencies, risks, and open decisions
Move to Step 3
Use the agreed scope to refine the enterprise capability map, process catalogue, event catalogue, enterprise entities, and KPI relationships. Validate any unconfirmed areas before treating the architecture as final.
Portfolio status: This page documents a proposed scope and requirements baseline for a fictional case study. Priorities, acceptance criteria, and ownership are illustrative until explicitly validated within the case-study narrative.