Differenza tra requisiti utente e requisiti di sistema

Requisiti software

In ingegneria del software, una definizione tipica di “requisito” software, è stata specificata dallo standard IEE- STD 1220-1998 (IEE 1998):

“A statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines).”

Quindi un requisito non è altro che un’informazione (ottenuta in qualche modo) circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare. Esso può variare da una descrizione astratta ed imprecisa del sistema, fino a una descrizione dettagliata e matematica dello stesso.

Dalla definizione tratta dallo standard, si evincono i principali aspetti di un requisito:

1. Statement. In realtà non è corretto dire che un requisito dovrebbe essere una dichiarazione in quanto esso potrebbe essere espresso anche sotto forma tabellare, in forma schematica quale UML (Unified Modeling Language), in notazioni formali oppure dello specifico dominio. Il concetto importante, però, è quello di avere un insieme di elementi gestibili e tracciabili, identificati come requisiti.
2. Product or process. Operational, functional, or design characteristic or constraint. Ci sono diversi tipi di requisiti, che danno luogo a tipologie differenti di linguaggio, analisi, modelli, processi e soluzioni. Le caratteristiche di design comprendono le prestazioni, la facilità d’uso, la sicurezza, la manutenibilità ed una serie di altre qualità.
3. Unambiguous. un requisito dovrebbe prestarsi ad una chiara, e singola comprensione, comune a tutte le parti coinvolte nel progetto.
4. Testable or measurable. I requisito vengono utilizzati per testare che il progetto o la soluzione adottata, risulti essere accettabile. Affinché ciò sia possibile, il requisito dovrebbe essere quantificato, fornendo così rispetto ad esso un mezzo di “misurazione” per la soluzione.
5. Necessary for product or process acceptability. Questi attributi evidenziano il ruolo multi-dimensionale ricoperto dai requisiti: essi servono a definire cosa dovrebbe essere progettato e sviluppato, ed anche come dovrebbe essere testata e accettata la soluzione. Quindi essi hanno un’influenza non solo nelle fasi iniziali del processo di sviluppo, ma anche nelle ultime fasi per l’accettazione del prodotto.
6. By consumers or internal quality assurance guidelinad esempio: Tipicamente i requisiti provengono da molte fonti tra cui, ma non solo, i clienti, gli enti di regolamentazione (standards), gli utenti e le procedure di qualità interna.

In definitiva i requisiti rappresentano il patrimonio di progetto più importante, dal momento che costituiscono l’anello di congiunzione tra i bisogni e le percezioni degli stakeholder e le soluzioni tecnologiche progettate dagli esperti software.

Essi possono essere classificati secondo due diversi punti di vista; in funzione del livello di dettaglio, dando luogo a due tipologie di requisiti:

1. Requisiti utente;
2. Requisiti di sistema;

ed in relazione alla tipologia di requisito rappresentato:

1. Requisiti funzionali;
2. Requisiti non funzionali;
3. Requisiti di dominio;
4. Requisiti di interfaccia.

Requisiti utente

I requisiti utente, noti anche come Stakeholder Requirements, rispecchiano il punto di vista del “cliente” (sono scritti per e con il cliente), ed essendo rivolti a personale non esperto e disinteressato ai dettagli implementativi, determinano solo il comportamento esterno del sistema mediante una descrizione chiare dei servizi che esso dovrebbe fornire ed i vincoli sotto cuoi dovrà operare.
Inoltre, poiché un requisito contenente troppe informazioni, anche dettagliate, potrebbe essere di difficile comprensione per l’utente, e limitare le possibili soluzioni alternative e innovative degli sviluppatori, tali requisiti dovrebbero specificare esclusivamente i servizi chiave3 che il sistema dovrà implementare.

Da quanto detto si evince che, nella stesura di tali requisiti, si dovrebbe evitare l’uso di un linguaggio specifico che descriva in che modo sarà implementato il sistema, poiché questo porterebbe a specificare un requisito che per definizione non sarà di utente. Tra l’altro è sconsigliato anche l’uso del solo linguaggio naturale, in quanto esso pur sembrando il mezzo più rapido ai fini della comprensione dell’utente, potrebbe portare a diverse problematiche a causa delle sue forti lacune.

Di conseguenza, per specificare i requisiti utente si preferisce un linguaggio naturale, corredato da diagrammi, che rappresenti il giusto compromesso tra formalismo e comprensibilità.
In definitiva, il cliente sottoporrà tali requisiti allo sviluppatore al fine di ottenere un offerta di realizzazione (requisiti aperti a soluzioni alternative) per il sistema software.

Esempio di Requisito Utente

Il sistema software deve fornire un mezzo per la rappresentare e visualizzare file esterni generati da altri tool.

Requisiti di sistema

Tutti gli aspetti tecnici prendono forma nei requisiti di sistema, i quali sono specificati mediante la stesura di un “documento” strutturato che descrive in modo più dettagliato le
funzioni, i servizi e i vincoli operativi del sistema software.
Quindi possiamo pensare a essi come una “versione espansa” dei requisiti utente e dovrebbero descrivere semplicemente, utilizzando notazioni più dettagliate rispetto a quelle adoperate per i requisiti utente, il comportamento esterno del sistema, senza specificare “come” il sistema dovrebbe essere progettato o implementato.

Naturalmente, essendo un sistema scomponibile, anche i suoi requisiti saranno organizzati così da far riferimento al particolare sottosistema al quale si riferiscono: questo è indispensabile per il riuso.
Questi requisiti sono tipicamente destinati agli specialisti, in altre parole a lettori che devono sapere con precisione “cosa” il sistema, dovrà fare. Pertanto, in questo caso il punto di vista è quello dello “sviluppatore”, che utilizza tali requisiti anche per definire il contratto con il cliente.

Il linguaggio naturale è poco adatto alla descrizione dei requisiti di sistema, per tale motivo sono state definite diverse alternative alla specifica in tale linguaggio, come:

1. Linguaggio naturale strutturato: limitazione delle forme linguistiche usabili, uso di costrutti di controllo tipo linguaggi di programmazione (if-then-else, while, for…), uso di forms (moduli predefiniti: nome e descrizione della funzione, input, output, precondizioni, ecc.).
2. Linguaggi di descrizione di progettazione: simili ai linguaggi di programmazione ma con caratteristiche più astratte per esprimere requisiti e definire modelli operazionali.
3. Notazioni grafiche: un linguaggio grafico, aiutato da annotazioni testuali, viene usato per definire i requisiti funzionali del sistema (ad esempio: casi d’uso proposti dall’utente).
4. Specifiche matematiche: linguaggi basati su concetti matematici (ad esempio: insiemi o automi a stati finiti). Riducono le ambiguità ma sono di difficile comprensione per il cliente.

In ultima analisi, nella stesura del documento di specifica dei requisiti, è consigliabile collocare i requisiti utente in sezioni del documento separate de quelle di sistema, fornendo così al destinatario le informazioni di suo interesse in una forma ad esso consona.

Esempi di Requisito di Sistema

1. L’utente deve avere la possibilità di definire il tipo dei file esterni.
2. Ad ogni tipo di file esterno deve essere associato il tool che lo ha generato.
3. Ogni tipo di file esterno deve essere rappresentato mediante una specifica icona sullo schermo.
4. L’utente deve avere la possibilità di definire l’icona che rappresenta il tipo di file esterno.
5. Quando l’utente seleziona un’icona che rappresenta un file esterno, deve poter essere eseguito il tool in grado di visualizzare il file.