Rispettare ciascuno dei dettagli e i requisiti definiti nel progetto di software che viene svolto, i grandi obiettivi che uno sviluppatore deve raggiungere per soddisfare le aspettative dei propri clienti e rendere il progetto un successo. Come può uno sviluppatore creare sistemi che soddisfino tutte le esigenze dei propri clienti? Può essere una delle tue prime domande.
Il fatto è che ci sono molti fattori che influenzano il successo del progetto software. Ma oggi parleremo di un documento essenziale che dovrebbe essere preparato nelle prime fasi dello sviluppo del prodotto. Stiamo parlando del documento sulle specifiche dei requisiti del software.
La Software Requirements Specification (SRS) è senza dubbio considerata come una delle fasi più critiche dello sviluppo software / prodotto. SRS-Software Requirement Specification-una documentazione software speciale che contiene informazioni su come dovrebbe comportarsi il sistema stesso, quali funzioni dovrebbe svolgere, quale carico dovrebbe sopportare e così via. Il documento dei requisiti del prodotto è il luogo in cui sono descritte le caratteristiche e i requisiti del software, del prodotto, del programma o del set di programmi. Questi elementi sono espressi in linguaggio naturale, senza considerazioni o termini tecnici.
- È possibile ottenere una stima accurata dei costi, dei rischi e dei costi di tempo.
- Il cliente sarà in grado di formare la propria visione del progetto in modo più chiaro.
- Il cliente e il contraente avranno la stessa idea circa il prodotto.
- Aiuterà a identificare l’insieme ottimale di funzioni.
- Serve come base per la formazione di altra documentazione tecnica.
- Il processo di sviluppo sarà ottimizzato e il tempo ridotto al minimo.
- Non ci saranno duplicazioni di compiti.
- Consente di strutturare i problemi per risolverli più facilmente e più velocemente.
È diventato molto evidente che una scarsa specificazione dei requisiti software può portare a progetti falliti. Quindi, questa disciplina diventa sempre più essenziale.
Come preparare un documento sui requisiti del prodotto?
Il seguente modello segue le linee guida stabilite nello standard IEEE 830, secondo cui la specifica dei requisiti software dovrebbe contenere la descrizione della funzionalità dell’applicazione, del rapporto con i sistemi esterni e dei requisiti non funzionali come prestazioni, disponibilità, tempi di risposta e manutenibilità tra gli altri.
Il modello per preparare i requisiti del software, il documento è articolato nelle seguenti sezioni:
Funzione:
Si dovrebbe aggiungere un nome o un titolo di un prodotto che è specificato nella carta, compreso il numero di versione o release. Descrivere quali elementi o parti dell’ambito del software sono inclusi nel documento, stabilire se copre l’intero software, solo una parte di esso, sottosistema o sottogruppo di processi.
L’ambito del software:
Deve essere fornita una breve descrizione della gamma del software che viene specificato, incluso lo scopo o l’obiettivo generale, i benefici forniti all’area aziendale e organizzativa, la relazione degli obiettivi del software con gli obiettivi aziendali e le strategie aziendali. È possibile fare riferimento ad altri documenti.
Qui è possibile includere altri documenti stampati, documenti elettronici o indirizzi elettronici che completano il documento dei requisiti del prodotto.
Funzionalità del prodotto:
Ogni funzionalità può essere composta da uno o più requisiti software funzionali. Deve essere incluso solo un elenco numerato delle principali funzionalità.
Caratteristiche degli utenti:
In questa sezione, è necessario descrivere gli utenti che utilizzeranno questo prodotto. Classificarli sulla base della regolarità di utilizzo, un gruppo di funzionalità utilizzate, privilegi di sicurezza, livello di esperienza e altri parametri.
Ambiente operativo:
Dovrebbe essere incluso anche l’ambiente in cui il sistema, il software, il modulo o il gruppo di funzionalità saranno sviluppati. Menzionare aspetti come le versioni del sistema operativo, la piattaforma hardware e altri sistemi o elementi con cui deve coesistere.
Requisiti funzionali:
Elenca le funzionalità e, per ciascuna di esse, annota i requisiti funzionali. Possono anche essere documentati in una matrice di tracciabilità dei requisiti.
Regole aziendali:
Questa parte contiene i principi che devono essere applicati all’intero set di specifiche software elencate nel documento. Ad esempio, spiega quali individui possono svolgere un ruolo specifico in determinate circostanze.
Requisiti delle interfacce esterne:
Questo capitolo include le interfacce con l’hardware, le interfacce con altri sistemi e le interfacce di comunicazione, le caratteristiche e gli attributi delle interfacce utente (GUI).
Requisiti non funzionali:
Specificano criteri per valutare il funzionamento di un servizio informatico, in contrasto con i requisiti funzionali che definiscono comportamenti specifici.
Altri requisiti:
Includono quei requisiti che non sono spiegati in qualsiasi altra sezione del documento sui requisiti del prodotto. Può essere requisiti di database, internazionalizzazione, obiettivi legali e di riutilizzo dei componenti software.
Glossario:
Aggiungi una descrizione dei termini e degli acronimi necessari per comprendere il documento creato.
Suggerimenti per scrivere SPS
- Descrivere tutto molto brevemente e chiaramente, per quanto possibile.
- Non includere cose che potrebbero non dover essere documentate.
- Scrivi senza descrizioni vaghe. Una persona che legge l’SRS deve capire esattamente cosa è scritto, e non qualcos’altro.
- Visualizza. Ad esempio, utilizzare diagrammi DFD (data flow diagrams). La specifica non può essere completa se non sappiamo cosa c’è all’ingresso del software descritto e cosa c’è all’uscita. Tutto deve essere incluso.
Ora hai tutti gli elementi principali che ti aiuteranno a rendere le specifiche dei requisiti del software. Fallo!