Concetto: Requisiti derivati
Un requisito derivato è qualcosa che viene dedotto o derivato dalla richiesta di un utente. Questi requisiti vengono derivati studiando a fondo nei dettagli della richiesta dell'utente.
Relazioni
Descrizione principale

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:

  1. Il sistema deve funzionare a temperature al di sotto di 32 F/0 C gradi.
  2. 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

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.