<Nome del progetto>
Specifiche dei requisiti di sistema
Versione <1.0>
[Nota: il seguente modello è fornito per l'utilizzo con RUP (Rational Unified Process). Il testo racchiuso in parentesi quadre e visualizzato in blue italics (stile=InfoBlue) è inserito per fornire una guida all'autore e dovrebbe essere cancellato prima di pubblicare il documento. Un paragrafo digitato seguendo questo stile sarà automaticamente riportato all'impostazione normale (style=Body Text).]
Cronologia revisione
Data |
Versione |
Descrizione |
Autore |
<gg/mmm/aa> |
<x.x> |
<dettagli> |
<nome> |
|
|
|
|
|
|
|
|
|
|
|
|
Indice
1.3 Definizioni, acronimi e abbreviazioni
3.2.5 Vincoli di progettazione
3.2.6 Considerazioni aggiuntive sulla progettazione di sistema
3.2.6.3 Requisiti di assicurazione di altri prodotti
3.2.6.4 Requisiti attinenti alla sfera umana
3.2.7 Requisiti di documentazione online dell'utente e di guida di sistema
3.2.9.4 Interfacce di comunicazione
3.2.11 Note legali, di copyright e altre
Specifiche dei requisiti di sistema
[L'introduzione del SysRS (System Requirements Specification) fornisce una panoramica dell'intero SysRS. Include obiettivo, ambito, definizioni, acronimi, abbreviazioni, riferimenti e panoramica di SysRS.]
[Nota: SysRS cattura tutti i requisiti del sistema o di una porzione. Quella che segue è una struttura tipica di SysRS per un progetto che utilizza soltanto i requisiti di stile del linguaggio naturale tradizionale - senza modellazione del caso d'uso. Cattura tutti i requisiti in un unico documento, insieme alle Specifiche supplementari combinate o ai materiali equivalenti inseriti.]
[Specificare lo scopo di questo SysRS. SysRS descrive in modo completo le capacità funzionali e comportamentali del sistema identificato. Descrive inoltre i requisiti non funzionali, i vincoli di progettazione e altri fattori necessari a fornire una descrizione completa ed esaustiva dei requisiti relativi al sistema.]
[Breve descrizione del sistema cui viene applicato SysRS e di qualunque cosa sia influenzata da questo documento.]
[Questa sezione secondaria fornisce le definizioni di tutti i termini, gli acronimi e le abbreviazioni necessarie per interpretare correttamente SysRS. Tali informazioni possono essere fornite mediante riferimento al Glossario del progetto.]
[Questa sezione secondaria fornisce un elenco completo di tutti i documenti citati in SysRS. Ogni documento deve essere identificato per titolo, numero di report (dove applicabile), data e organizzazione di pubblicazione. Specificare le fonti da cui è possibile ottenere i riferimenti. Tali informazioni possono essere fornite mediante riferimento all'appendice o a un altro documento.]
[Questa sezione secondaria descrive ciò che contiene il resto di SysRS e spiega come è organizzato il documento.]
[Questa sezione di SysRS descrive i fattori generali che influenzano il sistema e i relativi requisiti. Questa sezione non include requisiti specifici. Al contrario, fornisce un background per quei requisiti definiti nel dettaglio alla Sezione 3 e li rende di facile comprensione. Includere problematiche quali:
Si può effettuare un riferimento da questa sezione all'artefatto di Visione, piuttosto che fare una copia del materiale da questo documento.]
[Se si sta utilizzando la modellazione del caso d'uso, questa sezione contiene una panoramica del modello di caso d'uso. Include un elenco di nomi e una breve descrizione di tutti i casi d'uso e degli attori, insieme a diagrammi e relazioni applicabili. Fare riferimento al Report di valutazione del modello Caso d'uso, che può essere utilizzato come una chiusura a questo punto.]
[Questa sezione descrive la fattibilità tecnica fondamentale, la disponibilità di sottosistemi e componenti o altri presupposti correlati al progetto sui quali deve basarsi l'applicabilità del sistema descritto da SysRS.]
[Questa sezione di SysRS contiene tutti i requisiti del sistema con un livello di dettaglio tale da consentire ai progettisti di creare un sistema che soddisfi tali requisiti e ai tester di verificare che il sistema sia poi effettivamente in grado di soddisfarli.
Quando si utilizza una modellazione di caso d'uso, tali requisiti vengono catturati nei casi d'uso e nelle specifiche supplementari applicabili (o come un artefatto vero e proprio o secondo quanto indicato dalle sezioni "3.2 Requisiti non funzionali," all'interno di questo documento).]
[Questa sezione descrive le capacità del sistema richieste, espresse come casi d'uso. Per molti sistemi, ciò potrebbe costituire il volume del pacchetto SysRS ed è necessario pensare all'organizzazione di questa sezione in base a caratteristiche, funzioni o gruppo funzionale (che generalmente caratterizzano una "capacità" - tracciabile dall'artefatto Visione). Possono essere ugualmente appropriati metodi alternativi come l'organizzazione per utente o ruolo.]
[Nella modellazione del caso d'uso, i casi d'uso definiscono la maggior parte dei requisiti funzionali del sistema, insieme ad alcuni non funzionali (correlati alla prestazione). Per ogni caso d'uso del modello Caso d'uso precedente, fare riferimento o includere il report di caso d'uso in questa sezione. Assicurarsi che ogni requisito sia classificato in modo chiaro. Raggruppare, quando appropriato, i casi d'uso per capacità - se necessario perfezionata in modo funzionale - così da raggiungere il giusto livello di descrizione funzionale e comportamentale.]
[Questa sezione descrive i requisiti funzionali aggiuntivi del sistema (non catturati come casi d'uso), espressi in linguaggio naturale.]
[Descrizione del requisito.]
[Nota: se è stato prodotto l'artefatto delle Specifiche supplementari, deve essere incluso qui. Riguarda gli stessi argomenti.]
[Questa sezione include tutti quei requisiti che influenzano l'utilizzabilità. Ad esempio:
[Descrizione del requisito.]
[Specificare qui i requisiti per l'affidabilità del sistema. I suggerimenti sono i seguenti:
[Descrizione del requisito.]
[In questa sezione, delineare le caratteristiche di prestazione del sistema. Includere i tempi di risposta specifici. Laddove possibile, fare riferimento al caso d'uso mediante nome. In generale, associare tutte le capacità richieste, descritte nella forma di caso d'uso o semplicemente dal testo, ad alcune dichiarazioni di prestazione (che descrivono il modo in cui il sistema dovrebbe fornire la capacità o la funzione). È preferibile mantenere queste dichiarazioni di prestazione in prossimità della capacità influenzata (ad esempio nella parte "requisiti speciali" della descrizione di caso d'uso). Qui è possibile mantenere le dichiarazioni di requisiti che devono essere testate, ma che non sono allineate con capacità specifiche. Le caratteristiche di prestazione includono:
[Descrizione del requisito.]
[Questa sezione indica i requisiti che potenziano la supportabilità o la manutenibilità del sistema in fase di costruzione, inclusi standard di codifica, convenzioni sui nomi, librerie di classe, accesso e programmi di utilità della manutenzione.]
[Descrizione del requisito.]
[Questa sezione indica tutti i vincoli progettuali sul sistema in fase di costruzione. I vincoli di progettazione rappresentano delle decisioni strutturali che sono state imposte e a cui è necessario aderire. Gli esempi includono linguaggi software, requisiti di processo software, utilizzo prescritto di tool di sviluppo, vincoli strutturali e progettuali, componenti acquisiti, librerie di classe e così via.]
[Descrizione del requisito.]
[La progettazione dei sistemi richiede potenzialmente altri tipi di requisiti da soddisfare.]
[Ad esempio: peso, misura, potenza e così via.]
[Ad esempio: fattori di umidità, contaminanti, termici, elettrici, meccanici e così via.]
[Ad esempio: incolumità, sicurezza o altri fattori di qualità (come la possibilità di sopravvivenza).]
[Descrivere i requisiti imposti al sistema per facilitarne l'utilizzo da parte degli utenti. Gli esempi includono capacità di formazione - materiali e attrezzatura da inserire per la formazione - capacità di manutenzione, considerazioni ergonomiche non coperte da descrizioni e standard di interfaccia.]
[Descrivere i requisiti imposti al sistema per via di considerazioni logistiche, inclusi manutenzione, supporto, trasporto, fornitura e installazione dei sistemi attuali.]
[Descrive i requisiti, se presenti, relativi alla documentazione online dell'utente, i sistemi guida, la guida per le informazioni legali e così via.]
[Questa sezione descrive i componenti acquisiti da utilizzare con il sistema, le licenze applicabili e i vincoli di utilizzo ed ogni compatibilità/interoperabilità associata o standard di interfaccia.]
[Questa sezione definisce le interfacce che devono essere supportate dal sistema e deve contenere specificità, protocolli, porte e indirizzi logici adeguati affinché il sistema possa essere sviluppato e verificato con i requisiti di interfaccia. Anche i requisiti da imporre alle interfacce interne al sistema devono essere descritti. Scaturiscono ad esempio quando il progetto di sistema è vincolato all'utilizzo interno di componenti hardware o software esistenti.]
[Descrivere le interfacce utente che devono essere implementate dal sistema.]
[Questa sezione definisce tutte le interfacce hardware che devono essere supportate dal sistema, incluse strutture logiche, indirizzi fisici, comportamenti previsti e così via.]
[Questa sezione definisce le interfacce software che devono essere supportate dal sistema in termini di operazioni e segnali supportati (e per cui è richiesto il supporto), protocolli e caratteristiche di dati.]
[Descrivere le interfacce di comunicazione ad altri sistemi o periferiche come reti LAN e così via.]
[Definisce tutti i requisiti di applicazione della licenza o altri requisiti di limitazione dell'utilizzo che devono essere presentati dal sistema.]
[Questa sezione descrive tutte le problematiche di conformità delle dichiarazioni di non responsabilità legali, garanzie, avvisi di copyright, brevetti, marchi e loghi relative al sistema.]
[Questa sezione descrive mediante riferimento tutti gli standard utilizzabili e le sezioni specifiche che si applicano al sistema in fase di descrizione. Ad esempio, ciò può includere standard legali, qualitativi e regolatori, standard industriali per l'utilizzabilità, l'interoperabilità, l'internazionalizzazione, la conformità del sistema operativo e così via.]
[Le informazioni di supporto rendono di facile utilizzo SysRS. Includono:
Queste ultime possono includere informazioni riguardo i prototipi strutturali e le interfacce utente. Quando sono presenti le appendici, SysRS deve dire in modo esplicito se devono essere considerate parte dei requisiti o no.]