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

Ti ricordi quando a scuola leggevi i romanzi del XIX secolo e pensavi: “Ma è 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 esistessero dei CliffsNotes per i colleghi.

A volte è essenziale che i reparti agli estremi opposti di un’organizzazione collaborino, 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 specifiche dei requisiti del software possono aiutare i project manager, i product manager e gli analisti aziendali a suddividere i concetti di alto livello in azioni che ogni membro del team può seguire durante il processo di sviluppo. 

Che cos’è un documento di specifiche 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 determinano l’obiettivo del progetto, i requisiti e le esigenze dell’utente finale e la funzionalità del prodotto in termini tecnici. In poche parole, 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 una visione di ciò che vuoi che faccia e di come vuoi che appaia, 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 creazione di un documento SRS ti aiuta a mettere la tua idea nero su bianco 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 dinamici, fungono anche da punto di comunicazione tra tutti gli stakeholder coinvolti nel processo di sviluppo del prodotto. Le iterazioni del prodotto sono inevitabili in qualsiasi progetto di sviluppo software. Registrando le modifiche nell’SRS, tutte le parti possono verificarle all’interno del documento per evitare qualsiasi confusione in merito ai requisiti del prodotto.

Se il tuo team sta ancora definendo il contesto aziendale più ampio alla base del software, abbina il documento SRS a un modello di documento dei requisiti aziendali per definire obiettivi, ambito e metriche di successo prima di documentare i dettagli tecnici.

Cosa includere in un documento SRS

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

1. Introduzione

Un’introduzione SRS è esattamente ciò che ti aspetti: una panoramica generale del progetto. Quando scrivi l'introduzione, descrivi lo scopo del prodotto, il pubblico di destinazione e come verrà utilizzato. Nella tua introduzione, assicurati di includere:

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

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

• Pubblico di destinazione: descrivi il tuo pubblico ideale. Sarà il pubblico a determinare l’aspetto del prodotto e il modo in cui lo commercializzerai. 

• Uso previsto: immagina come il pubblico utilizzerà il prodotto. Elenca le funzioni che fornisci e tutti i modi possibili in cui il tuo 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 termini specifici. Definisci i termini che utilizzi nel documento SRS, per assicurarti che tutte le parti coinvolte capiscano cosa stai cercando di dire.

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

Assicurati che l’introduzione sia chiara e concisa. Ricorda che la tua introduzione sarà la guida per il resto dello schema SRS e che deve essere interpretata allo stesso modo da tutti coloro che utilizzano il documento.

2. Requisiti di sistema e requisiti funzionali

Una volta scritta l'introduzione, è il momento di entrare nello specifico. I requisiti funzionali suddividono le caratteristiche e le funzioni del sistema che consentono al sistema di funzionare come previsto. 

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

• Comportamenti se/allora

• Logica di gestione dei dati

• flussi di lavoro di sistema

• Gestione delle transazioni

• Funzioni amministrative

• Esigenze normative e di conformità

• Requisiti di prestazione

• Dettagli delle operazioni condotte per ogni schermata

Se ti sembra un compito arduo, prova ad affrontare un requisito alla volta. Più dettagli riesci a includere nel documento SRS, meno problemi dovrai risolvere in seguito. 

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

3. Requisiti dell’interfaccia esterna

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

• Interfacce utente: la chiave per l’usabilità dell’applicazione, che include la presentazione dei contenuti, 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 prodotto utilizzerà, come email o moduli incorporati. 

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

4. Requisiti non funzionali (NRF)

La sezione finale del documento contiene i dettagli dei requisiti non funzionali. Mentre i requisiti funzionali indicano a un sistema cosa fare, i requisiti non funzionali (NRF) 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 prodotto. Un NRF garantirà che il documento venga stampato su carta bianca 4"x6", il formato standard per le bolle di accompagnamento. 

Sebbene un sistema possa funzionare anche se non soddisfa i requisiti non funzionali, potresti mettere a rischio le aspettative degli utenti o degli stakeholder. Questi requisiti tengono sotto controllo i requisiti funzionali, quindi includono ancora attributi come l’accessibilità del prodotto e la facilità d’uso. 

I tipi più comuni di NFR sono chiamati “Itys”. Sono:

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

• Capacità: le esigenze di archiviazione attuali e future del prodotto, incluso un piano per la scalabilità del sistema in base alle crescenti 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 ti aspetti che gli utenti utilizzino il tuo software e qual è il tempo di guasto critico in condizioni di utilizzo normale. 

• Scalabilità: i carichi di lavoro più elevati in cui il sistema continuerà a funzionare 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 requisiti di prestazione, normativi e ambientali. 

Modello di documento dei requisiti del software

Vuoi iniziare la tua avventura nello sviluppo di software? Il nostro modello SRS delinea tutti e quattro i componenti chiave di un ottimo documento SRS, offrendo 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 abbiano la stessa visione in mente.

Best practice per la stesura di un documento SRS

Lo scopo di un SRS è garantire che ogni team in 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 SRS con elementi visivi

Includere 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 progetto è la mappa mentale, che organizza idee, funzionalità e scenari e traccia le connessioni tra di loro. Crea una mappa mentale per strutturare pensieri casuali mentre inizi a mettere insieme le tue idee. Questo elemento visivo non deve essere super dettagliato: è a questo che serve il documento SRS. Concentrati invece sulle funzioni chiave del tuo software e su come si relazionano tra loro.

Sii chiaro e conciso

L'ultima cosa che vuoi è che i tuoi sviluppatori si mettano in discussione quando costruiscono il tuo prodotto. Cerca di non lasciare spazio alla creatività dei membri del team. 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 barra, che potrebbe essere interpretata come "e" oppure "o"

• Utilizzare valori limite complicati

• Usare negazioni doppie e triple

Una revisione formale tra colleghi è 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 nell’SRS 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 includilo nel tuo SRS. Ricorda che gli sviluppatori implementeranno esattamente ciò che includi nel documento, né più né meno. 

Includi un margine di flessibilità

L’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. È inoltre buona norma tenere traccia delle modifiche apportate al documento per evitare incomprensioni. I partecipanti dovrebbero essere in grado di risalire a ogni requisito originale e vedere chi effettua la modifica, quando e perché. 

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

Scrivere un SRS non è facile, ma non lo è nemmeno risolvere problemi senza fine o gestire discussioni tra i membri del team. Il lavoro che metti in un documento completo di specifiche dei requisiti del software sarà ripagato con un prodotto straordinario di cui tu e i tuoi stakeholder potrete essere orgogliosi.