Esercizio - specifica dei requisiti di un sistema di prestito bibliotecario (progetto originale)

Esercizio originale, nello stile del progetto d'esame (specifica dei requisiti di un sistema). Teoria: Ingegneria dei requisiti - requisiti funzionali e non funzionali; i casi di test degli stessi requisiti sono in Esercizio - casi di test con classi di equivalenza e valori limite per il limite di prestiti (progetto originale).

Testo

La biblioteca comunale vuole sostituire il registro cartaceo dei prestiti con un sistema software. Dalle interviste con il personale sono emerse queste frasi, annotate così come dette:

Direttrice: "Voglio sapere sempre quanti libri sono fuori e quanti sono in ritardo. Il sistema deve essere veloce." Bibliotecario: "Allo sportello devo poter registrare un prestito e una restituzione leggendo la tessera e il codice a barre; se l'iscritto ha troppi libri o una multa non pagata, deve dirmelo." Iscritta: "Vorrei prenotare un libro in prestito e ricevere un avviso quando torna. E cercare nel catalogo da casa." Informatico del comune: "Dovete usare il nostro database Oracle e il sistema deve girare su Linux."

Una prima bozza dell'elenco dei requisiti, scritta in fretta, è la seguente:

id	requisito
R1	Il sistema deve essere veloce.
R2	Il bibliotecario può registrare prestiti e restituzioni, gestire le multe e inviare gli avvisi.
R3	Un iscritto può avere al massimo 5 prestiti.
R4	I docenti possono avere fino a 8 prestiti.
R5	La ricerca nel catalogo deve essere facile da usare.
R6	Il sistema deve calcolare la multa in base al ritardo.
R7	Il sistema deve usare Oracle.
R8	I dati degli iscritti si cancellano dopo un tempo adeguato.

Si richiede di:

elencare gli stakeholder e le loro esigenze principali;
classificare ogni requisito della bozza (utente o di sistema; funzionale, non funzionale di prodotto, organizzativo o esterno, di dominio) e trovare almeno cinque difetti (ambiguità, accorpamento, incoerenza, incompletezza, non verificabilità);
riscrivere i requisiti in forma corretta: almeno 6 requisiti utente e i relativi requisiti di sistema, con tre requisiti non funzionali verificabili e almeno un requisito di interfaccia, usando "deve" e "dovrebbe" e un identificatore per ciascuno;
descrivere con un modulo strutturato la funzione "registrare un prestito" e con una tabella il calcolo della multa;
scrivere lo scenario "Prestito con prenotazione" e la descrizione tabellare del caso d'uso "Registrare un prestito";
dire quali controlli di validazione si applicano e quali tecniche si useranno.

Soluzione

1. Stakeholder

stakeholder	tipo	esigenza principale
iscritti (adulti, ragazzi, docenti, soci)	utenti finali	prenotare, cercare da casa, ricevere avvisi, multe chiare
bibliotecari	utenti finali	operazioni rapide allo sportello, segnalazione di limiti e multe
direttrice	proprietario	statistiche su prestiti e ritardi, costi contenuti
informatico del comune	gestore del sistema	integrazione con Oracle e Linux, manutenzione semplice
garante della privacy (esterno)	esterno	trattamento dei dati personali conforme alla legge
comune (finanziatore)	proprietario/esterno	budget, tempi

Sono in conflitto l'esigenza dell'iscritto (prestiti lunghi, poche multe) e quella della direttrice (rotazione dei documenti, incasso delle multe): va negoziata (analisi dei requisiti).

2. Classificazione e difetti della bozza

id	classificazione	difetto
R1	utente, non funzionale di prodotto (prestazioni)	"veloce" è un obiettivo, non verificabile: serve una misura (tempo di risposta e carico)
R2	utente, funzionale	requisiti accorpati: registrare prestiti, restituzioni, gestire multe e inviare avvisi sono almeno quattro funzioni; "gestire le multe" è vago
R3	di sistema, funzionale (regola di business)	incoerente con R4 se i docenti sono iscritti (per un docente valgono 5 o 8?)
R4	di sistema, funzionale	stesso difetto di R3; manca la regola per le altre categorie (ragazzi)
R5	utente, non funzionale (usabilità)	obiettivo non verificabile: va trasformato in una misura (tempo di formazione, errori per ora)
R6	di sistema, funzionale	incompleto: mancano la tariffa, il tetto, le eccezioni (soci)
R7	organizzativo (vincolo di implementazione); è un requisito di progetto	va tenuto ma motivato; il documento dei requisiti dovrebbe dire il vincolo, non la soluzione; "Oracle" senza versione è ambiguo
R8	di dominio (norma sulla privacy) / non funzionale esterno	"tempo adeguato" non è verificabile: serve un periodo preciso

Altri difetti: manca la prenotazione, mancano i requisiti sulla ricerca da casa (interfaccia web), sulla disponibilità e sulla sicurezza degli accessi; nessun requisito ha una motivazione né un identificatore di tracciabilità coerente con i test.

3. Requisiti riscritti

Requisiti utente (linguaggio naturale, per i clienti)

id	requisito utente
U1	Il sistema deve permettere ai bibliotecari di registrare il prestito di un documento a un iscritto.
U2	Il sistema deve permettere ai bibliotecari di registrare la restituzione di un documento.
U3	Il sistema deve segnalare al bibliotecario, prima di registrare un prestito, se l'iscritto ha raggiunto il limite di prestiti o ha multe non pagate.
U4	Il sistema deve permettere agli iscritti di prenotare un documento in prestito e di ricevere un avviso quando è disponibile.
U5	Il sistema deve permettere agli iscritti di cercare nel catalogo da casa.
U6	Il sistema deve calcolare la multa per i documenti restituiti in ritardo.
U7	Il sistema deve fornire alla direttrice statistiche sui prestiti in corso e in ritardo.

Requisiti di sistema (strutturati)

id	requisito di sistema	tipo	da
S1.1	Il sistema deve registrare un prestito dati il numero di tessera e il codice del documento, letti con il lettore di codici a barre.	funzionale	U1
S1.2	La scadenza del prestito deve essere la data odierna più 30 giorni per i libri, 7 per le riviste e 3 per i DVD.	funzionale	U1
S3.1	Il limite di prestiti contemporanei deve essere 2 (6-13 anni), 4 (14-17), 6 (18-64), 8 (65 e oltre), più 2 con tessera premium; il sistema deve rifiutare il prestito oltre il limite, mostrando il motivo.	funzionale (regola di business)	U3
S3.2	Il sistema deve rifiutare il prestito a un iscritto con multe non pagate per più di 5,00 euro.	funzionale	U3
S4.1	Il sistema deve inviare un messaggio di posta all'iscritto che ha prenotato un documento entro 5 minuti dalla restituzione di una copia.	funzionale + prestazione	U4
S4.2	Il documento deve essere riservato all'iscritto avvisato per 48 ore; scadute, passa al successivo prenotato.	funzionale	U4
S6.1	La multa deve essere 0 per ritardo 0; 0,30 euro per giorno dal 1° al 10° giorno; 3,00 euro più 0,60 euro per ogni giorno oltre il decimo dall'11° al 30°; 15,00 euro da 30 giorni in su; la metà per i soci (tabella nel punto 4).	funzionale	U6
N1	La ricerca nel catalogo deve rispondere entro 2 secondi per il 95% delle richieste con 50 utenti contemporanei.	non funzionale di prodotto (prestazioni, verificabile)	U5
N2	Il personale deve poter usare tutte le funzioni di sportello dopo 4 ore di formazione, e gli utenti esperti non devono commettere più di 2 errori per ora.	non funzionale di prodotto (usabilità, verificabile)	U1, U2
N3	La registrazione di un prestito deve completarsi entro 1 secondo per il 99% delle operazioni; il sistema deve essere disponibile almeno il 99% del tempo di apertura.	non funzionale di prodotto (prestazioni, disponibilità)	U1
N4	I dati personali degli iscritti non devono essere ceduti a terzi e devono essere cancellati 24 mesi dopo la scadenza della tessera.	di dominio (privacy)	R8
N5	Il sistema deve usare il database Oracle del comune (versione 19) e girare su Linux.	organizzativo (vincolo di implementazione)	R7
I1	La ricerca deve essere esposta anche come API REST in formato JSON; la lettura dei codici avviene dal lettore che invia il codice come testo terminato da invio; il collegamento con il server usa HTTPS.	interfaccia (con altri sistemi, hardware, comunicazione)	U5, U1

Note sul linguaggio: "deve" per i requisiti obbligatori; i desiderabili si scrivono "dovrebbe" (per esempio "il sistema dovrebbe suggerire documenti simili"). I requisiti R3 e R4 della bozza sono stati unificati in S3.1, che risolve l'incoerenza con una tabella per fascia d'età.

4. Modulo strutturato e tabella

Modulo (S1.1 e S3.1).

campo	contenuto
funzione	registrare un prestito
descrizione	assegna una copia di un documento a un iscritto e crea il prestito attivo
input e sorgente	numero di tessera e codice del documento, dal lettore del bibliotecario
output e destinazione	ricevuta di prestito con scadenza (stampante), prestito attivo (archivio)
dati necessari	anagrafica iscritti (limite, multe), catalogo (copie), prestiti attivi
azione	si verificano tessera valida, multe non pagate $\le$ 5,00 euro, prestiti attivi inferiori al limite e almeno una copia disponibile; si decrementano le copie, si crea il prestito con scadenza = oggi + durata del tipo di documento
precondizione	tessera in corso di validità, bibliotecario autenticato
postcondizione	copie disponibili ridotte di uno; prestiti attivi dell'iscritto aumentati di uno
effetti collaterali	se l'iscritto aveva prenotato il documento, la prenotazione è cancellata

Tabella della multa (S6.1).

condizione	azione
ritardo = 0 giorni	multa = 0
1 $\le$ ritardo $\le$ 10	multa = 0,30 euro $\times$ giorni di ritardo
11 $\le$ ritardo $\le$ 30	multa = 3,00 euro + 0,60 euro $\times$ (giorni - 10)
ritardo > 30	multa = 15,00 euro (tetto)
socio	importo dimezzato
ritardo < 0	non valido: il sistema deve rifiutare il dato

Dalla tabella derivano le classi di equivalenza e i valori limite dei test (vedi Software testing - progettazione dei casi di test e JUnit).

5. Scenario e caso d'uso

Scenario "Prestito con prenotazione".

Ipotesi iniziale: il bibliotecario è autenticato; Anna ha una tessera valida e 2 prestiti attivi (limite 6); la copia del libro è disponibile ma prenotata da Anna.
Funzionamento normale: il bibliotecario legge la tessera e il codice; il sistema controlla limite, multe e disponibilità, registra il prestito con scadenza a 30 giorni, cancella la prenotazione e stampa la ricevuta.
Cosa può andare storto: (a) limite raggiunto: rifiuto con il motivo; (b) tessera scaduta: il sistema propone il rinnovo; (c) la copia è riservata a un altro iscritto: rifiuto; (d) la stampante non risponde: il prestito è registrato e la ricevuta si può ristampare; (e) codice a barre non letto: inserimento manuale.
Altre attività: un altro bibliotecario può registrare prestiti di altri documenti nello stesso momento.
Stato finale: prestito attivo creato, copie disponibili diminuite di uno, prenotazione chiusa, Anna ha 3 prestiti attivi.

Caso d'uso "Registrare un prestito".

voce	contenuto
attori	bibliotecario, sistema del catalogo
descrizione	il bibliotecario registra a nome di un iscritto il prestito di un documento disponibile
dati	tessera, codice del documento, scadenza
stimolo	comando "Presta" dell'operatore
risposta	conferma e ricevuta; oppure rifiuto con motivo
commenti	richiede il ruolo "bibliotecario"; le operazioni sono registrate in un log

6. Validazione

controllo	applicato a
validità	la direttrice e i bibliotecari confermano che S3.1 e S6.1 sono le regole vere
coerenza	la tabella per fascia d'età elimina il conflitto R3 e R4; si controlla che S3.2 non contraddica S6.1
completezza	nuovi requisiti per prenotazione, ricerca da casa, sicurezza (autenticazione degli accessi), registro delle operazioni
realismo	N3 (99% di disponibilità) e N1 (50 utenti) sono compatibili con il server del comune? si misura su un prototipo
verificabilità	per ogni requisito si scrive almeno un caso di test (N1: prova di carico; N2: prova con 4 operatori; S6.1: test a valori limite)

Tecniche: revisione dei requisiti con personale della biblioteca e del comune (controllando comprensibilità, tracciabilità e adattabilità), prototipo dell'interfaccia di sportello e della ricerca, generazione dei casi di test. Gli identificatori (U1, S1.1, N1...) servono alla tracciabilità: ogni test cita il requisito che prova, e una modifica del limite S3.1 mostra quali test e quali parti del progetto sono toccati.

Versione ripasso

Metodo: (1) stakeholder (utenti finali, gestori, proprietari, esterni) e conflitti; (2) classificare e cercare difetti; (3) riscrivere (utente in linguaggio naturale, sistema strutturato, "deve"/"dovrebbe", identificatori, NFR misurabili, interfacce); (4) modulo e tabella; (5) scenario e caso d'uso; (6) validazione e tracciabilità.
Stakeholder: iscritti, bibliotecari, direttrice, informatico del comune, garante della privacy, comune. Conflitto: prestiti lunghi e poche multe contro rotazione e incasso: si negozia.
Difetti della bozza:

id	difetto
R1 "veloce"	obiettivo, non verificabile: serve misura e carico
R2	quattro funzioni accorpate; "gestire le multe" vago
R3 e R4	5 contro 8 prestiti: incoerenti per i docenti; manca la fascia ragazzi
R5 "facile da usare"	obiettivo: tempo di formazione ed errori per ora
R6	incompleto: tariffa, tetto, soci
R7 "Oracle"	requisito organizzativo; dire il vincolo, con la versione
R8 "tempo adeguato"	di dominio (privacy): serve un periodo preciso

Requisiti riscritti (esempi): S1.2 scadenza = oggi + 30 (libri), 7 (riviste), 3 (DVD); S3.1 limite 2/4/6/8 per fascia d'età (6-13, 14-17, 18-64, 65+) più 2 con premium, con rifiuto e motivo; S4.1 avviso entro 5 minuti dalla restituzione; S4.2 riserva per 48 ore.
NFR verificabili: N1 ricerca entro 2 s per il 95% con 50 utenti; N2 formazione di 4 ore e al massimo 2 errori per ora; N3 prestito entro 1 s per il 99% e disponibilità 99%; N4 (dominio) nessuna cessione a terzi, cancellazione dopo 24 mesi; N5 (organizzativo) Oracle 19 su Linux; I1 interfaccia REST/JSON, lettore a codici, HTTPS.
Modulo "registrare un prestito": input tessera e codice; output ricevuta e prestito attivo; dati: anagrafica, catalogo, prestiti attivi; azione: verifiche e decremento delle copie, scadenza = oggi + durata; precondizione tessera valida; postcondizione copie $-1$ e prestiti attivi $+1$ ; effetto collaterale: cancella la prenotazione.
Tabella multa: 0 giorni $\to$ 0; 1-10 $\to$ 0,30 per giorno; 11-30 $\to$ 3,00 + 0,60 per giorno oltre il decimo; oltre 30 $\to$ 15,00; soci metà; negativo non valido.
Scenario "Prestito con prenotazione": normale (controlli, prestito a 30 giorni, prenotazione cancellata, ricevuta); può andare storto: limite, tessera scaduta, copia riservata ad altri, stampante, codice non letto; stato finale: 3 prestiti attivi di Anna.
Caso d'uso: attori bibliotecario e catalogo; stimolo "Presta"; risposta conferma o rifiuto con motivo; ruolo "bibliotecario", log.
Validazione: validità (conferma con i clienti), coerenza (tabella per fasce), completezza (prenotazione, ricerca, sicurezza), realismo (prototipo), verificabilità (un test per requisito); tecniche: revisioni, prototipi, generazione dei test; tracciabilità con identificatori.
Altri requisiti da aggiungere dopo la revisione: prenotazione (U4, S4.1, S4.2), ricerca da casa (U5, N1, I1), sicurezza (autenticazione degli accessi), registro delle operazioni (log); per ogni requisito almeno un caso di test (N1: prova di carico; N2: prova con 4 operatori; S6.1: valori limite).
Classificazione in breve: S1.1, S1.2, S3.1, S3.2, S4.1, S4.2, S6.1 funzionali; N1, N2, N3 non funzionali di prodotto; N4 di dominio (privacy); N5 organizzativo; I1 interfaccia.
Errori tipici: scrivere NFR come obiettivi; accorpare requisiti; lasciare regole contraddittorie per categorie sovrapposte; confondere vincolo di progetto e requisito; non dare identificatori.

Esercizi su questo argomento

Esercizio - casi di test con classi di equivalenza e valori limite per il limite di prestiti (progetto originale)