Analisi dei requisiti v0.2
Documenti di progetto (richiesta, sintesi, domande, workflow, indice), fonti del cliente del 25/09/2026 e CLAUDE.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
commit
a17065f33f
8 files changed
+1359
No files matched your search
@@ -0,0 +1,100 @@
|
|||||||
|
# CLAUDE.md
|
||||||
|
|
||||||
|
Istruzioni per Claude su questo progetto. Leggere prima di ogni attività.
|
||||||
|
|
||||||
|
## Progetto
|
||||||
|
|
||||||
|
Gestionale web **multi-ente** per enti del Terzo Settore: uno **studio professionale** gestisce molti enti clienti (ODV, APS, imprese sociali…). Circa 100 utenti.
|
||||||
|
Il cliente finanzia il progetto con un **bando a fondo perduto**: il budget è vincolato e il preventivo deve essere **rendicontabile**.
|
||||||
|
Autore: Davide, primo preventivo da libero professionista. Sviluppa con Claude come strumento; il costo di Claude Max (90 €/mese × 12 mesi) va nel preventivo.
|
||||||
|
|
||||||
|
**Fase attuale:** analisi dei requisiti. Nessuna scelta tecnica (stack, hosting, fornitori) è ancora presa. Lo stato aggiornato è in `indice-documenti.md` e nella sezione "Stato" di `richiesta.md`.
|
||||||
|
|
||||||
|
## Ruolo di Claude
|
||||||
|
|
||||||
|
Consulente tecnico senior in architettura software, DevOps e preventivazione. Davide è preciso e vuole capire il perché di ogni scelta: **spiegare sempre il ragionamento, non solo la conclusione**.
|
||||||
|
|
||||||
|
## Regole
|
||||||
|
|
||||||
|
1. **Non inventare cifre.** Se una stima dipende da un dato mancante: dichiararlo, indicare l'assunzione usata e come verificarla. **Le tariffe orarie le decide Davide.**
|
||||||
|
2. **Ogni scelta tecnica si motiva** con un requisito (RF, RT) o un vincolo. Se non c'è un requisito dietro, la scelta non si fa.
|
||||||
|
3. **Requisito ambiguo → chiedere prima di procedere**, non indovinare. Se serve andare avanti, scrivere l'ipotesi e segnarla 🔸.
|
||||||
|
4. **Aspetti fiscali, contrattuali, privacy e rendicontazione del bando:** dare le informazioni utili, ma ricordare sempre di farle verificare a un **commercialista** o a un **legale**.
|
||||||
|
5. **Segnalare i rischi** (scope creep, dipendenze dal cliente, sicurezza dei dati) invece di ometterli per semplificare il preventivo.
|
||||||
|
6. **Privacy by design:** il software tratta dati personali di molte persone (soci, volontari, dipendenti), dati antiriciclaggio e possibili dati particolari (art. 9 GDPR). Ogni proposta tecnica va valutata anche sotto questo aspetto.
|
||||||
|
|
||||||
|
## Formato delle risposte
|
||||||
|
|
||||||
|
- **Italiano**, tono professionale e diretto.
|
||||||
|
- Tabelle per confrontare opzioni o elencare costi; prosa per i ragionamenti.
|
||||||
|
- Documenti completi consegnati come **file separati** (Markdown o Word), con struttura riutilizzabile.
|
||||||
|
- **Chiudere ogni risposta con lo stato:** fase corrente, decisioni prese, prossimo passo.
|
||||||
|
|
||||||
|
## Documenti
|
||||||
|
|
||||||
|
| File | Ruolo |
|
||||||
|
|---|---|
|
||||||
|
| `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 |
|
||||||
|
| `indice-documenti.md` | Versioni in vigore e schema di versione |
|
||||||
|
|
||||||
|
**Dipendenze:** fonti del cliente → `richiesta.md` → sintesi, domande, workflow.
|
||||||
|
**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.
|
||||||
|
- Se il cliente manda una versione nuova: creare una nuova sottocartella con la data di ricezione, lasciare intatte le precedenti, registrarla in `indice-documenti.md` (§1.1) e aggiornare `richiesta.md`.
|
||||||
|
- Un file `… - testo estratto.md` è una trascrizione di servizio, non l'originale: se c'è l'originale, vale l'originale.
|
||||||
|
- Se una fonte non è disponibile, chiederla a Davide invece di citarla a memoria. Una copia delle fonti è anche nei documenti del Project su claude.ai.
|
||||||
|
|
||||||
|
## Convenzioni
|
||||||
|
|
||||||
|
**Codici** (stabili: non rinumerare, un codice eliminato non si riusa):
|
||||||
|
|
||||||
|
| 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` |
|
||||||
|
| Wn | Workflow | `workflow.md` |
|
||||||
|
| Bn.m | Dubbio progettuale (uso interno) | `domande-cliente.md` parte B |
|
||||||
|
|
||||||
|
**Simboli:** ✅ deciso · ⏳ aperto, da chiedere al cliente · 🔸 ipotesi o passo dedotto, da confermare · ⚖️ da verificare con legale o commercialista.
|
||||||
|
|
||||||
|
**Struttura dei documenti:** intestazione (Progetto, Documento, Versione · Data · Stato, Allineato a) → contenuto → "Registro delle modifiche" → "Stato" finale. Date nel formato GG/MM/AAAA.
|
||||||
|
|
||||||
|
**Terminologia:** **interno = studio**, **esterno = ente**. I due documenti del cliente usano "interno" in modi diversi: usare sempre questa convenzione.
|
||||||
|
|
||||||
|
**Distinguere sempre** ciò che è scritto nelle fonti, ciò che ha deciso Davide (Dn) e ciò che è una deduzione di Claude (🔸). Una deduzione non diventa requisito finché non è confermata.
|
||||||
|
|
||||||
|
## Versioni
|
||||||
|
|
||||||
|
Schema **X.Y.Z** (dettagli in `indice-documenti.md`):
|
||||||
|
- **X:** 0 = bozza · 1 = approvata dal cliente · 2+ = nuove versioni approvate;
|
||||||
|
- **Y:** cambiano i requisiti (risposte del cliente, nuove decisioni);
|
||||||
|
- **Z:** solo correzioni che non toccano i requisiti.
|
||||||
|
|
||||||
|
I documenti derivati hanno le **stesse X.Y di `richiesta.md`**. I nomi dei file non contengono la versione.
|
||||||
|
|
||||||
|
**Ogni modifica a un documento, anche minima, aggiorna sempre la versione.** Nessun file si modifica senza:
|
||||||
|
|
||||||
|
1. alzare la versione: Y se cambiano i requisiti, altrimenti Z;
|
||||||
|
2. aggiornare l'intestazione (versione, data);
|
||||||
|
3. aggiungere una riga al registro delle modifiche del documento;
|
||||||
|
4. aggiornare la tabella §1.2 di `indice-documenti.md`.
|
||||||
|
|
||||||
|
`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).
|
||||||
|
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.
|
||||||
|
|
||||||
|
**Quando si invia un documento al cliente:** conservarne una copia in `invii/AAAA-MM-GG_<nome>_v<X.Y>.md`, per sapere sempre cosa ha ricevuto. Mai includere la parte B di `domande-cliente.md`.
|
||||||
@@ -0,0 +1,117 @@
|
|||||||
|
# Domande per il cliente e dubbi progettuali
|
||||||
|
**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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Parte A: domande 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? | |
|
||||||
|
|
||||||
|
## 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)? | |
|
||||||
|
|
||||||
|
## 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? | |
|
||||||
|
|
||||||
|
## A4. 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. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Parte B: dubbi progettuali (uso interno)
|
||||||
|
|
||||||
|
## B1. Scelte che dipendono dalle risposte del cliente
|
||||||
|
|
||||||
|
| # | Dubbio | Da cosa dipende | 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 |
|
||||||
|
|
||||||
|
## 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 |
|
||||||
|
|
||||||
|
## B3. Da verificare con legale e commercialista
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
| 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 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Registro delle modifiche
|
||||||
|
|
||||||
|
| 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 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
Binary file not shown.
@@ -0,0 +1,110 @@
|
|||||||
|
<!--
|
||||||
|
TESTO ESTRATTO, NON È IL FILE ORIGINALE.
|
||||||
|
Fonte: "funzioni software.docx" [D], ricevuto dal cliente il 25/09/2026.
|
||||||
|
Il testo è stato estratto automaticamente dai documenti del Project su claude.ai e riportato senza modifiche.
|
||||||
|
Il file .docx originale va copiato in questa cartella da Davide. Quando c'è l'originale, vale l'originale.
|
||||||
|
-->
|
||||||
|
|
||||||
|
**FUNZIONI DI BASE INDISPENSABILI**
|
||||||
|
|
||||||
|
**CONTRATTUALISTICA:** possibilità di inviare preventivi e offerte da firmare in digitale, le offerte saranno definite tramite l’inserimento di una serie di servizi singolarmente o a pacchetto, dovranno essere comprensive di privacy e antiriciclaggio. Dovranno contenere anche le modalità di pagamento e le relative scadenze.
|
||||||
|
|
||||||
|
**ANAGRAFICA ENTI**: l’operatore dovrà inserire tutti i dati dell’ente/cliente ovvero:
|
||||||
|
|
||||||
|
- Denominazione sociale
|
||||||
|
|
||||||
|
- Codice fiscale
|
||||||
|
|
||||||
|
- Partita IVA (eventuale)
|
||||||
|
|
||||||
|
- Data di costituzione
|
||||||
|
|
||||||
|
- Numero iscrizione RUNTS e data iscrizione
|
||||||
|
|
||||||
|
- Qualifica (ODV, APS, ETS, IMPRESA SOCIALE, SOMS, RETE, ENTE FILANTROPICO)
|
||||||
|
|
||||||
|
- Attività di interesse generale contenute nello statuto e svolte tra tutte quelle previste dall’art. 5 CTS
|
||||||
|
|
||||||
|
- Eventuali attività diverse da art. 6 CTS svolte
|
||||||
|
|
||||||
|
- Eventuale Raccolta fondi continuativa svolta con modalità commerciali
|
||||||
|
|
||||||
|
- Raccolta fondi continuativa ordinaria
|
||||||
|
|
||||||
|
- Numero soci
|
||||||
|
|
||||||
|
- Numero volontari
|
||||||
|
|
||||||
|
**ANAGRAFICHE COLLEGATE****: **l’operatore interno all’ente deve poter inserire i dati anagrafici dei soci, aderenti e tesserati, dei volontari e dei propri lavoratori, dei sostenitori o partecipanti.
|
||||||
|
|
||||||
|
**COMPILAZIONE LIBRI SOCIALI CON ****CONSERVAZIONE DIGITALE E ****MARCATURA TEMPORALE: **
|
||||||
|
|
||||||
|
- Libro soci (con data delibera ammissione socio, dati anagrafici, data decadenza da socio, note. Firma operatore
|
||||||
|
|
||||||
|
- Libro verbali assemblea soci
|
||||||
|
|
||||||
|
- Libro verbali organo di amministrazione
|
||||||
|
|
||||||
|
- Registro volontari (con data inizio volontariato presso ente, dati anagrafici, data fine volontariato, note, firma operatore)
|
||||||
|
|
||||||
|
Il programma deve consentire la compilazione autonoma da parte degli enti e il controllo da parte dei professionisti interni all’impresa prima della stampa e archiviazione definitiva dei documenti.
|
||||||
|
|
||||||
|
**CONTABILITA****’**
|
||||||
|
|
||||||
|
Il software dovrà mandare agli enti registrati degli alert alle scadenze fissate per ricordare di caricare documenti per la redazione dei rendiconti di cassa, i documenti saranno:
|
||||||
|
|
||||||
|
- Estratti conto bancari trimestrali in excel o pdf;
|
||||||
|
|
||||||
|
- Prima nota cassa trimestrale;
|
||||||
|
|
||||||
|
- Rendiconti raccolte fondi pubbliche occasionali.
|
||||||
|
|
||||||
|
Inoltre, dovrà permettere agli enti di scrivere in maniera guidata e su modelli preimpostati una relazione illustrativa delle attività svolte durante l’anno, dei progetti finanziati e realizzati;
|
||||||
|
|
||||||
|
Il software dovrà consentire l’elaborazione dei dati contenuti in questi documenti per redigere i rendiconti di cassa su modello D (modello ministeriale) e compilare una relazione illustrativa da allegare ai bilanci.
|
||||||
|
|
||||||
|
**PROGETTAZIONE**
|
||||||
|
|
||||||
|
Il software dovrà guidare l’operatore nell’ inserire i dati necessari per la stesura di un progetto secondo uno schema che sarà impostato nel dettaglio, i dati principali da chiedere saranno:
|
||||||
|
|
||||||
|
- ANALISI CONTESTO
|
||||||
|
|
||||||
|
- ANALISI BISOGNI
|
||||||
|
|
||||||
|
- IDEA
|
||||||
|
|
||||||
|
- ATTIVITA’
|
||||||
|
|
||||||
|
- CRONOPROGRAMMA
|
||||||
|
|
||||||
|
- COSTI
|
||||||
|
|
||||||
|
- PIANO ECONOMICO – FINANZIARIO
|
||||||
|
|
||||||
|
**FUNZIONI AGGIUNTIVE DA INSERIRE ANCHE IN UN SECONDO MOMENTO**
|
||||||
|
|
||||||
|
**RENDICONTAZIONE SOCIALE **
|
||||||
|
|
||||||
|
Raccolta dati per bilancio sociale. Sempre tramite procedura guidata il software deve accompagnare l’operatore nell’inserire i dati necessari alla redazione del bilancio sociale ed estrapolare automaticamente i dati già in suo possesso. Il bilancio sociale contiene:
|
||||||
|
|
||||||
|
- Serie di dati standard
|
||||||
|
|
||||||
|
- IDENTITA’ ENTE
|
||||||
|
|
||||||
|
- PRINCIPALI STAKEHOLDERS
|
||||||
|
|
||||||
|
- UTENTI
|
||||||
|
|
||||||
|
- OBIETTIVI E ATTIVITA’
|
||||||
|
|
||||||
|
- SITUAZIONE ECONOMICO FINANZIARIA
|
||||||
|
|
||||||
|
- RELAZIONE ORGANO DI CONTROLLO
|
||||||
|
|
||||||
|
**POSSIBILITA’ DI MANDARE CIRCOLARI PER LE SCADENZE SU ADEMPIMENTI AMMINISTRATIVI****,**** CONTABILI E FISCALI**
|
||||||
|
|
||||||
|
**VALUTAZIONE VOLONTARIATO**
|
||||||
|
|
||||||
|
Inserimento time sheet volontari e dipendenti il cui contenuto è:
|
||||||
|
|
||||||
|
- Tipo di attività svolta con indicazione delle ore e valorizzazione ‘di ciascuna ora a seconda dell’attività
|
||||||
@@ -0,0 +1,91 @@
|
|||||||
|
# Indice dei documenti di progetto
|
||||||
|
**Progetto:** Gestionale per enti del Terzo Settore
|
||||||
|
**Documento:** `indice-documenti.md` · **Aggiornato il:** 25/09/2026
|
||||||
|
|
||||||
|
Questo indice è il punto unico in cui si vede **quale versione è in vigore** per ogni documento e **come si versionano**. Si aggiorna ogni volta che un documento cambia versione.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Documenti in vigore
|
||||||
|
|
||||||
|
### 1.1 Documenti del cliente (fonti)
|
||||||
|
|
||||||
|
Le fonti stanno nella cartella `fonti/`, con una sottocartella per ogni consegna, nominata con la data di ricezione. I file in `fonti/` non si modificano mai.
|
||||||
|
|
||||||
|
| Consegna | File | Contenuto | Note |
|
||||||
|
|---|---|---|---|
|
||||||
|
| `fonti/2026-09-25/` | `funzioni software.docx` | Funzioni richieste, divise in base e aggiuntive ([D]) | ⚠️ **Originale da copiare in cartella** (Davide). Nel frattempo c'è `funzioni software - testo estratto.md`, trascrizione senza modifiche |
|
||||||
|
| `fonti/2026-09-25/` | `Software.xlsx` | Tabella Moduli / Funzioni / Contenuti / Operatore / Note ([X]) | Originale. SHA-256: `419b4d48…fb63cb9` |
|
||||||
|
|
||||||
|
Il cliente non indica versioni: ogni consegna si identifica con la data di ricezione. Se il cliente manda una nuova versione, si crea una nuova sottocartella **senza toccare le precedenti**, si aggiunge una riga qui e si aggiorna `richiesta.md`.
|
||||||
|
|
||||||
|
### 1.2 Documenti di progetto
|
||||||
|
|
||||||
|
| Documento | Ruolo | 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 |
|
||||||
|
| `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 |
|
||||||
|
|
||||||
|
**Dipendenze:**
|
||||||
|
|
||||||
|
```
|
||||||
|
fonti/AAAA-MM-GG/ (docx, xlsx del cliente)
|
||||||
|
↓
|
||||||
|
richiesta.md ← documento base
|
||||||
|
↓
|
||||||
|
├── richiesta-sintesi.md
|
||||||
|
├── domande-cliente.md
|
||||||
|
└── workflow.md
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Schema di versione
|
||||||
|
|
||||||
|
### 2.1 Numero di versione: `X.Y.Z`
|
||||||
|
|
||||||
|
| Parte | Significato | Quando cambia |
|
||||||
|
|---|---|---|
|
||||||
|
| **X** | Stato di validazione | **0** = bozza, non ancora approvata dal cliente · **1** = approvata dal cliente (base per il preventivo) · **2, 3…** = nuova versione approvata dopo una modifica dei requisiti a progetto avviato |
|
||||||
|
| **Y** | Revisione dei contenuti | Quando cambia **cosa deve fare il software**: nuove risposte del cliente, nuove decisioni, requisiti aggiunti o tolti |
|
||||||
|
| **Z** | Correzione | Solo per correzioni che **non cambiano i requisiti**: refusi, riformulazioni, formattazione. Si omette quando è 0 (0.2 = 0.2.0) |
|
||||||
|
|
||||||
|
**Esempi:**
|
||||||
|
- Il cliente risponde a Q1 → `richiesta.md` passa da 0.2 a **0.3**.
|
||||||
|
- Si corregge un refuso in `workflow.md` → `workflow.md` passa da 0.2 a **0.2.1**; gli altri documenti non cambiano.
|
||||||
|
- Il cliente approva i requisiti → tutti i documenti passano a **1.0**.
|
||||||
|
- Dopo l'approvazione il cliente chiede una modifica → `richiesta.md` passa a **1.1** (proposta), poi a **2.0** quando la modifica è approvata.
|
||||||
|
|
||||||
|
### 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.
|
||||||
|
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
|
||||||
|
|
||||||
|
1. Aggiornare il contenuto del documento.
|
||||||
|
2. Aggiornare l'intestazione: versione, data, stato.
|
||||||
|
3. Aggiungere una riga al **registro delle modifiche** in fondo al documento: cosa è cambiato e perché.
|
||||||
|
4. Se è cambiato `richiesta.md`, aggiornare i documenti derivati e allinearne la versione.
|
||||||
|
5. Aggiornare la tabella del §1.2 di questo indice.
|
||||||
|
|
||||||
|
### 2.4 Nomi dei file
|
||||||
|
|
||||||
|
I nomi dei file **non contengono la versione** (`richiesta.md`, non `richiesta_v0.2.md`). Così i riferimenti tra documenti restano validi.
|
||||||
|
La versione si legge nell'intestazione e in questo indice. Quando un documento viene **inviato al cliente**, se ne conserva una copia con la versione nel nome (es. `invii/2026-09-25_domande-cliente_v0.2.md`), per sapere sempre cosa ha ricevuto il cliente.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Registro delle modifiche dell'indice
|
||||||
|
|
||||||
|
| Data | Modifica |
|
||||||
|
|---|---|
|
||||||
|
| 25/09/2026 | Creazione dell'indice e dello schema di versione; tutti i documenti di progetto portati a v0.2 |
|
||||||
|
| 25/09/2026 | Aggiunto `CLAUDE.md` |
|
||||||
|
| 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/`) |
|
||||||
@@ -0,0 +1,200 @@
|
|||||||
|
# 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.
|
||||||
+480
@@ -0,0 +1,480 @@
|
|||||||
|
# Analisi della 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
|
||||||
|
|
||||||
|
**Novità rispetto alla v0.1:** vedi il registro delle modifiche in fondo al documento.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Scopo del documento
|
||||||
|
|
||||||
|
Il documento riordina le due richieste del cliente in un'unica descrizione lineare del software. Serve a:
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Qui non si fanno scelte tecniche e non si stimano costi. Quelle attività vengono dopo, sui requisiti validati.
|
||||||
|
|
||||||
|
**Legenda usata nel documento:**
|
||||||
|
- ✅ = deciso
|
||||||
|
- ⏳ = aperto, da chiedere al cliente
|
||||||
|
- 🔸 = ipotesi di lavoro, da confermare con il cliente
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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) |
|
||||||
|
|---|---|---|
|
||||||
|
| **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 |
|
||||||
|
| **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
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Mappa dei moduli e priorità
|
||||||
|
|
||||||
|
### 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
|
||||||
|
|
||||||
|
| # | 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) |
|
||||||
|
| 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 |
|
||||||
|
| 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Requisiti funzionali per modulo
|
||||||
|
|
||||||
|
Legenda: **RF** = requisito funzionale · **Fonte**: [D], [X] o *Decisione* (vedi §9).
|
||||||
|
|
||||||
|
### M1: Gestione cliente e contrattualistica (fase 1)
|
||||||
|
|
||||||
|
**Obiettivo:** gestire il rapporto commerciale tra lo studio e l'ente, dall'offerta all'incasso.
|
||||||
|
|
||||||
|
| ID | Requisito | Fonte |
|
||||||
|
|---|---|---|
|
||||||
|
| RF-1.1 | Catalogo dei **servizi** dello studio, vendibili **singolarmente o a pacchetto** ⏳ Q3 | D |
|
||||||
|
| RF-1.2 | Composizione di **preventivi/offerte** a partire dal catalogo | D + X |
|
||||||
|
| RF-1.3 | Nell'offerta vanno indicate **modalità di pagamento e scadenze** | D |
|
||||||
|
| RF-1.4 | Invio dell'offerta all'ente e **firma digitale** per l'accettazione ⏳ Q4 | D + X |
|
||||||
|
| RF-1.5 | L'offerta comprende l'**informativa privacy**, con firma di presa visione | D + X |
|
||||||
|
| RF-1.6 | L'offerta comprende la **raccolta dati antiriciclaggio**, con firma | D + X |
|
||||||
|
| RF-1.7 | **Scadenziario** dei pagamenti, generato dalle condizioni dell'offerta | X |
|
||||||
|
| RF-1.8 | Emissione di **proforma** alle scadenze ⏳ Q5 | X |
|
||||||
|
| RF-1.9 | **Alert** allo studio sulle scadenze | X |
|
||||||
|
| RF-1.10 | Invio di **circolari di aggiornamento** ai clienti (dettaglio in M8) | X |
|
||||||
|
|
||||||
|
### M2: Anagrafica enti (fase 1)
|
||||||
|
|
||||||
|
**Obiettivo:** scheda completa di ciascun ente cliente. La compila lo studio.
|
||||||
|
|
||||||
|
| ID | Campo | Fonte | Note |
|
||||||
|
|---|---|---|---|
|
||||||
|
| RF-2.1 | Denominazione sociale | D + X | |
|
||||||
|
| RF-2.2 | Sede | X | |
|
||||||
|
| RF-2.3 | Codice fiscale | D + X | |
|
||||||
|
| RF-2.4 | Partita IVA (se presente) | D + X | Facoltativa |
|
||||||
|
| RF-2.5 | Data di costituzione | D | |
|
||||||
|
| RF-2.6 | Numero e data di iscrizione al RUNTS | D + X | |
|
||||||
|
| RF-2.7 | Sezione di iscrizione al RUNTS | X | Lista chiusa |
|
||||||
|
| RF-2.8 | Qualifica: ODV, APS, ETS, Impresa sociale, SOMS, Rete, Ente filantropico | D | Lista chiusa |
|
||||||
|
| RF-2.9 | Attività di interesse generale (art. 5 CTS) previste da statuto e svolte | D + X | Selezione multipla dall'elenco di legge |
|
||||||
|
| 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) |
|
||||||
|
|
||||||
|
> 🔸 **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, cioè le persone dell'ente (fase 1)
|
||||||
|
|
||||||
|
**Obiettivo:** registro delle persone legate a ciascun ente. Lo compila l'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* |
|
||||||
|
|
||||||
|
**Le categorie citate nei due documenti:**
|
||||||
|
|
||||||
|
| Categoria | [D] | [X] |
|
||||||
|
|---|---|---|
|
||||||
|
| Soci | ✔ | ✔ |
|
||||||
|
| Aderenti | ✔ | |
|
||||||
|
| Tesserati | ✔ | ✔ |
|
||||||
|
| Volontari | ✔ | ✔ |
|
||||||
|
| Volontari occasionali | | ✔ |
|
||||||
|
| Dipendenti / lavoratori | ✔ | ✔ |
|
||||||
|
| Collaboratori | | ✔ |
|
||||||
|
| 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.
|
||||||
|
|
||||||
|
| ID | Requisito | Fonte |
|
||||||
|
|---|---|---|
|
||||||
|
| RF-4.1 | **Libro soci**: data delibera di ammissione, dati anagrafici, contatti, data cessazione/decadenza, note, firma operatore | D + X |
|
||||||
|
| RF-4.2 | **Registro volontari**: data inizio, dati anagrafici, contatti, data fine, note, firma operatore | D + X |
|
||||||
|
| RF-4.3 | **Libro verbali assemblea soci**: redazione dei verbali | D + X |
|
||||||
|
| 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 |
|
||||||
|
|
||||||
|
### M5: Contabilità (fase 1)
|
||||||
|
|
||||||
|
**Obiettivo:** raccogliere i documenti contabili dell'ente e produrre il rendiconto di cassa e la 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.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.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.
|
||||||
|
|
||||||
|
| 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.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).
|
||||||
|
|
||||||
|
### M7: Rendicontazione sociale (fase 2)
|
||||||
|
|
||||||
|
**Obiettivo:** raccolta guidata dei dati per il bilancio sociale, riusando automaticamente 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 |
|
||||||
|
|
||||||
|
### 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.
|
||||||
|
|
||||||
|
### M9: Valutazione volontariato (fase 2)
|
||||||
|
|
||||||
|
| ID | Requisito | Fonte |
|
||||||
|
|---|---|---|
|
||||||
|
| 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* |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Requisiti trasversali (valgono per tutti i moduli)
|
||||||
|
|
||||||
|
Questi requisiti non sono scritti come moduli nei documenti, ma **derivano da quanto richiesto**. Hanno un forte impatto sull'architettura e sui costi.
|
||||||
|
|
||||||
|
| 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-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-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-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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Dati personali: cosa tratta il software
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
| Dato | Di chi | Modulo | Nota |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Anagrafici e contatti | Soci, volontari, dipendenti, collaboratori, sostenitori | M3, M4 | Volume elevato |
|
||||||
|
| Dati per l'adeguata verifica antiriciclaggio (documenti d'identità, titolare effettivo…) | Legali rappresentanti degli enti | M1 | Obblighi specifici di conservazione (D.Lgs. 231/2007) |
|
||||||
|
| Dati di lavoro e ore | Dipendenti, volontari | M9 | |
|
||||||
|
| 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):**
|
||||||
|
- 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Differenze tra i due documenti
|
||||||
|
|
||||||
|
| # | Punto | [D] docx | [X] xlsx | Stato |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 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 |
|
||||||
|
| 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 |
|
||||||
|
|
||||||
|
> 🔸 **Le righe "Unione"** sono una proposta di chi scrive, non una richiesta del cliente. Si possono confermare tutte insieme con una sola domanda (Q20).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Domande per il cliente
|
||||||
|
|
||||||
|
### 8.1 Domande aperte
|
||||||
|
|
||||||
|
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 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 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 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Registro delle modifiche
|
||||||
|
|
||||||
|
| 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) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
+261
@@ -0,0 +1,261 @@
|
|||||||
|
# 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`)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
||||||
|
**Attori:** **Studio** (operatore interno) · **Ente** (operatore esterno) · **Sistema** (azioni automatiche).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Mappa dei workflow
|
||||||
|
|
||||||
|
| # | Workflow | Moduli | Fase | Frequenza | Stato |
|
||||||
|
|---|---|---|---|---|---|
|
||||||
|
| W1 | Acquisizione e attivazione di un ente | M1, M2 | 1 | Una volta per ente | Definito |
|
||||||
|
| W2 | Scadenziario pagamenti e proforma | M1 | 1 | Alle scadenze dell'offerta | Definito (⏳ Q5) |
|
||||||
|
| W3 | Gestione delle persone dell'ente | M3 | 1 | Continua | ⏳ Q8 |
|
||||||
|
| W4 | Tenuta dei libri sociali | M4 | 1 | A ogni evento (ammissione, cessazione, riunione) | Definito (⏳ Q4, Q9) |
|
||||||
|
| W5 | Ciclo contabile | M5 | 1 | Trimestrale + annuale | Definito (⏳ Q10, Q12) |
|
||||||
|
| W6 | Stesura di un progetto | M6 | 1 | A ogni bando | ⏳ Q13, Q19 |
|
||||||
|
| W7 | Invio delle circolari | M8 | 1 | Quando serve | Definito |
|
||||||
|
| W8 | Bilancio sociale | M7 | 2 | Annuale | ⏳ Q14, Q19 |
|
||||||
|
| W9 | Time sheet e valorizzazione del volontariato | M9 | 2 | Periodica | ⏳ Q15 |
|
||||||
|
|
||||||
|
### Ciclo di vita di un ente
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
A[W1 Offerta e firma] --> B[W1 Attivazione ente]
|
||||||
|
B --> C[W3 Persone]
|
||||||
|
C --> D[W4 Libri sociali]
|
||||||
|
B --> E[W5 Contabilità trimestrale]
|
||||||
|
E --> F[W5 Modello D e relazione annuale]
|
||||||
|
B --> G[W6 Progetti]
|
||||||
|
F --> H[W8 Bilancio sociale - fase 2]
|
||||||
|
C --> H
|
||||||
|
B --> I[W2 Proforma alle scadenze]
|
||||||
|
B --> J[W7 Circolari]
|
||||||
|
C --> K[W9 Time sheet - fase 2]
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. W1: Acquisizione e attivazione di un ente (M1, M2)
|
||||||
|
|
||||||
|
**Scopo:** trasformare un potenziale cliente in un ente attivo sulla piattaforma.
|
||||||
|
**Inizio:** lo studio decide di fare un'offerta · **Fine:** l'ente ha accesso al sistema.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Studio | Compone l'offerta scegliendo servizi singoli o pacchetti dal catalogo | Calcola il totale | RF-1.1, RF-1.2 (⏳ Q3) |
|
||||||
|
| 2 | Studio | Indica modalità di pagamento e scadenze | Salva le condizioni, da cui nasce lo scadenziario (W2) | RF-1.3 |
|
||||||
|
| 3 | Studio | Invia l'offerta all'ente | Allega informativa privacy e modulo antiriciclaggio; notifica l'ente | RF-1.4–1.6 |
|
||||||
|
| 4 | Ente | Legge e firma offerta, presa visione privacy e dati antiriciclaggio | Registra le firme con data e ora | RF-1.4–1.6 (⏳ Q4 tipo di firma) |
|
||||||
|
| 4b | Ente | 🔸 Rifiuta l'offerta, oppure l'offerta scade senza firma | Offerta chiusa, studio avvisato | 🔸 dedotto |
|
||||||
|
| 5 | Studio | Compila l'anagrafica dell'ente | Controlla i campi obbligatori | RF-2.1–2.14 |
|
||||||
|
| 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. W2: Scadenziario pagamenti e proforma (M1)
|
||||||
|
|
||||||
|
**Scopo:** incassare secondo le condizioni firmate.
|
||||||
|
**Inizio:** offerta firmata (W1, passo 4) · **Fine:** tutte le scadenze emesse.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Sistema | — | Genera lo scadenziario dalle condizioni dell'offerta | RF-1.7 |
|
||||||
|
| 2 | Sistema | — | All'avvicinarsi di una scadenza avvisa lo studio | RF-1.9 |
|
||||||
|
| 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)
|
||||||
|
|
||||||
|
**Scopo:** tenere aggiornato il registro delle persone legate all'ente, base per libri sociali e bilancio sociale.
|
||||||
|
**Inizio:** ingresso o modifica di una persona · **Fine:** anagrafica aggiornata.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Ente | Inserisce o modifica la persona: anagrafica, contatti, categoria | Controlla i duplicati | RF-3.1, RF-3.2 |
|
||||||
|
| 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)
|
||||||
|
|
||||||
|
**Scopo:** registrare ammissioni, cessazioni e verbali con valore probatorio.
|
||||||
|
**Inizio:** un evento (ammissione o uscita di un socio o volontario, assemblea, riunione del consiglio) · **Fine:** documento archiviato.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Ente | Compila la voce o il verbale: libro soci, registro volontari, verbale di assemblea, verbale dell'organo di amministrazione | Salva in stato "bozza" | RF-4.1–4.4 |
|
||||||
|
| 2 | Ente | Firma come operatore e invia allo studio per il controllo | Stato "in revisione"; notifica lo studio | RF-4.1, RF-4.2, RF-4.7 (⏳ Q4) |
|
||||||
|
| 3 | Studio | Controlla il documento | — | RF-4.7 |
|
||||||
|
| 3b | Studio | 🔸 Rimanda all'ente con osservazioni | Stato "da correggere"; notifica l'ente; si torna al passo 1 | 🔸 dedotto |
|
||||||
|
| 4 | Studio | Approva | Stato "approvato" | RF-4.7 |
|
||||||
|
| 5 | Sistema | — | Applica la marca temporale e archivia in modo definitivo; il documento non è più modificabile | RF-4.5, RF-4.6 (⏳ Q9) |
|
||||||
|
| 6 | Studio / Ente | Stampa | Genera il PDF | RF-4.7, RT-7 |
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. W5: Ciclo contabile (M5)
|
||||||
|
|
||||||
|
**Scopo:** raccogliere i documenti contabili durante l'anno e produrre il rendiconto annuale.
|
||||||
|
|
||||||
|
### 6.1 Ciclo trimestrale
|
||||||
|
|
||||||
|
**Inizio:** scadenza del calendario · **Fine:** movimenti del trimestre imputati.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Studio | Imposta il calendario delle scadenze, uguale per tutti gli enti | ⏳ Ammette modifiche anche per il singolo ente | RF-5.1, D7 (⏳ Q12) |
|
||||||
|
| 2 | Sistema | — | Alla scadenza manda all'ente l'alert per caricare i documenti | RF-5.1, RT-4 |
|
||||||
|
| 3 | Ente | Carica gli estratti conto (Excel o PDF), la prima nota cassa (Excel) e gli eventuali rendiconti delle raccolte fondi occasionali | Archivia i file; ⏳ estrae i movimenti da Excel/CSV | RF-5.2–5.4 (⏳ Q10) |
|
||||||
|
| 4 | Sistema | 🔸 — | 🔸 Se l'ente non carica, manda un sollecito e avvisa lo studio | 🔸 dedotto |
|
||||||
|
| 5 | Studio | Imputa ogni movimento a una voce del Modello D | Salva l'imputazione | RF-5.5, D6 |
|
||||||
|
|
||||||
|
### 6.2 Chiusura annuale
|
||||||
|
|
||||||
|
**Inizio:** fine esercizio · **Fine:** Modello D e relazione pronti da allegare al bilancio.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Sistema | — | Aggrega i movimenti dei quattro trimestri e compila il rendiconto per cassa su Modello D | RF-5.6 |
|
||||||
|
| 2 | Ente | Scrive la relazione illustrativa guidata: attività dell'anno, progetti finanziati e realizzati | Propone i modelli preimpostati | RF-5.7 |
|
||||||
|
| 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)
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Ente o Studio | Crea il progetto | Apre la procedura guidata | RF-6.1 |
|
||||||
|
| 2 | Ente | Compila le sezioni: contesto, bisogni, idea, obiettivi, attività, risorse, cronoprogramma, costi, piano economico-finanziario | Guida sezione per sezione | RF-6.2 (⏳ Q13 schema di dettaglio) |
|
||||||
|
| 3 | Ente | Invia allo studio | Stato "in revisione" | RF-6.4 (⏳ Q19) |
|
||||||
|
| 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)
|
||||||
|
|
||||||
|
**Scopo:** informare gli enti su scadenze e adempimenti.
|
||||||
|
**Inizio:** lo studio deve comunicare una scadenza · **Fine:** circolare consegnata e letta.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Studio | Scrive la circolare (amministrativa, contabile o fiscale) | — | RF-8.1 |
|
||||||
|
| 2 | Studio | 🔸 Sceglie i destinatari: tutti gli enti o una parte | — | 🔸 dedotto |
|
||||||
|
| 3 | Sistema | — | Invia via email e pubblica nell'area comunicazioni dell'ente | RF-8.2, D5 |
|
||||||
|
| 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
|
||||||
|
|
||||||
|
**Scopo:** redigere il bilancio sociale riusando i dati già presenti.
|
||||||
|
**Inizio:** fine esercizio · **Fine:** bilancio sociale esportato.
|
||||||
|
|
||||||
|
> ⏳ Stessa ipotesi di W6 (Q19, opzione a). Le sezioni sono da confermare (Q14).
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Ente o Studio | Avvia il bilancio sociale dell'anno | Precompila con i dati già presenti: anagrafica ente (W1), persone (W3), dati economici (W5) | RF-7.1, RF-7.2 |
|
||||||
|
| 2 | Ente | Completa le sezioni: lettera del presidente, dati standard, identità, stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo | Procedura guidata | RF-7.3 (⏳ Q14) |
|
||||||
|
| 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
|
||||||
|
|
||||||
|
**Scopo:** registrare le ore di volontari e dipendenti e darne un valore economico.
|
||||||
|
**Inizio:** l'ente comunica le ore · **Fine:** ore registrate e valorizzate.
|
||||||
|
|
||||||
|
| # | Chi | Azione | Sistema | Rif. |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | Studio | ⏳ Imposta il valore orario per ogni tipo di attività | Salva le tariffe | RF-9.3 (⏳ Q15) |
|
||||||
|
| 2 | Ente | Manda le ore allo studio | ⏳ Forma da definire: fuori dal sistema o tramite caricamento file | ⏳ Q15 |
|
||||||
|
| 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
|
||||||
|
|
||||||
|
| 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 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
Reference in new issue
Block a user