Introduzione
Esiste inevitabilmente una gerarchia di requisiti associati allo sviluppo del sistema, dal meno dettagliato, che
definisce la missione del sistema o il riepilogo delle mete e degli obiettivi dell'utente per il sistema, fino al più
dettagliato, attraverso diversi livelli intermedi. Al livello più dettagliato i requisiti possono essere espressi nel
vocabolario tecnico utilizzato dal sistema; pur al livello più alto, in genere vengono espressi in modo più astratto
nel linguaggio del dominio servito dal sistema, come le capacità, i servizi, i comportamenti, le funzioni, ecc. ecc.,
con una scelta delle parole spesso arbitraria. E' sicuramente possibile attribuire diversi significati a queste parole
per essere più precisi riguardo a cosa viene espresso (ad esempio, è possibile che la descrizione di un particolare
comportamento di un sistema non riveli molto sull'obiettivo o l'intenzione, ed è necessario qualche altro tipo di
descrizione), ma non è questo lo scopo di questa sezione.
Il perfezionamento dei requisiti (dal livello più alto, aggiungendo più dettagli) può continuare in un modo
puramente funzionale, vale a dire suddividendo le funzioni in funzioni secondarie o attività secondarie che le
supportano - a prescindere dalla realizzazione dell'architettura - e possono essere portato ad un livello in cui ciò
che viene descritto verrebbe collocato profondamente all'interno del sistema (i sistemi erano costruiti in questo modo)
e forse non avere comunicazione diretta al di fuori del sistema. Questo accadrebbe, per esempio, in un approccio
di analisi strutturata che è andata in profondità fino alla bolla primitiva di trasformazione.
Questo approccio è consigliato male, primo, perché porta all'identificazione di elementi come dei requisiti che non
sono affatto requisiti, ma semplicemente prodotti di lavoro della scomposizione; secondo, può portare ad architetture
scarse (ad esempio, che non soddisfano gli altri requisiti non formali o li eseguono in modo approssimativo), se il
progettista associa la realizzazione molto vicino alla scomposizione. Tuttavia esiste un valido motivo per effettuare
una certa scomposizione funzionale quando gli obiettivi della visione sono espressi ad un livello alto,
limitando la profondità della scomposizione a capacità e funzioni discernibili, cioè con sufficienti dettagli da
catturare tutto il comportamento significativo (per gli stakeholder), le funzioni ecc., in modo che il progettista
possa realizzarle correttamente. I requisiti perfezionati (più o meno direttamente) da requisiti di più alto livello
sono un tipo di requisito derivato.
Requisiti derivati
Ecco un esempio diretto:
Si supponga che un requisito di un utente sia "il sistema deve funzionare all'esterno, per 12 mesi all'anno in
Alaska."
Alcuni requisiti derivati sono:
-
Il sistema deve funzionare a temperature al di sotto di 32 F/0 C gradi.
-
Il sistema deve funzionare con la neve.
Esiste un altro tipo di requisito derivato. Quando i requisiti a livello di sistema sono stati espressi con
dettagli appropriati alla realizzazione:
-
Eseguire la partizione del sistema (modello) in elementi (ad esempio, utilizzando i metodi OOAD).
-
Determinare come questi elementi collaborano per produrre il comportamento di sistema desiderato.
-
Aggregare i comportamenti di livello inferiore, provenienti dalla collaborazione, per produrre i requisiti a
livello dell'elemento.
Questi requisiti a livello inferiore sono requisiti derivati; sono emersi in concomitanza con la scomposizione del
sistema. Questo è in contrasto con un approccio basato funzionalmente, in cui il partizionamento si verifica a
prescindere da qualsiasi scomposizione strutturale, e con il perfezionamento dei requisiti a livello di sistema, come
descritto nell'introduzione.
Requisiti assegnati
I requisiti assegnati sono requisiti che sono stati allocati (in base a considerazioni funzionali) a dei
componenti di un sistema, ad esempio dei sottosistemi hardware o software. Al livello massimo, quando ad esempio si
pensa a requisiti a livello di missione per un sistema-di-sistemi, potrebbe essere ancora appropriato elaborare i
requisiti funzionalmente, quindi eseguire la partizione dei requisiti derivati risultanti ed assegnando i gruppi a dei
sistemi - forse perfezionando ulteriormente prima della realizzazione. Oltre quel punto, la scelta è di
continuare come per i requisiti derivati. Anche al livello sistema-di-sistemi, è possibile considerare di continuare in
questo modo, utilizzando l'approccio di modellazione del business.
Notare che in un approccio derivato, si scompone il sistema in entità e si determinano i requisiti delle entità
studiando come collaborano per soddisfare i requisiti di livello superiore. In un approccio funzionale assegnato si
scompongono i requisiti e si specificano le entità che soddisfano i requisiti di livello inferiore.
L'approccio da utilizzare dipende dal contesto e dalle aspettative culturali e contrattuali. Ad esempio, la NASA
(National Aeronautics and Space Agency) [in the Software Assurance Guidebook, NASA Goddard Space Flight Center
Office of Safety, Reliability, Maintainability and Quality Assurance, 9/89] definisce i requisiti in quattro livelli di
dettaglio:
-
Livello 1, il livello della missione - sono ad un livello molto alto e si consolidano molto presto.
-
Livello 2, il livello del sistema (assegnati) - anche questi si consolidano molto presto a questo livello. Questi
requisiti sono derivati dal livello della missione e vengono poi assegnati a segmenti.
-
Livello 3, il livello del sottosistema (o segmento) (derivati) - i requisiti a questo livello sono derivati dai
requisiti a livello di sistema assegnati al segmento.
-
Livello 4, livello elemento di configurazione (HWCI [hardware configuration item], SWCI [software configuration
item]) (dettagliato) - assegnato dal livello precedente e poi perfezionato.
Livelli dei requisiti e mappatura per RUP.
In genere, i contratti sono offerte d'appalto di livello 3. La NASA è abituata a gestire i requisiti in questo modo e
sarebbe naturale per qualsiasi organizzazione che interagisce con la NASA adottare una tassonomia simile. Ci sarebbe
ancora una certa flessibilità per gli sviluppatori su come derivare i requisiti di livello inferiore, ma dato il
livello molto alto di astrazione dei requisiti a livello di missione (spesso sono più come dei requisiti a
livello di programma), la derivazione dei requisiti a livello di sistema (e l'assegnazione ai segmenti) può verificarsi
naturalmente lungo le linee funzionali. Nonostante ciò, con l'interesse nelle architetture di impresa, è sempre più
comune derivare anche i requisiti di sistema utilizzando le considerazioni strutturali. La figura precedente illustra
quanto appena descritto e mostra la mappatura dei livello della NASA per il prodotti di lavoro di RUP (inclusa la
modellazione del business). Notare come, nel processo RUP, l'assegnazione visualizzata nel flusso tradizionale viene
eseguita nel processo di realizzazione del caso d'uso e nella successiva aggregazione di comportamento. Le righe blu
tratteggiate collegano i prodotti di lavoro di livello simile.
|