67 lines
3.8 KiB
Markdown
67 lines
3.8 KiB
Markdown
## 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
|
|
|