3.8 KiB
Purpose
Define stable requirements for frontend-compute-shift.
Requirements
Requirement: Display-Layer Computation SHALL be Shifted to Frontend Safely
The system SHALL move eligible display-layer computations from backend to frontend while preserving existing business behavior.
Scenario: Equivalent metric output
- WHEN frontend-computed metrics are produced for a supported page
- THEN output values MUST match baseline backend results within defined rounding rules
Requirement: Compute Shift MUST be Verifiable by Parity Fixtures
Each migrated computation MUST have parity fixtures comparing baseline and migrated outputs.
Scenario: Parity test gating
- WHEN a compute-shifted module is changed
- THEN parity checks MUST run and fail the migration gate if output differs beyond tolerance
Requirement: Compute-Shifted Logic SHALL Be Exposed as Reusable Frontend Core Modules
Frontend-computed metrics and transformations MUST be implemented as reusable, testable modules instead of page-local inline logic.
Scenario: Multiple pages consume shared compute logic
- WHEN two or more pages require the same metric transformation or aggregation
- THEN they MUST import a shared frontend core module and produce consistent outputs
Requirement: Frontend Compute Parity MUST Include Tolerance Contracts Per Metric
Parity verification SHALL define explicit tolerance and rounding contracts per migrated metric.
Scenario: Parity check for migrated metric
- WHEN migrated frontend computation is validated against baseline output
- THEN parity tests MUST evaluate the metric against its declared tolerance and fail when outside bounds
Requirement: Compute Shift MUST Preserve Existing User-Facing Logic
Frontend compute migration MUST preserve existing filter semantics, drill-down behavior, and displayed totals.
Scenario: Existing dashboard interactions after compute shift
- WHEN users apply filters and navigate drill-down flows on migrated pages
- THEN interaction results MUST remain behaviorally equivalent to the pre-shift baseline
Requirement: Frontend Compute Paths MUST Handle Zero and Boundary Values Correctly
Frontend-computed report metrics SHALL preserve valid zero values and boundary conditions in user-visible KPI and summary components.
Scenario: Zero-value KPI rendering
- WHEN OU% or availability metrics are computed as
0 - THEN the page MUST render
0%(or configured numeric format) instead of placeholder values
Requirement: Hierarchical Filter Compute Logic SHALL Be Deterministic Across Levels
Frontend matrix/filter computations SHALL produce deterministic selection and filtering outcomes for group, family, and resource levels.
Scenario: Matrix selection at multiple hierarchy levels
- WHEN users toggle matrix cells across group, family, and resource rows
- THEN selected-state rendering and filtered equipment result sets MUST remain level-correct and reversible
Requirement: Reusable Browser Compute Modules SHALL Power Report Derivations
Derived computations for report filters, KPI cards, chart series, and table projections SHALL be implemented through reusable frontend modules.
Scenario: Shared report derivation logic
- WHEN multiple report pages require equivalent data-shaping behavior
- THEN pages MUST consume shared compute modules instead of duplicating transformation logic per page
Requirement: Browser Compute Shift SHALL Preserve Export and Field Contracts
Moving computations to frontend MUST preserve existing field naming and export column contracts.
Scenario: User exports report after frontend-side derivation
- WHEN transformed data is rendered and exported
- THEN exported field names and ordering MUST remain consistent with governed field contract definitions