25 lines
3.2 KiB
Markdown
25 lines
3.2 KiB
Markdown
# 2. Requirements
|
|
|
|
## Functional
|
|
|
|
1. **FR1: System Initialization:** The system must provide an interface for the first user ("Initiator") to create the "Община" and generate their initial cryptographic key pair.
|
|
2. **FR2: Citizen Onboarding:** The Initiator must be able to generate a unique, single-use invitation link to onboard new "Citizens". The onboarding process must include key pair generation and profile creation in the "Registry".
|
|
3. **FR3: Optional Key Vault:** During onboarding, a new "Citizen" must have the option to create a login/password account to store their private key in the server-side "Vault".
|
|
4. **FR4: Immutable Ledger:** Every state-changing action within the system (e.g., creating a Cell, joining, confirming payment) must be recorded as a new, cryptographically signed transaction in "The Main Ledger". The system must not allow direct modification or deletion of past transactions.
|
|
5. **FR5: Cell Creation:** Any "Citizen" must be able to create a financial "Cell" for a "Common Good", specifying the goal and the required items/costs ("Executor" roles).
|
|
6. **FR6: Cell Participation:** "Citizens" must be able to join a "Cell" as either an "Executor" (committing to purchase an item) or a "Consumer" (sharing the cost of the "Common Good").
|
|
7. **FR7: Real-Time Calculation:** The system must automatically and transparently calculate and display the financial obligations between all "Consumers" and "Executors" of a "Cell" as participants join or leave.
|
|
8. **FR8: Payment Confirmation:** An "Executor" must have the ability to sign a transaction confirming the receipt of payment from a specific "Consumer" for a specific "Cell".
|
|
9. **FR9: Social Key Recovery:** A "Citizen" who uses the "Vault" and has forgotten their password must be able to initiate a recovery process that requires cryptographic confirmation from a quorum of other "Citizens" (1 confirmation if <=4 members; 2 confirmations if >=5 members).
|
|
|
|
## Non-Functional
|
|
|
|
1. **NFR1: Performance on Embedded Hardware:** The entire system (backend and database) must be optimized to run efficiently on a Raspberry Pi (Model 4 or newer recommended).
|
|
2. **NFR2: High-Trust Environment Security:** While designed for a trusted, private network, the application must include baseline web security practices (e.g., CSRF protection, secure headers). Direct database access should not be exposed.
|
|
3. **NFR3: Cryptographic Integrity:** All transactions must be signed using the Ed25519 algorithm or a similarly secure and lightweight standard. The integrity of the ledger's chain (verified by linking transaction hashes) must be maintained.
|
|
4. **NFR4: Multi-Currency Support:** The system must be able to handle calculations and record transactions in multiple fiat currencies (e.g., UAH, PLN, USD), with the currency specified at the "Cell" or "Plan" level.
|
|
5. **NFR5: Internationalization (i18n) Readiness:** The frontend architecture must be built to support multiple languages, even if the MVP only includes one language pack.
|
|
6. **NFR6: Usability:** The user interface for common, simple actions (like creating a quick "Cell") must be low-friction and require a minimal number of steps to encourage daily use.
|
|
|
|
---
|