Ingegneria dei requisiti - requisiti funzionali e non funzionali

Definizione (ingegneria dei requisiti). Il requirements engineering (RE) è il processo con cui si stabiliscono i servizi richiesti al sistema dal cliente e i vincoli sotto i quali deve operare ed essere sviluppato. I requisiti di sistema sono le descrizioni di servizi e vincoli che questo processo produce.

È la prima delle attività fondamentali (la specifica, vedi Ingegneria del software - prodotto software e processo di sviluppoL'ingegneria del software (IdS) è la disciplina che copre tutti gli aspetti della produzione di software professionale, dalle prime specifiche alla manutenzione: il software sono programmi più documentazione, può essere generico (venduto sul mercato) o specifico (su misura per un cliente), e un buon prodotto ha quattro attributi (manutenibilità, affidabilità e sicurezza, efficienza, accettabilità); le attività fondamentali sono specifica, sviluppo, validazione ed evoluzione; i costi sono dominati dalla manutenzione e un difetto di requisiti scoperto dopo il rilascio costa fino a 100 volte uno scoperto subito; i tre problemi di fondo sono incertezza, irreversibilità e complessità; verifica ("costruiamo bene il prodotto?") e validazione ("costruiamo il prodotto giusto?") sono cose diverse.Ingegneria del software - prodotto software e processo di sviluppo →) ed è decisiva: un errore nei requisiti scoperto dopo la consegna costa fino a 100 volte uno di implementazione. Nella parte di database lo stesso tema compare come analisi dei requisiti di un sistema informativo (Ciclo di vita di un sistema informativo e analisi dei requisitiIl ciclo di vita di un sistema informativo ha le fasi studio di fattibilità, analisi dei requisiti, progettazione (dei dati e delle applicazioni), sviluppo, collaudo, esercizio e manutenzione; il modello a cascata procede in sequenza, quello a spirale itera per versioni. I requisiti sono funzionali (che cosa fa il sistema), non funzionali (come lo fa, es. tempi) e vincoli aggiuntivi imposti dai committenti; si raccolgono da frasi in linguaggio naturale, documentazione e applicazioni esistenti e si analizzano con frasi filtrate e glossario dei dati. La progettazione di una base di dati ha tre fasi: concettuale (schema ER, indipendente dal DBMS), logica (schema relazionale, per una classe di DBMS, con il carico applicativo) e fisica (strutture del DBMS scelto). Un modello è un insieme di costrutti, lo schema è la rappresentazione del mini-mondo (livello intensionale), l'istanza sono i dati (livello estensionale); un buono schema è completo, corretto, minimale e leggibile.Ciclo di vita di un sistema informativo e analisi dei requisiti →); qui si guarda il software. Esempio guida di tutta la parte di ingegneria del software: il sistema di prestito di una biblioteca.

Che cos'è un requisito

Un requisito può essere da un'affermazione astratta di alto livello a una specifica matematica dettagliata. La genericità è inevitabile, perché lo stesso testo ha due funzioni:

• base di un bando (un'offerta per un contratto): resta aperto all'interpretazione, perché imprese diverse possano proporre soluzioni diverse;
• base del contratto: deve essere definito in dettaglio.

Requisiti utente e di sistema

Esempio (biblioteca).

• Utente: "Il sistema deve permettere ai bibliotecari di registrare il prestito di un documento a un iscritto."
• Sistema: "1.1 Il sistema deve consentire di registrare un prestito indicando tessera e codice del documento. 1.2 Se l'iscritto ha già raggiunto il limite di prestiti (6 per gli adulti), il sistema deve rifiutare il prestito e mostrare il motivo. 1.3 Alla registrazione il sistema deve calcolare la scadenza (30 giorni per i libri, 3 per i DVD)."

Stakeholder

Definizione (stakeholder). Chiunque sia interessato al sistema o abbia un interesse legittimo nel suo funzionamento.

Categorie: utenti finali, gestori del sistema, proprietari, stakeholder esterni (per esempio i clienti di una banca che usano il software dell'istituto). Nella biblioteca: iscritti, bibliotecari, direttore, personale informatico, responsabile della privacy, il comune che finanzia. Hanno interessi in conflitto (l'iscritto vuole prestiti lunghi, il direttore meno costi di sollecito) e le richieste cambiano durante il processo.

Requisiti funzionali, non funzionali e di dominio

I requisiti non funzionali possono essere più critici dei funzionali: se non li soddisfa, il sistema può risultare inutilizzabile. Un solo requisito non funzionale (per esempio di sicurezza) può generare più requisiti funzionali (autenticazione, registro degli accessi) e requisiti che limitano altri requisiti. Per soddisfarli può essere necessario scegliere una certa Architettura del software - decisioni, organizzazione e stiliL'architettura del software descrive come un sistema è organizzato in componenti, le loro relazioni e la loro distribuzione; è il ponte tra requisiti e progetto dettagliato, e le sue decisioni derivano soprattutto dai requisiti non funzionali (prestazioni, sicurezza, disponibilità, manutenibilità), spesso in conflitto tra loro; si descrive con più viste (logica, processi, sviluppo, fisica); gli stili di organizzazione ricorrenti sono a livelli (layered), MVC, repository, client-server, pipe and filter, publish-subscribe e microservizi; la modularizzazione mira ad alta coesione e basso accoppiamento, nascondendo le decisioni dietro interfacce (information hiding, inversione delle dipendenze).Architettura del software - decisioni, organizzazione e stili → (per esempio pochi scambi tra componenti per le prestazioni).

Imprecisione, completezza, coerenza

• Un requisito ambiguo è letto in modo diverso da sviluppatori e utenti. Esempio: "L'utente può cercare nel catalogo": l'utente intendeva cercare in tutte le sedi; lo sviluppatore ha realizzato la ricerca in una sola sede scelta in precedenza.
• In teoria i requisiti sono completi (descrivono tutte le funzioni richieste) e coerenti (nessuna contraddizione); in pratica, per la complessità del sistema e dell'ambiente, non si ottiene un documento perfettamente completo e coerente.

Classificazione dei requisiti non funzionali

Obiettivi e requisiti verificabili

Un obiettivo (goal) è un'intenzione generale ("il sistema deve essere facile da usare") utile agli sviluppatori per capire che cosa vogliono gli utenti, ma non verificabile. Un requisito non funzionale verificabile usa una misura che si può testare oggettivamente:

Esempio. Obiettivo: "Il sistema deve essere facile da usare per il personale." Requisito verificabile: "Il personale deve poter usare tutte le funzioni dopo quattro ore di formazione e gli utenti esperti non devono commettere più di due errori per ora di uso."

Requisiti di interfaccia

Il programma cita esplicitamente le interfacce: i requisiti devono dire anche come il sistema comunica con l'esterno.

Le interfacce con sistemi esistenti generano spesso vincoli di progetto, e per descriverle sono adatti i linguaggi con notazione quasi di programmazione (le firme dei metodi in Java sono già una specifica di interfaccia).

Il processo di ingegneria dei requisiti

Le attività sono comuni a tutti i processi e si intrecciano in modo iterativo (a spirale):

Elicitazione e analisi

Fasi del ciclo: scoperta dei requisiti (compresi quelli di dominio); classificazione e organizzazione (gruppi coerenti); priorità e negoziazione (risolvere i conflitti); specifica. Problemi tipici: gli stakeholder non sanno che cosa vogliono; usano il proprio linguaggio; hanno esigenze contrastanti; fattori organizzativi e politici incidono; i requisiti cambiano durante l'analisi.

Tecniche di scoperta:

Uno scenario è una storia d'uso strutturata, con: situazione di partenza, flusso normale, che cosa può andare storto, attività concomitanti, stato finale. Esempio:

Scenario "Prestito con prenotazione". Ipotesi iniziale: il bibliotecario ha eseguito l'accesso; il documento ha una copia disponibile; l'iscritto Anna ha una tessera valida. Normale: il bibliotecario legge la tessera e il codice, il sistema registra il prestito, calcola la scadenza (30 giorni) e stampa la ricevuta. Può andare storto: (a) Anna ha raggiunto il limite: il sistema rifiuta e mostra il motivo; (b) tessera scaduta: il sistema propone il rinnovo; (c) la copia è già prenotata da un altro iscritto: il prestito è permesso solo se la prenotazione è di Anna. Altre attività: nello stesso momento un altro bibliotecario può prestare una copia diversa. Stato finale: copia in prestito, prestito attivo di Anna aumentato di uno.

Specifica dei requisiti

Linee guida per il linguaggio naturale: un formato standard per tutti i requisiti; usare "deve" (shall) per i requisiti obbligatori e "dovrebbe" (should) per i desiderabili; evidenziare le parti chiave; evitare il gergo informatico; aggiungere la motivazione (rationale). Problemi: mancanza di chiarezza (precisione e leggibilità sono in contrasto), requisiti funzionali e non funzionali confusi, più requisiti accorpati in una sola frase.

Moduli (specifica strutturata). Campi: funzione o entità, input e provenienza, output e destinazione, informazioni necessarie per il calcolo e altre entità usate, azione, condizioni preliminari e finali, effetti collaterali.

Esempio (modulo).

• Funzione: registrare un prestito.
• Descrizione: assegna una copia di un documento a un iscritto.
• Input: numero di tessera, codice del documento (dal lettore di codici a barre).
• Sorgente: bibliotecario; Output: ricevuta di prestito con scadenza; Destinazione: stampante e archivio dei prestiti.
• Necessita di: anagrafica degli iscritti, catalogo, prestiti attivi.
• Azione: si controllano tessera valida, limite non superato e copia disponibile; si decrementa il numero di copie, si crea il prestito con scadenza = data odierna + durata del tipo di documento.
• Precondizione: tessera in corso di validità. Postcondizione: le copie disponibili sono diminuite di uno.
• Effetti collaterali: se c'è una prenotazione dell'iscritto, viene cancellata.

Specifica tabellare (per più alternative). Esempio: tariffa di multa.

(La stessa specifica è provata con casi di test nella nota Software testing - progettazione dei casi di test e JUnitIl testing esegue il programma con dati artificiali per mostrare che soddisfa i requisiti (validation testing) e per scoprirne i difetti (defect testing), ma può rivelare la presenza di errori e non la loro assenza; il test di sviluppo comprende unit test (singole classi e metodi), test dei componenti (le interfacce) e test di sistema (le interazioni); i casi di test si ricavano con le classi di equivalenza (una per partizione) e i valori limite (ai bordi delle partizioni), più linee guida per sequenze e input anomali; JUnit automatizza i test con @Test, fixture @Before/@After (@BeforeClass/@AfterClass), le asserzioni (assertEquals con atteso per primo), eccezioni attese, timeout e @Ignore; nel TDD il test si scrive prima del codice (red, green, refactor) e i test automatici diventano la suite di regressione; seguono i test di rilascio (black box sui requisiti, prestazioni) e dell'utente (alpha, beta, accettazione).Software testing - progettazione dei casi di test e JUnit →.)

Casi d'uso. Un caso d'uso è un tipo di scenario (UML): identifica gli attori (persone o altri sistemi) e descrive l'interazione; un insieme di casi d'uso deve coprire tutte le interazioni possibili. Si hanno un diagramma di alto livello e una descrizione tabellare (attori, descrizione, dati, stimolo, risposta, commenti). I diagrammi di sequenza aggiungono il dettaglio dei messaggi.

Il documento dei requisiti

È la dichiarazione ufficiale di ciò che chiedono agli sviluppatori. Contiene sia requisiti utente sia requisiti di sistema, e non è un documento di progetto: dice che cosa il sistema fa, non come (in pratica requisiti e progetto sono inseparabili: l'architettura può strutturare i requisiti e i sistemi con cui si interagisce impongono vincoli).

I sistemi sviluppati in modo incrementale hanno meno dettaglio; esistono standard (IEEE) per grandi progetti. I metodi agili ritengono i requisiti dettagliati una perdita di tempo perché cambiano troppo in fretta (documento sempre obsoleto) e usano storie dell'utente (Processi di sviluppo - modelli plan-based, metodi agili e ScrumUn processo software è un insieme strutturato di attività (specifica, progetto e realizzazione, validazione, evoluzione) e si descrive con attività, prodotti, ruoli e condizioni; i processi plan-driven pianificano tutto in anticipo e misurano il progresso sul piano (cascata, modello a V con i livelli di test corrispondenti, sviluppo incrementale pianificato, integrazione e configurazione di componenti, con prototipi e consegna incrementale per gestire il cambiamento, e miglioramento del processo con i livelli di maturità SEI), mentre i metodi agili pianificano in modo incrementale e accolgono il cambiamento (manifesto agile, XP con i suoi valori e le sue dodici pratiche, storie dell'utente e story point); Scrum organizza il lavoro in sprint con tre ruoli (Product Owner, Scrum Master, team), eventi (planning, daily scrum, review, retrospective) e artefatti (product backlog, sprint backlog, incremento), stimando con il planning poker; non c'è un processo giusto, ma priorità diverse (stabilità dei requisiti, criticità, dimensione e distribuzione del team).Processi di sviluppo - modelli plan-based, metodi agili e Scrum →), il che è difficile per sistemi critici o sviluppati da molti gruppi.

Validazione dei requisiti

Dimostra che i requisiti definiscono il sistema che il cliente vuole. Controlli:

Tecniche: revisione sistematica (con personale del cliente e dell'appaltatore), prototipi, generazione di casi di test (se per un requisito non si riesce a scrivere un test, è probabilmente vago). Nella revisione si controllano anche comprensibilità, tracciabilità (origine del requisito) e adattabilità (si può modificare senza troppi effetti su altri requisiti).

Cambiamento dei requisiti e loro gestione

L'ambiente tecnico e commerciale cambia dopo l'installazione (nuovo hardware, altri sistemi, priorità aziendali, leggi); chi paga il sistema e chi lo usa raramente coincidono, e il risultato è un compromesso che con l'esperienza va ribilanciato. La gestione dei requisiti richiede:

• identificazione univoca di ogni requisito (per i riferimenti incrociati);
• un processo di gestione delle modifiche: analisi del problema e specifica della modifica, analisi del cambiamento e dei costi (con le informazioni di tracciabilità), poi modifica del documento e, se serve, di progetto e codice;
• politiche di tracciabilità: collegamenti tra requisiti, e tra requisiti e progetto;
• strumenti di supporto (da fogli di calcolo a sistemi dedicati).

Il documento va scritto in modo modulare, con pochi riferimenti esterni, perché si possano cambiare singole sezioni.

Modelli del sistema

I modelli astratti (di solito in UML) aiutano a chiarire e a comunicare i requisiti:

Un modello si usa per discutere (può essere incompleto), per documentare (accurato ma non completo) o come descrizione dettagliata da cui generare codice (corretto e completo: model-driven engineering). L'ingegneria guidata dai modelli ha avuto adozione limitata per costi degli strumenti e perché l'astrazione utile alla discussione non è quella giusta per l'implementazione.

Domande d'esame

1. Classificare ciascuna frase: (a) "Il sistema deve consentire la ricerca per autore"; (b) "Il sistema deve rispondere in meno di 2 secondi per il 95% delle richieste"; (c) "Il sistema deve essere facile da usare". Traccia. (a) requisito funzionale; (b) requisito non funzionale di prodotto, verificabile perché misurato; (c) è un obiettivo, non verificabile: va trasformato in un requisito misurabile (tempo di formazione, errori per ora).

2. Quali problemi ha il linguaggio naturale per la specifica? Come si limitano? Traccia. Ambiguità e mancanza di chiarezza, confusione tra requisiti funzionali e non, accorpamento di più requisiti. Si limitano con un formato standard, "deve/dovrebbe" usati con coerenza, evidenziazione, niente gergo, motivazione per ogni requisito, e con moduli o tabelle per i requisiti di sistema.

3. Quali controlli si fanno nella validazione dei requisiti e con quali tecniche? Traccia. Validità, coerenza, completezza, realismo, verificabilità; tecniche: revisioni, prototipi, generazione dei casi di test. Perché presto: l'errore costa fino a 100 volte di più dopo la consegna.