Caiet de Sarcini — <Nume Building Block> (PaaS / GovStack BB)
Acest conținut nu este încă disponibil în limba selectată.
Template tender-grade pentru Building Block-uri PaaS (componente de infrastructură reutilizabile: audit, notificări, semnătură, storage etc.), nu pentru aplicații de business. Spre deosebire de
template.md(business-only), aici produsul ESTE tehnic, deci secțiunile tehnice se scriu, nu doar se moștenesc — dar tot ce e transversal-standard (NFR, securitate de bază, deployment, observabilitate) se referențiază din anexa tehnică comună (skillparti-comune) și Standardul API (skillstandard-api), parametrizând doar specificul BB-ului.Document destinat licitației: trebuie să fie complet, neambiguu, cu criterii de acceptanță testabile, livrabile, mentenanță/SLA și trasabilitate. Limba: română; identificatori tehnici în engleză.
| Câmp | Valoare |
|---|---|
| Document | Caiet de Sarcini (PaaS Building Block) |
| Building Block | |
| Versiune | 0.1 (draft) |
| Autor | Esempla Systems |
| Data | |
| Status | Draft / În review / Aprobat |
| Anexă tehnică moștenită | Anexa Tehnică Comună Esempla/GovStack v1.0 |
| Standard API | skill standard-api |
| Catalog cerințe universale | skill cerinte-universale (CU-*) |
1. Introducere
Section titled “1. Introducere”1.1 Descriere generală
Section titled “1.1 Descriere generală”Ce este BB-ul, ce capabilitate oferă ecosistemului, cui se adresează (sisteme consumatoare).
1.2 Obiectivele sistemului
Section titled “1.2 Obiectivele sistemului”Obiective măsurabile (ex. „1 BB pentru N sisteme”, latență ingest p95, conformitate logging).
1.3 Părțile implicate (stakeholders)
Section titled “1.3 Părțile implicate (stakeholders)”Posesor / Deținător / Administrator tehnic / Operatori platformă / Sisteme consumatoare / Auditori.
1.4 Obiectivele și sumarul documentului
Section titled “1.4 Obiectivele și sumarul documentului”1.5 Abrevieri
Section titled “1.5 Abrevieri”1.6 Termeni
Section titled “1.6 Termeni”2. Context & motivație
Section titled “2. Context & motivație”- Starea curentă (ce există azi, limitări) și de ce un BB unic.
- Relația cu sistemele guvernamentale existente (ce înlocuiește / extinde / cu ce e compatibil).
- Cadru legal aplicabil (ex. HG-uri, GDPR/cadru RM), dacă există.
3. Domeniu de aplicare
Section titled “3. Domeniu de aplicare”- În scope (capabilități, moduri de livrare).
- În afara scope (explicit, ca să nu existe ambiguitate de licitație).
4. Actori & sisteme
Section titled “4. Actori & sisteme”| Actor / Sistem | Tip (uman/sistem) | Rol față de BB | Mod de acces |
|---|---|---|---|
| … | … | producător/consumator/administrator/auditor | REST/AMQP/SDK/UI |
Pentru BB-uri, „actorii” sunt în mare parte alte sisteme și operatori de platformă.
5. Fluxul principal
Section titled “5. Fluxul principal”Ciclul de viață al datului prelucrat de BB, end-to-end. Diagramă + narativ. (ex. pentru audit: ingest → validare → calcul integritate → persistare → forward → retenție → purge; plus calea de citire/consum.)
6. Cazuri de utilizare & cerințe funcționale
Section titled “6. Cazuri de utilizare & cerințe funcționale”Pentru fiecare capabilitate, un UC cu: actor, precondiții, pași, rezultat, reguli.
| ID | UC | Actor | Precondiții | Pași | Rezultat | Reguli |
|---|---|---|---|---|---|---|
| UC-01 | … | … | … | … | … | RB-01 |
| Grupează pe capabilități (ingest, citire/căutare/export, integritate/verificare, administrare, | ||||||
| forward/integrare, retenție). |
7. Modelul obiectului prelucrat (date)
Section titled “7. Modelul obiectului prelucrat (date)”Inima unui BB. Pentru un BB de logging/audit: câmpuri universale + payload abstract.
7.1 Câmpuri universale (comune oricărei înregistrări)
Section titled “7.1 Câmpuri universale (comune oricărei înregistrări)”| Câmp | Tip | Oblig. | Descriere |
|---|---|---|---|
| event_timestamp | timestamptz | da | când s-a produs (la sursă) |
| received_at | timestamptz | da | când a fost recepționat (server) |
| tenant_id | string | da | ce sistem/organizație (din claim) |
| principal / idnp | string | da/cond. | cine (identificator user / IDNP) |
| user_details | string | nu | afișaj actor |
| ip_address | string | nu | de unde |
| object_type / action_type | string | da | ce (tip obiect / acțiune) |
| object_affected | string | nu | obiectul vizat |
| correlation_id | string | nu | corelare trace |
| severity / category | enum | nu | clasificare |
7.2 Payload abstract (specific aplicației consumatoare)
Section titled “7.2 Payload abstract (specific aplicației consumatoare)”details (JSONB) — structură liberă per aplicație: eveniment, componentă, acțiune, detalii.
Schema e validată minimal (câmpuri universale obligatorii), payload-ul rămâne extensibil.
7.3 Nomenclatoare & relații
Section titled “7.3 Nomenclatoare & relații”object_type / action_type / strategii de forward / politici de retenție (entități de configurare).
8. Componentele soluției
Section titled “8. Componentele soluției”Descrierea modulelor interne (ingest core, motor integritate, motor retenție, guard multi-tenant, search, forward sinks, SDK-uri, administrare). Diagramă C4 Container recomandată.
9. Moduri de livrare & integrare
Section titled “9. Moduri de livrare & integrare”Cum consumă și cum se rulează BB-ul. Aliniat la pattern-ul tri-modal (ADR-0010). | Mod | Pentru cine | Transport | Trade-off | |-----|-------------|-----------|-----------| | REST | sincron, low-volume | HTTPS
api/v{N}| latență directă, simplu | | AMQP / event consumer | high-volume, async | RabbitMQ / Kafka | non-blocking | | SDK embedded | buffer local + retry | NuGet/.NET, Nexus/Java | round-trip redus | | Sidecar / serviciu central | per-proiect vs. central | Docker / K8s | izolare vs. partajare |
- Pachete & distribuție (coordonate Nexus/NuGet, imagine Docker, Helm chart, OpenAPI/AsyncAPI).
- Documentație de integrare „descarcă & integrează fără să cunoști procesele”.
10. Cerințe tehnice (parametrizate; bază moștenită din anexa comună)
Section titled “10. Cerințe tehnice (parametrizate; bază moștenită din anexa comună)”Pentru fiecare: valoarea specifică BB-ului + referința CU-* moștenită.
- 10.1 Arhitectură (stack, persistență per-serviciu, mesagerie)
- 10.2 Interfață / Admin (headless v1? portal? — vezi §9)
- 10.3 Performanță & SLO (p95 ingest, throughput;
CU-PERF-001) - 10.4 Securitate (auth: token / SSO Keycloak / cert-mTLS;
CU-SEC-*,CU-AUTH-*) - 10.5 Kubernetes (
CU-K8S-*) - 10.6 Disponibilitate (
CU-AVAIL-001) - 10.7 Observabilitate (
CU-OBS-*) - 10.8 Fiabilitate (retry, DLQ, outbox;
CU-MSG-001) - 10.9 Automatizare (CI/CD;
CU-DEPLOY-*) - 10.10 Reutilizare (SDK, multi-tenant;
CU-API-*) - 10.11 Testare (
CU-*+ biblioteca TC-COM-*) - 10.12 Medii (dev/staging/prod)
- 10.13 Drepturi de proprietate (licență open-source; ex. Apache 2.0)
- 10.14 Documentare (ADR, runbook, threat model, ghid integrare)
11. Securitate & integritate
Section titled “11. Securitate & integritate”Specificul de securitate al BB-ului peste baza comună: model de integritate (ex. hash chain
tamper-evident), retenție legală, izolare multi-tenant, date personale (CU-PD-*).
12. Conformitate cu Standardul API GovStack
Section titled “12. Conformitate cu Standardul API GovStack”api/v{N} + zone (public/citizen/staff/admin/app) + endpoint-uri operaționale
(/health/live, /health/ready, /metrics, /info, /api/v1/openapi.json) + erori RFC 7807.
Checklist: skill standard-api. (CU-API-003..006.)
13. Cerințe pentru implementare
Section titled “13. Cerințe pentru implementare”- Metodologie & plan (faze, durate, dependențe).
- Livrabile per fază.
- Structura echipei de implementare.
14. Cerințe pentru mentenanță & SLA
Section titled “14. Cerințe pentru mentenanță & SLA”- Servicii de întreținere & asistență tehnică (niveluri, timpi de răspuns).
- Procedura de gestionare a modificărilor.
- Cerințe la încheierea contractului (transfer cunoaștere, cod, date).
15. Criterii de acceptanță
Section titled “15. Criterii de acceptanță”Testabile, Given/When/Then, per UC/capabilitate, + conformance suite (contract REST/AMQP).
| Ref | Criteriu de acceptanță |
|---|---|
| UC-01 | Given … When … Then … |
16. Tabel de conformitate cu cerințele universale (CU-*)
Section titled “16. Tabel de conformitate cu cerințele universale (CU-*)”| Domeniu (CU) | Stare | Parametri / Abateri / Justificare |
|---|---|---|
| SEC securitate | Aplicabil | … |
| AUTH autentificare | Parametrizat | token / Keycloak / cert-mTLS |
| RBAC roluri | Parametrizat | scope-uri/roluri BB |
| AUDIT | Special | BB-ul este sistemul de audit / sau Aplicabil |
| OBS observabilitate | Aplicabil | … |
| CACHE | Aplicabil/N/A | … |
| SEARCH | Parametrizat/N/A | … |
| DOCS | Aplicabil/N/A | … |
| INTEROP/API/MSG | Parametrizat | building blocks & contracte |
| DATA persistență | Aplicabil | … |
| PD date personale | Parametrizat | categorii de date |
| I18N/A11Y | Parametrizat/N/A | (headless? doar admin?) |
| PERF/AVAIL | Parametrizat | p95: …; disponibilitate: … |
| DEPLOY/K8S | Aplicabil | … |
17. Trasabilitate
Section titled “17. Trasabilitate”| Cerință / UC | CU-* / ADR | Criteriu de acceptanță | Caz de test |
|---|---|---|---|
| UC-01 | CU-… / ADR-… | §15 | TC-… |
18. Anexe
Section titled “18. Anexe”- Ecosistem digital relevant (MPass, MConnect, MLog, MCloud etc.).
- Glosar (
vault/2-structurat/data/glosar.md). - Exemple de payload (request/response, mesaj AMQP).
- Referințe OpenAPI / AsyncAPI.
- ADR-uri per modul (listă + link).