Differences

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

--- reference:system-architecture:sign-management-system [2025/09/03 09:52] – [Functional requirements] 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 =====