Requisiti chiari aiutano i team di sviluppo a creare il prodotto giusto. E una specifica dei requisiti del software (SRS) aiuta a porre le basi per lo sviluppo del prodotto.
Definiremo cos’è, quando ne userete uno, e cinque passi per scrivere un documento SRS.
A colpo d’occhio, ecco come scrivere un documento sui requisiti:
- Definire lo scopo del vostro prodotto.
- Descrivere cosa state costruendo.
- Dettagli sui requisiti.
- Farlo approvare.
Cos’è un documento di Specifica dei Requisiti del Software (SRS)?
Una specifica dei requisiti del software (SRS) è un documento che descrive cosa farà il software e come ci si aspetta che lo esegua. Descrive anche le funzionalità di cui il prodotto ha bisogno per soddisfare tutte le esigenze degli stakeholder (business, utenti).
Un tipico SRS include:
- Uno scopo
- Una descrizione generale
- Requisiti specifici
I migliori documenti SRS definiscono come il software interagirà quando sarà incorporato nell’hardware – o quando sarà collegato ad altri software. I buoni documenti SRS tengono anche conto degli utenti della vita reale.
Perché usare un documento SRS?
Una specifica dei requisiti software è la base per l’intero progetto. Stabilisce la struttura che ogni team coinvolto nello sviluppo seguirà.
E’ usato per fornire informazioni critiche a più team – sviluppo, assicurazione qualità, operazioni e manutenzione. Questo mantiene tutti sulla stessa pagina.
L’uso dell’SRS aiuta a garantire che i requisiti siano soddisfatti. E può anche aiutarvi a prendere decisioni sul ciclo di vita del vostro prodotto – per esempio, quando ritirare una funzionalità.
Scrivere un SRS può anche minimizzare il tempo di sviluppo complessivo e i costi. I team di sviluppo embedded beneficiano particolarmente dell’uso di un SRS.
Software Requirements Specification vs. System Requirements Specification
Un software requirements specification (SRS) include descrizioni approfondite del software che sarà sviluppato.
Una specifica dei requisiti di sistema (SyRS) raccoglie informazioni sui requisiti di un sistema.
“Software” e “sistema” sono talvolta usati in modo intercambiabile come SRS. Ma, una specifica dei requisiti del software fornisce maggiori dettagli di una specifica dei requisiti di sistema.
>> Avete bisogno di dimostrare la conformità? Ecco come creare una matrice di tracciabilità >>
Come scrivere un documento SRS
Scrivere un documento SRS è importante. Ma non è sempre facile da fare.
Qui ci sono cinque passi da seguire per scrivere un documento SRS efficace.
Creare uno schema (o usare un modello SRS)
Il primo passo è creare uno schema per le specifiche dei requisiti del software. Questo può essere qualcosa che si crea da soli. O si può usare un modello SRS esistente.
Se lo si crea da soli, ecco come potrebbe essere il vostro schema:
1. Introduzione
1.1 Scopo
1.2 Destinatari
1.3 Uso previsto
1.4 Portata
1.5 Definizioni e acronimi
2. Descrizione generale
2.1 Esigenze degli utenti
2.2 Presupposti e dipendenze
3. Caratteristiche e requisiti del sistema
3.1 Requisiti funzionali
3.2 Requisiti dell’interfaccia esterna
3.3 Caratteristiche del sistema
3.4 Requisiti non funzionali
Una volta che hai il tuo schema di base, sei pronto per iniziare a compilarlo.
Scarica un white paper sulle migliori pratiche per scrivere i requisiti >>
Inizia con uno scopo
L’introduzione al tuo SRS è molto importante. Stabilisce l’aspettativa per il prodotto che stai costruendo.
Quindi, inizia definendo lo scopo del tuo prodotto.
Pubblico previsto e uso previsto
Definire chi nella vostra organizzazione avrà accesso all’SRS – e come dovrebbe usarlo. Questo può includere sviluppatori, tester e project manager. Potrebbe anche includere le parti interessate in altri dipartimenti, compresi i team di leadership, le vendite e il marketing.
Scopo del prodotto
Descrivere il software che viene specificato. E includere i benefici, gli obiettivi e i traguardi. Questo dovrebbe riferirsi agli obiettivi generali del business, specialmente se i team al di fuori dello sviluppo avranno accesso all’SRS.
Definizioni e acronimi
È intelligente includere una definizione del rischio. Evitare il rischio è una priorità per molti sviluppatori – specialmente quelli che lavorano in team di sviluppo critici per la sicurezza.
Ecco un esempio. Se state creando un dispositivo medico, il rischio potrebbe essere che il dispositivo si guasti e causi una fatalità.
Definendo questo rischio in anticipo, è più facile determinare i requisiti specifici di cui avrete bisogno per mitigarlo.
>> Dovete creare un PRD? Ecco un how-to con esempi >>
Fate una panoramica di ciò che costruirete
Il vostro prossimo passo è quello di dare una descrizione di ciò che state per costruire. Si tratta di un aggiornamento di un prodotto esistente? È un nuovo prodotto? È un add-on per un prodotto che hai già creato?
Queste cose sono importanti da descrivere in anticipo, così tutti sanno cosa stai costruendo.
Dovresti anche descrivere perché lo stai costruendo e per chi è.
I bisogni degli utenti
I bisogni degli utenti – o le classi e le caratteristiche degli utenti – sono fondamentali. Dovrete definire chi userà il prodotto e come.
Avrete utenti primari e secondari che useranno il prodotto regolarmente. Potreste anche aver bisogno di definire i bisogni di un acquirente separato del prodotto (che potrebbe non essere un utente primario/secondario). E, per esempio, se state costruendo un dispositivo medico, avrete bisogno di descrivere i bisogni del paziente.
Assunzioni e dipendenze
Ci potrebbero essere dei fattori che influenzano la tua capacità di soddisfare i requisiti delineati nel tuo SRS. Quali sono questi fattori?
Ci sono delle ipotesi che stai facendo con l’SRS che potrebbero rivelarsi false? Dovreste includere anche quelle qui.
Infine, dovreste notare se il vostro progetto dipende da fattori esterni. Questo potrebbe includere componenti software che state riutilizzando da un altro progetto.
Dettagliate i vostri requisiti specifici
La prossima sezione è fondamentale per il vostro team di sviluppo. Qui è dove dettagli i requisiti specifici per costruire il tuo prodotto.
Requisiti funzionali
I requisiti funzionali sono essenziali per costruire il tuo prodotto.
Se state sviluppando un dispositivo medico, questi requisiti possono includere infusione e batteria. E all’interno di questi requisiti funzionali, potresti avere un sottoinsieme di rischi e requisiti.
Requisiti di interfaccia esterna
I requisiti di interfaccia esterna sono tipi di requisiti funzionali. Sono importanti per i sistemi embedded. E delineano come il vostro prodotto si interfaccerà con altri componenti.
Ci sono diversi tipi di interfacce per cui potreste avere dei requisiti, tra cui:
- Utente
- Hardware
- Software
- Comunicazioni
Funzioni di sistema
Le caratteristiche di sistema sono tipi di requisiti funzionali. Sono caratteristiche che sono richieste per far funzionare un sistema.
Altri requisiti non funzionali
I requisiti non funzionali possono essere importanti quanto quelli funzionali.
Questi includono:
- Performance
- Safety
- Security
- Quality
L’importanza di questo tipo di requisiti può variare a seconda del vostro settore. I requisiti di sicurezza, per esempio, saranno critici nell’industria dei dispositivi medici.
L’EIEEE fornisce anche una guida per scrivere le specifiche dei requisiti software, se ne siete membri.
Ottieni l’approvazione per la SRS
Una volta completata la SRS, dovrai farla approvare dai principali stakeholder. E tutti dovrebbero rivedere l’ultima versione del documento.
Scrivere una SRS in Microsoft Word vs. Software dei requisiti
È possibile scrivere le specifiche dei requisiti software in Microsoft Word. Un modo intelligente per farlo è creare un modello di SRS che potete usare come punto di partenza per ogni progetto.
Tuttavia, anche con un modello, scrivere un SRS in questo modo può essere un processo minuzioso. E se un requisito cambia, il tuo SRS può cadere facilmente fuori tempo. Inoltre, ci possono essere problemi di versione con i documenti dei requisiti in Word.
Puoi risparmiare tempo – e assicurare l’accuratezza – scrivendo invece un SRS in Helix ALM.
Perché Helix ALM è meglio…
Helix ALM (che viene fornito con uno strumento di gestione dei requisiti dedicato) aggiunge efficienza all’intero processo di gestione dei requisiti.
Creando un SRS in Helix ALM, vi assicurerete una singola fonte di verità sul vostro SRS. Sarà più facile fare le revisioni dei requisiti del vostro SRS. E questo vi aiuterà a ottenere approvazioni più veloci, in modo che i vostri sviluppatori possano iniziare.
Una volta che avete i requisiti in un SRS, potete facilmente gestirli durante tutto il processo di sviluppo.
Se stai anche scrivendo un PRD, puoi collegare quei requisiti di funzionalità al requisito di alto livello nell’SRS. Questo crea una tracciabilità attraverso il processo dei requisiti.
Puoi anche collegare i requisiti nel tuo SRS ai test. Questo vi aiuterà a garantire che il prodotto che consegnate soddisfi lo scopo e i requisiti del vostro SRS.
Vedete voi stessi quanto può essere facile scrivere un SRS. Provate gratuitamente Helix ALM – e vedrete come un SRS efficace migliorerà il vostro processo di sviluppo. Puoi anche guardare la nostra demo per vedere più funzionalità.
Risparmiate tempo scrivendo un SRS in Helix ALM ▶️ guardate prima la demo