Come scrivere un documento dei requisiti del software (con modello)

Ricordi quando a scuola leggevi i romanzi del XIX secolo e pensavi: “Ma questa è la stessa lingua?” Beh, è probabile che tu abbia avuto lo stesso pensiero in ufficio quando hai collaborato con sviluppatori di intelligenza artificiale o analisti SEO esperti di web. Se solo ci fossero dei CliffsNotes per i colleghi.

A volte è essenziale che i reparti che si trovano agli estremi opposti di un’organizzazione lavorino insieme, anche se parlano linguaggi tecnici diversi. Se hai mai lavorato in un team interfunzionale, sai quanto può essere difficile mantenere tutti sulla stessa lunghezza d’onda. 

I documenti di specifica dei requisiti del software possono aiutare i project manager, i product manager e i business analyst a suddividere i concetti di alto livello in attività che ogni membro del team può seguire durante il processo di sviluppo. 

Cos'è un documento di specifica dei requisiti del software (SRS)?

Un documento di specifiche dei requisiti del software (SRS) elenca i requisiti, le aspettative, la progettazione e gli standard per un progetto futuro. Questi includono i requisiti aziendali di alto livello che dettano l’obiettivo del progetto, i requisiti e le esigenze dell’utente finale e le funzionalità del prodotto in termini tecnici. In parole povere, un documento SRS fornisce una descrizione dettagliata di come dovrebbe funzionare un prodotto software e di come il team di sviluppo dovrebbe farlo funzionare.

Immagina di avere un’ottima idea per un’app. Hai un’idea di cosa vuoi che faccia e di come vuoi che sia, ma sai che non puoi semplicemente dare una descrizione verbale a uno sviluppatore e aspettarti che soddisfi le tue aspettative. È qui che entra in gioco un SRS.

Perché usare un SRS?

Se gli sviluppatori non hanno indicazioni chiare durante la creazione di un nuovo prodotto, potresti finire per spendere più tempo e denaro del previsto cercando di far sì che il software corrisponda a ciò che avevi in mente. 

La composizione di un documento SRS ti aiuta a mettere la tua idea su carta e a definire un elenco chiaro di requisiti. Questo documento diventa l’unica fonte di riferimento del tuo prodotto, in modo che tutti i tuoi team, dal marketing alla manutenzione, siano sulla stessa lunghezza d’onda. 

Poiché le specifiche dei requisiti del software sono documenti in continua evoluzione, possono anche fungere da punto di comunicazione tra tutti gli stakeholder coinvolti nel processo di sviluppo del prodotto. Le iterazioni del prodotto sono destinate a verificarsi durante qualsiasi progetto di sviluppo software: annotando le modifiche nel documento SRS, tutte le parti possono convalidarle. Ciò faciliterà la comprensione dei requisiti del prodotto. 

Cosa includere in un documento SRS

La struttura di base di un documento SRS è costituita da quattro parti: un’introduzione, i requisiti di sistema e funzionali, i requisiti di interfaccia esterna e i requisiti non funzionali.

1. Introduzione

L’introduzione di un documento SRS è esattamente quello che ci si aspetta: una panoramica a 360 gradi del progetto. Quando scrivi l’introduzione, descrivi lo scopo del prodotto, il pubblico a cui è destinato e come verrà utilizzato. Nell’introduzione, assicurati di includere:

• Ambito del prodotto: l’ambito dovrebbe riguardare gli obiettivi aziendali generali del prodotto, il che è particolarmente importante se più team o appaltatori avranno accesso al documento. Elenca i vantaggi, gli obiettivi e le finalità previsti per il prodotto. 

• Valore del prodotto: perché il tuo prodotto è importante? In che modo aiuterà il pubblico a cui è destinato? Quale funzione svolgerà o quale problema risolverà? Chiediti in che modo il tuo pubblico troverà valore nel prodotto. 

• Destinatari previsti: descrivi i tuoi destinatari ideali. Sarà il pubblico a determinare l'aspetto del prodotto e il modo in cui lo commercializzerai. 

• Destinazione d’uso: immagina come il tuo pubblico utilizzerà il prodotto. Elenca le funzioni che offri e tutti i modi in cui il pubblico può utilizzare il prodotto, a seconda del suo ruolo. È anche una best practice includere casi d'uso per illustrare la tua visione.

• Definizioni e acronimi: ogni settore o azienda ha i propri acronimi o gergo. Definisci i termini che utilizzi nel tuo documento per assicurarti che tutte le parti capiscano cosa stai cercando di dire.

• Indice: un documento SRS completo sarà probabilmente molto lungo. Includi un indice per aiutare tutti i partecipanti a trovare esattamente ciò che stanno cercando. 

Assicurati che l’introduzione sia chiara e concisa. Ricorda che l’introduzione sarà la guida per il resto del documento e che dovrà essere interpretata allo stesso modo da tutti coloro che lo utilizzeranno.

2. Requisiti di sistema e requisiti funzionali

Una volta che hai scritto l’introduzione, è il momento di entrare nello specifico. I requisiti funzionali analizzano le caratteristiche e le funzioni del sistema che consentono a quest’ultimo di funzionare come previsto. 

Usa la panoramica come riferimento per verificare che i tuoi requisiti soddisfino le esigenze di base dell’utente mentre inserisci i dettagli. Ci sono migliaia di requisiti funzionali da includere, a seconda del prodotto. Di seguito sono riportati alcuni dei più comuni.

• Comportamenti se/allora

• Logica di gestione dei dati

• flussi di lavoro del sistema

• Gestione delle transazioni

• Funzioni amministrative

• Esigenze normative e di conformità

• Requisiti di prestazione

• Dettagli delle operazioni eseguite per ogni schermata

Se ti sembra troppo, prova a occuparti di un requisito alla volta. Più dettagli riesci a includere nel tuo documento SRS, meno problemi dovrai risolvere in seguito. 

Man mano che si entra nel dettaglio dei requisiti, è altrettanto importante mantenere i materiali di supporto coerenti e facili da seguire. Un modello di documentazione tecnica può far risparmiare tempo, ridurre gli errori e garantire che tutti, dagli sviluppatori agli utenti finali, dispongano di istruzioni chiare e aggiornate.

3. Requisiti dell’interfaccia esterna

I requisiti dell'interfaccia esterna sono tipi di requisiti funzionali che assicurano che il sistema comunichi correttamente con i componenti esterni, come ad esempio:

• Interfacce utente: la chiave per l'usabilità dell'applicazione, che include la presentazione del contenuto, la navigazione dell'applicazione e l'assistenza agli utenti, tra gli altri componenti.

• Interfacce hardware: le caratteristiche di ciascuna interfaccia tra i componenti software e hardware del sistema, come i tipi di dispositivi supportati e i protocolli di comunicazione.  

• Interfacce software: le connessioni tra il prodotto e altri componenti software, tra cui database, raccolte e sistemi operativi. 

• Interfacce di comunicazione: i requisiti per le funzioni di comunicazione che il tuo prodotto utilizzerà, come email o moduli incorporati. 

I sistemi integrati si basano su requisiti di interfaccia esterni. È necessario includere elementi come il layout dello schermo, le funzioni dei pulsanti e una descrizione di come il prodotto dipende da altri sistemi. 

4. Requisiti non funzionali (NRF)

L’ultima sezione del documento contiene i dettagli dei requisiti non funzionali. Mentre i requisiti funzionali dicono a un sistema cosa fare, i requisiti non funzionali (NFR) determinano come il sistema implementerà queste funzionalità. Ad esempio, un requisito funzionale potrebbe indicare al sistema di stampare una bolla di accompagnamento quando un cliente ordina il tuo prodotto. Un NFR garantirà che la bolla di accompagnamento venga stampata su carta bianca 10 x 15 cm, il formato standard per le bolle di accompagnamento. 

Sebbene un sistema possa funzionare anche se non si soddisfano i requisiti non funzionali, si potrebbero mettere a rischio le aspettative degli utenti o degli stakeholder. Questi requisiti tengono sotto controllo i requisiti funzionali, in modo da includere ancora caratteristiche come la convenienza e la facilità d’uso del prodotto. 

I tipi più comuni di requisiti non funzionali sono chiamati “Itys”. Sono:

• Sicurezza: ciò che è necessario per garantire che tutte le informazioni sensibili che il tuo software raccoglie dagli utenti siano protette. 

• Capacità: le esigenze di spazio di archiviazione attuali e future del tuo prodotto, incluso un piano su come il tuo sistema si adatterà all’aumento delle richieste di volume.

• Compatibilità: i requisiti hardware minimi per il software, come il supporto per i sistemi operativi e le loro versioni. 

• Affidabilità e disponibilità: la frequenza con cui prevedi che gli utenti utilizzino il tuo software e il tempo di errore critico in condizioni di utilizzo normale. 

• Scalabilità: i carichi di lavoro più elevati con i quali il sistema funzionerà ancora come previsto. 

• Manutenibilità: come la tua applicazione dovrebbe utilizzare l’integrazione continua in modo da poter distribuire rapidamente funzionalità e correzioni di bug. 

• Usabilità: quanto è facile utilizzare il prodotto. 

Altri tipi comuni di requisiti non funzionali includono i requisiti prestazionali, normativi e ambientali. 

Modello di documento dei requisiti del software

Sei pronto per iniziare la tua avventura di sviluppo software? Il nostro modello di SRS delinea tutti e quattro i componenti chiave di un ottimo documento SRS, fornendo a te e al tuo team preziosi approfondimenti sul prodotto che svilupperai. Ricorda di mantenere i tuoi requisiti dettagliati, chiari e concisi, in modo che tutte le parti coinvolte abbiano la stessa visione in mente.

Best practice per la stesura di un documento SRS

Lo scopo di un documento SRS è quello di far sì che ogni team di ogni reparto lavori per un obiettivo chiaro. Detto questo, ci sono alcune best practice da seguire per garantire che il tuo SRS serva al suo scopo.

Arricchisci il tuo documento con elementi visivi

L’inclusione di elementi visivi come diagrammi, schemi e modelli aiuterà i membri del team a comprendere meglio il processo. Sono particolarmente utili quando illustrano le principali funzioni e l'operatività del software. 

Una tecnica da provare durante il brainstorming del tuo progetto è la mappa mentale, che organizza idee, funzionalità e scenari e disegna le connessioni tra di essi. Crea una mappa mentale per strutturare i pensieri casuali mentre inizi a mettere insieme le tue idee. Questo elemento visivo non deve essere super dettagliato: è a questo che serve il tuo SRS. Concentrati invece sulle funzioni chiave del tuo software e su come si relazionano tra loro.

Mantieni chiarezza e concisione

L’ultima cosa che vuoi è che i tuoi sviluppatori abbiano dei ripensamenti durante la creazione del tuo prodotto. Cerca di non lasciare spazio ai membri del team per essere creativi e riempire gli spazi vuoti. Includi quanti più dettagli possibili quando descrivi i requisiti del software ed evita di:

• Usare parole vaghe come "generalmente" o "approssimativamente"

• combinare i termini con una “/”, che potrebbe essere interpretata come “e” o “o”;

• Usare valori limite complicati

• usare negazioni doppie e triple.

Una revisione paritaria formale è un buon modo per individuare le ambiguità nel documento SRS. Pianifica di esaminarlo con ciascun partecipante per confrontare la sua comprensione dei requisiti e apportare le modifiche necessarie. 

Conosci il tuo utente finale

Aggiungi la tua ricerca sul campo e le interviste agli utenti nel documento per costruire una chiara comprensione dei requisiti, delle aspettative e delle esigenze degli utenti finali. Questo dovrebbe aiutarti a visualizzare le operazioni che l’utente finale eseguirà con il software. Prendi in considerazione ogni possibile scenario e sfumatura che potrebbe verificarsi e includili nel tuo SRS. Ricorda che i tuoi sviluppatori implementeranno esattamente ciò che includi nel documento, né più né meno. 

Includi un margine di flessibilità

Il tuo SRS è un documento in continua evoluzione, il che significa che aggiungerai nuove funzionalità e modifiche a ogni iterazione. Tienine conto mantenendo i requisiti flessibili nel caso in cui il risultato non soddisfi le tue aspettative. È anche una best practice tenere un registro delle modifiche apportate al documento per evitare malintesi. I partecipanti dovrebbero essere in grado di risalire a ogni requisito originale e vedere chi apporta la modifica, quando e perché. 

Usa i documenti dei requisiti del software per chiarire la tua visione

Scrivere un documento di specifica dei requisiti del software non è facile, ma non è facile nemmeno risolvere continuamente problemi o gestire discussioni tra i membri del team. Il lavoro che dedichi a un documento completo sui requisiti del software ti ripagherà con un prodotto straordinario di cui tu e i tuoi stakeholder potrete essere orgogliosi.