Abbiamo precedentemente discusso le 4 attività principali dell’ingegneria dei requisiti.

L’ingegneria dei requisiti è un processo di raccolta e definizione dei servizi che dovrebbero essere forniti dal sistema.

Si concentra sul valutare se il sistema è utile al business (studio di fattibilità), scoprire i requisiti (elicitazione e analisi), convertire questi requisiti in qualche formato standard (specifica), e controllare che i requisiti definiscano il sistema che il cliente vuole (validazione).

In pratica, l’ingegneria dei requisiti non è un processo sequenziale, è un processo iterativo in cui le attività sono intrecciate.

Per esempio, si itera prima sui requisiti utente; elicitazione, specificazione e validazione, e si ripetono gli stessi passi per i requisiti di sistema.

All’inizio del processo, la maggior parte degli sforzi saranno spesi per capire i requisiti di business e utente di alto livello. Più tardi nel processo, più sforzi saranno spesi nell’elicitazione e nella comprensione dei requisiti di sistema dettagliati.

Alcuni considerano l’ingegneria dei requisiti come il processo di applicazione del metodo di analisi strutturato, come l’analisi orientata agli oggetti. Questo comporta l’analisi del sistema e lo sviluppo di un insieme di modelli grafici del sistema, come i modelli dei casi d’uso, che poi servono come specifica del sistema.

Anche se i metodi strutturati hanno un ruolo da giocare nel processo di ingegneria dei requisiti, c’è molto di più nell’ingegneria dei requisiti di quello che è coperto da questi metodi.

L’analisi e il design orientati agli oggetti saranno discussi in un’altra serie di tutorial.

Requisiti dell’utente e del sistema

In genere, i requisiti sono presentati in due livelli di dettaglio; requisiti dell’utente e del sistema, dove l’utente ha bisogno di dichiarazioni di alto livello dei requisiti, mentre gli sviluppatori del sistema hanno bisogno di una specifica di sistema più dettagliata. Quindi, i requisiti dell’utente e del sistema si riferiscono semplicemente a diversi livelli di dettaglio.

Avere diversi livelli di dettaglio è utile perché comunica informazioni sul sistema che viene sviluppato per diversi tipi di lettori.

Così, gli utenti finali non saranno interessati al dettaglio, hanno bisogno di un requisito scritto generico e astratto.

Mentre le persone che sono coinvolte nello sviluppo, hanno bisogno di ciò che esattamente il sistema dovrebbe fare.

Si finirà probabilmente con un sacco di problemi e malintesi se non si ha una chiara separazione tra i diversi livelli di dettaglio.

Requisiti degli utenti

Descrive i servizi che il sistema dovrebbe fornire e i vincoli sotto i quali deve operare. Non ci aspettiamo di vedere alcun livello di dettaglio, o cosa esattamente farà il sistema, è più un requisito generico.

Di solito è scritto in un linguaggio naturale e fornito da diagrammi.

Discuteremo diversi modi di specificare i requisiti più avanti in questa serie.

Requisiti di sistema

I requisiti di sistema significano una descrizione più dettagliata dei servizi di sistema e dei vincoli operativi come il modo in cui il sistema sarà usato, e i vincoli di sviluppo come i linguaggi di programmazione.

Questo livello di dettaglio è necessario per coloro che sono coinvolti nello sviluppo del sistema, come ingegneri, architetti di sistema, tester, ecc.

Requisiti funzionali &Non funzionali

I requisiti del software sono classificati in requisiti funzionali e requisiti non funzionali.

Requisiti funzionali

Si tratta delle funzioni principali che dovrebbero essere fornite dal sistema. Quando sono espressi come requisiti utente, di solito sono descritti in modo astratto.

Tuttavia, i requisiti funzionali di sistema più specifici descrivono le funzioni del sistema, i suoi input, l’elaborazione; come reagirà a un particolare input, e qual è l’output previsto.

Requisiti non funzionali

Sono i vincoli sulle funzioni fornite dal sistema.

I vincoli, come quanti processi il sistema può gestire (performance), quali sono i problemi (di sicurezza) di cui il sistema deve occuparsi come le iniezioni SQL…

Il tasso di fallimento (affidabilità), quali sono i linguaggi e gli strumenti che verranno usati (sviluppo), quali sono le regole da seguire per assicurare che il sistema operi entro la legge dell’organizzazione (legislativo).

I requisiti non funzionali sono spesso più critici dei singoli requisiti funzionali. Gli utenti possono solitamente trovare modi per aggirare una funzione del sistema che non soddisfa realmente i loro bisogni. Tuttavia, non riuscire a soddisfare un requisito non funzionale può significare che l’intero sistema è inutilizzabile.

Per esempio, se un aereo non soddisfa i suoi requisiti di affidabilità, non sarà sicuro per il funzionamento, o se un sistema di controllo incorporato non riesce a soddisfare i suoi requisiti di prestazione, le funzioni di controllo non funzioneranno correttamente.

I requisiti non funzionali dovrebbero essere misurabili

Quando possibile, dovremmo scrivere i requisiti non funzionali in modo quantitativo, in modo che possano essere testati. Si possono misurare quando il sistema viene testato per controllare se il sistema soddisfa i suoi requisiti non funzionali.

In pratica, i clienti di un sistema spesso trovano difficile tradurre i loro obiettivi in requisiti misurabili. Non capiscono cosa sia un certo numero che definisce la velocità o l’affidabilità richiesta. Per alcuni obiettivi, come la manutenibilità, non ci sono metriche che possono essere usate.

I costi di verifica dei requisiti non funzionali misurabili possono essere molto alti e i clienti potrebbero non pensare che questi costi siano giustificati.

I requisiti non funzionali e funzionali sono dipendenti

I requisiti non funzionali spesso sono in conflitto, interagiscono o addirittura generano altri requisiti funzionali o non funzionali.

Un requisito utente che riguarda la sicurezza, come limitare l’accesso agli utenti autorizzati, può generare altri requisiti che sono funzionali, come la necessità di includere strutture di autenticazione dell’utente nel sistema.

La distinzione tra requisiti funzionali e non funzionali

In pratica, è difficile separare requisiti funzionali e non funzionali. La distinzione non è chiara come suggeriscono le loro definizioni.

Separare tra requisiti funzionali e non funzionali

Se i requisiti non funzionali sono dichiarati separatamente dai requisiti funzionali, la relazione tra loro può essere difficile da capire.

Tuttavia, dovremmo evidenziare esplicitamente i requisiti che sono chiaramente collegati alle proprietà emergenti del sistema, come le prestazioni o l’affidabilità.

Le proprietà emergenti sono proprietà del sistema nel suo insieme piuttosto che proprietà che possono essere derivate dalle proprietà dei singoli componenti del sistema.