Specifica Funzionale (FSD) v0.4¶
1. Contesto e obiettivi¶
SIS (Student Information System) per una scuola in vari ordini (materna, elementari, medie, superiori). Il sistema deve essere progettato per supportare la gestione integrata di studenti, docenti (interni ed esterni), personale (interno, esterno, amministrativo), genitori e servizi accessori come mensa, trasporto scolastico, psicologi/AIDES, infermeria e sicurezza. La piattaforma dovrà consentire il caricamento, la consultazione e l’aggiornamento dei dati anagrafici e contrattuali, la gestione delle presenze e delle assenze, la programmazione delle lezioni, la gestione delle sostituzioni, l’amministrazione delle tasse scolastiche e delle comunicazioni con le famiglie, nonché le funzioni di reportistica.
2. Ambito¶
Scope¶
Gestione anagrafiche: registrazione e aggiornamento dei dati personali, di contatto, medici, contrattuali e documentali di studenti, docenti (interni ed esterni) e personale; caricamento di documenti (carta d’identità, passaporto, codice fiscale, permesso di soggiorno, diplomi, certificazioni, contratti, CV) e campi personalizzabili.
Gestione presenze e orari: pianificazione degli orari delle classi e degli insegnanti (homeroom e classi), registrazione delle presenze di studenti, docenti e personale, generazione di liste classe giornaliere basate sulle presenze.
Gestione sostituzioni: flusso per la segnalazione di assenze dei docenti di ruolo, identificazione e assegnazione del docente supplente, creazione automatica dell’account con email personale, definizione del periodo di accesso al LMS, notifica al supplente e tracciamento delle ore a contatto/non a contatto.
Comunicazioni: sistema per l’invio di comunicazioni e newsletter a genitori e personale; possibilità per i genitori di comunicare variazioni tramite app; integrazione con social/eventi; cross-check automatici con la presenza degli studenti.
Classi e corsi: creazione e modifica di classi/homerooms, associazione docenti/studenti, gestione di materie e attività; scheduling di afterschool e coordinamento.
Gestione calendario e timetabling: definizione dei programmi scolastici (curricula), dei cicli e gradi, creazione delle classi e dei piani di studio con materie e ore settimanali; generazione automatica delle lezioni e dello schema orario utilizzando vincoli (docente, classe, aula, compatibilità, capienza, ore da contratto, numero di ore per materia) e regole organizzative (distribuzione settimanale, continuità didattica, doppie ore, lezioni multi‑classe); supporto a più sistemi scolastici (italiano, IB, British); gestione del calendario scolastico e dei time slot disponibili.
Out of scope¶
Amministrazione finanziaria: gestione delle rette scolastiche e delle quote extra, possibilità di aggiungere “one-off fees”, struttura tariffaria personalizzabile, tracciamento dei pagamenti (status, scadenze), integrazione con il contabile e tasto di pagamento diretto; notifica automatica in caso di morosità.
Reportistica e audit: generazione di report su presenze, assenze, sostituzioni, pagamenti, ore di docenza e statistiche per dipartimento; audit trail delle modifiche anagrafiche e cambi di stato.
Gestione ammissioni: modulo completo per il ciclo di ammissione di nuovi studenti, composto da un form di application multi-step con campi su studente, informazioni mediche, genitori, contatti di emergenza, preferenze di pagamento e servizi; supporto a upload di documenti (passaporti, certificati, vaccinazioni) con anteprima e OCR; progress bar e salvataggio automatico; possibilità per il candidato di pianificare tour/interviste tramite calendario integrato; workflow per generare e firmare digitalmente il contratto di iscrizione, gestire la quota di iscrizione (stato “arrivata/non arrivata” con reminder) e inviare credenziali al momento del pre‑enrollment; dashboard e report sui candidati per grado, paese d’origine, tasso di conversione e importi raccolti.
Piattaforme di pagamento esterne (integrazione con il pagamento online verrà definita successivamente);
Gestione servizi accessori: mensa (gestione di allergie alimentari, diete speciali, accesso a costo ridotto per dipendenti, numero di persone), trasporto scolastico (gestione autobus e accompagnatori), infermeria, psicologi/AIDES, sicurezza.
Assunzioni¶
Il sistema deve integrarsi con Empowered per consentire ai supplenti di accedere ai piani di lezione caricati dal docente di ruolo.
Per ogni studente/docente/personale è previsto un set minimo di dati (vedere sezione modello dati); campi aggiuntivi possono essere configurati dall’amministratore.
Alcuni servizi (psicologi, mensa, bus, infermeria, sicurezza) possono essere opzionali a seconda dell’istituto; l’abilitazione di tali moduli è configurabile.
Dipendenze e vincoli¶
Empowered per l’accesso ai piani di lezione dei docenti;
Sistema di pagamento elettronico per l’incasso delle rette (da integrare tramite API ma inizialmente inserimento manuale "pagato");
Eventuali servizi esterni per la firma digitale dei contratti;
Infrastruttura cloud con supporto a container, database relazionale e sistemi di messaggistica/email;
Vincoli normativi come GDPR per la protezione dei dati personali, normativa scolastica nazionale per la gestione degli archivi.
3. Attori e permessi¶
Di seguito i principali ruoli identificati e un sommario dei permessi. I permessi dovranno essere implementati a livello di API e interfaccia utente con un sistema RBAC (Role‑Based Access Control). Ulteriori ruoli specifici (psicologi, AIDES, infermieri) ereditano permessi dal ruolo “Staff” con eventuali permessi aggiuntivi.
| Ruolo | Descrizione | Permessi principali |
|---|---|---|
| Admin | Gestisce la configurazione generale del sistema, crea/gestisce ruoli, imposta campi personalizzati, abilita/disabilita moduli, accede a tutti i dati. | CRUD completo su tutte le entità; gestione utenti e permessi; audit e report globali. |
| HR/Segreteria | Personale amministrativo responsabile di anagrafiche, contratti, sostituzioni e pagamenti. | Gestione anagrafiche di studenti/docenti/staff; creazione/aggiornamento classi; gestione contratti e documenti; creazione sostituzioni; gestione pagamenti; generazione report. |
| Head of education/Principal | Direzione didattica, supervisiona docenti e classi. | Visualizza dati aggregati di studenti/docenti; approva sostituzioni; visualizza report; invia comunicazioni globali. |
| Docente interno | Insegnante di ruolo appartenente all’istituto. | Accede ai propri orari, classi e studenti; registra presenze; carica piano della giornata sul LMS; segnala assenze; consulta comunicazioni. |
| Docente esterno (supplente) | Insegnante esterno chiamato per supplenze. | Accesso temporaneo e limitato a classi/orari assegnati; consulta piano della giornata; registra presenze; accesso al LMS solo per la durata della supplenza. |
| Personale interno | Collaboratori scolastici, addetti mensa, infermieri, psicologi, addetti alla sicurezza, personale di segreteria non HR. | Visualizza/elabora dati necessari al proprio servizio: es. mensa (diete, allergie, numero pasti), trasporto (lista studenti, presenze), infermeria (cartelle mediche), sicurezza (accessi). |
| Personale esterno | Fornitori o personale esterno (bus driver, consulenti) non dipendenti. | Accesso limitato alle funzioni specifiche (es. percorso bus, lista studenti assegnati), upload documenti contrattuali. |
| Studente | Utente finale (o tramite account genitore) che può accedere a orari, presenze, comunicazioni. | Visualizza e aggiorna i propri dati personali (nei limiti), consulta calendario e comunicazioni; visualizza pagamenti effettuati. |
| Genitore/Tutore | Responsabile dello studente. | Consulta anagrafica del proprio figlio, calendario, presenze e pagamenti; paga rette; invia comunicazioni di cambiamenti (es. assenze, permessi). |
| Accountant/Finance | Responsabile contabile. | Gestione delle rette e dei pagamenti; configurazione struttura tariffaria; accesso ai report finanziari; collegamento con sistemi contabili esterni. |
| Guest | Utente non autenticato. | Accesso al portale pubblico (es. informazioni generali), form di interesse per nuovi iscritti. |
| Responsabile Ammissioni | Figura che gestisce il processo di ammissione, dalla ricezione delle candidature alla decisione finale. | Visualizza e modifica le application; pianifica colloqui e tour; genera contratti e coordina la firma digitale; monitora pagamenti della quota di iscrizione; assegna stato (accepted/rejected/pre‑enrolled) e genera credenziali; accede a dashboard e report ammissioni. |
| Candidato/Prospect | Persona esterna interessata a iscriversi. | Compila e salva il form di application multi‑step; carica documenti; pianifica tour/interviste; riceve comunicazioni e notifiche di stato; visualizza il proprio progresso e può completare in più sessioni; accetta o rifiuta la proposta di iscrizione. |
| Custom | Ruolo configurabile da piattaforma | Custom |
Bozza permessi, saranno dettagliati in fase di implementazione; le autorizzazioni potranno essere ulteriormente granulari su singoli campi sensibili (es. dati medici).
4. User journeys e flussi¶
4.1 Flussi principali¶
4.1.1 Gestione anagrafica studente¶
Segreteria crea un nuovo record studente inserendo i dati anagrafici (nome, cognome, data di nascita, genere, nazionalità), contatti (telefono, email), indirizzo, documenti (carta d’identità, passaporto, codice fiscale), informazioni mediche (allergie, diete speciali), dati di iscrizione (classe, ordine scolastico, status: interessato → pre-iscritto → iscritto).
Possono essere aggiunti campi custom in base alle esigenze (es. interessi extracurriculari).
La segreteria assegna lo studente a una classe/homeroom e a eventuali servizi (mensa, bus, afterschool).
Il sistema genera le credenziali per studente e genitore, inviando email con istruzioni di accesso.
Lo studente/genitore può accedere per consultare i dati, aggiornare alcuni campi (es. contatti), pagare le rette e ricevere comunicazioni.
4.1.2 Segnalazione assenza docente e gestione supplenza¶
Docente di ruolo accede al sistema e segnala la propria assenza indicando data/e e motivazione.
HR/Segreteria riceve la notifica di assenza e consulta l’elenco dei docenti disponibili (interni ed esterni) con competenze affini e disponibilità oraria.
HR seleziona un docente supplente e ne verifica i documenti (contratto, CV) presenti in anagrafica.
Il sistema genera un account temporaneo per il supplente (o attiva un account esistente) e definisce l’intervallo di validità in base alla durata dell’assenza.
Viene inviata una email automatica al supplente con le credenziali e le istruzioni per accedere ad Empowered e al SIS.
Il supplente accede, consulta il piano della giornata caricato dal docente di ruolo e svolge le lezioni.
Alla fine del periodo, il sistema revoca automaticamente l’accesso del supplente e aggiorna il registro delle presenze/ore lavorate.
4.1.3 Pagamento rette e gestione quote¶
Segreteria configura il listino delle rette (tariffa base, tariffe agevolate, extra “one‑off”, scadenze).
Per ogni studente viene generato un piano di pagamento con importi e scadenze; lo stato dei pagamenti è visualizzabile nella sezione finanziaria.
Il genitore accede al sistema, vede il dettaglio delle rette da pagare e può effettuare il pagamento tramite tasto di pagamento diretto (integrazione con gateway esterno).
All’avvenuto pagamento, il sistema aggiorna lo status del pagamento, invia ricevuta via email e notifica l’accountant.
In caso di pagamento mancante oltre la scadenza, il sistema attiva una procedura di sollecito con notifica al genitore e segreteria; se i pagamenti rimangono insoluti viene generato un alert per la direzione.
4.1.4 Comunicazioni scuola–famiglia¶
La scuola pubblica newsletter, avvisi o eventi tramite un modulo di comunicazione integrato, selezionando le classi o gruppi target.
I genitori ricevono la comunicazione via app/email e possono inviare richieste o variazioni (es. permessi, variazione orario, deleghe).
Il sistema incrocia automaticamente le comunicazioni con la presenza dello studente (es. se un genitore segnala uscita anticipata, la segreteria lo vede nel registro presenze).
Tutte le comunicazioni sono salvate per fini di audit e tracciabilità.
4.1.5 Gestione mensa e diete¶
All’iscrizione o durante l’anno, la segreteria raccoglie le informazioni alimentari (allergie, intolleranze, diete speciali) dello studente/personale.
Le informazioni vengono condivise con il personale mensa, che visualizza la lista dei pasti per giorno/classe, il numero di pasti e le eventuali restrizioni.
Per i dipendenti è possibile impostare pasti a costo ridotto; il sistema registra il numero di pasti consumati e invia i dati alla contabilità.
È possibile generare report su diete speciali e allergie per la gestione della mensa.
4.2 Edge cases e flussi alternativi¶
Assenza docente last‑minute: se l’assenza è comunicata con poco preavviso, il sistema invia una notifica urgente a una lista di supplenti disponibili e permette la conferma della disponibilità via app; il primo supplente che accetta viene assegnato.
Studente con allergie multiple: nel caso di combinazioni di allergie/diete, il sistema segnala la criticità sia alla mensa che all’infermeria e richiede conferma della presa visione.
Pagamento fallito: se il pagamento elettronico fallisce, il genitore può scegliere un metodo alternativo (bonifico, contanti in segreteria) e la segreteria aggiorna manualmente lo status.
Genitore non tecnologico: in caso di utenti senza email/app, la segreteria può stampare comunicazioni e registrare manualmente l’acknowledgement.
Campo custom richiesto: quando un dipartimento richiede un nuovo campo anagrafico, l’admin deve approvarne la creazione verificando l’impatto su GDPR e modulo di registrazione.
Incomplete application: se un candidato non completa il modulo o non allega tutti i documenti, il sistema invia promemoria automatici; dopo un numero configurabile di remind senza risposta, l’application viene contrassegnata come Dormant e archiviata.
Intervista mancata: se il candidato non si presenta all’intervista, il responsabile può riprogrammarla; dopo due no‑show consecutivi, l’application viene messa in stand‑by fino a nuova richiesta.
Pagamento non ricevuto: se la quota di iscrizione non viene ricevuta entro la scadenza, il sistema invia ulteriori solleciti e può annullare l’offerta dopo X giorni; il posto viene assegnato ad altri candidati.
Conflitto di orari nell’agenda: il calendario integrato deve gestire sovrapposizioni; se due candidati prenotano lo stesso slot, il sistema ne impedisce la conferma e propone altri slot disponibili.
4.3 Diagramma di flusso – Sostituzione docente¶
flowchart TD
A[Docente di ruolo segnala assenza] --> B{HR riceve assenza}
B --> C[Verifica disponibilità docenti]
C --> D[Seleziona supplente]
D --> E[Genera account temporaneo]
E --> F[Definisce periodo di accesso]
F --> G[Invia email al supplente]
G --> H[Supplente accede al SIS/LMS]
H --> I[Registra presenze e ore]
I --> J[Revoca accesso a fine periodo]
### 4.4 Flusso di ammissione
Il Candidato avvia una nuova application dal portale pubblico compilando un modulo multi‑step. I passi includono: informazioni dello studente (nome, data di nascita, genere, nazionalità), contatti e indirizzo, documenti (passaporto, carte di identità, certificati medici), informazioni mediche (allergie, disabilità, supporti), dati su genitori/guardian (relazione, contatti, indirizzo, occupazione) e preferenze di pagamento e servizi (afterschool, mensa, bus). Il modulo supporta progress bar, autosalvataggio e caricamento drag‑and‑drop di documenti; viene mostrata una checklist “cosa manca” per facilitare il completamento.
Una volta completato, il candidato invia l’application che va nello stato Submitted/Pending; il Responsabile Ammissioni riceve una notifica e la domanda appare in una kanban board con filtri (grado, paese, status, documenti mancanti).
Il responsabile verifica la completezza dei documenti, può richiedere integrazioni e pianifica una intervista o tour tramite calendario integrato con gestione del fuso orario e link a videocall (Zoom/Teams). Il candidato riceve email/SMS di invito e può riprogrammare.
Dopo l’intervista, l’intervistatore registra l’esito e il responsabile può accettare o rifiutare. In caso di accettazione, il sistema genera un contratto di iscrizione con importo e condizioni; il candidato riceve via email un link per la firma digitale. Il sistema traccia lo stato del contratto (“drafting”, “sent”, “received/signed”) e invia reminder se non è stato ancora restituito.
In parallelo viene richiesta la quota di iscrizione al reparto contabile. Lo stato “Arrivato/Non arrivato” viene aggiornato; in caso di mancato pagamento vengono inviati solleciti automatici.
Dopo la firma del contratto e il pagamento della quota, l’application passa allo stato Pre‑enrolled. Le credenziali per l’accesso verranno inviate all’inizio dell’anno scolastico (prima settimana di settembre).
La segreteria/HR converte l’application in un record studente nel SIS, associando la classe e i servizi scelti; lo stato diventa Enrolled.
Ogni anno tra febbraio e giugno, agli studenti iscritti viene inviata una richiesta di re‑enrollment: se i genitori confermano, compilano e firmano il modulo e lo studente rimane in stato “Enrolled”; in caso contrario lo studente viene spostato nella lista Leavers.
Tutte le fasi prevedono comunicazioni automatiche con template personalizzabili (email, SMS), utilizzo di token (nome studente, programma, data intervista) e registrazione nel sistema di audit.
4.4 Flusso di ammissione¶
Candidato/Prospect accede al portale di ammissione come ospite e avvia la compilazione del modulo multi‑step. I passi includono:
Dati dello studente: nome, cognome, data di nascita, genere, nazionalità, stato di provenienza, indirizzo di residenza, attuale scuola e livello, lingua primaria, eventuali bisogni educativi speciali.
Informazioni mediche: allergie alimentari, allergie a farmaci, diete speciali, problemi medici, certificato medico, tipo di disabilità, necessità di supporto docente.
Genitori e contatti: Parent 1, Parent 2, altri tutori; per ciascuno relazione, nome completo, indirizzo, contatti (telefono, email), professione, lingua principale, autorizzazione al ritiro; possibilità di duplicare l’indirizzo dello studente.
Preferenze di pagamento: scelta tra annuale, mensile o trimestrale; definizione del genitore responsabile del pagamento; indicazione dei servizi richiesti (afterschool, mensa, bus).
Allegati: upload di documenti come passaporto, carta d’identità, permesso di soggiorno, certificati di vaccinazione, pagelle, certificati medici. Il modulo supporta anteprima inline e drag‑and‑drop.
Consensi: caselle di consenso per la privacy, l’uso dei dati per marketing e accettazione delle politiche di cancellazione/retention secondo GDPR.
Il candidato può salvare il modulo in bozza (autosave) e riprenderlo successivamente; il sistema mostra una barra di progresso e un elenco “cosa manca”.
Al termine della compilazione, il modulo viene inviato e lo status dell’application passa a Submitted/Pending. Il sistema invia una conferma via email e crea una voce nella kanban board per il Responsabile Ammissioni.
Responsabile Ammissioni verifica la completezza dei documenti, può richiedere integrazioni e pianifica un colloquio/intervista tramite un calendario integrato con supporto a fusi orari e link a videocall (Zoom/Teams). I candidati ricevono email/SMS di convocazione con possibilità di riprogrammare.
Dopo il colloquio, l’intervistatore registra l’esito e l’ammissione passa allo stato Accepted o Rejected. Per i candidati accettati:
Viene generato un contratto di iscrizione con importo della retta e condizioni; inviato via email per firma digitale.
Il sistema controlla la ricezione del contratto: stato “Not arrived” → invio reminder; “Contract received” → procedere.
In parallelo viene richiesta la quota di iscrizione al reparto contabile; se il pagamento non arriva entro la data prevista, vengono inviati solleciti.
Una volta firmato il contratto e verificato il pagamento, l’applicazione passa allo stato Pre‑enrolled e vengono generate le credenziali che saranno inviate all’inizio dell’anno scolastico (prima settimana di settembre).
La segreteria converte il record dell’application in un record studente nel SIS, associandolo alla classe e ai servizi scelti; lo status diventa Enrolled.
Re‑enrollment: tra febbraio e giugno, il sistema invia un modulo di rinnovo agli studenti iscritti con la retta per l’anno successivo. Se i genitori confermano e firmano, lo studente rimane in stato “Enrolled”; se non confermano, viene spostato nella lista Leavers.
Tutte le fasi prevedono comunicazioni automatiche (email/SMS) e possibilità di personalizzazione dei template. I report e le dashboard consentono al responsabile di monitorare candidature per grado, paese di origine, tasso di risposta, tempo‑per‑offerta e fees raccolte.
4.5 Creazione e gestione del calendario scolastico¶
Definizione del curriculum: l’Admin o la segreteria crea un programma scolastico (es. italiano, IB, British) e definisce i cicli (materna, primaria, media, superiore). Per ogni ciclo vengono definiti i gradi (es. Grade 1, Year 7) e le relative classi/sezioni.
Creazione del piano di studio: per ogni classe si definisce il piano di studio con l’elenco delle materie e il numero di ore settimanali (es. italiano 4 ore, matematica 3 ore). Eventuali percorsi specifici di liceo/indirizzo nelle scuole superiori sono gestiti come livelli aggiuntivi.
Definizione del calendario scolastico e degli slot: l’Admin imposta il calendario scolastico (giorni di lezione, festività) e crea gli slot orari disponibili (ora di inizio/fine, giorno, eventuali pause) per ogni ciclo.
Assegnazione docenti e aule: il responsabile orari assegna ad ogni materia un docente qualificato e una aula compatibile, tenendo conto delle disponibilità dei docenti, della capienza e attrezzatura delle aule.
Generazione automatica dello schema orario: il sistema utilizza un algoritmo di scheduling che assegna ogni lezione a uno slot, rispettando i vincoli bloccanti (nessun docente/classe/aula in due lezioni contemporanee, rispetto del numero di ore da contratto, compatibilità materia–docente–aula, rispetto delle ore previste dal piano di studio) e i vincoli organizzativi (distribuzione equilibrata durante la settimana, doppie ore dove richiesto, no buchi nel calendario, possibilità di lezioni con studenti di classi differenti).
Revisione e aggiustamenti: il responsabile può visualizzare la bozza dello schema orario, identificare conflitti, apportare modifiche manuali (es. spostare una lezione, inserire una doppia ora), con evidenza dei vincoli violati.
Pubblicazione: una volta approvato, lo schema orario viene pubblicato sul sistema; docenti, studenti e genitori possono visualizzare il proprio calendario, con notifiche automatiche in caso di modifiche.
Aggiornamenti dinamici: in caso di variazioni (assenze docenti, eventi speciali, aggiornamenti al piano di studio), il sistema rigenera le parti interessate dello schedule mantenendo i vincoli e notifica gli utenti coinvolti.
5. Requisiti funzionali¶
La seguente lista numerata definisce i requisiti funzionali principali. Le priorità sono indicate come Alta (A), Media (M) o Bassa (B).
| ID | Descrizione | Priorità | Criteri di accettazione |
|---|---|---|---|
| FR‑001 | Gestione anagrafiche per studenti, docenti, personale e genitori con campi obbligatori (nome, cognome, data di nascita, genere, nazionalità, contatti) e campi custom configurabili. | A | È possibile creare, leggere, aggiornare e cancellare (CRUD) un record; i campi obbligatori sono validati; i campi custom possono essere creati dall’Admin e appaiono nei form. |
| FR‑002 | Caricamento e gestione documenti (carta d’identità, passaporto, codice fiscale, permesso di soggiorno, titoli di studio, certificazioni, contratti, CV) in formato digitale per ogni record. | A | È possibile associare n documenti a ciascun soggetto; i file vengono salvati in modo sicuro; i documenti possono essere scaricati/aggiornati; tracciamento di chi e quando ha caricato il documento. |
| FR‑003 | Gestione informazioni mediche: registrazione di allergie alimentari, allergie a farmaci, diete speciali e note mediche, con visibilità controllata a mensa, infermeria e personale autorizzato. | A | L’utente autorizzato può inserire e aggiornare i dati; la mensa visualizza solo le informazioni necessarie; il sistema impedisce la visualizzazione a ruoli non autorizzati; audit trail delle modifiche. |
| FR‑004 | Creazione e gestione di classi e homerooms, con assegnazione di studenti e docenti e definizione dell’orario settimanale. | A | È possibile creare/modificare/eliminare classi; assegnare studenti e docenti; definire orari (giorni, fasce orarie, materia); visualizzare calendario; generare lista classe giornaliera. |
| FR‑005 | Gestione presenze per studenti, docenti e personale, con registrazione delle presenze/assenze, motivazione e possibilità di consultare report. | A | Docenti e personale possono registrare le presenze tramite interfaccia; i genitori visualizzano le presenze dei figli; report esportabili; edge cases: ritardo, uscita anticipata. |
| FR‑006 | Flusso di segnalazione assenza docente e sostituzione come descritto nel flusso 4.1.1. | A | Quando un docente segnala un’assenza, HR riceve una notifica; è possibile selezionare un supplente; il sistema genera account temporaneo e invia email; a fine periodo l’accesso viene revocato; log completo del processo. |
| FR‑007 | Integrazione con Empowered per consentire ai docenti di ruolo di caricare il piano della giornata e ai supplenti di consultarlo automaticamente. | M | È disponibile una sezione per il caricamento del piano; il supplente accede e vede le attività assegnate senza interazioni manuali. |
| FR‑008 | Gestione finanziaria: configurazione delle rette, quote extra e structure tariffaria; generazione di piani di pagamento per ogni studente; tracking dei pagamenti con scadenze e status; invio di solleciti. | A | Admin/Accountant può definire tariffe e scadenze; il sistema genera il piano per ogni studente; lo status del pagamento si aggiorna automaticamente dopo il pagamento; solleciti automatici se in ritardo. |
| FR‑009 | Funzione di pagamento diretto con integrazione a gateway esterno. | M | Il genitore può avviare il pagamento dall’interfaccia; il pagamento viene processato esternamente; ricezione di esito (success/failure) e aggiornamento dello status. |
| FR‑010 | Sistema di comunicazioni: invio di newsletter, avvisi e messaggi a gruppi di utenti (classi, genitori, personale); possibilità per i genitori di inviare comunicazioni di variazione. | M | L’interfaccia consente di creare e inviare comunicazioni; i destinatari ricevono notifica via app/email; le comunicazioni vengono salvate; gli utenti possono rispondere/inoltrare richieste; cross‑check con presenza studenti. |
| FR‑011 | Gestione mensa: registrazione dei pasti, visualizzazione di allergie e diete, gestione pasti a costo ridotto per dipendenti, reportistica. | M | La mensa può visualizzare la lista giornaliera di pasti per classe; segnala eventuali allergie/diete; registra numero di pasti consumati e invia dati al finance; applica sconti per dipendenti. |
| FR‑012 | Gestione trasporto (bus): assegnazione di studenti alle corse, gestione degli autisti e del personale accompagnatore, registrazione della salita/discesa, orari e percorsi. | B | È possibile definire percorsi e orari dei bus, assegnare studenti; registrare presenze a bordo; inviare notifiche ai genitori in caso di ritardo o variazioni. |
| FR‑013 | Gestione servizi ausiliari (infermeria, psicologi/AIDES, sicurezza): accesso ai dati necessari, registrazione interventi e richieste. | B | L’infermeria può registrare visite e terapie; psicologi/AIDES possono registrare incontri; il personale di sicurezza può consultare liste autorizzati e gestire accessi. |
| FR‑014 | Possibilità di aggiungere/eliminare/modificare campi personalizzati per le anagrafiche e i moduli, con gestione dei diritti di visualizzazione. | M | L’Admin può creare nuovi campi; è possibile definire il tipo (testo, numero, data, documento), se obbligatorio e chi lo può vedere/modificare; i moduli si aggiornano dinamicamente. |
| FR‑015 | Reporting e analytics: generazione di report personalizzabili su presenze, sostituzioni, pagamenti, ore di docenza, status studenti (interessato, pre‑iscritto, iscritto) e altre metriche. | M | L’utente autorizzato può selezionare un periodo, filtri e campi; il sistema genera report esportabili (PDF/CSV); grafici interattivi; possibilità di salvare template di report. |
| FR‑016 | Modulo di ammissione multi‑step: creazione e gestione di un form suddiviso in step (studente, documenti, informazioni mediche, genitori/guardians, servizi, pagamento) con progress bar, salvataggio automatico, verifica dei campi obbligatori e upload di documenti con preview e OCR. | A | È possibile avviare, salvare e riprendere l’application; i documenti possono essere caricati trascinando i file; la progress bar mostra la percentuale di completamento e la checklist di elementi mancanti; il sistema valida la presenza di tutti i campi prima della sottomissione. |
| FR‑017 | Scheduling interviste/tour: integrazione con un calendario che permetta al candidato di prenotare slot di intervista o tour, con gestione dei fusi orari, link a videocall (Zoom/Teams) e possibilità di riprogrammazione. Invio di promemoria via email/SMS. | A | Il candidato vede gli slot disponibili e può prenotare; riceve conferma e promemoria; può riprogrammare; il responsabile e l’intervistatore vedono l’appuntamento nel proprio calendario; in caso di sovrapposizioni viene impedita la prenotazione. |
| FR‑018 | Gestione contratti di iscrizione e firma digitale: generazione automatica del contratto di iscrizione a partire dai dati dell’application, invio via email per firma elettronica, tracciamento dello stato (bozza, inviato, ricevuto/firma) e reminder se la firma non è pervenuta. | A | Il responsabile può generare un contratto per il candidato; l’email contiene link per la firma digitale; il sistema aggiorna lo stato in base al feedback (contract sent, not arrived, arrived); se non ricevuto entro X giorni viene inviato un remind automatico. |
| FR‑019 | Gestione quota di iscrizione: richiesta al reparto contabile del pagamento della quota di iscrizione, monitoraggio dello stato (arrivata/non arrivata) con solleciti e integrazione al modulo finanziario. | A | Al momento dell’accettazione l’application genera un piano di pagamento per la quota di iscrizione; l’Accountant aggiorna lo status a “Arrivato”; se “Non arrivato” entro la scadenza viene inviato un sollecito automatico; il sistema impedisce l’enrollment senza pagamento. |
| FR‑020 | Pre‑enrollment e invio credenziali: transizione dell’application allo stato “Pre‑enrolled” dopo firma contratto e pagamento; generazione e invio automatico delle credenziali prima dell’inizio dell’anno scolastico. | M | Quando contratto e quota sono completati, il sistema marca il candidato come pre‑iscritto; vengono schedulati l’invio delle credenziali (settembre); all’invio il candidato diventa studente nel SIS. |
| FR‑021 | Re‑enrollment annuale: invio automatico del modulo di rinnovo agli studenti iscritti tra febbraio e giugno; raccolta consensi, firma e pagamento della retta; gestione della lista Leavers per chi non rinnova. | M | Il sistema invia il modulo di rinnovo; i genitori completano e firmano entro la scadenza; se confermato, lo studente rimane “enrolled” e viene aggiornato il piano di pagamento per l’anno successivo; se non confermato il sistema lo sposta in stato “Leaver” e avvisa la segreteria. |
| FR‑022 | Reporting ammissioni e dashboard: generazione di report sulle candidature (numero per grado, paese di provenienza, tasso di conversione “interested → accepted”, tempo medio per offrire un posto, importi raccolti) con esportazione in CSV/XLS e dashboard con filtri e grafici. | M | Il responsabile ammissioni può selezionare periodo e filtri; il sistema genera report aggregati e visualizzazioni; i dati possono essere esportati; la dashboard consente di filtrare per status, origine, priorità e documenti mancanti. |
| FR‑023 | Template e comunicazioni per i candidati: gestione di email/SMS template per ogni stato dell’application, con personalizzazione tramite token (nome studente, programma, data intervista) e invio in bulk. | M | L’Admin può creare e modificare template; il responsabile seleziona i destinatari e invia comunicazioni in massa; i token vengono sostituiti automaticamente; le comunicazioni sono registrate nell’audit trail. |
| FR‑024 | Gestione priorità e categorie speciali: possibilità di indicare priorità (sibling priority, figli del personale, ex studenti, feeder schools, aziende convenzionate) e visualizzare lo stato nelle liste di candidati. | B | Durante la compilazione il candidato può indicare relazioni (sibling, staff child); il responsabile ammissioni può applicare filtri e ordinare la lista; il sistema tiene traccia della priorità per l’assegnazione dei posti disponibili. |
| FR‑025 | Funzioni AI e raccomandazioni (Nice‑to‑have): suggerimenti automatici per valutare le candidature (es. punteggio di idoneità), generazione di risposte automatiche, predizione del tempo di conversione. | B | Se abilitato, il sistema calcola un punteggio per ogni candidato basato su criteri configurabili; i suggerimenti devono essere approvati manualmente; l’utente può disattivare o ignorare le raccomandazioni. |
| FR‑026 | Gestione curricula e cicli: creazione e gestione di programmi scolastici (Italiano, IB, British), definizione dei cicli (materna, primaria, media, superiore) e dei livelli/anni associati. | A | L’Admin può creare un curriculum e associare cicli; per ogni ciclo definire i gradi con etichette e ordine; è possibile attivare/disattivare curricula; i livelli sono visibili nelle configurazioni. |
| FR‑027 | Piani di studio e classi: per ogni classe, definizione del piano di studio con elenco materie e ore settimanali; supporto a percorsi specifici per indirizzi nelle scuole superiori. | A | L’utente autorizzato può creare un piano di studio, aggiungere materie con numero di ore; associare il piano a una classe; i piani possono essere versionati; il sistema controlla che le ore totali per materia rispettino lo studio plan. |
| FR‑028 | Calendario scolastico e slot orari: definizione del calendario accademico (giorni di lezione, festività) e configurazione degli slot orari disponibili per ciascun ciclo. | A | L’Admin può impostare periodi di lezione e vacanze; creare time slot con giorno e ora; gli slot sono utilizzati dal motore di scheduling; modifiche al calendario rigenerano lo schedule. |
| FR‑029 | Motore di scheduling e vincoli: generazione automatica dello schema orario per ogni classe sulla base dei piani di studio e dei vincoli bloccanti (non sovrapporre lezioni per classe/docente/aula, compatibilità materia‑docente‑aula, ore da contratto, ore per materia) e organizzativi (distribuzione settimanale, continuità, doppie ore, lezioni multi‑classe). | A | Il sistema produce uno schedule valido senza conflitti; se non trova una soluzione segnala i conflitti; gli utenti possono rigenerare con parametri diversi; il motore considera tutte le ore del piano di studio e le disponibilità dei docenti e aule. |
| FR‑030 | Gestione carico di lavoro e competenze docenti: assicurare che le ore assegnate a ciascun docente non superino il contratto, rispettare il numero massimo di ore a contatto e verificare che il docente sia abilitato a insegnare la materia. | A | Durante lo scheduling il sistema controlla che le ore totali assegnate non eccedano il contratto; se un docente è sovraccarico, segnala un conflitto; solo docenti con le competenze registrate possono essere assegnati; aggiornare le ore quando le lezioni vengono spostate o cancellate. |
| FR‑031 | Lezioni multi‑classe: supporto alla creazione di lezioni che coinvolgono studenti di classi differenti, ad esempio per materie di lingue o corsi opzionali. | M | È possibile definire una lezione multi‑classe selezionando più classi; il sistema assegna un’unica aula e un unico docente; lo scheduling verifica che non ci siano conflitti per ciascuna classe e per l’aula; gli studenti vedono la lezione nel proprio calendario. |
| FR‑032 | Supporto a curricula multipli: capacità di gestire nomenclature diverse per i livelli (Grade, Year) e strutture diverse tra sistemi scolastici (Italiano, IB, British). | M | Il sistema consente di configurare curricula con durate diverse; i nomi dei gradi si adattano alla terminologia del curriculum; i report e le interfacce mostrano i livelli corretti; l’utente può filtrare dati per curriculum. |
| FR‑033 | Modifica manuale e versioning dello schedule: possibilità per l’admin di apportare modifiche manuali allo schedule generato, con rilevamento dei conflitti e salvataggio di versioni. | M | L’utente può spostare o cancellare lezioni; il sistema avvisa se i vincoli vengono violati; le modifiche sono tracciate; è possibile salvare versioni dello schedule e ripristinarle. |
| FR‑034 | Pubblicazione e notifiche schedule: pubblicazione dello schema orario per docenti, studenti e genitori; invio di notifiche automatiche in caso di modifiche. | M | Una volta approvato lo schedule, gli utenti vedono il calendario nelle proprie dashboard; eventuali variazioni generano notifiche via app/email; è possibile esportare lo schedule in PDF/CSV. |
6. Requisiti non funzionali¶
Performance: il sistema deve gestire contemporaneamente centinaia di utenti (docenti, genitori, segreteria) garantendo tempi di risposta < 500 ms per le operazioni standard e < 2 s per operazioni pesanti (generazione report).
Sicurezza: applicare le best practice OWASP (prevenzione XSS/CSRF, injection, session fixation); password e token memorizzati con algoritmi sicuri (bcrypt/argon2) e salting; uso di HTTPS/TLS per tutte le comunicazioni.
Privacy/GDPR: i dati personali e sensibili (sanitari) devono essere trattati in conformità al GDPR; implementare meccanismi di consenso, minimizzazione dei dati, diritto all’oblio e portabilità; registri delle attività (log) con finalità di accountability.
Accessibilità: conformità alle linee guida WCAG 2.1 livello AA; supporto a lettori di schermo; contrasti adeguati; navigazione da tastiera; testi alternativi per immagini.
Compatibilità: supporto cross‑browser (Chrome, Firefox, Safari, Edge) e cross‑device (desktop, tablet, mobile) con design responsive; app mobile per genitori e docenti.
Scalabilità: architettura modulare (microservizi) con possibilità di scalare singoli componenti; utilizzo di container (Docker, Kubernetes) e auto‑scaling.
Osservabilità: logging strutturato, trace distribuiti e metriche mediante stack di monitoring (es. ELK, Prometheus, Grafana); alerting su errori, latenze elevate e anomalie nei pagamenti/presenze.
Internazionalizzazione: supporto multilingue (almeno italiano e inglese) per interfacce e comunicazioni.
Backup giornalieri e piani di disaster recovery.
7. UX/UI requirements¶
Dashboard: vista iniziale personalizzata in base al ruolo (per es. la segreteria vede riepilogo iscrizioni, pagamenti in scadenza, assenze; i docenti vedono orario settimanale e avvisi; i genitori vedono presenze e notifiche). Elementi card, grafici e liste.
Anagrafica utente: moduli suddivisi in sezioni (Informazioni di base, Contatti, Documenti, Informazioni mediche, Lavoro, Servizi); campi obbligatori evidenziati; upload multiplo di documenti con anteprima.
Calendario e orari: vista calendario con possibilità di filtrare per classe, docente, aula; drag‑and‑drop per la programmazione; legenda per tipologie di attività (lezione, afterschool, riunione).
Presenze: interfaccia per registrare presenze/assenze; funzioni quick‑action (marcare tutti presenti, indicare ritardi/uscite anticipate); visualizzazione storica.
Sostituzioni: wizard che guida la segreteria nella selezione del supplente; riepilogo delle assenze e delle sostituzioni in corso; calendario delle coperture.
Pagamenti: sezione “Finance” con tab per configurare tariffe, visualizzare piani di pagamento, inviare solleciti; per i genitori una vista semplice con importi, scadenze e pulsante “Paga ora”.
Comunicazioni: editor di messaggi con template e allegati; rubrica per selezionare destinatari (classi/gruppi); area “Le mie comunicazioni” per genitori.
Servizi accessori:
Mensa: tabella con elenco degli iscritti, allergie, diete, numero pasti, stato dei pasti a costo ridotto;
Bus: percorso e orari, elenco studenti, stato salita/discesa;
Infermeria/PSICO: registro visite, note mediche;
Sicurezza: registro accessi, liste autorizzate.
Responsive design: tutti i moduli dovranno adattarsi a schermi mobili; per azioni critiche (es. segnalazione assenza) fornire workflow semplificato via mobile.
Microcopy e stato: testi chiari e contestuali, messaggi di errore/informazione comprensibili; indicatori di caricamento e stati vuoti (es. “Nessuna comunicazione disponibile”).
Per il modulo di ammissione si prevedono ulteriori requisiti UX/UI:
Form multi‑step con progress bar: il form deve essere suddiviso in step logici (dati studente, documenti, medici, genitori, pagamento); una progress bar visualizza la percentuale di completamento e una checklist riassume cosa manca.
Autosave e drag‑and‑drop: il form salva automaticamente i progressi per evitare perdita di dati; i documenti possono essere caricati trascinando i file, con anteprima inline e OCR per estrarre informazioni chiave.
Calendario integrato: widget per la prenotazione di interviste/tour, con visualizzazione della disponibilità in tempo reale e gestione dei fusi orari.
Kanban board per gli admin: visualizzazione delle application suddivise per status con possibilità di filtrare (grado, paese, documenti mancanti) e applicare azioni di massa (invia remind, contrassegna documenti verificati, esporta CSV).
Mobile‑first: layout progettato per l’utilizzo da smartphone, visto che molte famiglie internazionali compilano il modulo da telefono.
Contenuti legali e consensi: presentazione chiara delle clausole di trattamento dati e marketing, con checkbox separate e link alla privacy policy; visualizzazione dell’informativa e richiesta di consenso ai genitori/tutori.
8. Modello dati¶
Campi essenziali. Campi custom saranno memorizzati in una tabella separata con riferimento all’entità proprietaria.
8.1 Entità core¶
| Entità | Campo | Tipo | Descrizione | Regole |
|---|---|---|---|---|
| Person | id | UUID | Identificativo univoco | obbligatorio |
| name | string | Nome | obbligatorio | |
| surname | string | Cognome | obbligatorio | |
| gender | enum (M/F/Altro) | Genere | obbligatorio | |
| date_of_birth | date | Data di nascita | obbligatorio | |
| nationality | string | Nazionalità | opzionale | |
| tax_code | string | Codice fiscale / SSN | opzionale | |
| contacts | JSON | Numeri di telefono, email, indirizzo | minimo un recapito | |
| documents | JSON | Elenco documenti caricati (tipo, file, data) | minimo documento identità | |
| medical_info | JSON | Allergie, diete, note mediche | visibile solo a ruoli autorizzati | |
| created_at, updated_at | timestamp | Timestamps di sistema | generati automaticamente |
| Entità | Campo | Tipo | Descrizione | Regole |
|---|---|---|---|---|
| Student | person_id | UUID (FK Person.id) | Relazione 1:1 con Person | obbligatorio |
| status | enum (interested, pre_enrolled, enrolled, withdrawn) | Stato dello studente | default “interested” | |
| school_order | enum (kindergarten, elementary, middle, high) | Ordine scolastico | obbligatorio | |
| class_id | UUID (FK Class.id) | Classe/Homeroom | obbligatorio alla conferma iscrizione | |
| services | JSON | Servizi attivati (mensa, bus, afterschool) | opzionale | |
| guardian_id | UUID (FK Parent.id) | Tutore principale | opzionale | |
| Parent | person_id | UUID (FK Person.id) | Identità del genitore | obbligatorio |
| students | array(UUID) | Figli associati | almeno uno | |
| communications_pref | enum (email, app, sms) | Preferenza di comunicazione | default app+email | |
| Teacher | person_id | UUID (FK Person.id) | Identità docente | obbligatorio |
| type | enum (internal, external) | Tipo di docente | obbligatorio | |
| department | string | Dipartimento di insegnamento | obbligatorio | |
| subjects | array(string) | Materie abilitate | almeno una | |
| available_days | array(date) | Giorni disponibili | obbligatorio per esterni | |
| contract_type | enum (indefinite, fixed_term, project_based, consultant) | Tipo contratto | obbligatorio | |
| contract_time | enum (full_time, part_time) | Orario di lavoro | obbligatorio | |
| Staff | person_id | UUID (FK Person.id) | Identità del personale | obbligatorio |
| role | enum (administration, canteen, bus, nurse, psychologist, security, aide, other) | Ruolo di servizio | obbligatorio | |
| department | string | Dipartimento di appartenenza | opzionale | |
| Class | id | UUID | Identificativo classe/homeroom | obbligatorio |
| name | string | Nome/etichetta classe | obbligatorio | |
| school_order | enum | Ordine scolastico | obbligatorio | |
| coordinator_teacher_id | UUID (FK Teacher.person_id) | Coordinatore di classe | opzionale | |
| students | array(UUID) | Studenti assegnati | ||
| teachers | array(UUID) | Docenti assegnati | ||
| ScheduleEntry | id | UUID | Identificativo entry di calendario | obbligatorio |
| class_id | UUID | Classe | obbligatorio | |
| teacher_id | UUID | Docente responsabile | obbligatorio | |
| subject | string | Materia/attività | obbligatorio | |
| start_time | datetime | Data e ora inizio | obbligatorio | |
| end_time | datetime | Data e ora fine | obbligatorio | |
| location | string | Aula/luogo | opzionale | |
| AttendanceRecord | id | UUID | Identificativo presenza | obbligatorio |
| schedule_entry_id | UUID | Riferimento alla lezione | obbligatorio | |
| person_id | UUID | Studente/docente/personale | obbligatorio | |
| status | enum (present, absent, late, excused) | Stato della presenza | obbligatorio | |
| reason | string | Motivo assenza/ritardo | opzionale | |
| timestamp | datetime | Data registrazione | automatico | |
| Absence | id | UUID | Identificativo assenza docente | obbligatorio |
| teacher_id | UUID | Docente assente | obbligatorio | |
| start_date | date | Data inizio assenza | obbligatorio | |
| end_date | date | Data fine assenza | obbligatorio | |
| reason | string | Motivazione | opzionale | |
| substitute_teacher_id | UUID | Docente supplente | aggiornato quando assegnato | |
| status | enum (reported, assigned, closed) | Stato della pratica | default reported | |
| PaymentPlan | id | UUID | Piano di pagamento dello studente | obbligatorio |
| student_id | UUID | Studente | obbligatorio | |
| items | JSON | Elenco rate/quote con importo, scadenza, stato | almeno una rata | |
| total_amount | decimal | Totale dovuto | calcolato | |
| paid_amount | decimal | Totale pagato | aggiornato | |
| Fee | id | UUID | Quota o tariffa configurabile | obbligatorio |
| name | string | Nome quota (es. retta, mensa, afterschool, one‑off) | obbligatorio | |
| amount | decimal | Importo | obbligatorio | |
| recurrence | enum (one_time, monthly, yearly) | Frequenza | obbligatorio | |
| description | string | Descrizione dettagliata | opzionale |
Campi e relazioni aggiuntive (es. per bus, mensa, infermeria) verranno modellati analogamente, con riferimento agli ID delle entità core.
8.2 Entità ammissioni¶
| Entità | Campo | Tipo | Descrizione | Regole |
|---|---|---|---|---|
| AdmissionApplication | id | UUID | Identificativo univoco | obbligatorio |
| candidate_person_id | UUID (FK Person.id) | Riferimento al candidato (entità Person) | obbligatorio | |
| status | enum (draft, submitted, pending, interview, accepted, rejected, contract_sent, contract_signed, deposit_pending, pre_enrolled, enrolled) | Stato dell’application | default draft | |
| form_data | JSON | Dati compilati nei vari step (student, documenti, medici, genitori, servizi) | salvato ad ogni autosave | |
| progress | integer (0‑100) | Percentuale di completamento | aggiornato automaticamente | |
| missing_items | JSON | Checklist di documenti/campi mancanti | generata dal sistema | |
| submission_date | datetime | Data di sottomissione del modulo | valorizzata al submit | |
| interview_slot_id | UUID (FK InterviewSlot.id) | Colloquio programmato | opzionale | |
| contract_id | UUID (FK Contract.id) | Contratto generato | opzionale | |
| deposit_status | enum (not_requested, pending, arrived) | Stato della quota di iscrizione | default not_requested | |
| created_at, updated_at | timestamp | Audit | generati automaticamente | |
| InterviewSlot | id | UUID | Identificativo slot | obbligatorio |
| interviewer_id | UUID (FK Person.id) | Persona che conduce l’intervista | obbligatorio | |
| scheduled_at | datetime | Data e ora dell’intervista | obbligatorio | |
| duration | integer (minuti) | Durata prevista | obbligatorio | |
| location | string | Luogo o link videoconferenza | obbligatorio | |
| status | enum (booked, completed, cancelled) | Stato dello slot | default booked | |
| Contract | id | UUID | Identificativo contratto | obbligatorio |
| application_id | UUID (FK AdmissionApplication.id) | Application associata | obbligatorio | |
| file | string (URL) | Percorso del file PDF firmabile | obbligatorio | |
| amount | decimal | Importo totale della retta | obbligatorio | |
| status | enum (drafting, sent, signed) | Stato del contratto | default drafting | |
| sent_at | datetime | Data di invio | opzionale | |
| signed_at | datetime | Data di firma | opzionale | |
| Consent | id | UUID | Identificativo consenso | obbligatorio |
| application_id | UUID (FK AdmissionApplication.id) | Application | obbligatorio | |
| type | enum (data_processing, marketing) | Tipo di consenso | obbligatorio | |
| given | boolean | Se il consenso è stato fornito | default false | |
| timestamp | datetime | Data di accettazione/negazione | obbligatorio | |
| ReEnrollment | id | UUID | Identificativo rinnovo | obbligatorio |
| student_id | UUID (FK Student.person_id) | Studente interessato | obbligatorio | |
| year | integer | Anno scolastico di riferimento | obbligatorio | |
| status | enum (pending, confirmed, not_confirmed) | Stato del rinnovo | default pending | |
| contract_id | UUID (FK Contract.id) | Contratto di rinnovo | opzionale | |
| updated_at | datetime | Timestamp | automatico |
Queste entità si aggiungono al modello core e consentono di tracciare l’intero ciclo di ammissione, dal form di candidatura all’enrollment e rinnovo.
8.3 Entità timetabling¶
| Entità | Campo | Tipo | Descrizione | Regole |
|---|---|---|---|---|
| Curriculum | id | UUID | Identificativo del programma (es. italiano, IB, British) | obbligatorio |
| name | string | Nome del programma | obbligatorio | |
| description | string | Descrizione | opzionale | |
| Cycle | id | UUID | Identificativo ciclo | obbligatorio |
| curriculum_id | UUID (FK Curriculum.id) | Programma di appartenenza | obbligatorio | |
| name | string | Nome ciclo (materna, primaria, media, superiore) | obbligatorio | |
| order | integer | Ordine gerarchico | obbligatorio | |
| GradeLevel | id | UUID | Identificativo grado | obbligatorio |
| cycle_id | UUID | Riferimento al ciclo | obbligatorio | |
| name | string | Nome livello (Grade 1, Year 7) | obbligatorio | |
| level | integer | Numero progressivo | obbligatorio | |
| StudyPlan | id | UUID | Identificativo piano di studio | obbligatorio |
| grade_level_id | UUID | Grado associato | obbligatorio | |
| name | string | Nome piano | obbligatorio | |
| version | integer | Versione | default 1 | |
| StudyPlanEntry | id | UUID | Voce del piano di studio | obbligatorio |
| study_plan_id | UUID | Piano | obbligatorio | |
| subject | string | Materia | obbligatorio | |
| hours_per_week | integer | Numero di ore settimanali | obbligatorio | |
| TimeSlotDefinition | id | UUID | Identificativo slot | obbligatorio |
| cycle_id | UUID | Ciclo a cui lo slot si applica | obbligatorio | |
| day_of_week | integer (0=Monday) | Giorno | obbligatorio | |
| start_time | time | Ora inizio | obbligatorio | |
| end_time | time | Ora fine | obbligatorio | |
| LessonSchedule | id | UUID | Identificativo lezione programmata | obbligatorio |
| class_id | UUID (FK Class.id) | Classe/homeroom | obbligatorio | |
| subject | string | Materia | obbligatorio | |
| teacher_id | UUID (FK Teacher.person_id) | Docente assegnato | obbligatorio | |
| room_id | UUID (FK Room.id) | Aula | obbligatorio | |
| date | date | Data della lezione | obbligatorio | |
| start_time | time | Ora inizio | obbligatorio | |
| end_time | time | Ora fine | obbligatorio | |
| multi_class | boolean | Se coinvolge più classi | default false | |
| Room | id | UUID | Identificativo aula | obbligatorio |
| name | string | Nome aula | obbligatorio | |
| capacity | integer | Capienza massima | obbligatorio | |
| features | JSON | Caratteristiche (laboratorio, palestra) | opzionale |
Queste entità consentono di modellare la struttura del curriculum, i piani di studio e la generazione dello schedule.
9. API e integrazioni¶
Le API saranno esposte secondo lo stile REST/JSON. Tutti gli endpoint protetti richiedono autenticazione via JWT/OAuth2 con scopes legati ai ruoli.
9.1 Endpoint principali¶
| Metodo | Path | Auth | Request (schema) | Response (schema) | Errori |
|---|---|---|---|---|---|
| POST | /api/students | HR/Admin | body: {person: {name, surname, ...}, student: {school_order, status}} | 201 Created con risorsa studente | 400 dati mancanti, 403 permesso mancante |
| GET | /api/students/{id} | HR/Principal/Parent(own) | – | 200 OK con record studente | 404 non trovato, 403 accesso negato |
| PUT | /api/students/{id} | HR/Parent(own, campi limitati) | campi aggiornabili | 200 OK | 400, 403 |
| POST | /api/teachers | HR/Admin | body: {person: {...}, teacher: {...}} | 201 Created | 400, 403 |
| POST | /api/absences | Teacher (own), HR | body: | 201 Created | 400, 403 |
| POST | /api/absences/{id}/assign | HR | body: | 200 OK | 400, 403 |
| GET | /api/schedule?class_id={id}&date={} | Authenticated | – | lista ScheduleEntry | 400 parametri invalidi |
| POST | /api/attendance | Teacher/Staff | body: {schedule_entry_id, records: [{person_id, status, reason}]} | 201 Created | 400, 403 |
| POST | /api/payment-plans | HR/Admin | body: | 201 Created | 400, 403 |
| POST | /api/payments/{plan_id}/pay | Parent/Finance | body: | 200 OK con transazione | 400, 402 Payment Required, 403 |
| POST | /api/communications | Admin/HR/Principal | body: | 201 Created | 400, 403 |
| GET | /api/reports/attendance?start={}&end={}&class_id={} | Authorized | – | CSV/PDF con report | 400, 403 |
9.2 Integrazioni esterne¶
Empowered: endpoint per importare/esportare piani di lezione; utilizzo di webhook per notificare caricamenti o modifiche.
Servizi di autenticazione: utilizzo di provider OIDC/SAML per Single Sign-On con eventuali directory scolastiche esistenti.
Servizi di email/SMS: integrazione con provider (es. SendGrid, Twilio) per l’invio di comunicazioni e notifiche.
9.3 Endpoint ammissioni¶
| Metodo | Path | Auth | Request (schema) | Response (schema) | Errori |
|---|---|---|---|---|---|
| POST | /api/admissions/applications | Candidate | body: form_data | 201 Created con application e id | 400 dati mancanti, 409 application esistente |
| GET | /api/admissions/applications/{id} | Candidate(own)/AdmissionsOfficer | – | 200 OK con stato, progress, missing_items | 404 non trovato, 403 accesso negato |
| PUT | /api/admissions/applications/{id} | Candidate(own) | body: form_data parziale | 200 OK con nuovo progress | 400, 403 |
| POST | /api/admissions/applications/{id}/submit | Candidate(own) | – | 200 OK, application in stato “submitted” | 400 incomplete form, 403 |
| POST | /api/admissions/applications/{id}/schedule-interview | AdmissionsOfficer/Candidate(own) | body: | 200 OK con conferma slot | 400 slot non disponibile, 403 |
| POST | /api/interview-slots | AdmissionsOfficer | body: | 201 Created | 400, 403 |
| POST | /api/admissions/applications/{id}/contract | AdmissionsOfficer | body: | 201 Created con URL di firma digitale | 400, 403 |
| POST | /api/admissions/applications/{id}/deposit | Accountant | body: | 200 OK | 400, 403 |
| POST | /api/re-enrollments | AdmissionsOfficer | body: | 201 Created | 400, 403 |
| GET | /api/reports/admissions?start={}&end={} | AdmissionsOfficer/Admin | – | elenco aggregato di candidature con KPI | 400, 403 |
9.4 Endpoint calendario¶
| Metodo | Path | Auth | Request (schema) | Response (schema) | Errori |
|---|---|---|---|---|---|
| POST | /api/curricula | Admin | body: | 201 Created con curriculum | 400 dati mancanti, 403 |
| POST | /api/cycles | Admin | body: | 201 Created | 400, 403 |
| POST | /api/grade-levels | Admin | body: | 201 Created | 400, 403 |
| POST | /api/study-plans | Admin | body: {grade_level_id, name, entries: [{subject, hours_per_week}]} | 201 Created con piano | 400, 403 |
| POST | /api/time-slots | Admin | body: | 201 Created | 400, 403 |
| POST | /api/schedule/generate | HR/Admin | body: | 200 OK con schedule generato | 400 conflitti, 403 |
| GET | /api/schedule | Authenticated | query: class_id o teacher_id e date | 200 OK lista LessonSchedule | 400 parametri invalidi, 403 |
| PUT | /api/schedule/{lesson_id} | HR | body: modifiche (es. nuova data, slot, aula) | 200 OK con schedule aggiornato | 400 vincoli violati, 403 |
10. Logiche di business¶
Le seguenti regole governano il comportamento del sistema oltre le semplici operazioni CRUD:
Controllo validità documenti: documenti di identità devono essere caricati in formato PDF/JPG e avere una data di scadenza; il sistema avvisa HR 30 giorni prima della scadenza.
Assegnazione supplenti: i docenti supplenti vengono selezionati in base a disponibilità, competenza nella materia richiesta e numero di ore già svolte. In caso di pari merito, priorità ai supplenti con meno incarichi.
Accesso temporaneo: gli account dei supplenti sono abilitati solo per il periodo di assenza del docente di ruolo; fuori da questo intervallo l’accesso al LMS/SIS viene revocato automaticamente.
Ciclo di vita studente: uno studente può essere negli stati interested, pre_enrolled, enrolled o withdrawn; determinate funzionalità (assegnazione classe, attivazione servizi, creazione piano di pagamento) sono abilitate solo dallo stato “pre_enrolled” in avanti.
Regole di pagamento: la mancata ricezione di un pagamento oltre 15 giorni dalla scadenza genera un sollecito automatico; dopo 30 giorni viene inviato un alert all’accountant e al principal.
Allergie e diete: le informazioni mediche sono propagate solo ai moduli necessari (mensa, infermeria); eventuali aggiornamenti devono essere confermati dal genitore e registrati con tracciabilità.
Creazione campi custom: la creazione di campi custom su dati personali richiede una giustificazione legata a esigenze didattiche/amministrative e l’approvazione da parte dell’Admin; i campi devono essere classificati (sensibili o non) per applicare corretti permessi.
Report e aggregazioni: i report su presenze/assenze e pagamenti calcolano statistiche aggregate (totali, percentuali di assenze, importi incassati vs dovuti) e devono poter essere filtrati per periodo, classe, docente, dipartimento.
Per il modulo di ammissione valgono ulteriori regole:
Stati delle application: un’application può transitare tra gli stati draft, submitted, pending review, interview, accepted, rejected, contract_sent, contract_signed, deposit_pending, pre_enrolled e enrolled. Ogni transizione deve essere tracciata; alcune transizioni richiedono condizioni (es. non si può generare un contratto se l’application è “rejected”).
Reminder automatici: il sistema invia promemoria ai candidati per completare il form, firmare il contratto o pagare la quota di iscrizione. Le scadenze sono configurabili per step (es. 7 giorni per completare il modulo, 14 giorni per la firma, 30 giorni per la quota).
Soglie per dormancy: se un’application rimane inattiva per un periodo definito (es. 60 giorni) e non risponde ai remind, viene marcata come Dormant e archiviata; può essere riattivata su richiesta.
Priorità: il sistema assegna priorità a candidati con fratelli già iscritti, figli di personale o di scuole convenzionate. In caso di posti limitati, la lista può essere ordinata per priorità.
Pre‑enrollment: la generazione delle credenziali per i candidati accettati avviene automaticamente nella settimana precedente all’inizio dell’anno scolastico; durante la fase di pre‑enrollment il candidato può accedere in sola lettura ad alcune informazioni.
Re‑enrollment: il rinnovo annuale richiede la conferma del genitore e la firma di un nuovo contratto; se non confermato entro la scadenza, lo studente viene spostato nella lista Leavers e il posto viene liberato.
Consenso e GDPR: durante l’application devono essere richiesti consensi separati per trattamento dati e marketing; il mancato consenso blocca il proseguimento dell’application; i consensi devono essere registrati con timestamp e audit.
Per il modulo di timetabling si applicano le seguenti regole:
Vincoli bloccanti: il motore di scheduling deve garantire che una classe non abbia due lezioni nello stesso slot, che un docente non sia assegnato a due classi contemporaneamente e che un’aula non sia utilizzata da due lezioni contemporanee.
Compatibilità docente/materia/aula: i docenti possono essere assegnati solo alle materie per cui sono abilitati; le aule devono essere adatte alla materia (es. laboratorio scientifico) e avere la capienza necessaria; il sistema verifica questi requisiti.
Ore contrattuali e ore di contatto: le ore assegnate a ciascun docente non devono superare quelle previste dal contratto; è previsto un limite di ore “a contatto” con gli studenti; il sistema rifiuta assegnazioni che superano i limiti.
Vincoli organizzativi: la distribuzione delle lezioni deve evitare di concentrare tutte le ore di una materia in un unico giorno, prevenire “buchi” nel calendario degli studenti e prevedere doppie ore dove richiesto.
Lezioni multi‑classe: è possibile pianificare lezioni che coinvolgono studenti di classi diverse; in tal caso tutti gli orari e le aule devono essere compatibili e la capienza adeguata.
Rispettare il piano di studio: il numero totale di ore per ciascuna materia assegnata in settimana deve corrispondere a quanto definito nel piano di studio.
Considerazione del calendario scolastico: lo scheduling deve tenere conto dei giorni di lezione e delle festività definiti nel calendario scolastico, evitando di assegnare lezioni nei giorni festivi.
11. Audit, logging, analytics¶
Eventi da tracciare: login/logout, creazione/modifica/cancellazione di record (studenti, docenti, classi, contratti, pagamenti), caricamento di documenti, segnalazione di assenze, assegnazioni supplenti, invio di comunicazioni, transazioni di pagamento, creazione/modifica di campi custom.
Audit trail: per ogni evento viene registrato l’ID dell’utente, l’entità interessata, l’azione eseguita, il timestamp e un eventuale commento/motivazione. I log devono essere immodificabili e conservati per un periodo definito (es. 10 anni per i dati fiscali, 5 anni per i dati scolastici).
Metriche: numero di login per ruolo, numero di assenze segnalate, tempo medio di assegnazione di un supplente, tasso di morosità, numero di comunicazioni inviate, errori API per endpoint, utilizzo moduli mensa/bus.
Alert: generare alert automatici su threshold definiti (presenze < 70 %, pagamenti scaduti > 30 giorni, numero di assenze docenti anomalo, documenti in scadenza) con notifiche verso i responsabili.
Analytics e dashboard: fornire dashboard interattive con grafici (presenze vs tempo, andamento pagamenti, distribuzione allergie/diete, occupazione classi) e possibilità di esportazione.
12. Testing e QA¶
12.1 Test case principali (esempio)¶
| Test case | Input | Output atteso | Note |
|---|---|---|---|
| TC‑001 – Creazione studente | Inserimento di dati anagrafici completi con documento valido | Record studente creato; id assegnato; email inviata al genitore con credenziali | Verificare campi obbligatori e validazione email. |
| TC‑002 – Segnalazione assenza docente | Docente segnala assenza per un giorno | HR riceve notifica; record assenza creato con stato “reported” | Verificare obbligo di motivazione e date coerenti. |
| TC‑003 – Assegnazione supplente | HR seleziona supplente disponibile e conferma | Account supplente generato; email inviata; assenza aggiornata a stato “assigned” | Testare revoca accesso al termine. |
| TC‑004 – Pagamento retta | Genitore effettua pagamento online per una rata | Transazione completata; PaymentPlan aggiornato; ricevuta inviata; saldo ridotto | Simulare esito fallito e sollecito automatico. |
| TC‑005 – Gestione mensa | Studente con allergie registrate; mensa genera lista giornaliera | Lo studente appare con indicazione delle allergie; numero di pasti corretto; report generato | Testare dieta combinata e sconti dipendenti. |
| TC‑006 – Compilazione modulo di ammissione | Candidato compila e salva il modulo multi‑step con documenti allegati | Lo stato dell’application passa da draft a submitted; la progress bar si aggiorna; i documenti sono visualizzabili in anteprima; viene inviata una conferma | Verificare autosave, checklist e validazione campi obbligatori. |
| TC‑007 – Prenotazione intervista | Candidato prenota uno slot disponibile tramite calendario integrato | Lo slot viene riservato; email/SMS di conferma e reminder inviati; lo slot non è più prenotabile da altri | Testare fusi orari e riprogrammazione. |
| TC‑008 – Firma contratto e pagamento quota | Responsabile genera contratto; candidato firma digitalmente e paga la quota di iscrizione | Il contratto risulta in stato “signed”; il pagamento appare come “arrivato”; l’application passa a “pre‑enrolled”; credenziali programmate per l’invio | Verificare reminder se non firmato/pagato, integrazione con e‑signature e finance. |
| TC‑009 – Rinnovo annuale | Sistema invia modulo di re‑enrollment; genitore conferma e firma | Lo stato del rinnovo passa a “confirmed”; viene creato un nuovo contratto e piano di pagamento per l’anno successivo; se non confermato va in lista “Leavers” | Testare scadenze, solleciti e conversione. |
| TC‑010 – Creazione piano di studio | Admin crea un curriculum, un ciclo, un grado e un piano di studio con tre materie e ore settimanali | Il curriculum, ciclo e grado sono creati; il piano di studio contiene le materie e ore; viene assegnato alla classe | Verificare validazione campi e versioning del piano di studio. |
| TC‑011 – Generazione schedule senza conflitti | HR genera lo schedule per una classe con piano di studio definito, docenti disponibili e aule adeguate | Il sistema produce un calendario settimanale dove non esistono sovrapposizioni di docenti, classi o aule; tutte le ore del piano sono distribuite | Testare conflitti se un docente è indisponibile o se manca un’aula. |
| TC‑012 – Lezione multi‑classe | HR crea una lezione di lingua per due classi diverse e genera lo schedule | La lezione appare nel calendario di entrambe le classi; non ci sono conflitti con altre lezioni; la capienza dell’aula è sufficiente | Testare caso in cui la capienza è insufficiente o docenti diversi sono assegnati. |
| TC‑013 – Modifica manuale dello schedule | HR sposta una lezione in un altro slot tramite interfaccia | Lo schedule viene aggiornato; il sistema segnala se si violano vincoli; le notifiche vengono inviate a docenti e studenti coinvolti | Verificare cronologia delle modifiche e versioning. |
| TC‑014 – Supporto curricula multipli | Admin crea curricula “Italiano” e “British” con cicli e gradi differenti | È possibile creare classi e piani di studio per entrambi i curricula; i nomi dei gradi e le strutture sono correttamente visualizzate; report filtrabili per curriculum | Testare compatibilità con reporting e API. |
13. Open questions¶
Modularità: alcuni moduli (mensa, bus, psicologi/AIDES, sicurezza) sono opzionali. È necessario definire esattamente quali istituti li adotteranno e come gestire la configurabilità a runtime (feature flag, licenze?).
Integrazione pagamento: quale gateway di pagamento si intende utilizzare (es. Stripe, PayPal, banco scolastico)? Sono richieste funzionalità specifiche (es. rateizzazione, SEPA)?
Single Sign‑On: l’istituto ha un sistema di identity provider già in uso (es. Google Workspace for Education) o è necessario implementare un provider interno?
Regole di privacy specifiche: vi sono ulteriori vincoli legali nazionali (es. normative ministeriali) oltre al GDPR che influenzano la gestione dei dati di studenti minorenni?
Workflow approvazioni: alcune operazioni (es. creazione campi custom, cambio stato studente) devono essere approvate da più figure (principal, head of education)?
Report avanzati: sono richieste esportazioni verso sistemi ministeriali o certificazioni obbligatorie (es. MIUR in Italia)?
Quota di iscrizione: quale importo e struttura tariffaria deve avere la quota di iscrizione? È uniforme per grado o variabile? Va considerata rimborsabile?
Provider di firma digitale: quale soluzione di e‑signature si intende adottare (DocuSign, AdobeSign)? Sono richiesti requisiti legali particolari (marca temporale, firma qualificata)?
Gestione preferenze di pagamento: il modulo di ammissione chiede se il candidato preferisce pagamento annuale, mensile o trimestrale. Come incide questa scelta sui piani di pagamento e sul contratto?.
Siblings e categorie speciali: come definire la priorità tra fratelli, figli di personale e altre categorie? Occorre un algoritmo di ranking? Quali documenti di prova servono?
AI e automazione: si desidera implementare le funzioni AI suggerite? Se sì, quali criteri di trasparenza e supervisione sono necessari per evitare discriminazioni?
Algoritmo di scheduling: quale approccio algoritmico si intende adottare (es. heuristics, Constraint Satisfaction, solver commerciale)? Quale livello di interazione manuale è accettabile? Come gestire i tempi di calcolo?
Teacher availability: come verranno raccolti e aggiornati i dati sulle disponibilità dei docenti? È prevista un’interfaccia self-service per i docenti?
Gestione stanze e attrezzature: quali categorie di aule (laboratori, palestre, sale musica) devono essere gestite? Come verificare automaticamente la compatibilità materia–aula?
Multi‑curriculum: è necessario supportare anche altri sistemi scolastici oltre a quelli menzionati (es. americano)? Come gestire l’equivalenza di livelli tra sistemi diversi?
Versioning dello schedule: quante versioni dello schedule devono essere conservate? In che modo si deve gestire la pubblicazione di nuove versioni senza confondere gli utenti?