Gli obiettivi di impatto di un progetto ci danno uno stato obiettivo. Dove vogliamo trovarci alla fine? Cosa si dovrebbe ottenere con il progetto? Gli obiettivi di implementazione forniscono le condizioni quadro. Quali risorse sono disponibili nel progetto? Da che parte andiamo per raggiungere l'obiettivo? Gli obiettivi del progetto, cioè gli obiettivi di impatto e di esecuzione, sono definiti al suo inizio (di solito). Ma cosa rappresentano i requisiti? E quando entrano in gioco?

I requisiti sono obiettivi concreti...

In un progetto ci sono solo pochi obiettivi, almeno rispetto ai requisiti. I requisiti di solito esistono in liste. Spesso, però, la relazione tra requisiti e obiettivi non è veramente stabilita. Dopotutto, cosa sono i requisiti se non obiettivi scomposti? Degli obiettivi dettagliati del progetto, o concretizzazione degli obiettivi del progetto. Nelle prime fasi di progetto, per esempio nella fase di design o di concept, vengono elaborati i requisiti. Ciò fa parte della disciplina di progetto "Ingegneria dei requisiti", e gli obiettivi del progetto ne sono il punto di partenza per questo. Almeno questa è la teoria.

...e gli obiettivi sono requisiti astratti

Guardiamo quest'affermazione un po' più da vicino. Giriamo la linea temporale e torniamo dall'elenco dei requisiti agli obiettivi. Gli obiettivi sono fondamentalmente il riassunto dei requisiti e formano un livello superiore di astrazione. In realtà, obiettivi e requisiti sono la stessa cosa, solo a diverse altezze o livelli di considerazione. Facciamo un esempio: diciamo che vogliamo costruire un sistema software che ci permetta di pianificare meglio le nostre risorse umane (un obiettivo di impatto del progetto). Aggiungiamo che dovrebbe costare non più di 200.000 euro ed essere realizzato entro un anno (due obiettivi di esecuzione del progetto). Questi sono probabilmente più obiettivi di progetto da una prospettiva di gestione (alto livello).

Il project manager e il suo team di progetto probabilmente non saranno ancora del tutto soddisfatti di questi obiettivi di gestione: cosa significa nello specifico "essere in grado di pianificare meglio le risorse umane"? E cosa significa "introdotto entro un anno"? Il team di progetto ha bisogno di saperlo con più precisione e di scomporre questi obiettivi al proprio livello di volo. Questa concretizzazione avviene nelle prime fasi del progetto. Migliore potrebbe significare, per esempio, che una panoramica dell'utilizzo delle risorse esistenti è ottenuta più rapidamente. O che si possono registrare i requisiti delle risorse nel sistema. Ancora più concreto: Il sistema dovrebbe mostrare graficamente a un responsabile di reparto le curve di carico di lavoro dei suoi dipendenti nei prossimi 3 mesi al semplice click di un pulsante. Nel mondo dello sviluppo del software, questo corrisponde un po' ad una storia utente o ad un caso d'uso. (Questa analogia dovrebbe bastare per questo approccio approssimativo).

Gli obiettivi sono il COSA, i requisiti il COME

Quando si scompongono gli obiettivi del progetto in requisiti nel contesto dell'ingegneria dei requisiti, diventa subito chiaro che ci possono essere diverse concretizzazioni per molti obiettivi. L'obiettivo "migliore" può essere inteso come "più veloce", "più chiaro" o anche "più conveniente". Si tratta di diversi approcci (design) per raggiungere un obiettivo. Così, molte decisioni devono essere prese in questa fase del progetto: ogni obiettivo (COSA) può essere raggiunto con diverse soluzioni (COME). E qualcuno deve decidere in questa fase quale di queste soluzioni sarà perseguita. Si tratta di decisioni di design che spesso vengono prese in modo insidioso e non proprio cosciente nel progetto.

Dall'obiettivo alla decisione di design al requisito, ad infinitum

Una volta che gli obiettivi del progetto (COSA) sono stati trasformati in forma di requisiti (COME) per mezzo di decisioni di design, l'intero processo può ovviamente essere ripetuto. Questi requisiti possono ora essere visti come obiettivi dettagliati. Dopo tutto, cosa sono i requisiti se non obiettivi concreti? Quindi possono essere concretizzati ancora di più. Tornando al nostro esempio, questo significa: la user story di cui sopra può essere ulteriormente concretizzata. Nello sviluppo del software, verrebbe probabilmente disegnata una schermata che mostra dove l'utente può premere quale pulsante per poi ottenere un grafico a barre, ecc.

Tuttavia, non vogliamo continuare questo esempio in modo così dettagliato qui. Piuttosto, il punto è che qui vediamo che la scomposizione degli obiettivi in requisiti può, in linea di principio, essere ripetuta più volte. Ogni requisito (HOW) può essere visto come un obiettivo (WHAT) ad un livello più profondo, che a sua volta può essere ulteriormente suddiviso in dettagli. Questo potrebbe essere ripetuto a volontà. Nello sviluppo del software, gli obiettivi potrebbero essere suddivisi con decisioni di design a tal punto da far emergere, alla fine, lo pseudo-codice o anche il codice eseguibile. I requisiti potrebbero diventare così concreti da porre la soluzione finita già quasi di fronte a voi. A questo livello di dettaglio si parla spesso di specifiche tecniche. Ma fondamentalmente, questi sono semplicemente obiettivi molto, molto dettagliati.