La fase di produzione dei requisiti del processo di sviluppo del software è Specifiche dei requisiti software (SRS) (chiamato anche a documento dei requisiti ). Questo rapporto pone le basi per le attività di ingegneria del software e viene costruito quando vengono individuati e analizzati interi requisiti. SRS è un rapporto formale, che funge da rappresentazione del software che consente ai clienti di verificare se esso (SRS) è conforme alle loro esigenze. Inoltre, comprende i requisiti utente per un sistema nonché le specifiche dettagliate dei requisiti di sistema.
L'SRS è una specifica per uno specifico prodotto software, programma o insieme di applicazioni che eseguono funzioni particolari in un ambiente specifico. Serve a diversi obiettivi a seconda di chi lo scrive. Innanzitutto, l'SRS potrebbe essere scritto dal client di un sistema. In secondo luogo, l'SRS potrebbe essere scritto da uno sviluppatore del sistema. I due metodi creano situazioni completamente diverse e stabiliscono scopi del tutto diversi per il documento. Il primo caso, SRS, viene utilizzato per definire i bisogni e le aspettative degli utenti. Il secondo caso, SRS, è scritto per vari scopi e funge da documento contrattuale tra cliente e sviluppatore.
Caratteristiche di un buon SRS
Di seguito sono riportate le caratteristiche di un buon documento SRS:
1. Correttezza: La revisione degli utenti viene utilizzata per fornire l'accuratezza dei requisiti indicati nell'SRS. Si dice che SRS sia perfetto se copre tutte le esigenze che ci si aspetta veramente dal sistema.
2. Completezza: La SRS è completa se, e solo se, include i seguenti elementi:
(1). Tutti i requisiti essenziali, siano essi relativi a funzionalità, prestazioni, design, vincoli, attributi o interfacce esterne.
elimina l'ultimo commit git
(2). Definizione delle risposte del software a tutte le classi realizzabili di dati di input in tutte le categorie di situazioni disponibili.
Nota: è essenziale specificare le risposte sia ai valori validi che a quelli non validi.
(3). Etichette complete e riferimenti a tutte le figure, tabelle e diagrammi nell'SRS e definizioni di tutti i termini e unità di misura.
3. Coerenza: L'SRS è coerente se, e solo se, nessun sottoinsieme di requisiti individuali è descritto nel suo conflitto. Ci sono tre tipi di possibili conflitti nella SRS:
(1). Le caratteristiche specificate degli oggetti del mondo reale potrebbero essere in conflitto. Per esempio,
(a) Il formato di un rapporto di output può essere descritto in un requisito come tabellare ma in un altro come testuale.
(b) Una condizione può stabilire che tutte le luci devono essere verdi mentre un'altra afferma che tutte le luci devono essere blu.
(2). Potrebbe esserci un conflitto ragionevole o temporale tra le due azioni specificate. Per esempio,
(a) Un requisito può determinare che il programma aggiungerà due input e un altro può determinare che il programma li moltiplicherà.
(b) Una condizione può affermare che 'A' deve sempre seguire 'B', mentre un'altra richiede che 'A e B' coesistano.
(3). Due o più requisiti possono definire lo stesso oggetto del mondo reale ma utilizzare termini diversi per quell'oggetto. Ad esempio, la richiesta di input dell'utente da parte di un programma può essere chiamata 'prompt' in un requisito e 'suggerimento' in un altro. L'uso di terminologia e descrizioni standard favorisce la coerenza.
4. Unicità: L'SRS è inequivocabile quando ogni requisito fisso ha una sola interpretazione. Ciò suggerisce che ogni elemento è interpretato in modo univoco. Nel caso in cui venga utilizzato un metodo con più definizioni, la relazione sui requisiti dovrebbe determinare le implicazioni nell’SRS in modo che sia chiara e semplice da comprendere.
menu a discesa JavaScript
5. Classifica per importanza e stabilità: L'SRS è classificato in base all'importanza e alla stabilità se ciascun requisito in esso contenuto ha un identificatore per indicare il significato o la stabilità di quel particolare requisito.
In genere, tutti i requisiti non sono ugualmente importanti. Alcuni prerequisiti possono essere essenziali, soprattutto per le applicazioni critiche per la vita, mentre altri possono essere desiderabili. Ogni elemento dovrebbe essere identificato per rendere queste differenze chiare ed esplicite. Un altro modo per classificare i requisiti è distinguere le classi di elementi in essenziali, condizionali e facoltativi.
6. Modificabilità: L'SRS dovrebbe essere reso il più possibile modificabile e dovrebbe essere in grado di ottenere rapidamente modifiche al sistema in una certa misura. Le modifiche devono essere perfettamente indicizzate e con riferimenti incrociati.
7. Verificabilità: SRS è corretto quando i requisiti specificati possono essere verificati con un sistema economicamente vantaggioso per verificare se il software finale soddisfa tali requisiti. I requisiti vengono verificati con l'aiuto delle recensioni.
8. Tracciabilità: L'SRS è tracciabile se l'origine di ciascuno dei requisiti è chiara e se facilita il riferimento a ciascuna condizione nella documentazione di sviluppo o miglioramento futuro.
Esistono due tipologie di Tracciabilità:
1. Tracciabilità a ritroso: Ciò dipende dal fatto che ciascun requisito faccia esplicitamente riferimento alla propria fonte nei documenti precedenti.
2. Tracciabilità futura: Ciò dipende dal fatto che ciascun elemento dell'SRS abbia un nome o un numero di riferimento univoco.
La tracciabilità futura dell'SRS è particolarmente cruciale quando il prodotto software entra nella fase di funzionamento e manutenzione. Quando il codice e il documento di progettazione vengono modificati, è necessario essere in grado di accertare l'insieme completo di requisiti che potrebbero essere interessati da tali modifiche.
9. Indipendenza dal design: Dovrebbe esserci un'opzione per scegliere tra più alternative di progettazione per il sistema finale. Più specificamente, l'SRS non dovrebbe contenere alcun dettaglio di attuazione.
10. Testabilità: Un SRS dovrebbe essere scritto in modo tale che sia semplice generare casi di test e piani di test dal report.
11. Comprensibile per il cliente: Un utente finale può essere un esperto nel suo dominio specifico ma potrebbe non avere una formazione in informatica. Pertanto, lo scopo delle notazioni e dei simboli formali dovrebbe essere evitato il più possibile. Il linguaggio dovrebbe essere mantenuto semplice e chiaro.
12. Il giusto livello di astrazione: Se l'SRS è scritto per la fase dei requisiti, i dettagli dovrebbero essere spiegati esplicitamente. Mentre per uno studio di fattibilità è possibile utilizzare meno analisi. Pertanto, il livello di astrazione si modifica in base all’obiettivo dell’SRS.
Proprietà di un buon documento SRS
Le proprietà essenziali di un buon documento SRS sono le seguenti:
Conciso: Il rapporto SRS dovrebbe essere conciso e allo stesso tempo inequivocabile, coerente e completo. Descrizioni dettagliate e irrilevanti riducono la leggibilità e aumentano anche le possibilità di errore.
Strutturato: Dovrebbe essere ben strutturato. Un documento ben strutturato è semplice da comprendere e modificare. In pratica, il documento SRS subisce diverse revisioni per far fronte alle esigenze degli utenti. Spesso i requisiti degli utenti si evolvono nel corso del tempo. Pertanto, per facilitare le modifiche al documento SRS, è fondamentale rendere il rapporto ben strutturato.
Visualizzazione scatola nera: Dovrebbe solo definire cosa dovrebbe fare il sistema e astenersi dal dichiarare come farlo. Ciò significa che il documento SRS dovrebbe definire il comportamento esterno del sistema e non discutere le questioni di implementazione. Il rapporto SRS dovrebbe considerare il sistema da sviluppare come una scatola nera e dovrebbe definire il comportamento visibile esternamente del sistema. Per questo motivo il rapporto SRS è noto anche come specifica della scatola nera di un sistema.
Integrità concettuale: Dovrebbe mostrare integrità concettuale in modo che il lettore possa semplicemente capirlo. Risposta a eventi indesiderati: dovrebbe caratterizzare le risposte accettabili a eventi indesiderati. Queste sono chiamate risposte del sistema a condizioni eccezionali.
javafx
Verificabile: Tutti i requisiti del sistema, come documentato nel documento SRS, dovrebbero essere corretti. Ciò significa che dovrebbe essere possibile decidere se i requisiti sono stati soddisfatti o meno in un'implementazione.