Perché i requisiti sono importanti nell'ingegneria del software?

In questo articolo, esaminiamo l'importanza dei requisiti nello sviluppo del software e le ragioni per cui trascurare la fase dei requisiti non è un'idea saggia quando si crea un'app.

" Software funzionante su documentazione completa. " Questa è una parte del Manifesto Agile.

In superficie, questa affermazione può sembrare implicare che i requisiti siano irrilevanti e non degni del tempo. Alcuni sviluppatori e i loro clienti rinunciano alla documentazione adeguata. Ma questo è un errore.

Cominciamo con una piccola spiegazione di quali sono i requisiti in termini di sviluppo del software.

Quali sono i requisiti nello sviluppo di app?

Non è che la definizione dei requisiti cambi in modo significativo quando viene applicata allo sviluppo del software. I requisiti specificano semplicemente quali funzionalità dovrebbe includere un prodotto e come dovrebbero funzionare tali funzionalità. Il modo in cui ti avvicini a loro è ciò che è importante.

La raccolta e l'analisi dei requisiti è una delle fasi iniziali del processo di sviluppo del software nelle metodologie Agile e Waterfall. Durante la fase dei requisiti della fase di validazione dell'idea, deve essere raggiunto un accordo tra il cliente e lo sviluppatore su cosa dovrebbe fare esattamente il prodotto finale e come. I requisiti nello sviluppo di app sono generalmente piuttosto dettagliati.

Come definire i requisiti del software

Ci possono essere diversi tipi di requisiti nello sviluppo del software.

Requisiti aziendali

Perché il cliente ha bisogno dell'app? A prima vista, queste informazioni potrebbero sembrare inutili o addirittura ridondanti. Dopotutto, hai un cliente che vuole pagarti per creare un'app. Perché dovresti preoccuparti delle loro ragioni?

Bene, se sei orgoglioso di quello che fai e ti sforzi di costruire prodotti di qualità, dovresti preoccuparti dei perché tanto quanto ti interessano del cosa e del come.

L'importanza dei requisiti aziendali è che forniscono una visione dell'obiettivo finale. Con l'obiettivo in vista, gli sviluppatori possono stabilire le priorità. Possono anche applicare la loro esperienza per offrire soluzioni migliori per raggiungere questi obiettivi. C'è un motivo per cui l'analisi aziendale è inclusa nel processo di sviluppo nella maggior parte delle aziende.

Senza requisiti aziendali chiari, possono essere prese decisioni sbagliate. Decisioni che rallenteranno lo sviluppo, interromperanno le scadenze e porteranno a ulteriori fasi di sviluppo.

Requisiti software

Esistono due tipi di requisiti: funzionali e non funzionali. In parole povere, la distinzione è la seguente:

I requisiti funzionali sono quali requisiti — Per cosa è progettato questo sistema? Come suggerisce il nome, descrivono la funzionalità del software.

I requisiti non funzionali sono i requisiti come — In che modo questo sistema farà ciò per cui è progettato? Questi requisiti descrivono come ciascuna funzionalità dovrebbe comportarsi in quali condizioni, quali limitazioni dovrebbero esserci e così via.

I due vanno mano nella mano. I requisiti non funzionali completano e definiscono i requisiti funzionali. Ad esempio, immaginiamo di creare un'app di messaggistica.

I principali requisiti funzionali, in questo caso, sarebbero:

1. L'app deve essere in grado di inviare messaggi.
2. L'app deve supportare il trasferimento di file e file multimediali.
3. Eccetera.

Questi sono piuttosto semplici ed è facile capire perché i requisiti funzionali sono importanti: delineano la funzionalità. In questo esempio, il i requisiti non funzionali potrebbero essere i seguenti :

1. Il servizio deve offrire tutte le funzionalità in tutti i principali browser: Microsoft Edge, Google Chrome (ultime due versioni), Mozilla Firefox (ultime due versioni), Opera, Safari (ultima versione).
2. I layout mobili devono essere supportati.
3. Eccetera.

Come potete vedere, i requisiti funzionali sono fondamentalmente un elenco di funzionalità che devono essere incluse nel sistema . D'altra parte, i requisiti non funzionali sono specifici. Sono necessari per definire le condizioni di sviluppo e test.

È vero che il processo Agile iterativo comporta la possibilità di introdurre modifiche in qualsiasi fase dello sviluppo , ma ciò non implica del tutto requisiti precedenti. Hai solo bisogno di renderli flessibili.

Senza parametri precisi specificati, è impossibile capire se una funzionalità è progettata esattamente come dovrebbe essere.

I requisiti devono essere accuratamente analizzati e documentati. Come mai? Perché tante cose possono andare storte se non lo sono.

La spada di Damocle dei requisiti non documentati

L'importanza dei requisiti software è meglio compresa dagli specialisti del controllo qualità. Quando i requisiti del progetto non sono definiti correttamente, i QA ricevono il colpo più grande. Immagina di provare a determinare se il software è implementato correttamente senza linee guida chiare su cosa dovrebbe fare e come dovrebbe farlo. È una follia totale.

Tuttavia, questo problema non riguarda solo i tester. Non avere specifiche ufficiali significa quanto segue:

• Non c'è una chiara comprensione di ciò che costituisce un prodotto finito o addirittura una caratteristica.
• Il cliente non sa cosa aspettarsi alla fine dello sviluppo e per cosa sta pagando.
• Gli sviluppatori sono lasciati in sospeso, dovendo capire le specifiche delle funzionalità in base a ciò che è stato detto e come lo hanno capito loro stessi.
• bug. Sono ovunque.

I requisiti non documentati portano a problemi di comunicazione da tutte le parti. Non è affatto raro che un cliente e uno sviluppatore comprendano gli stessi termini in modo diverso. Specialmente se stiamo parlando di una società di sviluppo in outsourcing che non conosce a fondo l'attività del cliente.

I problemi di comunicazione, a loro volta, aprono la strada a continue rielaborazioni, modifiche e correzioni di bug. C'è una possibilità che tutto andrà come previsto senza requisiti documentati, ma è scarso. Di solito, questa catena termina con scadenze interrotte e costi alle stelle.

Per garantire un corretto sviluppo del progetto, tutte le parti del prodotto e il processo del suo sviluppo devono essere compresi allo stesso modo da ogni membro del team. Per garantire che gli sviluppatori vedano ogni funzionalità del prodotto esattamente come fa il cliente, viene creata una specifica dei requisiti software (SRS).

Il diavolo sta nei dettagli: cosa rende una buona specifica dei requisiti software?

Ora, le specifiche dei requisiti software effettivi possono essere eccezionalmente dettagliate o possono essere solo uno schema delle funzionalità. Il livello di dettaglio dipende da una serie di fattori.

I requisiti di alta qualità sono facilmente comprensibili da tutti coloro che sono coinvolti nel progetto. Ciò include il cliente, che può essere o meno esperto negli aspetti tecnici. Alcune aziende richiedono un elenco di requisiti eccezionalmente tecnico e ricco di dettagli, mentre altre preferiscono i requisiti in termini semplici.

Indipendentemente da quanto sarà ricca di tecnologia la tua documentazione, esistono regole generali per la gestione dei requisiti software. Esiste persino uno standard ufficiale: IEEE Std 830-1998, "Pratica consigliata per le specifiche dei requisiti software". Ecco cosa dovrebbe essere un buon SRS, secondo lo standard:

• Corretto . Questo è facile. La correttezza dell'SRS viene verificata dal cliente e dallo sviluppatore in base all'accordo che hanno. L'SRS deve essere conforme alle specifiche tecniche ea tutta la documentazione di progetto che disciplina.

• Inequivocabile . Uno degli scopi principali di un SRS è eliminare i problemi di comunicazione. Ecco perché ogni specifica dei requisiti deve essere scritta per avere una sola possibile interpretazione. Non è insolito che un SRS includa un glossario.

• Completo . Più complessa è l'applicazione, più dettagliato deve essere l'SRS. Un SRS completo copre ogni aspetto, dai requisiti prestazionali alla funzionalità. Stabilisce anche alcuni limiti al design. Tuttavia, non specifica mai un design esatto. Offre solo parametri.

• Coerente . Coerenza interna significa che nessuna affermazione in un SRS contraddice altre affermazioni nello stesso SRS. Questo è un altro motivo per includere un glossario, in modo che qualsiasi oggetto, processo e specifica all'interno del documento sia designato con un termine preciso.

• Classificato per importanza e/o stabilità . Nella maggior parte dei casi, ci sono requisiti indispensabili e requisiti desiderati. È importante che le specifiche dei requisiti software etichettino chiaramente entrambi i tipi. Ciò aiuterà gli sviluppatori e i project manager a creare un piano passo passo per il progetto.

• verificabile . Ci deve essere un modo per testare ogni requisito che includi nell'SRS. Per essere considerati verificabili, i requisiti devono contenere concetti misurabili e concreti.

• Modificabile . Questo si riferisce alla struttura SRS. Per non interrompere il flusso di lavoro del progetto quando è necessario implementare modifiche, l'SRS deve essere chiaro e facile da modificare e i requisiti non devono essere ripetuti.

• Tracciabile . Dovrebbe essere facile identificare la fonte di ciascun requisito stabilito nell'SRS.

Queste sono raccomandazioni . In realtà, le aziende possono rinunciare ad alcuni di questi punti a seconda del progetto, del cliente e del team. Ma è sempre bene avere una guida.

I requisiti sono utili sia che tu sia specializzato nello sviluppo di applicazioni iOS e Android o nello sviluppo web. Sono documenti di uso generale. E il loro aspetto dipende generalmente dagli sviluppatori e dai loro clienti.

Poiché un SRS dovrebbe essere di facile comprensione per tutte le parti coinvolte, anche il modo migliore per progettarlo è discutibile. Alcuni preferiscono le tabelle, altri preferiscono le liste. Ci sono sviluppatori che preferiscono le loro specifiche in forma visiva come diagrammi di flusso di dati e grafici. Non esiste un unico modo giusto per creare un documento di specifica dei requisiti.

Conclusione

Ecco i punti più comuni in cui i requisiti software tornano utili:

• Capire l'obiettivo
• Stima dei costi di sviluppo
• Creare un programma completo
• Stabilire le priorità

Se documentare i requisiti è qualcosa che ogni sviluppatore decide da solo. E il valore dei requisiti varia a seconda della scala del progetto. In Mind Studios, preferiamo avere le cose in ordine, quindi documentiamo tutti i requisiti . Se sei interessato a come lo facciamo o hai domande sul valore dei requisiti in generale, contattaci tramite il nostro modulo di contatto .