Gestione dei requisiti: la chiave del successo dei progetti IT

Siete uno sviluppatore di software e avete appena accettato un nuovo progetto. Le aspettative del cliente? Elevate. Le specifiche? Ancora un grosso punto interrogativo. Il primo passo è chiaro: vi sedete con il cliente per capire le sue idee e i suoi obiettivi - la pietra miliare di ogni progetto di successo.

Ciò che all'inizio sembra semplice - "Abbiamo bisogno di una piattaforma per la nostra azienda" - si rivela rapidamente più complesso. Quali funzioni sono essenziali? Chi utilizzerà esattamente il software? È necessario collegare i sistemi esistenti? Ad ogni risposta sorgono nuove domande e una cosa diventa chiara: ogni cliente ha la propria idea di cosa significhi davvero "la soluzione perfetta". Ed è proprio qui che entra in gioco il vostro lavoro.

Senza un approccio strutturato, il caos può rapidamente scatenarsi. I requisiti che oggi sembrano chiari possono rivelarsi in seguito incompleti o fuorvianti. Le modifiche ai requisiti possono influenzare il corso dello sviluppo e persino far slittare la data di rilascio.

Una cosa che possiamo già dire è che a nessun cliente piace sentire queste notizie! Ma con una buona gestione dei requisiti è possibile evitare tutti questi problemi e garantire il successo del progetto.

In questo articolo scoprirete come raccogliere, documentare e dare priorità ai requisiti e al software futuro in modo efficiente, affinché il vostro progetto offra esattamente ciò di cui i vostri clienti hanno realmente bisogno e che si aspettano.

Cosa significa gestione dei requisiti?

Nello sviluppo del prodotto, la gestione dei requisiti si riferisce al processo strutturato di registrazione, documentazione, analisi, gestione e coordinamento dei requisiti di un prodotto o di un sistema. L'obiettivo è garantire che tutte le parti interessate abbiano una comprensione comune dei requisiti e che questi rimangano tracciabili e controllabili durante l'intero processo di sviluppo. Una gestione efficace dei requisiti aiuta a evitare malintesi, a minimizzare i rischi e a garantire il successo del progetto.

La gestione dei requisiti viene spesso definita anche gestione dei requisiti o ingegneria dei requisiti. Gli ingegneri dei requisiti sono quindi membri importanti di ogni team di progetto. Garantiscono il buon funzionamento dei processi assumendo il compito di documentare i requisiti di un progetto o di un prodotto nel modo più preciso possibile all'interno del team.

Cosa sono i requisiti del software?

Esistono speciali sottocategorie di requisiti che devono essere discusse prima della realizzazione di un progetto software. Servono a differenziare lo scopo di un requisito. Si può fare una distinzione tra requisiti funzionali e non funzionali.

Requisiti funzionali

I requisiti funzionali sono così chiamati nel settore dei progetti perché descrivono ciò che un sistema deve fare. In genere si intende che in ultima analisi concordano su caratteristiche specifiche che il cliente ha richiesto come parte della prossima versione del software.

Esempio: un'applicazione per il fitness deve tracciare i miei movimenti e mostrarmi un diagramma delle mie attività giornaliere e settimanali.

Requisiti non funzionali

I requisiti non funzionali descrivono COME un sistema deve implementare qualcosa. I requisiti non funzionali tendono quindi a specificare le condizioni e le circostanze in cui entrano in gioco i requisiti funzionali.

Esempio: l'applicazione per il fitness deve utilizzare solo una piccola quantità di memoria sul mio smartphone.

La gestione dei requisiti viene attuata sia nei progetti agili che in quelli non agili. Nella gestione classica dei progetti a cascata, cioè nell'approccio non agile, i requisiti devono essere definiti prima dell'inizio dei lavori di sviluppo, poiché è difficile influenzare le fasi specifiche di implementazione nel corso del progetto. Al contrario, nella gestione agile dei progetti, spesso vengono definiti solo alcuni requisiti all'inizio, che vengono poi adattati, sostituiti o aggiunti nel corso del progetto. Nei progetti agili, inoltre, i requisiti degli utenti possono essere implementati e prioritari passo dopo passo. A differenza della gestione tradizionale del progetto, che spesso richiede una specifica completa in anticipo, la pianificazione in intervalli agili consente lo sviluppo incrementale del software con un rapido feedback.

Che aspetto hanno i requisiti?

Questo probabilmente solleva la questione di chi è responsabile della stesura dei requisiti e di come si presentano in pratica. Di norma, il Product Owner ha il ruolo di Requirement Engineer, che traduce in parole le specifiche sviluppate nelle riunioni congiunte. A questo scopo si utilizzano spesso le storie utente. Una user story è una breve descrizione del caso d'uso in cui l'utente svolge un'attività con una funzionalità del software per raggiungere un obiettivo specifico. Ad esempio, la storia utente è strutturata come segue

"Come utente registrato dell'applicazione, vorrei cliccare su un pulsante per ricevere un link di conferma via e-mail in modo da poter reimpostare la mia password".

La storia utente può essere suddivisa in 3 componenti:

• Ruolo (utente, amministratore, sviluppatore, ...)

• Attività di esecuzione (ricevere un link di conferma via e-mail)

• Obiettivo/intenzione (reimpostare la mia password)

Vantaggi delle storie utente

Le storie utente offrono diversi vantaggi rispetto alle forme tradizionali di documentazione dei requisiti, come le specifiche dei requisiti e funzionali o le specifiche dettagliate:

1. Semplicità e comprensibilità - Le storie utente sono scritte in un linguaggio quotidiano e sono facili da capire, anche per i non addetti ai lavori. A differenza dei documenti formali sui requisiti, evitano termini tecnici complicati e sono comprensibili per tutti i soggetti coinvolti.

2. Focus sull'utente - Mentre i documenti tradizionali spesso enfatizzano i dettagli tecnici, le storie degli utenti si concentrano sui benefici effettivi per l'utente. Di conseguenza, lo sviluppo rimane più focalizzato sulle esigenze dell'utente.

3. Flessibilità e adattabilità - I requisiti possono cambiare nel corso di un progetto. Le storie utente possono essere facilmente adattate, aggiunte o ridefinite, mentre i documenti formali sono spesso rigidi e ingombranti.

4. Migliore collaborazione e comunicazione - Poiché le storie utente sono volutamente semplici, favoriscono il dialogo diretto tra sviluppatori, clienti e stakeholder. Servono come base per il dialogo, invece di essere una specifica finale e immutabile.

5. Evitare funzionalità non necessarie - la focalizzazione su esigenze specifiche dell'utente assicura che vengano sviluppate solo le funzioni veramente rilevanti. Questo riduce il rischio di "feature creep" e di inutili sforzi di sviluppo.

Nonostante questi vantaggi, le storie utente non sono sempre la scelta migliore: una specifica dettagliata può essere necessaria per sistemi critici per la sicurezza o altamente complessi. In molti progetti software, tuttavia, offrono un metodo efficiente e pratico per documentare i requisiti.

Artefatti nella gestione dei requisiti

Le storie utente possono essere integrate e concretizzate con dati e documenti aggiuntivi. Più materiale illustrativo, ad esempio modelli di progettazione, grafici o diagrammi, viene aggiunto ai requisiti sviluppati, più i requisiti diventano chiari.

Gli sviluppatori raramente devono scrivere le storie utente, ma sono responsabili dell'estrazione delle funzionalità e dei requisiti tecnici dalle storie. Se necessario, possono anche dividere la storia utente in storie più piccole e devono quindi delineare un diagramma di flusso adeguato delle varie storie per soddisfare i requisiti della storia utente.

I diagrammi di flusso, noti anche come flussi utente, hanno forme e dimensioni diverse. Alcuni sono basati sul testo, ma i flussi utente possono anche essere rappresentati da una serie di caselle collegate da frecce, o anche da wireframe o semplici prototipi. I flussi utente tracciano i percorsi più intuitivi che un utente può seguire per completare un'attività su un sito web o in un'applicazione per soddisfare le sue esigenze.

Il principio SMART

Oltre alle storie degli utenti, anche il principio SMART, spesso utilizzato nello sviluppo del software e nella gestione dei progetti, è uno dei metodi collaudati per la gestione dei requisiti.

Il principio SMART è così chiamato perché la parola "SMART" è composta dalle lettere iniziali delle proprietà dei requisiti.

• Specifico: i requisiti devono sempre affrontare un problema specifico.

• Misurabile: il risultato di un requisito è misurabile, cioè genera un reale valore aggiunto per il progetto.

• Accettato: Il requisito è stato concordato con tutte le parti interessate.

• Realistico: il requisito può essere realizzato nelle rispettive condizioni quadro.

• Programmato: Il requisito deve essere implementato entro una certa scadenza.

Un requisito formulato con la tecnica SMART è più facile da capire per il team e può aiutare a chiarire i malintesi e a fare chiarezza.

Un altro metodo collaudato per formulare i requisiti in modo preciso, comprensibile e realizzabile è quello di evitare l'uso di negazioni e ambiguità . Se non avete abbastanza tempo per spiegare i requisiti del prodotto durante le riunioni di rifinitura, dovete assicurarvi di usare un linguaggio chiaro quando scrivete i ticket. Questi possono contenere un testo descrittivo più lungo che può chiarire qualsiasi incertezza.

Un'altra cosa che può aiutare nella stesura dei requisiti è allineare il linguaggio dei ticket al metodoMoSCoW . Il metodo MoSCoW è una tecnica di prioritizzazione spesso utilizzata nella gestione dei requisiti per classificare i requisiti in base alla loro importanza. Il nome deriva dalle lettere iniziali dei quattro livelli di priorità:

• M (= "Must-Have"): Questa caratteristica deve essere realizzata.

• S (= "Should-Have"): Questa funzionalità è richiesta con urgenza.

• C (="Could-Have"): Questa caratteristica sarebbe gradita, ma è meno essenziale per il prodotto finale.

• W (="Will-Have"): Questa caratteristica potrebbe esistere in futuro, ma non ancora.

La regola MoSCoW fornisce punti di riferimento per la creazione di requisiti che facilitano la descrizione del ticket. Può anche essere utile agli sviluppatori e agli altri stakeholder per comprendere meglio i requisiti di un project manager.

Quali strumenti si usano per l'ingegneria dei requisiti?

Chi non ha mai avuto a che fare con la gestione dei requisiti si chiederà naturalmente dove vengono documentati i requisiti in modo che ogni membro del team possa visualizzarli in seguito. Di seguito abbiamo elencato gli strumenti più importanti che possono essere utilizzati per la specifica dei requisiti, la convalida dei requisiti e la gestione dei requisiti.

1. elicitazione dei requisiti

Questi strumenti ci aiutano a raccogliere i requisiti dalle parti interessate, a strutturare le discussioni e a registrare le idee in modo collaborativo. Tra questi, Miro o MURAL, lavagne digitali per il brainstorming, la mappatura delle storie degli utenti e i workshop, oppure Lucidchart e draw.io, utilizzati per creare diagrammi come diagrammi di flusso o diagrammi dei casi d'uso.

2. gestione dei requisiti

Un sistema di ticket, come Jira o Redmine, non dovrebbe mancare in nessun progetto agile. In questi prodotti software basati su cloud, i manager possono creare ticket , il che li rende estremamente adatti alla gestione, alla definizione delle priorità e al monitoraggio dei requisiti. Vengono utilizzati per organizzare meglio i requisiti e definire i backlog e i flussi di lavoro nelle sessioni di collaborazione del team.

Durante il funzionamento, i ticket possono essere assegnati a singoli o a più partecipanti. In caso di modifiche, vengono creati ticket di follow-up e collegati ai ticket originali oppure questi ultimi vengono rivisti in seguito a una nuova analisi dei requisiti nel team. Oltre a migliorare l'organizzazione dei compiti, gli strumenti di gestione dei progetti aiutano a garantire la tracciabilità delle singole fasi dell'implementazione dei requisiti.

3. documentazione dei requisiti

Altri strumenti frequentemente utilizzati per documentare i requisiti sono strumenti come Confluence o Notion. Confluence viene spesso utilizzato in combinazione con Jira e funge da database centrale della conoscenza. Qui si possono documentare i requisiti, registrare i verbali delle riunioni e condividere le specifiche con il team.

Strumenti come questi sono utilizzati per la documentazione strutturata e l'archiviazione dei requisiti per tutta la durata del progetto. Sono utili anche perché forniscono informazioni su ciò che è già stato implementato in un progetto e sulle misure già adottate. In questo modo, i nuovi dipendenti possono familiarizzare rapidamente e facilmente con un progetto in corso e acquisire le conoscenze necessarie per contribuire all'implementazione di ulteriori requisiti.

La documentazione del software svolge comunque un ruolo importante nel processo di sviluppo e non dovrebbe essere trascurata.

Conclusione

La gestione strutturata dei requisiti è la base per il successo dei progetti software. Se all'inizio di un progetto non avete ben chiaro quali funzioni deve avere il prodotto finale, non potete formulare compiti chiari per il vostro team e rischiate che lo sviluppo del prodotto duri più del previsto. Noi diciamo che non deve essere così! Con i nostri consigli per una gestione strutturata delle applicazioni, andrete sul sicuro!

Avete bisogno di supporto per determinare i requisiti di un nuovo software? Siete alla ricerca di membri del team di progetto già esperti nella gestione dei requisiti? Avete bisogno di un partner per il vostro prossimo progetto che abbia imparato a riformulare problemi e idee in requisiti chiari e comprensibili? Allora contattateci! Non vediamo l'ora di lavorare con voi per realizzare le vostre idee!