ngx-admin

Feature Inventory

Document Date: April 2026

1. Overview

Scope

This Feature Inventory catalogs every distinct feature observable from the screen documentation provided for the ngx-admin web application. Features are extracted exclusively from implemented behavior as described in the source documentation for three screens: the Charts shell (/charts), the Chart.js screen (/charts/chartjs), and the D3 screen (/charts/d3). Features that exist on undocumented screens (e.g., /charts/echarts or any screen outside the /charts route hierarchy), planned or unreleased features, and backend-only behaviors not visible in any documented screen are explicitly excluded from this inventory.

Methodology

Features were extracted by systematically scanning each section of the screen documentation — UI layout, user interactions, navigation, routing, error handling, real-time behavior, integration points, security, and accessibility — for distinct, independently valuable capabilities. Each feature is classified using BABOK v3.0 requirements categories (Functional, Non-Functional, Constraint), prioritized using MoSCoW notation where determinable, and assessed for complexity based on the number of UI components, API interactions, and error-handling paths involved. Quality dimensions are assigned per ISO/IEC 25010:2023.

Feature Granularity

A feature is defined as a distinct capability that delivers value to a user role, is independently testable, and can be described in one sentence without using "and" to join unrelated capabilities. Because the three documented screens are all thin shell or presentational components with no business logic, state management, or API calls, the resulting feature set is small. Several features that would normally be cataloged at the child-component level (e.g., individual chart type rendering, data filtering, export) cannot be documented because the child component source files and templates were not provided.

Coverage

This Feature Inventory covers 3 screen(s) of the ngx-admin application:

Features derived from screens not included in the assessed documentation are outside the scope of this document. This document reflects a partial view of the application. The /charts route hierarchy references additional child routes (e.g., /charts/echarts) that are not documented here.

Disclosure

Generated by DocAgent — automated codebase documentation analysis. Subject matter expert review is recommended before distribution.

How to Use This Document

• Feature Inventory Table (Section 2): Use for quick lookup, filtering by role, screen, type, or priority. Suitable for import into a spreadsheet or backlog tool.
• Feature Detail Cards (Section 3): Use for full specifications, acceptance criteria, and technical component details for a specific feature.
• Feature-Screen Matrix (Section 4): Use to identify which features appear on which screens — useful for migration and impact analysis.
• Feature-Role Matrix (Section 5): Use to audit role-based access coverage across features.
• Feature Dependencies (Section 6): Use to assess change impact and sequencing.
• Coverage Gap Analysis (Section 7): Use to identify documentation gaps, missing requirements, and risks before roadmap planning.

2. Feature Inventory Table

3. Feature Detail Cards

FEAT-001: Host Child Chart Routes

Category: Navigation > Routing Structure Screen(s): Charts (/charts) User Role(s): All Authenticated Users Type: Functional Status: Active Priority: Must Complexity: Simple

Description: The Charts screen acts as a structural shell that hosts Angular's <router-outlet> directive, enabling the application to dynamically render child chart screens (such as /charts/chartjs and /charts/d3) within the same layout context. Without this shell, child chart routes cannot be rendered. This is a foundational routing feature that enables the entire charts section of the application.

User Interaction: The user does not interact with this feature directly. When a user navigates to any URL beneath /charts, Angular's router matches the child route and inserts the corresponding component into the outlet automatically. The user perceives this as arriving at a chart page; the shell is invisible.

Acceptance Criteria:

• AC-1: Given the user navigates to /charts/chartjs, the Chart.js child component is rendered in the outlet without a full page reload.
• AC-2: Given the user navigates to /charts/d3, the D3 child component is rendered in the outlet without a full page reload.
• AC-3: Given the user navigates to an unrecognized path beneath /charts, the router handles the unmatched route gracefully (e.g., redirects to a 404 page or a default child route).

Technical Components:

• UI: <router-outlet> directive in ChartsComponent template
• API: None
• Data: None

Error Handling: No error handling is implemented at this component level. Unmatched child routes are handled by Angular's router wildcard configuration, which is defined in the routing module (not documented here).

Quality Dimensions (ISO 25010):

• Functional Suitability — provides the correct routing structure for child chart views
• Reliability — Angular's router is a stable, framework-managed mechanism

Known Limitations: The ChartsComponent does not specify ChangeDetectionStrategy.OnPush, which is a minor best-practice deviation for a stateless shell component. The component uses NgModule-based architecture rather than Angular's standalone component pattern, which may represent a future migration opportunity.

Source Evidence: Charts (/charts)

Related Features: FEAT-002, FEAT-003, FEAT-004

FEAT-002: Navigate to Chart Sub-Pages

Category: Navigation > Client-Side Routing Screen(s): Charts (/charts) User Role(s): All Authenticated Users Type: Functional Status: Active Priority: Must Complexity: Simple

Description: Users can move between the different chart sub-pages within the /charts section of the application by using the application's global navigation menu or sidebar. Angular's router handles the URL change and renders the appropriate child component into the <router-outlet> of the Charts shell without a full browser page reload.

User Interaction: The user clicks a navigation link (e.g., in the application sidebar or top menu) that targets a chart sub-page URL such as /charts/chartjs or /charts/d3. Angular intercepts the navigation event, matches the route, and renders the corresponding child component. The user sees the new chart page appear in the content area.

Acceptance Criteria:

• AC-1: Given the user is on any page in the application, when they click a navigation link to /charts/chartjs, the Chart.js visualization page loads without a full browser reload.
• AC-2: Given the user is on any page in the application, when they click a navigation link to /charts/d3, the D3 visualization page loads without a full browser reload.
• AC-3: Given the user navigates directly to /charts with no child segment, the router either renders a default child route or handles the empty path gracefully.

[Not documented — WHO: Engineering lead; WHAT: Is there a default redirect configured for the bare /charts route (e.g., redirect to /charts/chartjs)? WHERE: Insert in AC-3 of FEAT-002 and in FGAP-01]

Technical Components:

• UI: Application sidebar/navigation menu (defined outside documented screens), Angular router
• API: None
• Data: None

Error Handling: No error handling is implemented within the ChartsComponent. Navigation failures (e.g., route guard rejection) are handled by the router guard configuration in the routing module.

Quality Dimensions (ISO 25010):

• Functional Suitability — routes users to the correct chart screen
• Usability — client-side navigation provides a fast, seamless transition between chart views

Known Limitations: The navigation menu that triggers this feature is defined outside the documented screens and cannot be fully specified here. The full child route configuration (including any lazy-loading setup) is in charts-routing.module.ts, which was not provided.

Source Evidence: Charts (/charts)

Related Features: FEAT-001, FEAT-003, FEAT-004

FEAT-003: Display Chart.js Visualizations

Category: Data Visualization > Chart Rendering Screen(s): Chartjs (/charts/chartjs) User Role(s): All Authenticated Users Type: Functional Status: Partial Priority: Should Complexity: Medium

Description: The Chart.js screen presents users with one or more Chart.js-based chart visualizations arranged in a card-based layout. Users can view these charts to understand the data being represented. The screen serves as either a data visualization dashboard or a demonstration of available Chart.js chart types integrated into the application.

User Interaction: The user navigates to /charts/chartjs via the application's navigation. The screen renders automatically upon arrival, displaying chart visualizations without requiring any user input. The user views the charts in a read-only capacity.

Acceptance Criteria:

• AC-1: Given the user navigates to /charts/chartjs, one or more Chart.js charts are rendered visibly on the screen without user interaction.
• AC-2: Given the screen has loaded, each chart is displayed within a labeled card component consistent with the application's Nebular UI framework styling.
• AC-3: Given the screen has loaded, chart data is presented accurately as defined in the template or child component data definitions.

(Acceptance criteria are partially inferred from technology conventions — verify against the chartjs.component.html template and child chart component definitions.)

[Not documented — WHO: Product owner; WHAT: What specific chart types (bar, line, pie, doughnut, radar, etc.) are required to be displayed on this screen?; WHERE: Insert in AC-2 of FEAT-003 and in the Description field]

[Not documented — WHO: Product owner; WHAT: Is this screen a static demo/showcase or does it display live/dynamic application data?; WHERE: Insert in the Description field of FEAT-003 and in FGAP-06]

Technical Components:

• UI: ChartjsComponent (ngx-chartjs selector), nb-card layout components (inferred from Nebular UI framework — verify against chartjs.component.html), Chart.js <canvas> elements
• API: None (no API calls documented)
• Data: Static chart data (inferred from component being stateless — verify against chartjs.component.html for hardcoded datasets)

Error Handling: No error handling is implemented in ChartjsComponent. If Chart.js fails to render (e.g., invalid data or missing canvas context), the error surfaces as an unhandled JavaScript runtime error in the browser console.

Quality Dimensions (ISO 25010):

• Functional Suitability — renders the correct chart types with the correct data
• Usability — card-based layout provides clear visual organization of chart content
• Accessibility — canvas-based charts are inherently inaccessible without explicit ARIA attributes (see FGAP-03)

Known Limitations: All chart configuration and data is (inferred from the stateless component pattern — verify against chartjs.component.html) hardcoded in the HTML template, making it difficult to maintain, test, or make data-driven. No error state, loading state, or empty state is handled by the component. Accessibility for <canvas> elements is not documented and represents a known gap.

Source Evidence: Chartjs (/charts/chartjs)

Related Features: FEAT-001, FEAT-006

FEAT-004: Display D3 Visualizations

Category: Data Visualization > Chart Rendering Screen(s): D3 (/charts/d3) User Role(s): All Authenticated Users Type: Functional Status: Partial Priority: Should Complexity: Medium

Description: The D3 screen presents users with one or more D3.js-based data visualizations, such as SVG charts, force-directed graphs, or tree diagrams. Users can view these visualizations within the application's standard page layout. The screen acts as a host for D3-powered child components that perform the actual rendering.

User Interaction: The user navigates to /charts/d3 via the application's navigation. The screen renders automatically upon arrival, displaying D3 visualizations without requiring any user input at the parent component level. The user views the visualizations in a read-only capacity (any interactive D3 behaviors such as zoom or pan are handled within child components).

Acceptance Criteria:

• AC-1: Given the user navigates to /charts/d3, one or more D3.js visualizations are rendered visibly on the screen without user interaction.
• AC-2: Given the screen has loaded, the visualizations are displayed within the application's standard page layout.
• AC-3: Given the screen has loaded, SVG-based chart elements are rendered correctly in the browser.

(Acceptance criteria are partially inferred from technology conventions — verify against the d3.component.html template and child D3 component definitions.)

[Not documented — WHO: Product owner; WHAT: What specific D3 visualization types (force-directed graph, bar chart, tree diagram, etc.) are required on this screen?; WHERE: Insert in AC-1 of FEAT-004 and in the Description field]

[Not documented — WHO: Engineering lead; WHAT: Is the d3.component.html template substantive or a placeholder stub? The component class is entirely empty.; WHERE: Insert in the Status field of FEAT-004 and in FGAP-01]

Technical Components:

• UI: D3Component (ngx-d3 selector), child D3 chart components (declared at module level, not in component class), SVG elements rendered by D3.js
• API: None (no API calls documented)
• Data: Static or child-component-managed data (inferred from the empty parent component class — verify against d3.component.html and child component source files)

Error Handling: No error handling is implemented in D3Component. Rendering failures within D3 child components would surface as unhandled JavaScript errors in the browser console.

Quality Dimensions (ISO 25010):

• Functional Suitability — renders the correct D3 visualizations
• Usability — standard page layout provides consistent visual context
• Accessibility — SVG-based D3 charts require explicit ARIA attributes for screen reader support (see FGAP-03)
• Security — D3's .html() and .append() methods in child components carry XSS risk if user-supplied data is rendered as raw HTML (applies to child components, not this shell)

Known Limitations: The D3Component class body is entirely empty, which may indicate this component is a stub or placeholder that was never fully implemented. The template file (d3.component.html) was not provided, so the actual rendered content cannot be confirmed. Accessibility for SVG elements is not documented. The ChangeDetectionStrategy.OnPush is not set, which is a minor best-practice deviation.

Source Evidence: D3 (/charts/d3)

Related Features: FEAT-001

FEAT-005: Enforce Route-Level Access Control

Category: Security > Authentication & Authorization Screen(s): Charts (/charts), Chartjs (/charts/chartjs), D3 (/charts/d3) User Role(s): All Authenticated Users Type: Non-Functional Status: Partial Priority: Must Complexity: Medium

Description: Access to the /charts route hierarchy is expected to be restricted to authorized users via Angular route guards (e.g., CanActivate). Unauthorized users attempting to access any chart screen are expected to be redirected to a login page or an access-denied page before the chart component is instantiated.

User Interaction: This feature is transparent to authorized users — they navigate to chart screens without interruption. Unauthorized users are redirected away from the chart screens automatically by the router guard before any chart content is displayed.

Acceptance Criteria:

• AC-1: Given an unauthenticated user attempts to navigate to /charts, /charts/chartjs, or /charts/d3, they are redirected to the application's login page.
• AC-2: Given an authenticated user with appropriate permissions navigates to any chart screen, they are not redirected and the chart content loads normally.
• AC-3: Given an authenticated user without chart-viewing permissions attempts to navigate to a chart screen, they are redirected to an access-denied page.

(AC-3 is inferred from common Angular route guard patterns — verify against the routing module and AuthGuard/RoleGuard implementation to confirm whether role-based restrictions beyond authentication are enforced.)

[Not documented — WHO: Engineering lead; WHAT: Which specific route guard(s) (e.g., AuthGuard, RoleGuard) are applied to the /charts route and its children? Is the guard applied at the parent /charts level or individually on each child route?; WHERE: Insert in the Technical Components section of FEAT-005]

[Not documented — WHO: Product owner; WHAT: Are there role-based restrictions on chart access (e.g., only admins or analysts can view charts), or is access granted to all authenticated users?; WHERE: Insert in the User Role(s) field of FEAT-005 and in the Feature-Role Matrix]

Technical Components:

• UI: None (guard operates at router level before component instantiation)
• API: (inferred from standard Angular auth guard patterns — verify against AuthGuard implementation) Authentication token validation endpoint
• Data: User session / authentication state

Error Handling: Unauthorized access is handled by the route guard, which redirects the user rather than displaying an error within the chart component. The specific redirect target (login page, 403 page) is defined in the routing module.

Quality Dimensions (ISO 25010):

• Security — prevents unauthorized access to chart data and screens
• Reliability — route guard enforcement is consistent across all chart sub-routes

Known Limitations: The route guard implementation is not included in the provided source documentation. It cannot be confirmed whether a guard is actually applied, which guard class is used, or whether role-based (as opposed to authentication-only) restrictions are enforced. This feature is marked Partial because the guard's existence is referenced in the documentation but its implementation is unverified.

Source Evidence: Charts (/charts), Chartjs (/charts/chartjs), D3 (/charts/d3)

Related Features: FEAT-001, FEAT-002

FEAT-006: Chart.js Native Chart Interactivity

Category: Data Visualization > User Interaction Screen(s): Chartjs (/charts/chartjs) User Role(s): All Authenticated Users Type: Functional Status: Partial Priority: Could Complexity: Simple

Description: Users can interact with Chart.js charts on the /charts/chartjs screen using Chart.js's built-in interaction behaviors, including hover tooltips that display data point values and legend item toggling to show or hide individual datasets. These interactions are provided natively by the Chart.js library and require no custom event handling by the application.

User Interaction: The user hovers over a data point or bar on a chart to see a tooltip displaying the value. The user clicks a legend item to toggle the visibility of the corresponding dataset on the chart. No form submission or application-level event handling is involved.

Acceptance Criteria:

• AC-1: Given a Chart.js chart is rendered, when the user hovers over a data point, a tooltip displaying the data value is shown.
• AC-2: Given a Chart.js chart with a legend is rendered, when the user clicks a legend item, the corresponding dataset is toggled visible or hidden on the chart.

(Acceptance criteria are inferred from Chart.js default behavior — verify against the chart configuration options defined in chartjs.component.html or child chart components to confirm tooltips and legend toggling are not disabled.)

Technical Components:

• UI: Chart.js <canvas> elements, Chart.js built-in tooltip and legend plugins
• API: None
• Data: In-memory chart dataset objects managed by Chart.js

Error Handling: No application-level error handling. Chart.js manages its own internal interaction state. If a chart fails to render, interactions are unavailable and no error message is displayed to the user.

Quality Dimensions (ISO 25010):

• Usability — tooltips and legend toggling improve data readability without requiring additional UI controls
• Accessibility — Chart.js tooltip and legend interactions are not keyboard-accessible by default; screen reader support is absent for canvas-based content

Known Limitations: Interactivity is entirely dependent on Chart.js library defaults. The application does not implement custom keyboard navigation, screen reader announcements, or ARIA live regions for tooltip content. The specific Chart.js configuration (which may enable or disable certain interactions) is defined in the template file, which was not provided.

Source Evidence: Chartjs (/charts/chartjs)

Related Features: FEAT-003

4. Feature-Screen Matrix

5. Feature-Role Matrix

[Not documented — WHO: Product owner; WHAT: What named user roles exist in the application (e.g., Admin, Analyst, Viewer, Guest)? The source documentation does not define specific roles for the charts section.; WHERE: Replace "All Authenticated Users" throughout this matrix with the specific role names once confirmed]

Note on FEAT-005: "Conditional" indicates that authenticated users with appropriate permissions are granted access, while those without are redirected. The specific conditions are not documented in the source — verify against the route guard implementation.

6. Feature Dependencies

7. Coverage Gap Analysis

FGAP-01: Undocumented Child Chart Screens

Type: Undocumented Screen Affected Feature(s): FEAT-001, FEAT-002 Risk Level: High

Description: The source documentation for the Charts shell (/charts) explicitly references child routes beneath /charts (e.g., /charts/echarts, /charts/chartjs, /charts/d3). Only two child screens (/charts/chartjs and /charts/d3) are included in the provided documentation. Additional child screens — most notably /charts/echarts — are referenced by name in the documentation but not documented. The full child route configuration in charts-routing.module.ts was not provided, so the complete list of child routes is unknown. Additionally, the D3Component class is entirely empty, raising the possibility that /charts/d3 is itself a stub or placeholder screen.

Recommendation: Obtain and document the charts-routing.module.ts file to enumerate all registered child routes. Document each child screen (especially /charts/echarts) using the same screen documentation format. Verify with the engineering lead whether d3.component.html contains substantive content or is a placeholder.

FGAP-02: Missing ECharts Screen Documentation

Type: Undocumented Screen Affected Feature(s): FEAT-001, FEAT-002 Risk Level: High

Description: The ECharts screen (likely at /charts/echarts) is referenced by name in the Charts shell documentation as an example child route but is not included in the provided screen documentation. ECharts (Apache ECharts) is a major charting library, and a dedicated screen for it would likely contain a significant number of features comparable to or exceeding those on the Chart.js screen. Its absence means this inventory is materially incomplete with respect to the charts section.

Recommendation: Request screen documentation for /charts/echarts (and any other undocumented chart library screens) from the engineering team. Add corresponding features to this inventory once documentation is available.

FGAP-03: Accessibility — Canvas and SVG Chart Elements

Type: Accessibility Affected Feature(s): FEAT-003, FEAT-004, FEAT-006 Risk Level: High

Description: Chart.js renders charts onto HTML <canvas> elements, which are inherently inaccessible to screen readers because canvas content is not part of the browser's accessibility tree. D3.js renders charts as SVG elements, which can be made accessible but require explicit role, aria-label, and tabindex attributes applied through D3's imperative DOM manipulation. Neither the ChartjsComponent nor the D3Component documentation describes any accessibility implementation. The template files — where ARIA attributes would be applied — were not provided. This represents a potential WCAG 2.1 AA compliance gap across all chart screens.

Recommendation: Review chartjs.component.html and d3.component.html (and all child chart component templates) for the presence of role="img", aria-label, fallback text within <canvas> tags, and keyboard navigation support. If absent, implement WCAG 2.1 AA-compliant accessibility patterns for all chart elements. Conduct an accessibility audit with assistive technology (e.g., NVDA, VoiceOver) before release.

FGAP-04: Missing Error States for Chart Rendering Failures

Type: Error State Affected Feature(s): FEAT-003, FEAT-004, FEAT-006 Risk Level: Medium

Description: Neither the ChartjsComponent nor the D3Component implements any error handling for chart rendering failures. If Chart.js fails to render (e.g., due to an invalid dataset, a missing canvas context, or a library load failure), or if a D3 visualization fails (e.g., due to malformed SVG data or a D3 computation error), the failure surfaces only as an unhandled JavaScript runtime error in the browser console. No user-facing error message, fallback content, or retry mechanism is documented for any chart screen.

Recommendation: Define and implement user-facing error states for chart rendering failures on both the Chart.js and D3 screens. At minimum, display a visible error message within the chart card when a chart fails to render. Consider implementing Angular's ErrorHandler or a try/catch wrapper in child chart components.

FGAP-05: No Documented User Roles or Access Control Policy

Type: Missing NFR Affected Feature(s): FEAT-005 Risk Level: Critical

Description: The source documentation for all three screens acknowledges that route guards are expected to enforce access control but explicitly states that the routing module (where guards are configured) was not provided. As a result, it cannot be confirmed whether any route guard is actually applied to the /charts route hierarchy, which guard class is used, what authentication mechanism it relies on, or whether role-based restrictions (beyond simple authentication) are enforced. The user roles for the application are entirely undocumented in the provided source.

Recommendation: Provide the charts-routing.module.ts and app-routing.module.ts files for review. Document the specific CanActivate guard(s) applied to the /charts route, the authentication mechanism used, and any role-based access rules. Update the Feature-Role Matrix in this document once roles are confirmed.

FGAP-06: Chart Data Source and CRUD Coverage

Type: Missing CRUD Affected Feature(s): FEAT-003, FEAT-004 Risk Level: Medium

Description: Both the Chart.js and D3 screens are documented as stateless presentational components with no API calls and no data-fetching logic. It is unclear whether the chart data displayed is: (a) entirely static/hardcoded in the HTML templates (a demo/showcase), (b) sourced from child components that fetch data from an API, or (c) intended to be connected to live application data in a future iteration. If the charts are intended to visualize real application data, the Read operation is the only CRUD operation present, and Create, Update, and Delete operations on the underlying data entities are entirely absent from the documented screens.

Recommendation: Clarify with the product owner whether the chart screens display static demo data or live application data. If live data is intended, document the data entities, API endpoints, and any planned data management features (filtering, date range selection, export) for inclusion in this inventory.

FGAP-07: Missing Non-Functional Requirements — Performance and Export

Type: Missing NFR Affected Feature(s): FEAT-003, FEAT-004 Risk Level: Low

Description: No non-functional requirements related to chart rendering performance (e.g., maximum acceptable render time for large datasets), data export (e.g., exporting chart images as PNG or data as CSV), or print support are documented for any chart screen. For a data visualization section of an application, these are commonly expected capabilities that are absent from the current documentation.

Recommendation: Confirm with the product owner whether chart image export, data export (CSV/XLSX), and performance benchmarks are in scope for the charts section. If so, add corresponding features to this inventory and define acceptance criteria.

8. Glossary

Feature Terms

Domain Terms

Roles