Sviluppo di software | Metodologia

Obiettivi contro requisiti: qual è la differenza?

Obiettivi e requisiti, due concetti apparentemente molto diversi. Ma le apparenze sono ingannevoli, ci sono chiare connessioni. Purtroppo, il ponte tra obiettivi e requisiti non è spesso sufficientemente presente in molti progetti. Con un approccio sistematico nell'inizializzazione del progetto e nella fase di concept, molti malintesi che possono sorgere nelle fasi successive possono essere evitati. Decisioni consapevoli di design nelle prime fasi del progetto aiutano.

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.

Circa l'autore


Amministratore delegato INTRASOFT AG

Daniel Hösli è Managing Director e Lead Consultant di INTRASOFT AG, la cui soluzione SaaS PQFORCE è la piattaforma leader per la gestione aziendale agile e orientata ai progetti. Per 15 anni è stato coinvolto quotidianamente nello sviluppo di sistemi di gestione dei progetti in qualità di consulente e gestore di progetti - sia dal punto di vista organizzativo che tecnico - e quindi ha l'esperienza acquisita da innumerevoli contatti e compiti da una grande varietà di aziende e diversi livelli di gestione.

Da non perdere

Con PQFORCE Insights riceverete le nostre ultime notizie, le migliori pratiche, i consigli e le offerte direttamente nella vostra casella di posta elettronica.
Ti invieremo solo email pertinenti e senza spam.
Puoi sempre annullare l'iscrizione con un semplice clic.
Provalo ora

Utilizzando questo sito web, l'utente accetta l'uso di cookie per migliorare l'offerta e per l'analisi dell'utilizzo.Politica sulla privacy