Come si realizza l'analisi dei requisiti?

Che aspetto ha il processo di pianificazione?

L'analisi dei requisiti è inclusa nel processo di pianificazione che, a sua volta, dovrebbe essere il seguente:

1. A progetto che descrive la visione finale prodotto da creare.
2. Un piano d'azione o un'idea generale che definisce ciò che deve essere fatto per raggiungere i nostri obiettivi.
3. Elenco dei compiti di base che determinano le fasi di lavoro del progetto.
4. Pianificazione del tempo, in cui si definisce cosa e quando deve essere consegnato.
5. Pianificazione dettagliata dei singoli compiti creati durante la terza fase.

L'analisi dei requisiti copre i primi tre punti del processo di pianificazione.

Visione del progetto

A questo punto, dovremmo porci alcune domande fondamentali:

1. Cosa vogliamo fare?

Sicuramente, a questo punto, siamo già consapevoli di ciò che stiamo cercando di ottenere e l'idea del progetto è stata presentata e pensata da tempo, ma vale la pena di rifletterci più a fondo. Forse scopriremo nuove questioni che vale la pena spiegare. A questo proposito possono essere utili le seguenti questioni:

• Quale problema dovrebbe risolvere questo progetto?
• Chi sarà l'utente finale?
• Stiamo creando un'interfaccia per gli utenti? La sua creazione è prevista in futuro? Il tipo di interfaccia che creiamo (desktop o mobile) è stato determinato? Ci interessa il RWD?
• Esistono applicazioni simili? Quali sono i loro pro e contro?
• Sono già stati creati i primi disegni o mockup del progetto?
• Il progetto dipenderà da applicazioni esterne? Hanno o conosciamo i loro limiti?
• Sappiamo qualcosa sulle prestazioni previste e sul livello di sicurezza?

2. Quali sono i requisiti?

È giunto il momento di stabilire un elenco di requisiti per il progetto. Oltre ai requisiti funzionali, specifichiamo quelli non legati alle funzionalità: usabilità, reattività, velocità, prestazioni e sicurezza.

Verifichiamo se ciascuno dei requisiti soddisfa i seguenti criteri:

• è completo - abbiamo la sua immagine completa,
• è corretto, veritiero e atteso,
• è fattibile - la fattibilità e gli altri requisiti non la annullano,
• è necessario - è necessario per il funzionamento del sistema o è richiesto dal cliente,
• è inequivocabile, leggibile e impossibile da interpretare in modo errato,
• è verificabile - dopo l'implementazione, attraverso l'osservazione e i test, è possibile determinare se questo requisito è stato soddisfatto o meno.

3. Qual è l'obiettivo finale?

Vale la pena di creare una semplice visualizzazione del funzionamento del progetto. Niente aiuta a comprendere appieno l'idea del progetto come disegnare un flusso di base o semplicemente scrivere sulla lavagna in punti ciò che deve accadere a turno. Nel caso di un'applicazione con un'interfaccia utente, la situazione ideale è avere anche i mockup più semplici.

4. Quali sono le priorità?

Proprio come quando si costruisce una casa, i progetti IT devono partire da zero all'inizio e poi rivolgersi a ciò che serve di più. All'inizio, quindi, sulla base dell'elenco dei requisiti, è necessario specificare un elenco di tutte le possibili funzioni che un determinato progetto dovrà svolgere e poi concordare quali di esse hanno la massima priorità e devono essere realizzate il prima possibile e quali sono di tipo "nice-to-have".

Il risultato dell'intera fase di visualizzazione del progetto dovrebbe essere un quadro generale di come il progetto dovrebbe funzionare, sia attraverso i mockup che il flusso disegnato delle attività. Dovremmo anche ricevere un elenco di tutte le possibili funzioni che un determinato progetto deve svolgere e sapere quale priorità ha ciascuna di esse.

La visualizzazione del progetto è un momento fondamentale dell'analisi dei requisiti. Aiuta a comprendere a fondo l'essenza del problema e quanto migliore è il materiale che lo illustra, tanto più efficienti saranno le fasi successive della pianificazione.

Piano d'azione

In questa fase, determiniamo già come immaginiamo il funzionamento del progetto nel suo complesso. È bene avere alcune idee per l'implementazione, riflettere e discutere su ciascuna di esse, evidenziandone i punti deboli e i punti di forza. Vale anche la pena di disegnare in dettaglio un'idea scelta, se non tutte.

Questa fase è anche il momento di considerare le questioni puramente tecnologiche, non solo in quale linguaggio o framework verrà scritto il progetto, ma anche di quali strumenti aggiuntivi avremo bisogno, ad esempio se decideremo di utilizzare lo stack AWS o magari qualcos'altro. Se siamo indecisi tra alcune tecnologie o non abbiamo idea di cosa usare, allora vale la pena spostare la decisione nel tempo e delegarla a un compito di ricerca. Certo, possiamo farlo solo se l'ulteriore pianificazione non è bloccata da questa ricerca. In caso contrario, possiamo tranquillamente collegarli ai compiti della sprint.

Compiti principali

Una volta stabilito il piano di progetto, si procede alla definizione dei compiti principali, che saranno poi discussi in dettaglio e suddivisi in compiti più piccoli dallo sviluppo. squadra quando si pianifica un nuovo sprint. È importante descrivere ogni compito nel modo più accurato possibile.

Sintesi

Come già detto, il processo di analisi dei requisiti varia a seconda della complessità del progetto. Ci sono problemi più facili e più difficili, e ci sono anche quelli che sono già stati risolti da qualcuno e quelli completamente nuovi su cui è necessario soffermarsi più a lungo. In ogni caso, ci sono alcuni suggerimenti importanti da tenere a mente:

• Comunicazione. È la componente più importante di ogni ciclo di vita del progetto: tutto deve essere definito e spiegato chiaramente.
• Comprendere rapidamente il problema. È bello avere una documentazione di progetto scritta, ma ricordiamoci che sia il più concisa possibile e non richieda mille pagine. Ogni membro del team di sviluppo deve avervi accesso e deve essere in grado di comprendere rapidamente la visione del progetto.
• La semplicità prima di tutto. Cerchiamo di rendere il più semplice possibile ciò che progettiamo, scegliamo soluzioni più semplici che possano essere facilmente sviluppate in futuro, o rinunciamo ad esse quando se ne presenta la necessità.
• Non ne avrete bisogno. Considerando che nella programmazione siamo guidati dal principio di YAGNI, qui lo abbiamo dietro la testa e non acceleriamo troppo.
• Modifiche. Non temiamoli: prima o poi ogni progetto ne ha bisogno. Inoltre, non illudiamoci che ciò che pianifichiamo oggi funzionerà per sempre. Allo stesso tempo, non dobbiamo considerare i cambiamenti come qualcosa di negativo e indesiderabile. I cambiamenti dovrebbero essere sinonimo di miglioramento, ed è questo che vogliamo: che il progetto sia il migliore.
• Tempo. Non lasciamo che la pianificazione duri troppo a lungo e si trascini all'infinito. Se abbiamo un problema che ci blocca, cerchiamo soluzioni all'esterno o scegliamo l'opzione più semplice.

Gli aspetti di cui sopra sono sempre da tenere a mente quando si analizzano i requisiti; in questo modo il lavoro si svolgerà senza intoppi e sarà la base di un progetto ben pianificato.

Per saperne di più:

• Qual è il miglior approccio di gestione del progetto per lo sviluppo del software?
• Le buone pratiche di Codest per la creazione di software. Il nostro approccio al viaggio del cliente
• Una guida rapida alla costruzione e allo sviluppo del proprio mercato. Cosa vale la pena di sapere?