32 lines
1.7 KiB
Markdown
32 lines
1.7 KiB
Markdown
# NFR Requirements Plan — Unit 03: Availability Module
|
|
|
|
Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de Availability Module (Unit 03).
|
|
|
|
## NFR Assessment Stappen
|
|
- [x] Vaststellen van de performance overhead van de Availability Middleware.
|
|
- [x] Definiëren van de betrouwbaarheidseisen voor de status check (bijv. caching).
|
|
- [x] Beveiligen van het onderhouds-bypass mechanisme.
|
|
- [x] Keuze van de opslag voor de dynamische status (Config vs Cache vs Database).
|
|
|
|
## NFR Vragen voor Unit 03
|
|
|
|
### 1. Performance
|
|
**Vraag 1.1**: Wat is de maximale toegestane latency die de Availability Middleware mag toevoegen aan elk request?
|
|
- A) **Ultra-laag**: < 1ms (vereist in-memory check zonder database/I/O).
|
|
- B) **Laag**: 1-5ms (staat een snelle cache of config check toe).
|
|
- C) **Gemiddeld**: < 10ms.
|
|
|
|
### 2. Status Opslag & Wijziging
|
|
**Vraag 2.1**: Hoe moet een beheerder de status van de API kunnen wijzigen in de MVP?
|
|
- A) **Static**: Alleen via `appsettings.json` (vereist herstart of config-reload).
|
|
- B) **Dynamic (In-Memory)**: Via een specifiek (beveiligd) endpoint dat de status in het geheugen aanpast (gaat verloren bij herstart).
|
|
- C) **Persistent**: Via de database, zodat de status over herstarts heen behouden blijft.
|
|
|
|
### 3. Caching
|
|
**Vraag 3.1**: Moet de resultaat van de beschikbaarheidscheck gecached worden in de middleware?
|
|
- A) Nee, altijd de actuele status ophalen via de service.
|
|
- B) Ja, voor een korte duur (bijv. 1 seconde) om performance te optimaliseren bij hoge belasting.
|
|
|
|
## Volgende Stappen
|
|
Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/availability-module/nfr-requirements/`.
|