From 8a822a924545b1ea803c1d52657474eae5b1ce07 Mon Sep 17 00:00:00 2001 From: Davide Grilli Date: Sun, 27 Sep 2026 15:43:13 +0200 Subject: [PATCH] Riorganizza i documenti per eliminare le informazioni ripetute - Eliminato richiesta-sintesi.md (ripeteva richiesta.md senza aggiungere informazione) - domande-cliente.md: aggiunta parte C (verifiche legale/commercialista, nuovi codici Cn), riorganizzata parte B - richiesta.md, workflow.md, costi-ricorrenti.md portati a v0.3.1: ciascuno descrive solo il proprio contenuto esclusivo, gli altri richiamano con il codice invece di ripetere - CLAUDE.md: aggiornato elenco documenti, codici Cn, regola "nessuna informazione ripetuta", procedura di aggiornamento - indice-documenti.md: registrate le versioni e il registro modifiche (D10/D11 su chi paga e gestisce i servizi di produzione; v0.3 poi v0.3.1 per la riorganizzazione) Co-Authored-By: Claude Sonnet 5 --- CLAUDE.md | 30 ++-- costi-ricorrenti.md | 77 +++++---- domande-cliente.md | 198 ++++++++++++++-------- indice-documenti.md | 24 +-- richiesta-sintesi.md | 200 ---------------------- richiesta.md | 395 +++++++++++-------------------------------- workflow.md | 64 ++----- 7 files changed, 317 insertions(+), 671 deletions(-) delete mode 100644 richiesta-sintesi.md diff --git a/CLAUDE.md b/CLAUDE.md index 335844a..3b514d1 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -36,14 +36,15 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da |---|---| | `fonti/2026-09-25/funzioni software.docx` | Fonte del cliente, citata come **[D]** | | `fonti/2026-09-25/Software.xlsx` | Fonte del cliente, citata come **[X]** | -| `richiesta.md` | **Documento base**: requisiti, decisioni, domande, rischi | -| `richiesta-sintesi.md` | Sintesi completa di `richiesta.md` | -| `domande-cliente.md` | Parte A: domande per il cliente · Parte B: dubbi progettuali (**uso interno, non inviare**) | -| `workflow.md` | Processi del software, passo per passo, con i riferimenti ai requisiti | -| `costi-ricorrenti.md` | Abbonamenti e servizi ricorrenti per 12 mesi (sviluppo, test, produzione): prezzi di listino con fonte, parametri, scenari | +| `richiesta.md` | **Documento base**: cosa deve fare il software (moduli, RF, RT, dati personali, differenze tra le fonti, decisioni D) | +| `workflow.md` | Processi del software passo per passo (W), con i riferimenti ai requisiti | +| `domande-cliente.md` | Tutto ciò che è aperto. Parte A: domande per il cliente (Q) e conferme sui processi · Parte B: dubbi architetturali, rischi, contesto delle domande · Parte C: verifiche con legale e commercialista (**B e C uso interno, non inviare**) | +| `costi-ricorrenti.md` | Costi ricorrenti di sviluppo, test e produzione: prezzi con fonte, scenari, effetti economici delle decisioni | | `indice-documenti.md` | Versioni in vigore e schema di versione | -**Dipendenze:** fonti del cliente → `richiesta.md` → sintesi, domande, workflow, costi. +**Nessuna informazione ripetuta:** ogni informazione sta in un solo documento; gli altri la richiamano con il codice (es. "D10", "C7"), senza riscriverla. + +**Dipendenze:** fonti del cliente → `richiesta.md` → workflow, domande, costi. **Fonti del cliente: cartella `fonti/`.** - Ogni consegna del cliente sta in una sottocartella con la data di ricezione: `fonti/AAAA-MM-GG/`. I file mantengono il nome originale. - **Non modificare, rinominare o cancellare mai i file in `fonti/`.** Sono le prove di cosa ha chiesto il cliente. @@ -57,13 +58,14 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da | Codice | Significato | Dove | |---|---|---| -| M1–M9 | Moduli | `richiesta.md` §3 | -| RF-x.y | Requisito funzionale del modulo x | `richiesta.md` §4 | -| RT-n | Requisito trasversale | `richiesta.md` §5 | -| Dn | Decisione presa | `richiesta.md` §9 | -| Qn | Domanda per il cliente | `richiesta.md` §8, `domande-cliente.md` | +| M1–M9 | Moduli | `richiesta.md` §2 | +| RF-x.y | Requisito funzionale del modulo x | `richiesta.md` §3 | +| RT-n | Requisito trasversale | `richiesta.md` §4 | +| Dn | Decisione presa | `richiesta.md` §7 | +| Qn | Domanda per il cliente | `domande-cliente.md` parte A | | Wn | Workflow | `workflow.md` | -| Bn.m | Dubbio progettuale (uso interno) | `domande-cliente.md` parte B | +| Bn.m | Dubbio architetturale (uso interno) | `domande-cliente.md` parte B | +| Cn | Verifica con legale o commercialista (uso interno) | `domande-cliente.md` parte C | **Simboli:** ✅ deciso · ⏳ aperto, da chiedere al cliente · 🔸 ipotesi o passo dedotto, da confermare · ⚖️ da verificare con legale o commercialista. @@ -92,8 +94,8 @@ I documenti derivati hanno le **stesse X.Y di `richiesta.md`**. I nomi dei file `indice-documenti.md` e `CLAUDE.md` non hanno versione: le loro modifiche si registrano nel §3 di `indice-documenti.md`. **Quando cambia la richiesta** (es. arriva una risposta del cliente): -1. Aggiornare `richiesta.md`: requisiti coinvolti, domanda (da §8.1 a §8.2), eventuale nuova decisione in §9, registro delle modifiche, versione. -2. Aggiornare i documenti derivati che citano i codici toccati: sintesi, domande, workflow (per i passi ⏳ e 🔸 interessati). +1. Aggiornare `richiesta.md`: requisiti coinvolti, eventuale nuova decisione in §7, registro delle modifiche, versione. +2. Aggiornare i documenti derivati che citano i codici toccati: in `domande-cliente.md` spostare la domanda tra le chiuse (Qn → Dn); in `workflow.md` i passi ⏳ e 🔸 interessati; in `costi-ricorrenti.md` le voci che dipendono dalla risposta. 3. Allineare versioni e registri delle modifiche di tutti i documenti toccati. 4. Aggiornare `indice-documenti.md`. 5. Consegnare i file aggiornati e ricordare a Davide di allineare entrambe le copie: cartella locale e documenti del Project su claude.ai. diff --git a/costi-ricorrenti.md b/costi-ricorrenti.md index bde9385..1a63d12 100644 --- a/costi-ricorrenti.md +++ b/costi-ricorrenti.md @@ -1,8 +1,8 @@ # Costi ricorrenti del primo anno **Progetto:** Gestionale per enti del Terzo Settore **Documento:** `costi-ricorrenti.md` -**Versione:** 0.2 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare -**Allineato a:** `richiesta.md` v0.2 · **Schema di versione:** vedi `indice-documenti.md` +**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare +**Allineato a:** `richiesta.md` v0.3 · **Schema di versione:** vedi `indice-documenti.md` --- @@ -23,7 +23,9 @@ Il documento elenca **tutti gli abbonamenti e i servizi a pagamento ricorrente** 2. **I fornitori citati sono riferimenti di prezzo, non scelte.** Servono a dare l'ordine di grandezza. La scelta dei fornitori si farà nella fase di architettura, motivata dai requisiti. 3. **Tutti i prezzi sono IVA esclusa.** Alcuni servizi fatturano in dollari (USD): li lascio in USD per non inventare un tasso di cambio. -⚖️ Trattamento IVA dei servizi esteri (reverse charge), ammissibilità delle spese nel bando e intestazione dei contratti: **da verificare con il commercialista** (vedi §7). +**Chi paga:** decisioni D10 e D11 (`richiesta.md` §7); effetti sui costi al §7. + +⚖️ IVA sui servizi esteri e ammissibilità nel bando: verifiche C7 e C8 (`domande-cliente.md` parte C). --- @@ -86,7 +88,7 @@ I costi certi sono solo una parte del totale. **La voce più pesante e più ince | Monitoraggio errori | Sentry Developer | 0 € | 0 € | Come in sviluppo | **Totale produzione, costi certi: 172,65 €** + IPv4 -(ipotesi: produzione attiva per tutti i 12 mesi. Se va online più tardi, queste voci si riducono in proporzione ai mesi) +(ipotesi: produzione attiva per 12 mesi. Il numero reale di mesi dipende da quando decorre il primo anno: vedi §7.3, Q23) ### 5.2 Costi che dipendono dalle risposte del cliente @@ -94,7 +96,7 @@ I costi certi sono solo una parte del totale. **La voce più pesante e più ince |---|---|---|---|---| | **Firma elettronica** (RT-5) | ⏳ **Q4** tipo di firma e numero di firme l'anno | Confirmo API: **da 30 €/mese**, con costo aggiuntivo per ogni firma oltre la soglia · Youtrust API Plus: **104 €/mese** (1.248 €/anno), 500 firme semplici l'anno incluse, **2 € a firma** in più | **360 – 1.248 €** e oltre | Per la firma avanzata o qualificata i costi salgono (Youtrust: firma qualificata da 10 € l'una a pacchetti). Serve un preventivo del fornitore basato sui volumi | | **Marche temporali** (RT-6) | Numero di documenti archiviati l'anno (W4, passo 5), cioè numero di enti (Q1) × eventi | Aruba: **19,90 € per 100 marche** (0,20 € a marca) | Volume × 0,20 € | Esempio con ipotesi dichiarata: 500 documenti/anno = 5 pacchetti = **99,50 €**. Il volume reale va stimato con il cliente | -| **Conservazione a norma** (RT-6) | ⏳ **Q9**: serve o no | Aruba DocFly: **49,90 €/anno** (1 GB) + **25 €/GB/anno** in più | Da 49,90 € | ⚠️ **Attenzione:** il servizio è "uno per partita IVA". Se la conservazione deve essere fatta **a nome di ogni ente**, il costo si moltiplica per il numero di enti (Q1), e molti enti hanno solo il codice fiscale. ⚖️ Da chiarire con il fornitore e un legale | +| **Conservazione a norma** (RT-6) | ⏳ **Q9**: serve o no | Aruba DocFly: **49,90 €/anno** (1 GB) + **25 €/GB/anno** in più | Da 49,90 € | ⚠️ Il servizio è "uno per partita IVA": se la conservazione va fatta **a nome di ogni ente**, il costo si moltiplica per il numero di enti (Q1). ⚖️ Verifica C6 | | **Fatturazione elettronica** | ⏳ **Q5**: solo proforma o anche fattura elettronica | Non quotata | — | Se serve, si valuta l'integrazione con un servizio esistente invece di svilupparla | | **Email oltre il piano gratuito** | Volume: numero di enti (Q1) × alert e circolari | Brevo Starter: **da $8,08/mese** con pagamento annuale | Circa **$97/anno** | Serve solo se si superano 300 email al giorno. Con pochi enti è improbabile | | **Monitoraggio con più utenti** | Più persone da avvisare sugli errori | Sentry Team: **$26/mese** | **$312/anno** | Serve solo se lavora più di una persona sul software | @@ -125,34 +127,37 @@ Se Q4, Q9 e Q1 vanno nella direzione più costosa, la spesa può superare lo sce --- -## 7. Punti da decidere prima del preventivo +## 7. Chi paga e quando -### 7.1 A nome di chi vanno i servizi di produzione? ⚖️ +### 7.1 Decisioni ✅ -È la questione più importante di questo documento. Ci sono due strade: +| Decisione (`richiesta.md` §7) | Effetto sui costi | +|---|---| +| D10: primo anno a carico e a nome di Davide | Tutte le voci di questo documento (§3, §4, §5) vanno **nel preventivo di Davide** | +| D11: dal secondo anno servizi al cliente, manutenzione a Davide | I costi del §5 passano al cliente; il compenso per la manutenzione si definisce nel contratto (tariffe decise da Davide) | -| | Servizi intestati a Davide, rifatturati | Servizi intestati allo studio (cliente) | +### 7.2 Conseguenze da mettere nel preventivo e nel contratto + +1. **Il passaggio dei servizi al cliente è un'attività di lavoro.** A fine primo anno vanno trasferiti account, dominio, backup, contratti con i fornitori, accessi, e va consegnato un documento con configurazioni e procedure (RT-15). Sono **ore di lavoro**, da stimare e mettere nel preventivo o nel contratto di manutenzione. +2. **I fornitori devono essere trasferibili (RT-15).** In fase di architettura si scelgono servizi che permettono di passare account o contratti a un altro intestatario senza fermare il sistema. Un fornitore che non lo permette obbliga a una migrazione, che costa di più e può comportare un fermo del servizio. +3. **Il rischio sui prezzi è di Davide.** Nel primo anno, se un fornitore aumenta i prezzi (Hetzner li ha aumentati a giugno 2026) o i volumi superano le stime (firme, marche, email), la differenza la paga Davide. Si può gestire in due modi, anche insieme: + - una clausola nel contratto che lega le voci ai prezzi di listino a una data e prevede l'adeguamento oltre una soglia di volume; + - un margine sulle voci variabili, deciso da Davide. + + ⚖️ Verifica C9. +4. **Conservazione e firma avanzata potrebbero dover essere a nome del cliente fin dall'inizio** (⚖️ verifica C5): il costo del primo anno resta comunque a carico di Davide. +5. **Rendicontazione:** i costi pagati da Davide entrano nel preventivo come voci di spesa; ammissibilità e forma da verificare (⚖️ C7). + +### 7.3 Da quando decorre il primo anno? ⏳ Q23 + +Il calcolo del §5 suppone 12 mesi di produzione. Il numero di mesi da mettere nel preventivo dipende però da quando decorre il primo anno: + +| Se il primo anno decorre… | Mesi di produzione a carico di Davide | Effetto | |---|---|---| -| **Proprietà** | L'infrastruttura è di Davide | L'infrastruttura è del cliente | -| **Privacy** | Davide è anche fornitore di hosting dei dati degli enti: più responsabilità e contratti GDPR più complessi | Lo studio sceglie e contratta i propri fornitori; Davide gestisce il sistema con un accesso autorizzato | -| **Dopo i 12 mesi** | Davide continua a pagare e deve rifatturare, o migrare tutto | Il cliente continua a pagare direttamente, senza interruzioni | -| **Rendicontazione del bando** | Da verificare se i costi rifatturati sono ammissibili | Da verificare se il bando ammette spese sostenute direttamente dal beneficiario per servizi ricorrenti | +| dalla **firma del contratto** | 12 meno i mesi di sviluppo prima del rilascio | Costo di produzione più basso; il passaggio avviene 12 mesi dopo la firma | +| dalla **messa in produzione** | 12 pieni, dopo il rilascio | Costo di produzione pieno; il periodo coperto da Davide dura più di 12 mesi, perché ai mesi di sviluppo si aggiungono 12 mesi di produzione. Anche gli strumenti di sviluppo (§3) e il test (§4) andrebbero calcolati su questo periodo più lungo | -**Orientamento (🔸, da confermare):** -- **strumenti di sviluppo** (Claude Max, test) intestati a Davide, perché li usa lui per lavorare; -- **servizi di produzione** intestati al cliente, per proprietà, privacy e continuità. - -⚖️ Va verificato con il **commercialista** (ammissibilità nel bando) e con un **legale** (ruoli GDPR, contratti con i fornitori). -→ Domanda nuova per il cliente, **proposta Q21:** "I servizi di produzione (server, firma, conservazione) li intestate voi o preferite che li gestisca io e ve li rifatturi?" - -### 7.2 Chi paga dopo il primo anno? ⏳ - -Il bando copre il progetto, ma i costi di produzione continuano **ogni anno** finché il software è in uso. Il cliente deve saperlo e metterli a bilancio. -→ Domanda nuova per il cliente, **proposta Q22:** "Dopo il primo anno i costi di esercizio (indicativamente quelli del §5) restano a vostro carico: avete previsto un budget? Vi serve anche un contratto di manutenzione?" - -### 7.3 Da quale mese parte la produzione? ⏳ - -Il calcolo al §5 suppone la produzione attiva per 12 mesi, quindi è un **tetto massimo**. Nella realtà la produzione parte con il rilascio della fase 1. La data dipende dal piano di lavoro, che non esiste ancora. +La differenza tocca soprattutto Claude Max (90 €/mese), che è la voce più pesante. → Domanda **Q23**. --- @@ -167,7 +172,7 @@ Non sono costi del software, ma di Davide come professionista. Conviene valutarl --- -## 9. Domande e dipendenze collegate +## 9. Domande che cambiano i costi | Codice | Effetto sui costi | |---|---| @@ -176,8 +181,7 @@ Non sono costi del software, ma di Davide come professionista. Conviene valutarl | Q4 tipo di firma | Voce più incerta: da 360 € a oltre 1.200 €/anno | | Q5 fatturazione elettronica | Possibile servizio aggiuntivo | | Q9 conservazione a norma | Da 0 € a 49,90 €/anno per archivio, per ogni ente se necessario | -| Q21 (proposta) intestazione dei servizi | Chi paga e come si rendiconta | -| Q22 (proposta) costi dopo il primo anno | Budget del cliente, contratto di manutenzione | +| Q23 ⏳ decorrenza del primo anno | Mesi di produzione e di strumenti da includere nel preventivo (§7.3) | --- @@ -205,13 +209,16 @@ Prezzi consultati il 27/09/2026. Sono listini pubblici e **possono cambiare**: v | Versione | Data | Allineato a | Modifiche | |---|---|---|---| | 0.2 | 27/09/2026 | `richiesta.md` v0.2 | Prima stesura: costi ricorrenti di sviluppo, test e produzione per 12 mesi, con prezzi di listino e scenari | +| 0.3 | 27/09/2026 | `richiesta.md` v0.3 | Registrate D10 e D11 (chi paga nel primo anno e dopo); riscritto il §7 con le conseguenze su preventivo e contratto; aggiunta Q23 (decorrenza del primo anno); aggiornato il §9 | +| 0.3.1 | 27/09/2026 | `richiesta.md` v0.3 | Riorganizzazione senza modifiche ai costi: testo delle decisioni D10 e D11 e delle verifiche legali sostituito dal rimando a `richiesta.md` §7 e a `domande-cliente.md` parte C; tolte dal §9 le domande già chiuse | --- ## Stato -- **Fase corrente:** analisi dei requisiti (v0.2), prima stima dei costi ricorrenti. -- **Decisioni prese:** nessuna scelta di fornitori. Costi certi 1.318,53 € + IVA l'anno; scenari tra 1.698,43 € e oltre 2.765,93 € + IVA. +- **Fase corrente:** analisi dei requisiti, costi ricorrenti v0.3.1. +- **Decisioni prese:** D10 (primo anno a carico e a nome di Davide), D11 (dal secondo anno al cliente, manutenzione a Davide). Costi certi 1.318,53 € + IVA su 12 mesi; scenari tra 1.698,43 € e oltre 2.765,93 € + IVA. - **Prossimo passo:** - - verificare con il commercialista l'intestazione dei servizi e l'ammissibilità delle spese nel bando (§7.1); - - aggiungere Q21 e Q22 alle domande per il cliente; + - chiarire con il cliente da quando decorre il primo anno (Q23); + - verifiche C5, C6, C7, C9 (`domande-cliente.md` parte C); + - stimare le ore del passaggio dei servizi a fine anno; - con le risposte a Q1, Q4 e Q9, ricalcolare gli scenari. diff --git a/domande-cliente.md b/domande-cliente.md index 29a9c3d..e8fb21e 100644 --- a/domande-cliente.md +++ b/domande-cliente.md @@ -1,105 +1,163 @@ -# Domande per il cliente e dubbi progettuali +# Domande per il cliente e dubbi architetturali **Progetto:** Gestionale per enti del Terzo Settore **Documento:** `domande-cliente.md` -**Versione:** 0.2 · **Data:** 25/09/2026 · **Stato:** Bozza, da validare con il cliente -**Allineato a:** `richiesta.md` v0.2 · **Schema di versione:** vedi `indice-documenti.md` -I codici (Q1, Q2…) sono gli stessi di `richiesta.md`, per ritrovare il contesto completo. +**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza +**Allineato a:** `richiesta.md` v0.3 · **Schema di versione:** vedi `indice-documenti.md` -Il documento ha due parti: -- **Parte A: domande per il cliente.** Si può portare all'incontro o inviare. La colonna "Risposta" serve per prendere appunti. -- **Parte B: dubbi progettuali.** Uso interno, da non condividere con il cliente. Sono le scelte che restano a chi sviluppa, e dipendono in parte dalle risposte della parte A. +**Cosa contiene:** tutto ciò che è ancora aperto. I codici (Q, RF, RT, D, M, W) rimandano a `richiesta.md` e `workflow.md`. + +| Parte | Contenuto | Si può inviare al cliente? | +|---|---|---| +| **A** | Domande per il cliente, conferme sui processi, cose da comunicare | **Sì** | +| **B** | Dubbi architetturali, scelte orientate, rischi, contesto delle domande | **No**, uso interno | +| **C** | Verifiche con legale e commercialista | **No**, uso interno | --- -# Parte A: domande per il cliente +# Parte A: per il cliente ## A1. Priorità alta: senza queste risposte non si può fare la stima -| # | Domanda | Risposta | -|---|---|---| -| Q1 | Quanti enti pensate di gestire con il software, oggi e tra 3 anni? | | -| Q2 | Sono previsti circa 100 utenti: quanti sono persone dello studio e quanti referenti degli enti? | | -| Q4 | Per accettare le offerte, la privacy e l'antiriciclaggio, e per i libri sociali, che firma serve? Una conferma semplice (click o codice via SMS), una firma elettronica avanzata o una firma digitale qualificata? | | -| Q5 | Il software deve emettere solo proforma o anche la fattura elettronica? Usate già un programma di fatturazione? | | -| Q9 | Per i libri sociali basta un archivio con data certa (marca temporale), o serve la conservazione digitale a norma tramite un servizio esterno? Serve anche la stampa? | | -| Q10 | Gli estratti conto in PDF devono essere letti in automatico dal software, estraendo i movimenti, o basta archiviarli? Da quante banche diverse arrivano? | | -| Q19 | Per progettazione e bilancio sociale, come lavorate con l'ente? (a) L'ente scrive e voi rivedete; (b) ognuno compila le sue parti; (c) lavorate sullo stesso documento, anche nello stesso momento. Vale lo stesso per entrambi? | | +| # | Domanda | Perché serve | Risposta | +|---|---|---|---| +| Q1 | Quanti enti pensate di gestire con il software, oggi e tra 3 anni? | Dimensionamento della piattaforma e dei costi | | +| Q2 | Sono previsti circa 100 utenti: quanti sono persone dello studio e quanti referenti degli enti? | Dimensionamento e permessi | | +| Q4 | Per accettare le offerte, la privacy e l'antiriciclaggio, e per i libri sociali, che firma serve? Una conferma semplice (click o codice via SMS), una firma elettronica avanzata o una firma digitale qualificata? | Scelta del fornitore di firma; è la voce di costo più incerta | | +| Q5 | Il software deve emettere solo proforma o anche la fattura elettronica? Usate già un programma di fatturazione? | La fatturazione elettronica è un sotto-progetto a sé | | +| Q9 | Per i libri sociali basta un archivio con data certa (marca temporale), o serve la conservazione digitale a norma tramite un servizio esterno? Serve anche la stampa? | Fornitore esterno, costi ricorrenti, valore legale | | +| Q10 | Gli estratti conto in PDF devono essere letti in automatico dal software, estraendo i movimenti, o basta archiviarli? Da quante banche diverse arrivano? | Rischio tecnico alto se si vuole la lettura automatica | | +| Q19 | Per progettazione e bilancio sociale, come lavorate con l'ente? (a) L'ente scrive e voi rivedete; (b) ognuno compila le sue parti; (c) lavorate sullo stesso documento, anche nello stesso momento. Vale lo stesso per entrambi? | Può cambiare di molto il costo di M6 e M7 | | +| Q23 | Il primo anno di servizi a mio carico parte dalla firma del contratto o dalla messa in produzione? In che data facciamo il passaggio dei servizi a voi? | Mesi di costi da inserire nel preventivo | | ## A2. Contenuto dei moduli -| # | Domanda | Risposta | -|---|---|---| -| Q3 | Il catalogo dei servizi e dei pacchetti chi lo gestisce? Servono listini, sconti o aliquote IVA diverse? | | -| Q7 | Nella scheda dell'ente, numero soci e numero volontari si inseriscono a mano? | | -| Q8.a | Quali tipi di persone deve gestire il software? Nei vostri documenti compaiono: soci, aderenti, tesserati, volontari, volontari occasionali, dipendenti/lavoratori, collaboratori, sostenitori, partecipanti. Aderenti e tesserati sono la stessa cosa? Sostenitori e partecipanti servono? | | -| Q8.b | Oltre ad anagrafica e contatti, ci sono dati specifici da raccogliere per ogni tipo di persona? Per esempio la quota associativa per i soci, il tipo di contratto per i dipendenti. | | -| Q8.c | Una stessa persona può essere socio e volontario insieme? Il libro soci e il registro volontari devono prendere i dati da queste schede? | | -| Q12 | Le scadenze degli alert sono uguali per tutti gli enti ma modificabili. Si modifica solo il calendario comune, o serve anche cambiare le scadenze di un singolo ente? | | -| Q13 | Lo schema del progetto non c'è ancora: chi lo prepara (voi, o lo costruiamo insieme) e per quando? In che formato va esportato il progetto (Word, PDF)? L'adattamento ai formulari dei bandi lo fate a mano o deve farlo il software? | | -| Q14.a | Nell'Excel la descrizione del bilancio sociale è identica a quella della progettazione: è un errore? Il bilancio sociale deve seguire le linee guida ministeriali per gli ETS? | | -| Q14.b | Le sezioni del bilancio sociale sono quelle di entrambi i documenti (con "lettera del presidente" e "serie di dati standard")? Cosa intendete per "serie di dati standard"? | | -| Q15 | Chi stabilisce il valore di un'ora per ogni tipo di attività dei volontari? In che forma l'ente vi manda le ore (Excel, carta, email)? | | +| # | Domanda | Perché serve | Risposta | +|---|---|---|---| +| Q3 | Il catalogo dei servizi e dei pacchetti chi lo gestisce? Servono listini, sconti o aliquote IVA diverse? | Complessità di M1 | | +| Q7 | Nella scheda dell'ente, numero soci e numero volontari si inseriscono a mano? | Coerenza con le anagrafiche | | +| Q8.a | Quali tipi di persone deve gestire il software? Nei vostri documenti compaiono: soci, aderenti, tesserati, volontari, volontari occasionali, dipendenti/lavoratori, collaboratori, sostenitori, partecipanti. Aderenti e tesserati sono la stessa cosa? Sostenitori e partecipanti servono? | Modello dati di M3 | | +| Q8.b | Oltre ad anagrafica e contatti, ci sono dati specifici da raccogliere per ogni tipo di persona? Per esempio la quota associativa per i soci, il tipo di contratto per i dipendenti | Modello dati di M3 | | +| Q8.c | Una stessa persona può essere socio e volontario insieme? Il libro soci e il registro volontari devono prendere i dati da queste schede? | Struttura del database | | +| Q12 | Le scadenze degli alert sono uguali per tutti gli enti ma modificabili: si modifica solo il calendario comune, o serve anche cambiare le scadenze di un singolo ente? | Complessità dello scadenziario | | +| Q13 | Lo schema del progetto non c'è ancora: chi lo prepara (voi, o lo costruiamo insieme) e per quando? In che formato va esportato il progetto (Word, PDF)? L'adattamento ai formulari dei bandi lo fate a mano o deve farlo il software? | Senza schema M6 non è stimabile | | +| Q14.a | Nell'Excel la descrizione del bilancio sociale è identica a quella della progettazione: è un errore? Il bilancio sociale deve seguire le linee guida ministeriali per gli ETS? | Correttezza dei requisiti di M7 | | +| Q14.b | Le sezioni del bilancio sociale sono quelle di entrambi i documenti (con "lettera del presidente" e "serie di dati standard")? Cosa intendete per "serie di dati standard"? | Correttezza dei requisiti di M7 | | +| Q15 | Chi stabilisce il valore di un'ora per ogni tipo di attività dei volontari? In che forma l'ente vi manda le ore (Excel, carta, email)? | Modello dati di M9 ed eventuale importazione | | ## A3. Organizzazione del progetto -| # | Domanda | Risposta | -|---|---|---| -| Q18 | Chi approva i requisiti da parte vostra? Se durante lo sviluppo servono modifiche, come le gestiamo (richiesta scritta, stima, approvazione)? | | -| Q20 | Dove il Word e l'Excel elencano campi o sezioni diversi senza contraddirsi, confermate che vanno inclusi tutti? | | +| # | Domanda | Perché serve | Risposta | +|---|---|---|---| +| Q18 | Chi approva i requisiti da parte vostra? Se durante lo sviluppo servono modifiche, come le gestiamo (richiesta scritta, stima, approvazione)? | Controllo dello scope creep | | +| Q20 | Dove il Word e l'Excel elencano campi o sezioni diversi senza contraddirsi, confermate che vanno inclusi tutti? | Chiude le righe "Unione" tra i due documenti | | -## A4. Da comunicare al cliente (non sono domande) +## A4. Conferme sui processi + +Passi 🔸 che il workflow prevede ma le fonti non citano. Vanno confermati prima di considerarli requisiti. + +| Workflow | Domanda | Risposta | +|---|---|---| +| W1 | Un ente può rifiutare un'offerta? Un'offerta non firmata deve scadere dopo un certo tempo? | | +| W1 | È lo studio a creare l'accesso al software per il referente di ogni ente? | | +| W2 | Lo studio registra nel software l'avvenuto pagamento? Come si gestiscono i ritardi? | | +| W4 | Lo studio può rimandare un documento all'ente con osservazioni da correggere? | | +| W5 | Se l'ente non carica i documenti alla scadenza, il software deve mandare solleciti e avvisare lo studio? | | +| W5 | Lo studio controlla e approva Modello D e relazione illustrativa prima dell'esportazione? | | +| W7 | Le circolari vanno sempre a tutti gli enti, o anche a gruppi (per esempio per qualifica)? | | + +## A5. Da comunicare al cliente (non sono domande) | Punto | Cosa dire | |---|---| -| Inserimento iniziale dei dati | Non è prevista l'importazione di dati esistenti: ogni ente dovrà inserire a mano i soci e i volontari che ha già. Se è un problema, l'importazione da Excel si può quotare a parte. | -| Uso da smartphone | Il software è pensato per computer. Da smartphone si apre, ma non viene progettato né collaudato per quell'uso. | -| Hosting | I dati saranno ospitati nell'Unione Europea, per rispettare il GDPR. | -| Materiali da consegnare | Per sviluppare servono da voi: lo schema del progetto, i modelli di verbale e di circolare, un esempio di estratto conto per ogni banca, le tariffe orarie del volontariato. | +| Inserimento iniziale dei dati (D8) | Non è prevista l'importazione di dati esistenti: ogni ente inserirà a mano i soci e i volontari che ha già. Se è un problema, l'importazione da Excel si può quotare a parte | +| Uso da smartphone (D9) | Il software è pensato per computer: da smartphone si apre, ma non viene progettato né collaudato per quell'uso | +| Hosting | I dati saranno ospitati nell'Unione Europea, per rispettare il GDPR | +| Servizi di produzione (D10, D11) | Il primo anno sono a mio nome e a mio carico; dal secondo anno passano a voi, con un contratto di manutenzione separato | +| Materiali da consegnare | Servono da voi: schema del progetto, modelli di verbale e di circolare, un esempio di estratto conto per ogni banca, tariffe orarie del volontariato | + +**Domande già chiuse:** Q6 → D5 · Q11 → D6 · Q12 (in parte) → D7 · Q13 (in parte: lo schema non esiste, RF-6.5) · Q16 → D8 · Q17 → D9 · Q21 → D10 · Q22 → D11. --- -# Parte B: dubbi progettuali (uso interno) +# Parte B: dubbi architetturali (uso interno) ## B1. Scelte che dipendono dalle risposte del cliente -| # | Dubbio | Da cosa dipende | Orientamento attuale | +| # | Dubbio | Dipende da | Orientamento attuale | |---|---|---|---| -| B1.1 | **Struttura dell'anagrafica persone:** una scheda per persona con più ruoli, o una scheda per ruolo? | Q8.c | Una scheda per persona con più ruoli: evita dati doppi e alimenta libro soci e registro volontari senza reinserimento. Va deciso prima di iniziare, perché definisce il database | -| B1.2 | **Come stimare progettazione (M6) e bilancio sociale (M7)** se Q19 e Q13 non hanno risposta | Q13, Q19 | Stimare sull'opzione (a), "l'ente scrive, lo studio rivede", e scriverlo nel preventivo come assunzione. Le opzioni (b) e (c) come varianti quotate a parte | -| B1.3 | **Estratti conto:** lettura automatica del PDF o solo archiviazione | Q10 | Fase 1: import da Excel/CSV e archiviazione del PDF. Lettura automatica del PDF solo come evoluzione, perché ogni banca ha un formato diverso e il risultato è poco affidabile | -| B1.4 | **Fornitori esterni** per firma, marca temporale e conservazione | Q4, Q9 | Usare fornitori qualificati, non soluzioni fatte in casa. La scelta del fornitore si fa dopo le risposte, e il costo ricorrente va nel preventivo | -| B1.5 | **Fatturazione elettronica** | Q5 | Se serve, trattarla come voce separata o integrarsi con un software già in uso, invece di svilupparla da zero | -| B1.6 | **Scadenziario degli alert:** solo calendario comune, o anche modifiche per singolo ente | Q12 | La seconda comprende la prima. Se la risposta tarda, progettare il database già pronto per le modifiche per ente | -| B1.7 | **Numero soci e volontari manuale** | Q7 | Se si conferma l'inserimento manuale, mostrare accanto anche il conteggio calcolato dalle anagrafiche, come controllo | +| B1.1 | **Struttura dell'anagrafica persone:** una scheda per persona con più ruoli, o una scheda per ruolo? | Q8.c | Una scheda per persona con più ruoli: i dati si inseriscono una volta sola e alimentano libro soci e registro volontari. Va deciso prima di iniziare, perché definisce il database | +| B1.2 | **Come stimare M6 e M7** se Q13 e Q19 restano senza risposta | Q13, Q19 | Stimare sull'opzione (a) di Q19 e scriverlo nel preventivo come assunzione; (b) e (c) come varianti quotate a parte | +| B1.3 | **Estratti conto:** lettura automatica del PDF o solo archiviazione | Q10 | Fase 1: import da Excel/CSV e archiviazione del PDF. Lettura automatica solo come evoluzione: ogni banca ha un formato diverso e il risultato è poco affidabile | +| B1.4 | **Fornitori esterni** per firma, marca temporale e conservazione | Q4, Q9 | Fornitori qualificati, non soluzioni fatte in casa. Si scelgono dopo le risposte | +| B1.5 | **Fatturazione elettronica** | Q5 | Se serve, voce separata o integrazione con un software già in uso, non sviluppo da zero | +| B1.6 | **Scadenziario degli alert:** solo calendario comune, o anche modifiche per singolo ente | Q12 | La seconda comprende la prima: se la risposta tarda, progettare il database già pronto per le modifiche per ente | +| B1.7 | **Numero soci e volontari manuale** | Q7 | Se si conferma, mostrare accanto il conteggio calcolato dalle anagrafiche, come controllo | +| B1.8 | **Fornitori trasferibili** (RT-15) | Q23 | Criterio obbligatorio per tutti i fornitori di produzione: verificare per ciascuno il cambio di intestatario senza migrazione | +| B1.9 | **Ore del passaggio** dei servizi al cliente | Q23 | Stimarle e metterle nel preventivo o nel contratto di manutenzione: trasferimento di account e dominio, documento di consegna | ## B2. Scelte già orientate, da motivare nel preventivo | # | Scelta | Motivazione | |---|---|---| -| B2.1 | Separazione rigorosa dei dati tra enti (multi-ente) | Uno studio gestisce molti enti: un ente non deve mai vedere i dati di un altro. Condiziona database, permessi e test di sicurezza | -| B2.2 | Voci del Modello D in una tabella configurabile | L'imputazione usa le voci del Modello D (D6). Se il Ministero cambia lo schema, si aggiorna la tabella senza toccare il codice | -| B2.3 | Un solo sistema di notifiche per alert, proforma e circolari (email + app) | Serve già per alert e circolari (D5): riusarlo riduce i costi | -| B2.4 | Un solo flusso di approvazione (bozza → revisione → approvato → archiviato) riusato nei moduli | Serve per i libri sociali e probabilmente per M5–M7 | -| B2.5 | Registro delle operazioni (chi ha fatto cosa e quando) | Dà valore probatorio ai libri sociali e serve per il GDPR | +| B2.1 | Separazione rigorosa dei dati tra enti | Un ente non deve mai vedere i dati di un altro (RT-1): condiziona database, permessi e test di sicurezza | +| B2.2 | Voci del Modello D in una tabella configurabile | L'imputazione usa le voci del Modello D (D6): se il Ministero cambia lo schema, si aggiorna la tabella senza toccare il codice | +| B2.3 | Un solo sistema di notifiche (email + app) per alert, proforma e circolari | Serve comunque per gli alert (RT-4): il doppio canale delle circolari (D5) costa più di un canale solo ma non il doppio, e dà allo studio lo stato di lettura, che la sola email non garantisce | +| B2.4 | Un solo flusso di approvazione riusato nei moduli | Serve per i libri sociali e probabilmente per M5–M7 (RT-3) | +| B2.5 | Registro delle operazioni | Valore probatorio dei libri sociali e GDPR (RT-9) | -## B3. Da verificare con legale e commercialista +## B3. Rischi -Non sono domande per il cliente, e su questi punti serve un parere professionale: - -1. **Ruoli privacy.** Ipotesi: lo studio è responsabile del trattamento per i dati dei soci e dei volontari degli enti, chi sviluppa e gestisce il software è sub-responsabile. Servono i contratti (DPA) conseguenti. -2. **Dati particolari (art. 9 GDPR).** L'iscrizione ad alcuni enti (religiosi, politici, sindacali, di pazienti) può rivelare dati particolari, con misure di sicurezza più stringenti. -3. **Antiriciclaggio.** Per quanto tempo conservare i dati raccolti e con quali misure. -4. **Valore legale** di firma, marca temporale e conservazione digitale dei libri sociali degli ETS. -5. **Rendicontazione del bando.** Come esporre le voci del preventivo, compresi gli strumenti di sviluppo come Claude Max, perché siano ammissibili. - -## B4. Rischi da tenere presenti +I rischi economici del primo anno (aumenti di prezzo, volumi, passaggio dei servizi) sono in `costi-ricorrenti.md` §7.2. | Rischio | Dove nasce | Come contenerlo | |---|---|---| -| Scope creep su M6 | Schema del progetto inesistente (Q13), modo di lavorare non definito (Q19) | Assunzione dichiarata nel preventivo; schema consegnato prima dello sviluppo del modulo | -| Dipendenza dal cliente | Materiali da ricevere (A4) | Elenco dei materiali con date di consegna scritto nel preventivo | -| Richiesta di importazione a progetto avviato | Nessuna migrazione prevista (D8) | Dirlo subito (A4) e offrire l'importazione come voce opzionale | -| Modifiche non controllate | Nessuna procedura per le modifiche (Q18) | Procedura scritta: richiesta, stima, approvazione | +| Scope creep su M6 | Schema del progetto inesistente (Q13), divisione del lavoro non definita (Q19) | Assunzione dichiarata nel preventivo (B1.2); schema consegnato prima dello sviluppo del modulo | +| Scope creep su M7 | Descritto solo per titoli | Fase 2 stimata a parte, requisiti firmati prima dell'avvio | +| Modifiche non controllate | Nessuna procedura (Q18) | Procedura scritta: richiesta, stima, approvazione | +| Dipendenza dal cliente | Materiali da ricevere (A5) | Elenco dei materiali con date di consegna nel preventivo | +| Richiesta di importazione a progetto avviato | Nessuna migrazione prevista (D8) | Dirlo subito (A5); import da Excel come voce opzionale | +| Sicurezza e privacy | Molte persone, possibili dati art. 9, dati antiriciclaggio | Privacy by design, contratti sul trattamento dei dati, hosting UE, verifiche C1–C3 | +| Valore legale dei documenti | Firma, marca temporale e conservazione hanno requisiti normativi | Fornitori qualificati (B1.4), verifica C4 | +| Estratti conto PDF | Formati diversi per ogni banca | B1.3 | +| Norme che cambiano | Modello D, bilancio sociale e RUNTS possono cambiare per legge | Voci e modelli configurabili (B2.2) | + +## B4. Contesto delle domande + +Spiegazioni per chi conduce l'incontro. Non vanno inviate. + +**B4.1 Q8, le persone dell'ente.** Le fonti citano 9 categorie, non le stesse (`richiesta.md` M3); alcune potrebbero coincidere ("aderenti" e "tesserati", "dipendenti" e "lavoratori"). Alcune categorie potrebbero avere dati propri (quota associativa, tipo di contratto, data di assunzione). Sulla possibilità di più ruoli per persona, le strade sono due: +- **una scheda per persona, con più ruoli**: dati inseriti e aggiornati in un solo punto; va decisa subito perché definisce il database; +- **una scheda per ruolo**: più semplice all'inizio, ma la stessa persona compare più volte, con il rischio di dati diversi. + +**B4.2 Q14, il bilancio sociale.** Nell'Excel la colonna "Funzioni" della Rendicontazione sociale dice *"Guidare gli utenti nella stesura di un progetto secondo un modello standard facilmente convertibile sui formulari imposti dagli enti erogatori"*: è la stessa frase della Progettazione. Per il bilancio sociale non ha senso, perché non è un progetto per un bando. Il bilancio sociale degli ETS segue le linee guida ministeriali (DM 4 luglio 2019). Quasi sicuramente è un copia-incolla. Le sezioni differiscono per "serie di dati standard" [D] e "lettera del presidente" [X]. + +**B4.3 Q19, divisione del lavoro in M6 e M7.** Le fonti dicono solo che ci lavorano ente e studio ("entrambi" in [X], "l'operatore" in [D]). Le opzioni hanno costi molto diversi: + +| Opzione | Come funziona | Impatto sullo sviluppo | +|---|---|---| +| (a) Redazione e revisione | L'ente scrive, lo studio rivede e approva, come per i libri sociali | Il più semplice: riusa il flusso di approvazione (RT-3) | +| (b) Sezioni divise | Alcune sezioni le compila l'ente, altre lo studio (es. piano economico-finanziario) | Medio: permessi per singola sezione | +| (c) Modifica contemporanea | Ente e studio lavorano sullo stesso documento nello stesso momento | Il più costoso: gestione dei conflitti e aggiornamento in tempo reale | + +La risposta può essere diversa per M6 e M7. Il workflow (W6, W8) è scritto sull'opzione (a). + +--- + +# Parte C: verifiche con legale e commercialista (uso interno) ⚖️ + +| # | Da verificare | Con chi | Collegato a | +|---|---|---|---| +| C1 | **Ruoli privacy:** studio titolare per i propri clienti e responsabile per i dati degli enti; sviluppatore e hosting sub-responsabili; contratti sul trattamento dei dati conseguenti | Legale | `richiesta.md` §5 | +| C2 | **Dati particolari (art. 9 GDPR):** l'iscrizione ad alcuni enti può rivelarli; quali misure di sicurezza aggiuntive servono | Legale | M3 | +| C3 | **Antiriciclaggio:** per quanto tempo conservare i dati e con quali misure | Legale / commercialista | RF-1.6 | +| C4 | **Valore legale** di firma, marca temporale e conservazione digitale dei libri sociali degli ETS | Legale | RT-5, RT-6 | +| C5 | **Intestazione nel primo anno:** conservazione a norma e firma elettronica avanzata possono essere a nome di Davide per conto dello studio, o devono essere a nome del cliente fin dall'inizio (con costi comunque a carico di Davide)? | Legale | D10 | +| C6 | **Conservazione per ente:** il servizio di riferimento è "uno per partita IVA"; la conservazione va fatta a nome di ogni ente? Molti enti hanno solo il codice fiscale | Legale / fornitore | RT-6, costi §5.2 | +| C7 | **Rendicontazione del bando:** ammissibilità degli strumenti di sviluppo (Claude Max) e dei servizi di produzione pagati da Davide; forma (servizio di hosting o rimborso di abbonamenti) | Commercialista | D10, costi §7.2 | +| C8 | **IVA sui servizi esteri** (reverse charge) | Commercialista | Costi §1 | +| C9 | **Clausola sui prezzi:** adeguamento se nel primo anno i fornitori aumentano i prezzi o i volumi superano le stime | Commercialista / legale | Costi §7.2 | +| C10 | **Contratto di manutenzione:** contenuto, durata, responsabilità di Davide dal secondo anno | Legale | D11 | +| C11 | **Responsabilità come intestatario dei servizi nel primo anno:** contratti con i fornitori, misure di sicurezza, assicurazione RC professionale e cyber | Legale | D10 | --- @@ -107,11 +165,13 @@ Non sono domande per il cliente, e su questi punti serve un parere professionale | Versione | Data | Allineato a | Modifiche | |---|---|---|---| -| 0.2 | 25/09/2026 | `richiesta.md` v0.2 | Prima stesura. Numerata inizialmente 1.0, riportata a 0.2 per allinearla allo schema di versione comune | +| 0.2 | 25/09/2026 | `richiesta.md` v0.2 | Prima stesura (numerata inizialmente 1.0, riportata a 0.2) | +| 0.3 | 27/09/2026 | `richiesta.md` v0.3 | Aggiunti Q23, B1.8, B1.9, verifiche e rischi conseguenti a D10 e D11 | +| 0.3.1 | 27/09/2026 | `richiesta.md` v0.3 | Riorganizzazione: diventa il documento unico di tutto ciò che è aperto. Aggiunta colonna "Perché serve"; Q23 spostata in A1; aggiunta A4 con i passi da confermare del workflow (prima in `workflow.md` §12); aggiunte in A5 le condizioni sui servizi di produzione; rischi riuniti in B3 (prima anche in `richiesta.md` §10); spiegazioni di Q8, Q14, Q19 in B4 (prima in `richiesta.md` §3.3 e §8); verifiche legali riunite nella parte C (prima in B3, in `richiesta.md` §5 e in `costi-ricorrenti.md` §7.2) | --- ## Stato - **Fase corrente:** analisi dei requisiti, domande pronte per il cliente. -- **Decisioni prese:** D1–D9 (vedi `richiesta.md`, §9). -- **Prossimo passo:** incontro con il cliente sulla parte A, partendo da A1. Poi si aggiorna `richiesta.md` alla v1.0 e si chiudono i dubbi della parte B. +- **Decisioni prese:** D1–D11 (`richiesta.md` §7). +- **Prossimo passo:** incontro con il cliente sulla parte A, partendo da A1; in parallelo verifiche della parte C. diff --git a/indice-documenti.md b/indice-documenti.md index 7b5f118..2e49bad 100644 --- a/indice-documenti.md +++ b/indice-documenti.md @@ -21,15 +21,16 @@ Il cliente non indica versioni: ogni consegna si identifica con la data di ricez ### 1.2 Documenti di progetto -| Documento | Ruolo | Versione | Stato | Allineato a | +Ogni informazione sta in **un solo documento**; gli altri la richiamano con il suo codice. + +| Documento | Contenuto (e solo questo) | Versione | Stato | Allineato a | |---|---|---|---|---| -| `richiesta.md` | **Documento base.** Analisi completa della richiesta: requisiti, decisioni, domande, rischi | **0.2** | Bozza | Fonti del 25/09/2026 | -| `richiesta-sintesi.md` | Sintesi di `richiesta.md`, senza perdita di informazioni | **0.2** | Bozza | `richiesta.md` v0.2 | -| `domande-cliente.md` | Domande per il cliente (parte A) e dubbi progettuali interni (parte B) | **0.2** | Bozza | `richiesta.md` v0.2 | -| `workflow.md` | Processi del software, passo per passo, con riferimento ai requisiti | **0.2** | Bozza | `richiesta.md` v0.2 | -| `costi-ricorrenti.md` | Abbonamenti e servizi ricorrenti per 12 mesi (sviluppo, test, produzione), con prezzi di listino e scenari | **0.2** | Bozza | `richiesta.md` v0.2 | -| `indice-documenti.md` | Questo indice | — | — | — | -| `CLAUDE.md` | Istruzioni per Claude: regole, convenzioni, procedura di aggiornamento | — | In uso | Non segue lo schema di versione: si aggiorna quando cambiano regole, documenti o convenzioni | +| `richiesta.md` | **Documento base.** Cosa deve fare il software: moduli, requisiti (RF, RT), dati personali, differenze tra le fonti, decisioni (D) | **0.3.1** | Bozza | Fonti del 25/09/2026 | +| `workflow.md` | Processi del software passo per passo (W), con i riferimenti ai requisiti | **0.3.1** | Bozza | `richiesta.md` v0.3 | +| `domande-cliente.md` | Tutto ciò che è aperto: domande per il cliente (Q), conferme sui processi, dubbi architetturali (B), rischi, verifiche con legale e commercialista (C) | **0.3.1** | Bozza | `richiesta.md` v0.3 | +| `costi-ricorrenti.md` | Costi ricorrenti di sviluppo, test e produzione: prezzi con fonte, scenari, effetti economici delle decisioni | **0.3.1** | Bozza | `richiesta.md` v0.3 | +| `indice-documenti.md` | Versioni in vigore e schema di versione | — | — | — | +| `CLAUDE.md` | Istruzioni per Claude: regole, convenzioni, procedura di aggiornamento | — | In uso | Non segue lo schema di versione | **Dipendenze:** @@ -38,9 +39,8 @@ fonti/AAAA-MM-GG/ (docx, xlsx del cliente) ↓ richiesta.md ← documento base ↓ - ├── richiesta-sintesi.md - ├── domande-cliente.md ├── workflow.md + ├── domande-cliente.md └── costi-ricorrenti.md ``` @@ -65,7 +65,7 @@ fonti/AAAA-MM-GG/ (docx, xlsx del cliente) ### 2.2 Regola di allineamento 1. **`richiesta.md` è il documento base.** Ogni modifica ai requisiti parte da lì. -2. I documenti derivati (sintesi, domande, workflow) **usano le stesse X e Y** della versione di `richiesta.md` a cui sono allineati. La Z è propria di ogni documento. +2. I documenti derivati (workflow, domande, costi) **usano le stesse X e Y** della versione di `richiesta.md` a cui sono allineati. La Z è propria di ogni documento. 3. Un documento derivato con X.Y diversa da `richiesta.md` è **disallineato** e va aggiornato prima di essere usato o inviato. ### 2.3 Cosa si fa a ogni cambio di versione @@ -92,3 +92,5 @@ La versione si legge nell'intestazione e in questo indice. Quando un documento v | 25/09/2026 | `CLAUDE.md` aggiornato da Davide: posizione delle fonti [D] e [X], codici Bn.m, simbolo ⚖️, struttura standard dei documenti, obbligo di versione a ogni modifica, procedura per gli invii al cliente; tolta la sezione "Da non fare" | | 25/09/2026 | Creata la cartella `fonti/2026-09-25/` con le fonti del cliente; aggiornati §1.1 e schema delle dipendenze; aggiornato `CLAUDE.md` (percorsi delle fonti e regole della cartella `fonti/`) | | 27/09/2026 | Aggiunto `costi-ricorrenti.md` (v0.2) in §1.2 e nelle dipendenze; aggiunto il documento alla tabella di `CLAUDE.md` | +| 27/09/2026 | Tutti i documenti di progetto portati a v0.3 per le decisioni D10 e D11 (chi paga e gestisce i servizi di produzione) | +| 27/09/2026 | Riorganizzazione per eliminare le informazioni ripetute: eliminato `richiesta-sintesi.md` (ripeteva `richiesta.md`); `richiesta.md`, `workflow.md`, `domande-cliente.md` e `costi-ricorrenti.md` portati a v0.3.1; descritto in §1.2 il contenuto esclusivo di ogni documento; aggiornato `CLAUDE.md` (elenco documenti, codici Cn) | diff --git a/richiesta-sintesi.md b/richiesta-sintesi.md deleted file mode 100644 index 8f21dba..0000000 --- a/richiesta-sintesi.md +++ /dev/null @@ -1,200 +0,0 @@ -# Richiesta del cliente: sintesi -**Progetto:** Gestionale per enti del Terzo Settore -**Documento:** `richiesta-sintesi.md` (sintesi di `richiesta.md`) -**Versione:** 0.2 · **Data:** 25/09/2026 · **Stato:** Bozza, da validare con il cliente -**Allineato a:** `richiesta.md` v0.2 · **Schema di versione:** vedi `indice-documenti.md` -**Fonti:** **[D]** `funzioni software.docx` · **[X]** `Software.xlsx` -**Documenti collegati:** `richiesta.md` (versione estesa) · `domande-cliente.md` (domande e dubbi progettuali) -**Legenda:** ✅ deciso · ⏳ aperto, da chiedere al cliente · 🔸 ipotesi da confermare - ---- - -## 1. Cos'è il software - -✅ Una **piattaforma web multi-ente**: uno **studio professionale** gestisce molti **enti del Terzo Settore** suoi clienti. Ogni ente vede solo i propri dati, lo studio li vede tutti. Circa **100 utenti** (⏳ numero di enti: Q1; ripartizione degli utenti: Q2). - -**Attori** (✅ **interno = studio**, **esterno = ente**, come in [X]): -- **Studio:** offerte, anagrafiche enti, imputazione contabile, circolari, time sheet; controlla e approva i documenti degli enti. -- **Ente:** inserisce le persone, compila i libri sociali, carica i documenti contabili. -- **Interessati** (non sono utenti): soci, volontari, dipendenti, collaboratori, sostenitori. - -**Flusso:** offerta e firma → attivazione dell'ente → l'ente inserisce e carica, lo studio controlla e imputa → alert, proforma e circolari alle scadenze → output annuali (Modello D, relazione illustrativa, bilancio sociale, progetti). - ---- - -## 2. Moduli - -| # | Modulo | Fase | Chi inserisce | Chi controlla / usa | Stato | -|---|---|---|---|---|---| -| M1 | Gestione cliente | 1 | Studio | Ente (firma, riceve proforma) | Definito | -| M2 | Anagrafica enti | 1 | Studio | Studio | Definito | -| M3 | Persone dell'ente | 1 | Ente | Ente; alimenta M4 e M7 | Definito (dettagli Q8) | -| M4 | Libri sociali | 1 | Ente | Studio approva, poi archiviazione | Definito | -| M5 | Contabilità | 1 | Ente | Studio imputa | Definito | -| M6 | Progettazione | 1 | Ente e studio | Ente e studio | ⏳ Q13, Q19 | -| M7 | Bilancio sociale | 2 | Ente e studio | Ente e studio | ⏳ Q14, Q19 | -| M8 | Circolari | 1 | Studio | Ente | Definito | -| M9 | Valutazione volontariato | 2 | Studio | Studio | Definito (dettagli Q15) | - -La fase viene da [D] ("di base" = fase 1, "aggiuntive" = fase 2), tranne M8, che segue [X]. -**Fase 1:** M1–M6, M8 · **Fase 2:** M7, M9. - ---- - -## 3. Requisiti per modulo - -**M1: Gestione cliente** -- Catalogo di servizi vendibili singolarmente o a pacchetto (⏳ Q3). Preventivi e offerte composti dal catalogo, con modalità di pagamento e scadenze. -- Invio all'ente e firma digitale (⏳ Q4) di offerta, informativa privacy (presa visione) e dati antiriciclaggio. -- Scadenziario dei pagamenti, proforma alle scadenze (⏳ Q5: anche fattura elettronica?), alert allo studio. - -**M2: Anagrafica enti** (la compila lo studio). Campi: -- denominazione, sede, codice fiscale, partita IVA (facoltativa), data di costituzione; -- n°, data e sezione di iscrizione al RUNTS; -- qualifica (ODV, APS, ETS, impresa sociale, SOMS, rete, ente filantropico); -- attività di interesse generale (art. 5 CTS) e attività diverse (art. 6 CTS); -- raccolta fondi continuativa commerciale e ordinaria (sì/no); -- n° soci e n° volontari. 🔸 Inseriti a mano (Q7); si mostra accanto il conteggio calcolato dalle anagrafiche, come controllo. - -**M3: Persone dell'ente** (le inserisce l'ente) -- Anagrafica e contatti per ogni persona. -- Categorie citate nei due documenti: soci, aderenti, tesserati, volontari, volontari occasionali, dipendenti/lavoratori, collaboratori, sostenitori, partecipanti. -- ⏳ Q8: quali categorie servono davvero, quali dati per ciascuna, se una persona può avere più ruoli. - -**M4: Libri sociali** -- **Libro soci:** data della delibera di ammissione, anagrafica, contatti, data di cessazione, note, firma dell'operatore. -- **Registro volontari:** data di inizio, anagrafica, contatti, data di fine, note, firma dell'operatore. -- Libri dei verbali dell'assemblea dei soci e dell'organo di amministrazione. -- Marca temporale e conservazione digitale (⏳ Q9). -- Flusso: l'ente compila → lo studio controlla → stampa e archiviazione definitiva. - -**M5: Contabilità** -- Alert all'ente per caricare i documenti. ✅ Calendario uguale per tutti gli enti, ma modificabile. ⏳ Q12: si modifica solo il calendario comune o anche quello del singolo ente? -- Caricamento di: estratti conto trimestrali in Excel o PDF (⏳ Q10), prima nota cassa trimestrale in Excel, rendiconti delle raccolte fondi occasionali. -- ✅ Lo studio imputa ogni movimento **direttamente sulle voci del Modello D**. Le voci stanno in una tabella configurabile, così un cambio di legge non richiede modifiche al codice. -- Output: rendiconto per cassa su Modello D; relazione illustrativa guidata su modelli preimpostati (attività, progetti), scritta dall'ente. - -**M6: Progettazione** -- Procedura guidata per sezioni: contesto, bisogni, idea, obiettivi, attività, risorse, cronoprogramma, costi, piano economico-finanziario. -- Modello standard adattabile ai formulari dei bandi. -- ⏳ Q13: lo schema di dettaglio **non esiste ancora**. Chi lo prepara, in che formato si esporta, l'adattamento ai formulari è manuale o automatico? - -**M7: Bilancio sociale** (fase 2) -- Procedura guidata che riusa in automatico i dati già presenti nel sistema. -- Sezioni: lettera del presidente, dati standard, identità dell'ente, stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo. -- ⏳ Q14: nell'Excel la descrizione è copiata da M6. Vanno confermati le sezioni e l'uso delle linee guida ministeriali. - -**M6 e M7, divisione del lavoro (⏳ Q19).** "Entrambi" può voler dire tre cose, dalla più semplice alla più costosa: -- (a) l'ente scrive, lo studio rivede; -- (b) sezioni divise tra ente e studio; -- (c) modifica contemporanea dello stesso documento. - -Senza risposta, si stima su (a) come assunzione dichiarata; (b) e (c) si quotano come varianti. - -**M8: Circolari** -- Circolari agli enti su scadenze amministrative, contabili e fiscali. -- ✅ Invio **via email e nell'app**. Costa più di un solo canale, ma non il doppio: il servizio email serve già per gli alert. In più lo studio vede quali circolari l'ente ha letto. - -**M9: Valutazione volontariato** (fase 2) -- ✅ Lo studio inserisce il time sheet di volontari e dipendenti: attività, ore, ruolo, valore economico di ogni ora. -- ⏳ Q15: chi fissa le tariffe orarie e in che forma l'ente manda le ore allo studio. - ---- - -## 4. Requisiti trasversali - -| Area | Requisito | -|---|---| -| Accessi | Dati separati per ente; ruoli e permessi distinti per studio ed ente | -| Processi | Un unico flusso di approvazione (bozza → revisione → approvato → archiviato); notifiche via email e nell'app | -| Documenti | Generazione di PDF/Word da modelli; importazione di Excel/PDF; firma elettronica (⏳ Q4); marca temporale e conservazione (⏳ Q9) | -| Tracciabilità | Registro di chi ha fatto cosa e quando (valore probatorio + GDPR) | -| Piattaforma | ✅ Web, da computer: nessun requisito per smartphone o accessibilità (va scritto nel preventivo) · ✅ nessuna preferenza di hosting, si raccomanda l'UE per il GDPR · ✅ nessuna migrazione: gli enti inseriscono a mano i dati esistenti (da dire al cliente, import da Excel quotabile come opzione) | - ---- - -## 5. Dati personali - -- **Chi è coinvolto:** anagrafiche di soci, volontari, dipendenti, collaboratori e sostenitori; dati antiriciclaggio dei legali rappresentanti (D.Lgs. 231/2007); ore di lavoro; movimenti bancari. -- **Dati particolari (art. 9 GDPR):** l'iscrizione ad alcuni enti (religiosi, politici, sindacali, di pazienti) può rivelarli. -- **Ipotesi sui ruoli:** - - lo studio è titolare per i propri clienti e per l'antiriciclaggio, e responsabile del trattamento (art. 28) per i dati degli enti; - - gli enti sono titolari dei dati delle proprie persone; - - chi sviluppa il software e l'hosting sono sub-responsabili. -- ⚖️ Da far verificare a un **legale** e a un **commercialista**: ruoli privacy, conservazione dei dati antiriciclaggio, valore legale di firma, marca temporale e conservazione dei libri, rendicontazione del bando. - ---- - -## 6. Differenze tra [D] e [X] - -| Punto | Come si risolve | -|---|---| -| Circolari: fase 2 in [D], dentro Gestione cliente in [X] | ✅ Si segue [X]: fase 1 | -| Scadenziario e proforma: solo in [X] | ✅ Inclusi (perimetro: Q5) | -| Time sheet: chi inserisce non è indicato in [D], operatore interno in [X] | ✅ Si segue [X]: lo studio | -| Categorie di persone diverse nei due documenti | ⏳ Q8 | -| Bilancio sociale: sezioni diverse, descrizione copiata in [X] | ⏳ Q14 | -| Campi di anagrafica ente, libri sociali, contabilità, sezioni della progettazione, valorizzazione oraria | 🔸 Unione dei due documenti (conferma: Q20) | - ---- - -## 7. Decisioni prese - -| # | Decisione | -|---|---| -| D1 | Interno = studio, esterno = ente | -| D2 | Piattaforma multi-ente | -| D3 | Circolari in fase 1 | -| D4 | Il time sheet lo inserisce lo studio | -| D5 | Circolari via email e nell'app | -| D6 | Imputazione sulle voci del Modello D | -| D7 | Scadenze uguali per tutti, modificabili | -| D8 | Nessuna migrazione di dati | -| D9 | Nessun requisito su smartphone, accessibilità, hosting | - -Le decisioni vengono da Davide e vanno approvate dal cliente con la v1.0 (Q18). -🔸 **Ipotesi da confermare:** n° soci e volontari inseriti a mano (Q7); unione dei requisiti dei due documenti (Q20). - ---- - -## 8. Punti aperti - -Il testo completo delle domande è in `domande-cliente.md`. - -- **Prioritari per la stima:** - - Q1 n° di enti · Q2 ripartizione degli utenti · Q4 tipo di firma · Q5 proforma o fattura elettronica; - - Q9 conservazione dei libri · Q10 estratti conto PDF · Q19 divisione del lavoro in M6 e M7. -- **Contenuto dei moduli:** - - Q3 catalogo dei servizi · Q7 conteggi manuali · Q8 categorie di persone e ruoli · Q12 scadenze per singolo ente; - - Q13 schema del progetto · Q14 bilancio sociale · Q15 tariffe orarie e invio delle ore. -- **Organizzazione:** Q18 approvazione e gestione delle modifiche · Q20 unione dei requisiti. - ---- - -## 9. Rischi - -| Rischio | Mitigazione | -|---|---| -| Scope creep su M6 (schema inesistente, divisione del lavoro non definita) e su M7 (descritto solo per titoli) | Assunzioni dichiarate nel preventivo, schema consegnato prima dello sviluppo, fase 2 stimata a parte, procedura per le modifiche (Q18) | -| Dipendenza dal cliente (schema, modelli di verbale e circolare, estratti conto di esempio, tariffe orarie) | Elenco dei materiali con date di consegna nel preventivo | -| Richiesta di importazione dati a progetto avviato | Dirlo subito; import da Excel come voce opzionale | -| Privacy e sicurezza (molte persone, possibili dati art. 9, antiriciclaggio) | Privacy by design, DPA, hosting UE, verifica legale | -| Valore legale dei documenti | Fornitori qualificati per firma, marca temporale e conservazione | -| Estratti conto in PDF di formati diversi | Fase 1: import Excel/CSV e archivio del PDF; lettura automatica come evoluzione | -| Norme che cambiano (Modello D, bilancio sociale, RUNTS) | Voci e modelli configurabili | -| Rendicontazione del bando | Voci chiare e verificabili, validate dal commercialista | - ---- - -## Registro delle modifiche - -| Versione | Data | Allineato a | Modifiche | -|---|---|---|---| -| 0.2 | 25/09/2026 | `richiesta.md` v0.2 | Prima stesura: sintesi completa di `richiesta.md` v0.2 | - ---- - -## Stato -- **Fase corrente:** analisi dei requisiti (v0.2). -- **Decisioni prese:** D1–D9. -- **Prossimo passo:** incontro con il cliente sulle domande prioritarie, poi v1.0 dei requisiti, architettura e stima. diff --git a/richiesta.md b/richiesta.md index c5db6c8..395e12d 100644 --- a/richiesta.md +++ b/richiesta.md @@ -1,141 +1,66 @@ -# Analisi della richiesta del cliente +# Richiesta del cliente **Progetto:** Gestionale per enti del Terzo Settore **Documento:** `richiesta.md` (documento base: gli altri documenti si allineano a questo) -**Versione:** 0.2 · **Data:** 25/09/2026 · **Stato:** Bozza, da validare con il cliente -**Schema di versione:** vedi `indice-documenti.md` -**Fonti analizzate:** -- **[D]** `funzioni software.docx`: descrizione testuale delle funzioni, divise in "di base indispensabili" e "aggiuntive" -- **[X]** `Software.xlsx`: tabella Moduli / Funzioni / Contenuti / Operatore / Note +**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare con il cliente +**Allineato a:** fonti del cliente del 25/09/2026 · **Schema di versione:** vedi `indice-documenti.md` -**Novità rispetto alla v0.1:** vedi il registro delle modifiche in fondo al documento. +**Fonti:** +- **[D]** `fonti/2026-09-25/funzioni software.docx`: funzioni richieste, divise in "di base indispensabili" e "aggiuntive" +- **[X]** `fonti/2026-09-25/Software.xlsx`: tabella Moduli / Funzioni / Contenuti / Operatore / Note + +**Cosa contiene:** cosa deve fare il software e cosa è stato deciso. +**Dove trovare il resto:** processi passo per passo in `workflow.md` · domande aperte, dubbi architetturali, rischi e verifiche legali in `domande-cliente.md` · costi in `costi-ricorrenti.md`. + +**Legenda:** ✅ deciso · ⏳ aperto (domanda in `domande-cliente.md`) · 🔸 ipotesi da confermare --- -## 1. Scopo del documento +## 1. Quadro generale -Il documento riordina le due richieste del cliente in un'unica descrizione lineare del software. Serve a: +### 1.1 Modello di business -1. capire **cosa deve fare** il programma, modulo per modulo; -2. tenere traccia di **cosa è deciso** e **cosa è ancora aperto**; -3. preparare le **domande da fare al cliente** prima di stimare tempi e costi. +✅ **Piattaforma multi-ente (D2):** uno **studio professionale** usa il software per gestire **molti enti del Terzo Settore** suoi clienti. Ogni ente vede solo i propri dati, lo studio li vede tutti (RT-1). ⏳ Numero di enti: Q1. -Qui non si fanno scelte tecniche e non si stimano costi. Quelle attività vengono dopo, sui requisiti validati. +### 1.2 Attori -**Legenda usata nel documento:** -- ✅ = deciso -- ⏳ = aperto, da chiedere al cliente -- 🔸 = ipotesi di lavoro, da confermare con il cliente +✅ **Terminologia (D1):** le due fonti usano "interno" con significati diversi. Qui, come in [X], **interno = studio** ed **esterno = ente**. ---- - -## 2. Il quadro generale: chi usa il software e perché - -### 2.1 Modello di business - -✅ Il software è una **piattaforma multi-ente**: uno **studio professionale** la usa per gestire **molti enti del Terzo Settore** suoi clienti. Di conseguenza ogni ente deve vedere solo i propri dati, mentre lo studio li vede tutti (RT-1). - -⏳ Resta da sapere **quanti enti** saranno gestiti (Q1). - -### 2.2 Attori - -✅ **Terminologia:** i due documenti usano "interno" con significati diversi. In questo documento, come in [X], **interno = studio** ed **esterno = ente**. - -| Attore | Chi è | Cosa fa (in sintesi) | +| Attore | Chi è | Cosa fa | |---|---|---| -| **Studio** (operatore interno) | Professionista dello studio committente | Acquisisce i clienti, gestisce offerte, anagrafiche enti, imputazione contabile, circolari, time sheet; controlla e approva i documenti degli enti | +| **Studio** (operatore interno) | Professionista dello studio committente | Offerte, anagrafiche enti, imputazione contabile, circolari, time sheet; controlla e approva i documenti degli enti | | **Ente** (operatore esterno) | Referente dell'ente cliente | Inserisce soci, volontari e lavoratori, compila i libri sociali, carica i documenti contabili | -| **Interessati** (non utenti) | Soci, volontari, dipendenti, collaboratori, sostenitori… | Sono le persone di cui si trattano i dati. Non accedono al sistema | - -### 2.3 Flusso complessivo - -``` -1. ACQUISIZIONE Lo studio prepara l'offerta → l'ente firma (offerta + privacy + antiriciclaggio) - ↓ -2. ATTIVAZIONE ENTE Lo studio registra l'anagrafica dell'ente → l'ente ottiene l'accesso - ↓ -3. GESTIONE ORDINARIA L'ente inserisce le persone, compila i libri sociali e carica i documenti contabili - Lo studio controlla, approva, imputa e registra i time sheet - ↓ -4. SCADENZE Il sistema invia all'ente alert (documenti da caricare), proforma (pagamenti) - e circolari (adempimenti) - ↓ -5. OUTPUT ANNUALI Rendiconto di cassa (Modello D), relazione illustrativa, bilancio sociale, progetti -``` +| **Interessati** (non utenti) | Soci, volontari, dipendenti, collaboratori, sostenitori… | Persone di cui si trattano i dati; non accedono al sistema | --- -## 3. Mappa dei moduli e priorità +## 2. Moduli -### 3.1 Come leggere la mappa - -Il software è diviso in **9 moduli**. Ogni modulo copre un'area di lavoro dello studio o dell'ente. Per ogni modulo la tabella indica: - -- **Fase**: quando si sviluppa. **Fase 1** = funzioni che [D] chiama "di base indispensabili". **Fase 2** = funzioni che [D] chiama "aggiuntive". Fa eccezione M8: [D] lo mette in fase 2, ma si è deciso di seguire [X] e portarlo in fase 1. -- **Chi inserisce i dati**: chi lavora materialmente nel modulo. -- **Chi controlla / usa il risultato**: chi verifica o riceve l'output del modulo. -- **Stato**: *Definito* se non ci sono dubbi che cambiano la struttura del modulo; *Da chiarire* se c'è un dubbio aperto. - -### 3.2 Mappa +**Fase:** fase 1 = funzioni che [D] chiama "di base indispensabili"; fase 2 = funzioni "aggiuntive". Eccezione: M8 in fase 1 (D3). +**Stato:** *Definito* se nessun dubbio aperto ne cambia la struttura; altrimenti è indicata la domanda. | # | Modulo | Cosa fa | Fase | Chi inserisce i dati | Chi controlla / usa il risultato | Stato | |---|---|---|---|---|---|---| | M1 | Gestione cliente e contrattualistica | Offerte, firme, scadenziario e proforma dello studio verso gli enti | 1 | Studio | Ente (firma l'offerta, riceve i proforma) | Definito (dettagli: Q3, Q4, Q5) | | M2 | Anagrafica enti | Scheda di ogni ente cliente | 1 | Studio | Studio | Definito | -| M3 | Anagrafiche collegate | Registro di soci, volontari, dipendenti e altre persone dell'ente | 1 | Ente | Ente. I dati alimentano M4 e M7 | Definito (dettagli: Q8) | +| M3 | Anagrafiche collegate | Registro di soci, volontari, dipendenti e altre persone dell'ente | 1 | Ente | Ente; i dati alimentano M4 e M7 | Definito (dettagli: Q8) | | M4 | Libri sociali | Libro soci, registro volontari, verbali, con marca temporale | 1 | Ente | Studio controlla, poi stampa e archiviazione definitiva | Definito (dettagli: Q9) | | M5 | Contabilità | Documenti contabili, Modello D e relazione illustrativa | 1 | Ente (carica documenti, scrive la relazione) | Studio (imputa i movimenti sulle voci del Modello D) | Definito (dettagli: Q10) | -| M6 | Progettazione | Stesura guidata di progetti per bandi | 1 | Ente e studio | Ente e studio | **Da chiarire** (dubbio C, Q13) | -| M7 | Rendicontazione sociale | Stesura guidata del bilancio sociale | 2 | Ente e studio | Ente e studio | **Da chiarire** (dubbio C, Q14) | -| M8 | Circolari | Comunicazioni dello studio agli enti su scadenze e adempimenti | 1 | Studio | Ente (le riceve via email e nell'app) | Definito | +| M6 | Progettazione | Stesura guidata di progetti per bandi | 1 | Ente e studio | Ente e studio | ⏳ Q13, Q19 | +| M7 | Rendicontazione sociale | Stesura guidata del bilancio sociale | 2 | Ente e studio | Ente e studio | ⏳ Q14, Q19 | +| M8 | Circolari | Comunicazioni dello studio agli enti su scadenze e adempimenti | 1 | Studio | Ente (via email e nell'app) | Definito | | M9 | Valutazione volontariato | Time sheet di volontari e dipendenti, con valorizzazione delle ore | 2 | Studio | Studio | Definito (dettagli: Q15) | -**In sintesi:** -- **Fase 1:** M1, M2, M3, M4, M5, M6, M8. -- **Fase 2:** M7, M9. - -### 3.3 Dubbi sulla mappa - -#### Dubbio A: in quale fase vanno le circolari (M8)? ✅ Risolto - -[D] le mette in fase 2 ("funzioni aggiuntive"), [X] dentro "Gestione cliente", quindi in fase 1. -**Decisione:** si segue [X]. Le circolari sono in **fase 1** e vengono inviate **sia via email sia dentro l'app** (vedi M8 al §4). - -#### Dubbio B: chi inserisce il time sheet (M9)? ✅ Risolto - -[D] non lo dice, [X] indica l'operatore interno. -**Decisione:** si segue [X]. Il time sheet lo inserisce **lo studio**. -**Conseguenze:** non serve un nuovo tipo di utente per volontari e dipendenti. Nasce però una **dipendenza dal cliente**: lo studio deve ricevere le ore dagli enti, in una forma ancora da definire (Q15). - -#### Dubbio C: cosa significa "entrambi" in progettazione e bilancio sociale (M6, M7)? ⏳ Aperto - -| | Cosa dice | -|---|---| -| [D] | Il software "guida l'operatore". Non dice quale operatore | -| [X] | Operatore "entrambi", ma non dice chi fa cosa | - -**Il dubbio:** i documenti dicono che ente e studio lavorano entrambi su progetti e bilancio sociale, ma non dicono **come si dividono il lavoro**. - -**Perché conta:** "entrambi" può voler dire modi di lavorare molto diversi, con costi di sviluppo molto diversi: - -| Opzione | Come funziona | Impatto sullo sviluppo | -|---|---|---| -| 1. Redazione e revisione | L'ente scrive, lo studio rivede e approva (come per i libri sociali, M4) | Il più semplice: riusa il flusso di approvazione già previsto (RT-3) | -| 2. Sezioni divise | Alcune sezioni le compila l'ente, altre lo studio (es. il piano economico-finanziario) | Medio: servono permessi per singola sezione | -| 3. Modifica contemporanea | Ente e studio lavorano sullo stesso documento nello stesso momento | Il più costoso: gestione dei conflitti e aggiornamento in tempo reale | - -La risposta può essere diversa per M6 e M7. → Domanda **Q19**. - -**Finché il cliente non risponde:** M6 e M7 non si possono stimare con precisione. Se serve presentare comunque il preventivo, conviene stimarli sull'opzione 1 e **scriverlo nel preventivo come assunzione**. Le opzioni 2 e 3 andrebbero quotate come variante. +**Fase 1:** M1, M2, M3, M4, M5, M6, M8 · **Fase 2:** M7, M9. --- -## 4. Requisiti funzionali per modulo +## 3. Requisiti funzionali per modulo -Legenda: **RF** = requisito funzionale · **Fonte**: [D], [X] o *Decisione* (vedi §9). +**RF** = requisito funzionale · **Fonte:** [D], [X] o decisione (Dn, §7). ### M1: Gestione cliente e contrattualistica (fase 1) -**Obiettivo:** gestire il rapporto commerciale tra lo studio e l'ente, dall'offerta all'incasso. +Gestire il rapporto commerciale tra studio ed ente, dall'offerta all'incasso. | ID | Requisito | Fonte | |---|---|---| @@ -152,7 +77,7 @@ Legenda: **RF** = requisito funzionale · **Fonte**: [D], [X] o *Decisione* (ved ### M2: Anagrafica enti (fase 1) -**Obiettivo:** scheda completa di ciascun ente cliente. La compila lo studio. +Scheda completa di ciascun ente cliente, compilata dallo studio. | ID | Campo | Fonte | Note | |---|---|---|---| @@ -168,23 +93,20 @@ Legenda: **RF** = requisito funzionale · **Fonte**: [D], [X] o *Decisione* (ved | RF-2.10 | Eventuali attività diverse (art. 6 CTS) | D + X | Selezione multipla / testo | | RF-2.11 | Raccolta fondi continuativa con modalità commerciali (sì/no) | D | | | RF-2.12 | Raccolta fondi continuativa ordinaria (sì/no) | D | | -| RF-2.13 | Numero soci | D + X | 🔸 Inserito **a mano** (Q7) | -| RF-2.14 | Numero volontari | D + X | 🔸 Inserito **a mano** (Q7) | +| RF-2.13 | Numero soci | D + X | 🔸 Inserito a mano (Q7) | +| RF-2.14 | Numero volontari | D + X | 🔸 Inserito a mano (Q7) | -> 🔸 **Q7, ipotesi di lavoro:** numero soci e numero volontari si inseriscono a mano. Da confermare con il cliente. -> **Da sapere:** il software avrà comunque l'elenco dei soci e dei volontari (M3). Con l'inserimento manuale i due numeri possono non coincidere con quegli elenchi. Una soluzione che non complica lo sviluppo è mostrare accanto al numero inserito anche il conteggio calcolato, come controllo. +### M3: Anagrafiche collegate (fase 1) -### M3: Anagrafiche collegate, cioè le persone dell'ente (fase 1) - -**Obiettivo:** registro delle persone legate a ciascun ente. Lo compila l'ente. +Registro delle persone legate a ciascun ente, compilato dall'ente. | ID | Requisito | Fonte | |---|---|---| | RF-3.1 | Inserimento dei dati anagrafici delle persone collegate all'ente | D + X | -| RF-3.2 | Categorie di persona ⏳ Q8: elenco da definire (vedi sotto) | D + X | -| RF-3.3 | Una persona può appartenere a più categorie ⏳ Q8 | *da confermare* | +| RF-3.2 | Categorie di persona: elenco definitivo da stabilire ⏳ Q8 | D + X | +| RF-3.3 | Una persona può appartenere a più categorie ⏳ Q8 | 🔸 | -**Le categorie citate nei due documenti:** +Categorie citate nelle fonti: | Categoria | [D] | [X] | |---|---|---| @@ -198,11 +120,9 @@ Legenda: **RF** = requisito funzionale · **Fonte**: [D], [X] o *Decisione* (ved | Sostenitori | ✔ | | | Partecipanti | ✔ | | -Le domande da fare al cliente su questo modulo sono spiegate in Q8 (§8). - ### M4: Libri sociali (fase 1) -**Obiettivo:** tenuta digitale dei libri obbligatori dell'ente, con valore probatorio. +Tenuta digitale dei libri obbligatori dell'ente, con valore probatorio. | ID | Requisito | Fonte | |---|---|---| @@ -212,67 +132,51 @@ Le domande da fare al cliente su questo modulo sono spiegate in Q8 (§8). | RF-4.4 | **Libro verbali organo di amministrazione**: redazione dei verbali | D + X | | RF-4.5 | **Marcatura temporale** dei documenti | D + X | | RF-4.6 | **Conservazione digitale** dei documenti ⏳ Q9 | D | -| RF-4.7 | **Flusso di approvazione**: l'ente compila, lo studio controlla, poi avvengono stampa e archiviazione definitiva | D + X | +| RF-4.7 | **Flusso di approvazione**: l'ente compila, lo studio controlla, poi stampa e archiviazione definitiva | D + X | ### M5: Contabilità (fase 1) -**Obiettivo:** raccogliere i documenti contabili dell'ente e produrre il rendiconto di cassa e la relazione illustrativa. +Raccolta dei documenti contabili dell'ente, rendiconto di cassa e relazione illustrativa. | ID | Requisito | Fonte | |---|---|---| -| RF-5.1 | **Alert all'ente** alle scadenze, per ricordare il caricamento dei documenti. Calendario delle scadenze **uguale per tutti gli enti, ma modificabile** ⏳ vedi nota | D + *Decisione* | +| RF-5.1 | **Alert all'ente** alle scadenze per il caricamento dei documenti; calendario **uguale per tutti gli enti, ma modificabile** ⏳ Q12 | D + D7 | | RF-5.2 | Caricamento degli **estratti conto bancari** trimestrali (Excel o PDF) ⏳ Q10 | D + X | | RF-5.3 | Caricamento della **prima nota cassa** trimestrale (Excel) | D + X | | RF-5.4 | Caricamento dei **rendiconti delle raccolte fondi pubbliche occasionali** | D | -| RF-5.5 | **Imputazione contabile dei singoli movimenti**, fatta dallo studio **direttamente sulle voci del Modello D** (nessun piano dei conti più dettagliato) | X + *Decisione* | -| RF-5.6 | Elaborazione dei dati per produrre il **rendiconto per cassa su Modello D** (schema ministeriale) | D | +| RF-5.5 | **Imputazione contabile dei singoli movimenti**, fatta dallo studio **direttamente sulle voci del Modello D** | X + D6 | +| RF-5.6 | Elaborazione dei dati per il **rendiconto per cassa su Modello D** (schema ministeriale) | D | | RF-5.7 | **Relazione illustrativa** guidata su modelli preimpostati (attività dell'anno, progetti finanziati e realizzati), da allegare al bilancio | D | -> **Nota su RF-5.1:** "modificabile" può voler dire due cose diverse: -> - (a) lo studio può modificare il calendario comune, e la modifica vale per tutti gli enti; -> - (b) oltre al calendario comune, lo studio può cambiare le scadenze di un singolo ente. -> -> La (b) comprende la (a) e costa un po' di più. Va precisato quale delle due serve (Q12). - -> **Conseguenza della scelta del Modello D (RF-5.5):** il modello dati della contabilità si semplifica, perché le voci sono fissate dallo schema ministeriale. Se il Ministero modifica lo schema, le voci vanno aggiornate: per questo conviene tenerle in una tabella configurabile, non scritte nel codice. - ### M6: Progettazione (fase 1) -**Obiettivo:** guidare la stesura di un progetto (per bandi) secondo un modello standard, facilmente adattabile ai formulari dei vari enti erogatori. +Stesura guidata di un progetto per bandi, secondo un modello standard adattabile ai formulari degli enti erogatori. | ID | Requisito | Fonte | |---|---|---| | RF-6.1 | Procedura guidata, a sezioni, per la stesura del progetto | D + X | -| RF-6.2 | Sezioni (unione di [D] e [X]): **analisi del contesto, analisi dei bisogni, idea, obiettivi, attività, risorse, cronoprogramma, costi, piano economico-finanziario** | D + X | +| RF-6.2 | Sezioni: **analisi del contesto, analisi dei bisogni, idea, obiettivi, attività, risorse, cronoprogramma, costi, piano economico-finanziario** | D + X | | RF-6.3 | Modello standard **convertibile sui formulari** degli enti erogatori ⏳ Q13 | X | -| RF-6.4 | Lavoro condiviso tra ente e studio ⏳ dubbio C, Q19 | X | -| RF-6.5 | Schema di dettaglio del progetto: **non esiste ancora** ("sarà impostato nel dettaglio") | D + *Risposta Q13* | - -> **Attenzione:** lo schema del progetto non è disponibile. Finché non esiste, il modulo M6 è solo un elenco di sezioni. È il punto con il **rischio di scope creep più alto** della fase 1 (vedi §10). Serve sapere chi lo prepara e quando (Q13). +| RF-6.4 | Lavoro condiviso tra ente e studio ⏳ Q19 | X | +| RF-6.5 | Schema di dettaglio del progetto: **non esiste ancora** ("sarà impostato nel dettaglio"; confermato nella risposta a Q13) ⏳ Q13 | D | ### M7: Rendicontazione sociale (fase 2) -**Obiettivo:** raccolta guidata dei dati per il bilancio sociale, riusando automaticamente i dati già presenti nel sistema. +Raccolta guidata dei dati per il bilancio sociale, riusando i dati già presenti nel sistema. | ID | Requisito | Fonte | |---|---|---| | RF-7.1 | Procedura guidata per redigere il bilancio sociale | D + X | | RF-7.2 | **Estrazione automatica** dei dati già presenti (anagrafica ente, soci, volontari, dati economici…) | D | -| RF-7.3 | Sezioni ⏳ Q14: **lettera del presidente** [X], **serie di dati standard** [D], identità dell'ente, principali stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo | D + X | -| RF-7.4 | Lavoro condiviso tra ente e studio ⏳ dubbio C, Q19 | X | +| RF-7.3 | Sezioni: **lettera del presidente** [X], **serie di dati standard** [D], identità dell'ente, principali stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo ⏳ Q14 | D + X | +| RF-7.4 | Lavoro condiviso tra ente e studio ⏳ Q19 | X | ### M8: Circolari (fase 1) | ID | Requisito | Fonte | |---|---|---| | RF-8.1 | Invio di circolari agli enti sulle scadenze di adempimenti **amministrativi, contabili e fiscali** | D + X | -| RF-8.2 | Canale di invio: **email e area comunicazioni dentro l'app** | *Decisione* | - -> **Quanto complica "entrambi" rispetto a un solo canale.** La circolare si scrive una volta sola e il software la manda su due canali. Ogni canale ha però un suo costo: -> - **Email:** serve un servizio di invio email (con un piccolo costo ricorrente), la configurazione del dominio dello studio perché le email non finiscano in spam, e la gestione delle email non recapitate. È molto probabile che l'email serva comunque per gli alert di M1 e M5 (RT-4), quindi questo costo c'è già. -> - **Nell'app:** serve un'area "comunicazioni" per l'ente, con lo stato letta/non letta. È un pezzo di sviluppo in più, non grande. -> -> Quindi "entrambi" costa più di un solo canale, ma non il doppio. In più dà allo studio una traccia di cosa l'ente ha letto, che la sola email non dà in modo affidabile. +| RF-8.2 | Canale di invio: **email e area comunicazioni dentro l'app**, con stato di lettura | D5 | ### M9: Valutazione volontariato (fase 2) @@ -281,40 +185,37 @@ Le domande da fare al cliente su questo modulo sono spiegate in Q8 (§8). | RF-9.1 | Inserimento del **time sheet** di volontari **e dipendenti** | D | | RF-9.2 | Per ogni registrazione: tipo di attività, ore dedicate, ruolo/qualifica | D + X | | RF-9.3 | **Valorizzazione economica** di ogni ora in base all'attività ⏳ Q15 | D | -| RF-9.4 | L'inserimento è fatto dallo **studio** | X + *Decisione* | +| RF-9.4 | L'inserimento è fatto dallo **studio** | X + D4 | --- -## 5. Requisiti trasversali (valgono per tutti i moduli) +## 4. Requisiti trasversali -Questi requisiti non sono scritti come moduli nei documenti, ma **derivano da quanto richiesto**. Hanno un forte impatto sull'architettura e sui costi. +Non sono scritti come moduli nelle fonti, ma derivano da quanto richiesto. | ID | Requisito | Da dove deriva | |---|---|---| -| RT-1 | **Separazione dei dati tra enti**: ogni ente vede solo i propri dati, lo studio li vede tutti | Piattaforma multi-ente (§2.1) | +| RT-1 | **Separazione dei dati tra enti**: ogni ente vede solo i propri dati, lo studio li vede tutti | D2 | | RT-2 | **Ruoli e permessi** distinti per studio ed ente | Colonna "Operatore" di [X] | -| RT-3 | **Flussi di approvazione** (bozza → in revisione → approvato/respinto → archiviato) | M4, e probabilmente M5–M7 | -| RT-4 | **Sistema di notifiche**: email + notifiche nell'app | M1, M5, M8 | +| RT-3 | **Flusso di approvazione** comune (bozza → in revisione → approvato/respinto → archiviato) | M4, e probabilmente M5–M7 | +| RT-4 | **Notifiche**: email + notifiche nell'app | M1, M5, M8 | | RT-5 | **Firma elettronica** dei documenti ⏳ Q4 | M1, M4 | | RT-6 | **Marca temporale** e **conservazione digitale** ⏳ Q9 | M4 | | RT-7 | **Generazione documenti** (PDF/Word) da modelli: offerte, verbali, libri, Modello D, relazioni, progetti | M1, M4–M7 | | RT-8 | **Importazione file** (Excel, PDF) per i documenti contabili | M5 | | RT-9 | **Registro delle operazioni** (audit trail): chi ha fatto cosa e quando | Valore probatorio dei libri + GDPR | -| RT-10 | **Conformità GDPR** (vedi §6) | Dati personali di soci, volontari, dipendenti, clienti | +| RT-10 | **Conformità GDPR** (§5) | Dati personali di soci, volontari, dipendenti, clienti | | RT-11 | Dimensionamento: circa **100 utenti** ⏳ Q1, Q2 | Contesto di progetto | -| RT-12 | **Applicazione web** usata da computer. Nessun requisito specifico per smartphone o accessibilità | *Risposta Q17* | -| RT-13 | **Hosting:** il cliente non ha preferenze. Per il GDPR si raccomanda comunque un hosting nell'Unione Europea | *Risposta Q17* + §6 | -| RT-14 | **Nessuna migrazione di dati** all'avvio: il sistema parte vuoto | *Risposta Q16* | - -> **Nota su RT-12:** "nessun requisito" per smartphone non vuol dire che dallo smartphone il software non si apra. Vuol dire solo che non si progetta e non si collauda per quell'uso. Conviene scriverlo nel preventivo, per evitare contestazioni dopo. - -> **Nota su RT-14:** senza migrazione, ogni ente deve inserire a mano i soci e i volontari che ha già. Per enti con molti soci è un lavoro lungo, e potrebbe tradursi in una richiesta di importazione fatta a progetto avviato. Conviene dirlo al cliente adesso. +| RT-12 | **Applicazione web** usata da computer; nessun requisito per smartphone o accessibilità | D9 | +| RT-13 | **Hosting nell'Unione Europea** (il cliente non ha preferenze; l'UE è richiesta dal GDPR) | D9 + §5 | +| RT-14 | **Nessuna migrazione di dati** all'avvio: il sistema parte vuoto | D8 | +| RT-15 | **Trasferibilità dei servizi di produzione:** a fine primo anno server, dominio, backup, email, firma, marche temporali ed eventuale conservazione passano al cliente senza interruzioni né perdita di dati; fornitori che permettono il trasferimento di account o contratto; documento di consegna con accessi, configurazioni e procedure | D10, D11 | --- -## 6. Dati personali: cosa tratta il software +## 5. Dati personali trattati -Il sistema tratta **molti dati personali di persone fisiche che non sono utenti del software**. Il tema va impostato da subito, perché condiziona architettura, hosting e contratti. +Il sistema tratta **molti dati personali di persone che non sono utenti del software**. | Dato | Di chi | Modulo | Nota | |---|---|---|---| @@ -324,142 +225,52 @@ Il sistema tratta **molti dati personali di persone fisiche che non sono utenti | Movimenti bancari e di cassa | Ente (possono contenere nomi di persone) | M5 | | | **Possibili categorie particolari (art. 9 GDPR)** | Soci | M3 | L'adesione a certi enti (religiosi, politici, sindacali, di pazienti) può rivelare di per sé dati particolari | -**Ruoli privacy (ipotesi da far verificare a un legale):** +**Ruoli privacy (🔸 ipotesi, da verificare: `domande-cliente.md` C1):** - lo **studio** è *titolare* per i dati dei propri clienti e per l'antiriciclaggio; -- lo **studio** è *responsabile del trattamento* (art. 28 GDPR) per i dati dei soci e dei volontari degli enti, di cui gli **enti** sono titolari; -- **chi sviluppa e gestisce il software** (e il fornitore di hosting) potrebbe essere *sub-responsabile*. - -> ⚖️ Ruoli privacy, durata di conservazione dei dati antiriciclaggio, valore legale di firma, marca temporale e conservazione dei libri sociali vanno **fatti verificare da un legale e da un commercialista**. Qui sono riportati solo come vincoli da chiarire. +- lo **studio** è *responsabile del trattamento* (art. 28 GDPR) per i dati delle persone degli enti, di cui gli **enti** sono titolari; +- **chi sviluppa e gestisce il software** e il fornitore di hosting sono *sub-responsabili*; +- **primo anno (D10):** Davide è intestatario dei servizi di produzione e firma i contratti sul trattamento dei dati con i fornitori; **dal secondo anno (D11)** i contratti passano al cliente e Davide resta coinvolto per la manutenzione. --- -## 7. Differenze tra i due documenti +## 6. Differenze tra le fonti -| # | Punto | [D] docx | [X] xlsx | Stato | +| # | Punto | [D] | [X] | Esito | |---|---|---|---|---| -| 1 | Circolari | Funzione aggiuntiva (fase 2) | Dentro "Gestione cliente" | ✅ Si segue [X]: fase 1 | -| 2 | Scadenziario e proforma | Non citati | Presenti | ✅ Inclusi. Perimetro da chiarire (Q5) | -| 3 | Campi anagrafica ente | Data costituzione, qualifica, raccolte fondi | Sede, sezione RUNTS | 🔸 Unione dei campi | +| 1 | Circolari | Funzione aggiuntiva (fase 2) | Dentro "Gestione cliente" | ✅ D3: fase 1 | +| 2 | Scadenziario e proforma | Non citati | Presenti | ✅ Inclusi (RF-1.7, RF-1.8) | +| 3 | Campi anagrafica ente | Data costituzione, qualifica, raccolte fondi | Sede, sezione RUNTS | 🔸 Unione dei campi (Q20) | | 4 | Categorie di persone | 7 categorie | 6 categorie, in parte diverse | ⏳ Q8 | -| 5 | Libri sociali | Firma operatore, note, conservazione digitale | Contatti | 🔸 Unione dei campi | -| 6 | Contabilità | Alert, raccolte fondi occasionali, Modello D, relazione illustrativa | Imputazione dei singoli movimenti | 🔸 Unione: [X] descrive *come* si arriva al Modello D | -| 7 | Sezioni progettazione | Contiene "Costi" | Contiene "Obiettivi" e "Risorse" | 🔸 Unione delle sezioni | -| 8 | Rendicontazione sociale | "Serie di dati standard" | "Lettera del presidente" + descrizione copiata da M6 | ⏳ Q14 | -| 9 | Time sheet: chi inserisce | Non indicato | Operatore interno | ✅ Si segue [X]: lo studio | -| 10 | Valorizzazione oraria | Presente | Assente, ma c'è "ruolo/qualifica" | 🔸 Unione | +| 5 | Libri sociali | Firma operatore, note, conservazione digitale | Contatti | 🔸 Unione dei campi (Q20) | +| 6 | Contabilità | Alert, raccolte fondi occasionali, Modello D, relazione illustrativa | Imputazione dei singoli movimenti | 🔸 Unione: [X] descrive *come* si arriva al Modello D (Q20) | +| 7 | Sezioni progettazione | Contiene "Costi" | Contiene "Obiettivi" e "Risorse" | 🔸 Unione delle sezioni (Q20) | +| 8 | Rendicontazione sociale | "Serie di dati standard" | "Lettera del presidente"; descrizione copiata da M6 | ⏳ Q14 | +| 9 | Time sheet: chi inserisce | Non indicato | Operatore interno | ✅ D4: lo studio | +| 10 | Valorizzazione oraria | Presente | Assente, ma c'è "ruolo/qualifica" | 🔸 Unione (Q20) | -> 🔸 **Le righe "Unione"** sono una proposta di chi scrive, non una richiesta del cliente. Si possono confermare tutte insieme con una sola domanda (Q20). +Le righe "Unione" sono una proposta di chi scrive, non una richiesta del cliente. --- -## 8. Domande per il cliente +## 7. Decisioni -### 8.1 Domande aperte +Decisioni indicate da Davide: D1–D9 il 25/09/2026, D10–D11 il 27/09/2026. Vanno approvate dal cliente con la versione 1.0 (Q18). -Ordinate per peso sulla stima. Ogni domanda è scritta in modo da poterla fare direttamente al cliente. - -**Pesano molto sulla stima** - -| # | Domanda | Perché serve | -|---|---|---| -| **Q1** | Quanti enti pensate di gestire con il software, oggi e tra 3 anni? | Dimensionamento della piattaforma e dei costi di hosting | -| **Q2** | I circa 100 utenti come si dividono tra persone dello studio e referenti degli enti? | Dimensionamento, permessi, eventuali licenze | -| **Q4** | Per offerte, privacy/antiriciclaggio e libri sociali, che tipo di firma vi serve: una conferma semplice (click o codice via SMS), una firma elettronica avanzata o una firma digitale qualificata? | Scelta del fornitore di firma e costo ricorrente | -| **Q5** | Il software deve emettere solo proforma o anche la fattura elettronica? Usate già un programma di fatturazione? | La fatturazione elettronica è un sotto-progetto a sé | -| **Q9** | Per i libri sociali basta un'archiviazione con marca temporale, o vi serve una conservazione digitale a norma tramite un conservatore esterno? Serve anche la stampa? | Fornitore esterno, costi ricorrenti, valore legale | -| **Q10** | Gli estratti conto in PDF devono essere letti in automatico (estraendo i movimenti) o basta archiviarli? Da quante banche diverse arrivano? | Rischio tecnico alto se si vuole la lettura automatica | -| **Q19** | Per la progettazione e per il bilancio sociale, come vi immaginate il lavoro tra voi e l'ente? L'ente scrive e voi rivedete? Ognuno compila le sue parti? Oppure lavorate sullo stesso documento, anche nello stesso momento? Vale lo stesso per progetti e bilancio sociale? | Dubbio C: può cambiare di molto il costo di M6 e M7 | - -**Definiscono il perimetro dei moduli** - -| # | Domanda | Perché serve | -|---|---|---| -| **Q3** | Il catalogo dei servizi e dei pacchetti chi lo gestisce? Servono listini, sconti, aliquote IVA diverse? | Complessità di M1 | -| **Q7** | *Conferma:* numero soci e numero volontari nella scheda dell'ente si inseriscono a mano? (Ipotesi attuale: sì) | Coerenza dei dati | -| **Q8** | Tre domande sulle persone dell'ente, spiegate sotto | Modello dati di M3 e M4 | -| **Q12** | *Precisazione:* le scadenze degli alert sono uguali per tutti gli enti ma modificabili. Si modifica solo il calendario comune, o serve anche poter cambiare le scadenze di un singolo ente? | Complessità dello scadenziario (nota RF-5.1) | -| **Q13** | Lo schema del progetto non c'è ancora: chi lo prepara (voi, o va costruito insieme) e per quando? In che formato va esportato il progetto (Word, PDF)? L'adattamento ai formulari dei bandi è manuale o deve farlo il software? | Senza schema M6 non è stimabile con precisione | -| **Q14** | Due domande sul bilancio sociale, spiegate sotto | Correttezza dei requisiti di M7 | -| **Q15** | Chi stabilisce il valore di un'ora per ogni tipo di attività? In che forma l'ente vi manda le ore di volontari e dipendenti (Excel, carta, email)? | Modello dati di M9 ed eventuale funzione di importazione | - -**Organizzazione del progetto** - -| # | Domanda | Perché serve | -|---|---|---| -| **Q18** | Chi approva i requisiti da parte vostra? Se durante lo sviluppo servono modifiche, come le gestiamo (richiesta scritta, stima, approvazione)? | Controllo dello scope creep | -| **Q20** | Dove i due documenti elencano campi o sezioni diversi senza contraddirsi, confermate che vanno inclusi tutti (unione dei requisiti, §7)? | Chiude le righe "Unione" del §7 | - -#### Q8 spiegata: le persone dell'ente - -Il modulo M3 è il registro delle persone legate all'ente. Per costruirlo servono tre informazioni. - -**Q8.a: quali categorie di persone esistono?** I due documenti ne citano 9 in tutto, ma non le stesse (tabella in M3). Serve l'elenco definitivo. Alcune potrebbero essere la stessa cosa con nomi diversi: per esempio "aderenti" e "tesserati", oppure "dipendenti" e "lavoratori". -> *Domanda al cliente:* "Quali tipi di persone deve gestire il software? Aderenti e tesserati sono la stessa cosa? Sostenitori e partecipanti servono?" - -**Q8.b: quali dati servono per ogni categoria?** Per tutti servono i dati anagrafici e i contatti. Alcune categorie però potrebbero avere dati propri. Per esempio, per un socio la quota associativa o la data della delibera di ammissione; per un dipendente il tipo di contratto e la data di assunzione. I documenti non lo dicono. -> *Domanda al cliente:* "Oltre ad anagrafica e contatti, ci sono dati specifici da raccogliere per soci, volontari, dipendenti e collaboratori?" - -**Q8.c: una persona può avere più ruoli?** Capita spesso che un socio sia anche volontario. Ci sono due modi di gestirlo: -- **una scheda per persona, con più ruoli**: i dati si inseriscono una volta sola e si aggiornano in un solo punto. È la soluzione più corretta, ma va decisa subito perché definisce la struttura del database; -- **una scheda per ogni ruolo**: più semplice all'inizio, ma la stessa persona compare due volte, con il rischio di dati diversi nelle due schede. - -Collegata a questa: il libro soci e il registro volontari (M4) dovrebbero essere **generati da queste schede**, senza reinserire i dati. -> *Domanda al cliente:* "Una stessa persona può essere socio e volontario insieme? Il libro soci e il registro volontari devono prendere i dati da queste schede?" - -#### Q14 spiegata: il bilancio sociale - -**Q14.a: la descrizione nell'Excel è corretta?** Nella colonna "Funzioni" dell'Excel, per la Rendicontazione sociale c'è scritto: *"Guidare gli utenti nella stesura di un progetto secondo un modello standard facilmente convertibile sui formulari imposti dagli enti erogatori"*. È la stessa identica frase della Progettazione. Per il bilancio sociale ha poco senso: il bilancio sociale non è un progetto per un bando, e non va adattato ai formulari degli enti erogatori. Il bilancio sociale degli ETS segue le linee guida ministeriali (DM 4 luglio 2019). Quasi sicuramente è un copia-incolla. -> *Domanda al cliente:* "Nell'Excel la descrizione del bilancio sociale è uguale a quella della progettazione: è un errore? Il bilancio sociale deve seguire le linee guida ministeriali?" - -**Q14.b: quali sono le sezioni?** Il Word cita "serie di dati standard", l'Excel cita "lettera del presidente". Il resto coincide. Serve l'elenco definitivo, e sapere cosa si intende per "serie di dati standard". -> *Domanda al cliente:* "Le sezioni del bilancio sociale sono quelle di entrambi i documenti? Cosa intendete per 'serie di dati standard'?" - -### 8.2 Domande chiuse - -| # | Domanda | Risposta | Effetto sul documento | +| # | Decisione | Motivo / origine | Requisiti toccati | |---|---|---|---| -| Q6 | Canale di invio delle circolari | **Email e nell'app** | RF-8.2, RT-4 | -| Q11 | Piano dei conti per l'imputazione | **Voci del Modello D** | RF-5.5 | -| Q12 | Scadenze degli alert | **Uguali per tutti, modificabili** (resta una precisazione, vedi §8.1) | RF-5.1 | -| Q13 | Lo schema del progetto è disponibile? | **No** (restano aperte le altre parti, vedi §8.1) | RF-6.5, rischi | -| Q16 | Dati esistenti da importare | **No** | RT-14 | -| Q17 | Smartphone, accessibilità, hosting | **Nessuna preferenza** | RT-12, RT-13 | +| D1 | Interno = studio, esterno = ente | Le fonti usano "interno" in modi diversi; si adotta la convenzione di [X] | §1.2 | +| D2 | Piattaforma multi-ente: uno studio gestisce molti enti clienti | Conferma del modello di business | RT-1 | +| D3 | Circolari (M8) in fase 1 | [D] le mette in fase 2, [X] in "Gestione cliente": si segue [X] | M8 | +| D4 | Il time sheet (M9) lo inserisce lo studio | [D] non lo dice, [X] indica l'operatore interno: si segue [X]. Non serve un nuovo tipo di utente | RF-9.4 | +| D5 | Circolari via email e nell'app | Risposta a Q6 | RF-8.2, RT-4 | +| D6 | Imputazione contabile direttamente sulle voci del Modello D | Risposta a Q11 | RF-5.5 | +| D7 | Scadenze degli alert uguali per tutti gli enti, ma modificabili | Risposta a Q12 (resta una precisazione) | RF-5.1 | +| D8 | Nessuna migrazione di dati all'avvio | Risposta a Q16 | RT-14 | +| D9 | Nessun requisito su smartphone, accessibilità o hosting | Risposta a Q17 | RT-12, RT-13 | +| D10 | Primo anno di produzione: servizi intestati a Davide, che li paga; costi nel preventivo | Risposta a Q21 | RT-15 | +| D11 | Dal secondo anno servizi intestati al cliente, che li paga; gestione tecnica a Davide con contratto di manutenzione separato | Risposta a Q22 | RT-15 | ---- - -## 9. Registro delle decisioni - -Tutte le decisioni sono state indicate da Davide (autore del preventivo) il 25/09/2026. Le decisioni sui requisiti vanno comunque fatte approvare dal cliente con la versione 1.0 (vedi Q18). - -| # | Decisione | Riferimento | -|---|---|---| -| D1 | Interno = studio, esterno = ente | §2.2 | -| D2 | Il software è una piattaforma multi-ente: uno studio gestisce molti enti clienti | §2.1, RT-1 | -| D3 | Le circolari (M8) sono in fase 1, come in [X] | Dubbio A | -| D4 | Il time sheet (M9) lo inserisce lo studio, come in [X] | Dubbio B | -| D5 | Le circolari si inviano via email e nell'app | Q6, RF-8.2 | -| D6 | L'imputazione contabile usa direttamente le voci del Modello D | Q11, RF-5.5 | -| D7 | Le scadenze degli alert sono uguali per tutti gli enti, ma modificabili | Q12, RF-5.1 | -| D8 | Nessuna migrazione di dati all'avvio | Q16, RT-14 | -| D9 | Nessun requisito su smartphone, accessibilità o hosting | Q17, RT-12, RT-13 | - -**Ipotesi di lavoro in attesa di conferma:** numero soci e volontari inseriti a mano (Q7); unione dei requisiti dei due documenti (Q20). - ---- - -## 10. Rischi - -| Rischio | Descrizione | Mitigazione proposta | -|---|---|---| -| **Scope creep su M6** | Lo schema del progetto non esiste (Q13) e non si sa come lavorano insieme ente e studio (Q19) | Stimare M6 su un'ipotesi dichiarata; far definire lo schema prima dello sviluppo del modulo; procedura formale per le modifiche (Q18) | -| **Scope creep in generale** | M7 è descritto solo come elenco di titoli | Requisiti firmati prima dell'avvio, fase 2 stimata a parte | -| **Dipendenza dal cliente** | Servono dal cliente: schema del progetto, modelli di verbale e di circolare, formati degli estratti conto, tariffe orarie, forma di invio delle ore | Elenco dei materiali da consegnare con date, riportato nel preventivo | -| **Inserimento iniziale dei dati** | Senza migrazione (D8), gli enti devono inserire a mano soci e volontari esistenti. Rischio di richiesta di importazione a progetto avviato | Dirlo al cliente ora; eventualmente quotare l'import da Excel come voce opzionale | -| **Sicurezza e privacy** | Dati personali di molte persone, possibili categorie particolari, dati antiriciclaggio | Privacy by design, DPA con lo studio e con i fornitori, hosting UE, verifica legale | -| **Valore legale dei documenti** | Firma, marca temporale e conservazione hanno requisiti normativi | Uso di fornitori qualificati invece di soluzioni fatte in casa, verifica legale | -| **Estratti conto PDF** | Formati diversi per ogni banca, estrazione poco affidabile | Fase 1 con import Excel/CSV e archiviazione del PDF; lettura automatica del PDF come evoluzione | -| **Adempimenti normativi** | Modello D, bilancio sociale e RUNTS possono cambiare per legge | Voci e modelli configurabili, non scritti nel codice | -| **Rendicontazione del bando** | Il budget è vincolato e le spese devono essere rendicontabili | Preventivo con voci chiare e verificabili, da validare con il commercialista | +**Ipotesi 🔸 in attesa di conferma:** RF-2.13 e RF-2.14 inseriti a mano (Q7); righe "Unione" del §6 (Q20). --- @@ -467,14 +278,14 @@ Tutte le decisioni sono state indicate da Davide (autore del preventivo) il 25/0 | Versione | Data | Modifiche | |---|---|---| -| 0.1 | 25/09/2026 | Prima analisi dei due documenti del cliente. Nel corso della revisione: confermati interno = studio / esterno = ente (D1) e piattaforma multi-ente (D2); riscritta la mappa dei moduli con i dubbi A, B, C; risolti dubbio A (circolari in fase 1, D3) e dubbio B (time sheet inserito dallo studio, D4); dubbio C trasformato nella domanda Q19 | -| 0.2 | 25/09/2026 | Registrate le risposte a Q6, Q7, Q11, Q12, Q13, Q16, Q17 (D5–D9); riscritte Q8 e Q14 in sotto-domande; aggiunte Q20 e i requisiti RT-12, RT-13, RT-14; aggiunto il registro delle decisioni (§9) | +| 0.1 | 25/09/2026 | Prima analisi delle fonti. Confermati D1 e D2; mappa dei moduli con i dubbi A, B, C; risolti A (D3) e B (D4); dubbio C trasformato in Q19 | +| 0.2 | 25/09/2026 | Risposte a Q6, Q7, Q11, Q12, Q13, Q16, Q17 (D5–D9); Q8 e Q14 divise in sotto-domande; aggiunte Q20 e RT-12, RT-13, RT-14; aggiunto il registro delle decisioni | +| 0.3 | 27/09/2026 | Decisioni D10 e D11; chiuse Q21 e Q22; aggiunti RT-15 e Q23; aggiornati ruoli privacy e rischi | +| 0.3.1 | 27/09/2026 | Riorganizzazione senza modifiche ai requisiti: spostati in `domande-cliente.md` domande, spiegazioni delle domande, dubbio C, rischi e verifiche legali; tolte le note su costi e scelte progettuali (già in `costi-ricorrenti.md` e `domande-cliente.md` parte B); tolto il flusso complessivo (già in `workflow.md`); motivazioni dei dubbi A e B spostate nella tabella delle decisioni | --- ## Stato - -- **Fase corrente:** analisi dei requisiti, bozza v0.2. -- **Decisioni prese:** D1–D9 (§9). Fase 1 = M1–M6 + M8; fase 2 = M7 + M9. -- **Aperto:** 16 domande per il cliente (§8.1): Q1, Q2, Q3, Q4, Q5, Q7 (conferma), Q8, Q9, Q10, Q12 (precisazione), Q13, Q14, Q15, Q18, Q19, Q20. Le prioritarie per la stima sono Q1, Q2, Q4, Q5, Q9, Q10 e Q19. -- **Prossimo passo:** incontro con il cliente sulle domande del §8.1. Con le risposte si produce la versione 1.0 dei requisiti e si passa alla scelta dell'architettura e alla stima. +- **Fase corrente:** analisi dei requisiti, bozza v0.3.1. +- **Decisioni prese:** D1–D11. Fase 1 = M1–M6 + M8; fase 2 = M7 + M9. +- **Prossimo passo:** risposte del cliente alle domande aperte (`domande-cliente.md`), poi versione 1.0 dei requisiti. diff --git a/workflow.md b/workflow.md index 064db47..848185c 100644 --- a/workflow.md +++ b/workflow.md @@ -1,21 +1,19 @@ # Workflow del software **Progetto:** Gestionale per enti del Terzo Settore **Documento:** `workflow.md` -**Versione:** 0.2 · **Data:** 25/09/2026 · **Stato:** Bozza, da validare con il cliente -**Allineato a:** `richiesta.md` v0.2 · **Schema di versione:** vedi `indice-documenti.md` -**Fa fede a:** `richiesta.md` (sintesi in `richiesta-sintesi.md`) +**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare con il cliente +**Allineato a:** `richiesta.md` v0.3 · **Schema di versione:** vedi `indice-documenti.md` --- ## 0. Regole del documento -1. **Il workflow deriva dalla richiesta, non il contrario.** Ogni passo cita il requisito (RF-x.x, RT-x), la decisione (Dx) o la domanda aperta (Qx) di `richiesta.md` da cui nasce. -2. **Versione allineata.** Il workflow segue lo schema di versione comune (`indice-documenti.md`). Quando `richiesta.md` cambia, si aggiorna il workflow e si registra la modifica al §11. -3. **Tre tipi di passo:** - - senza simbolo: scritto nella richiesta; - - 🔸 **dedotto**: non è scritto, ma serve perché il processo funzioni (es. "l'ente può rifiutare un'offerta"). Va confermato con il cliente; - - ⏳ **aperto**: dipende da una domanda senza risposta. Il passo descrive l'ipotesi di lavoro. -4. **Come si legge un passo:** chi lo fa, cosa fa, cosa fa il sistema, riferimento. +1. **Il workflow deriva dalla richiesta.** Ogni passo cita il requisito (RF, RT), la decisione (D) o la domanda (Q) di `richiesta.md` da cui nasce. Quando la richiesta cambia, si aggiornano i passi che ne citano i codici. +2. **Tre tipi di passo:** + - senza simbolo: scritto nelle fonti; + - 🔸 **dedotto**: non è scritto, ma serve perché il processo funzioni. La domanda di conferma è in `domande-cliente.md` A4; + - ⏳ **aperto**: dipende da una domanda senza risposta (in `domande-cliente.md`); il passo descrive l'ipotesi di lavoro. +3. **Come si legge un passo:** chi lo fa, cosa fa, cosa fa il sistema, riferimento. **Attori:** **Studio** (operatore interno) · **Ente** (operatore esterno) · **Sistema** (azioni automatiche). @@ -70,7 +68,6 @@ flowchart LR | 6 | Studio | 🔸 Crea l'accesso per il referente dell'ente | Invia le credenziali; l'ente vede solo i propri dati | RT-1, RT-2 (🔸 dedotto) | **Stati dell'offerta:** bozza → inviata → firmata · 🔸 rifiutata · 🔸 scaduta. -**Domande aperte:** Q3 catalogo · Q4 tipo di firma · 🔸 da confermare: gestione di rifiuto e scadenza dell'offerta; chi crea l'accesso dell'ente. --- @@ -86,8 +83,6 @@ flowchart LR | 3 | Studio | Verifica ed emette il proforma | Invia il proforma all'ente | RF-1.8 (⏳ Q5) | | 4 | Studio | 🔸 Registra l'avvenuto pagamento | Chiude la scadenza | 🔸 dedotto | -**Domande aperte:** Q5 solo proforma o anche fattura elettronica · 🔸 da confermare: registrazione dell'incasso e gestione dei ritardi. - --- ## 4. W3: Gestione delle persone dell'ente (M3) @@ -101,8 +96,6 @@ flowchart LR | 2 | Ente | ⏳ Assegna uno o più ruoli (es. socio e volontario) | ⏳ Una scheda per persona con più ruoli | RF-3.3 (⏳ Q8.c) | | 3 | Sistema | — | ⏳ Se la persona è socio o volontario, prepara la voce nel libro soci o nel registro volontari (W4) | ⏳ Q8.c | -**Domande aperte:** Q8.a categorie · Q8.b dati per categoria · Q8.c più ruoli e collegamento con i libri. - --- ## 5. W4: Tenuta dei libri sociali (M4) @@ -122,7 +115,6 @@ flowchart LR **Stati:** bozza → in revisione → 🔸 da correggere → approvato → archiviato. **Flusso di approvazione:** è lo stesso flusso comune a più moduli (RT-3), riusato in W6 e W8. -**Domande aperte:** Q4 firma · Q9 conservazione a norma e stampa · 🔸 da confermare: il rimando all'ente con osservazioni. --- @@ -153,8 +145,6 @@ flowchart LR | 3 | Studio | 🔸 Controlla Modello D e relazione | 🔸 Flusso di approvazione (RT-3) | 🔸 dedotto | | 4 | Studio / Ente | Esporta i documenti da allegare al bilancio | Genera PDF/Word | RT-7 | -**Domande aperte:** Q10 lettura automatica del PDF · Q12 scadenze per singolo ente · 🔸 da confermare: solleciti in caso di mancato caricamento; controllo dello studio su Modello D e relazione. - --- ## 7. W6: Stesura di un progetto (M6) @@ -162,7 +152,7 @@ flowchart LR **Scopo:** preparare un progetto da presentare a un bando. **Inizio:** l'ente o lo studio avvia un nuovo progetto · **Fine:** progetto esportato. -> ⏳ **Ipotesi di lavoro (Q19, opzione a):** l'ente scrive e lo studio rivede, con lo stesso flusso di W4. Se il cliente sceglie (b) sezioni divise o (c) modifica contemporanea, questo workflow va riscritto. +> ⏳ **Ipotesi di lavoro (Q19, opzione a):** l'ente scrive e lo studio rivede, con lo stesso flusso di W4. Con le opzioni (b) o (c) (`domande-cliente.md` B4.3) questo workflow va riscritto. | # | Chi | Azione | Sistema | Rif. | |---|---|---|---|---| @@ -172,8 +162,6 @@ flowchart LR | 4 | Studio | Rivede; approva o rimanda con osservazioni | Flusso di approvazione (RT-3) | RF-6.4 (⏳ Q19) | | 5 | Studio / Ente | Esporta e adatta al formulario del bando | ⏳ Esporta in Word/PDF | RF-6.3 (⏳ Q13) | -**Domande aperte:** Q13 schema, formato di esportazione, adattamento ai formulari · Q19 divisione del lavoro. - --- ## 8. W7: Invio delle circolari (M8) @@ -189,8 +177,6 @@ flowchart LR | 4 | Ente | Legge la circolare nell'app | Registra "letta" | RF-8.2 | | 5 | Studio | Consulta chi l'ha letta e chi no | Mostra lo stato di lettura; segnala le email non recapitate | RF-8.2 | -**Domande aperte:** 🔸 da confermare: scelta dei destinatari (tutti o per gruppi, es. per qualifica dell'ente). - --- ## 9. W8: Bilancio sociale (M7), fase 2 @@ -207,8 +193,6 @@ flowchart LR | 3 | Studio | Rivede; approva o rimanda | Flusso di approvazione (RT-3) | RF-7.4 (⏳ Q19) | | 4 | Studio / Ente | Esporta | Genera PDF/Word | RT-7 | -**Domande aperte:** Q14 sezioni e linee guida · Q19 divisione del lavoro. - --- ## 10. W9: Time sheet e valorizzazione del volontariato (M9), fase 2 @@ -223,8 +207,6 @@ flowchart LR | 3 | Studio | Inserisce il time sheet: attività, ore, ruolo/qualifica | — | RF-9.1, RF-9.2, RF-9.4, D4 | | 4 | Sistema | — | Calcola il valore delle ore | RF-9.3 | -**Domande aperte:** Q15 chi definisce le tariffe; in che forma l'ente manda le ore. - --- ## 11. Registro delle modifiche @@ -232,30 +214,12 @@ flowchart LR | Versione | Data | Versione di `richiesta.md` | Modifica | |---|---|---|---| | 0.2 | 25/09/2026 | 0.2 | Prima stesura, allineata a `richiesta.md` v0.2 | - -**Procedura quando cambia la richiesta:** -1. Aggiornare `richiesta.md` e alzarne la versione. -2. Cercare in questo documento i riferimenti toccati (RF, D, Q). -3. Aggiornare i passi coinvolti; se una domanda ⏳ ha avuto risposta, togliere il simbolo; se un passo 🔸 è stato confermato o scartato, aggiornarlo o eliminarlo. -4. Allineare la versione del workflow e aggiungere una riga a questa tabella. - ---- - -## 12. Riepilogo dei passi da confermare con il cliente - -Sono i passi 🔸 dedotti, non scritti nella richiesta. Conviene aggiungerli alle domande (`domande-cliente.md`): - -| Workflow | Passo dedotto | -|---|---| -| W1 | L'ente può rifiutare l'offerta; l'offerta può scadere; lo studio crea l'accesso dell'ente | -| W2 | Lo studio registra l'incasso; gestione dei ritardi di pagamento | -| W4 | Lo studio può rimandare un documento all'ente con osservazioni | -| W5 | Solleciti se l'ente non carica i documenti; controllo dello studio su Modello D e relazione | -| W7 | Circolari a tutti gli enti o a gruppi di enti | +| 0.3 | 27/09/2026 | 0.3 | Solo allineamento di versione: D10, D11 e RT-15 riguardano la gestione dei servizi, non i processi del software. Nessun passo modificato | +| 0.3.1 | 27/09/2026 | 0.3 | Riorganizzazione senza modifiche ai passi: tolti le righe "Domande aperte" (ripetevano la colonna Rif.), la procedura di aggiornamento (è in `indice-documenti.md`) e il §12 dei passi da confermare (spostato in `domande-cliente.md` A4) | --- ## Stato -- **Fase corrente:** analisi dei requisiti (v0.2), workflow in prima stesura. -- **Decisioni prese:** D1–D9 (`richiesta.md`, §9), riportate nei passi. -- **Prossimo passo:** confermare con il cliente i passi dedotti (§12) insieme alle domande aperte. Con le risposte si aggiornano richiesta e workflow alla v1.0. +- **Fase corrente:** analisi dei requisiti, workflow v0.3.1. +- **Decisioni prese:** D1–D11 (`richiesta.md` §7), riportate nei passi. +- **Prossimo passo:** confermare con il cliente i passi 🔸 (`domande-cliente.md` A4) e rispondere alle domande ⏳; poi aggiornare i passi coinvolti.