Differences

This shows you the differences between two versions of the page.

--- reference:system-architecture:sign-management-system [2025/08/25 09:22] – ↷ Page moved from system-architecture:sign-management-system to reference:system-architecture:sign-management-system runarbe
+++ reference:system-architecture:sign-management-system [2025/09/03 09:54] (current) – [Technical requirements] runarbe
@@ Line 7: / Line 7: @@
   * Data model development: The tool must support a comprehensive data model tailored for sign management, incorporating essential elements such as identifiers, QR code content, locations, materials, manufacturing, installation dates, warranty details, and cost/value.
   * Integration with addressing data model: The data model must reference the existing addressing data model, including street and address unit number identifiers to ensure consistency and accuracy.
-  * Sign CRUD operations: Capability to create, read, update, and delete various signs, including address unit number plates, sub address signs, cul de sac/crescent signs, and street name signs.
+  * Sign CRUD operations: Capability to create, read, update, and delete various signs, including address unit number plates, sub address signs, cul de sac/crescent signs, and street name signs. The integration should be based on use of the addressing API to ensure real-time availability of address unit numbers and streets
   * Task CRUD operations: The system must allow users to create, read, update, and delete tasks associated with signs, with functions to assign users, signs, and specify the type of task involved.
   * Log message management: Efficient logging functionality for creating, reading, updating, and deleting log messages related to tasks concerning aspects like damage reporting, maintenance needs, and inspection notes.
+  * Should also expose an API that makes it possible to read data from the various tables for use in third party BI and reporting solutions.
 ===== Functional requirements =====
@@ Line 16: / Line 18: @@
   * QR code integration: QR codes must be integrated for each sign, holding relevant content and linking back to the management system for fast data retrieval.
   * Location management: The system must indicate precise locations of signs within the hierarchy of national addressing data.
-  * Warranty and cost tracking: Users should track warranty periods, conditions, and cost/value associated with each sign, supporting financial and operational planning.
+  * Warranty and cost tracking: Users should track warranty periods, conditions, and cost/value associated with each sign, supporting financial and operational planning
+  * Incident registration and follow-up: It must be possible to register and follow up damages to signs including responsibility, cost recovery and follow-up.
   * User and task assignments: Flexibility in assigning users and tasks relevant to specific signs, ensuring proper accountability and task completion tracking.
   * Responsive log messaging: Automatic logging and alerting features for tasks, allowing for swift action on addressing damage reports, maintenance needs, and inspection findings.
+===== Provisional data model =====
+The following is a provisional data model for the sign management system
+{{  :wiki:reference:system:requirements:sign-management:signmanagementdatamodel_1.png?direct&800x429  }}
 ===== Status =====