<Nome del progetto>
Specifiche supplementari
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 (stile=Body Text).]
Cronologia revisione
Data |
Versione |
Descrizione |
Autore |
<gg/mmm/aa> |
<x.x> |
<dettagli> |
<nome> |
|
|
|
|
|
|
|
|
|
|
|
|
Indice
1.3 Definizioni, acronimi e abbreviazioni
2.1 <Requisito funzionale uno>
3.1 <Requisito di utilizzabilità uno>
4.1 <Requisito di affidabilità uno>
5.1 <Requisito di prestazione uno>
6.1 <Requisito di supportabilità>
7.1 <Vincolo di progettazione uno>
8. Considerazioni aggiuntive di progettazione di sistemi
8.3 Requisiti di assicurazione di altri prodotti
8.4 Requisiti attinenti alle persone
9. Requisiti di guida di sistema e di documentazione online dell'utente
11.4 Interfacce di comunicazioni
13. Note legali, di copyright e altre
Specifiche supplementari
[L'introduzione delle Specifiche supplementari dovrebbe fornire una panoramica dell'intero documento e includere obbiettivo, ambito, acronimi, abbreviazioni, referenze e panoramica di queste Specifiche supplementari.
Le Specifiche supplementari catturano i requisiti del sistema non catturati prontamente nei casi d'uso del modello di caso d'uso. Tali requisiti includono:
· Requisiti legali e contrattuali, compresi gli standard di applicazione.
· Attributi di qualità del sistema da creare, incluso i requisiti di utilizzabilità, affidabilità, prestazioni e supportabilità.
· Altri requisiti come i sistemi operativi e gli ambienti, requisiti di compatibilità e vincoli progettuali.]
[Definire lo scopo di queste Specifiche supplementari.]
[Breve descrizione dell'ambito di queste Specifiche supplementari, dei progetti con i quali è associato 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 le Specifiche supplementari. Tali informazioni possono essere fornite mediante riferimento al Glossario del progetto.]
[Questa sezione secondaria fornisce un elenco completo di tutti i documenti citati nelle Specifiche supplementari. 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 delle Specifiche supplementari e spiega come è organizzato il documento.]
[Questa sezione descrive ogni requisito funzionale aggiuntivo del sistema espresso in linguaggio naturale.]
[Descrizione del requisito.]
[Questa sezione include tutti quei requisiti che influenzano l'utilizzabilità. Ad esempio:
· specificare il tempo di addestramento richiesto per utenti normali e utenti molto esperti per diventare produttivi durante particolari operazioni
· specificare i tempi di compito misurabili per compiti specifici, o
· specificare i requisiti conformi ai comuni standard di utilizzo, ad esempio gli standard CUA IBM o gli standard GUI Microsof]
Descrizione del requisito.
[I requisiti relativi all'affidabilità del sistema devono essere specificati qui. I suggerimenti sono i seguenti:
· Disponibilità ? specificare la percentuale di tempo disponibile ( xx.xx%), le ore di utilizzo, l'accesso alla manutenzione, le operazioni carenti della modalità e così via.
· Mean Time Between Failures (MTBF) ? questa funzione viene di solito specificata in ore, ma può essere anche specificata in termini di giorni, mesi o anni.
· Mean Time To Repair (MTTR) ? per quanto tempo è consentito al sistema di restare inattivo dopo un'interruzione.
· Esattezza ? specificare la precisione (risoluzione) ed accuratezza (mediante qualche standard conosciuto) richieste negli output dei sistemi.
· Numero massimo di errori o incidenza di difetti ? di solito espresso in termini di errori/KLOC (migliaia di righe di codice) oppure errori/punto funzione.
· Incidenza di errori o difetti ? classificato in termini di errori meno gravi, significativi e critici: i requisiti devono definire il significato di un errore ?critico? (ad esempio, perdita totale di dati o completa incapacità di utilizzare determinate parti della funzionalità del sistema).]
[Descrizione del requisito.]
[Le caratteristiche di prestazione del sistema dovrebbero essere indicate in questa sezione. Includere i tempi di risposta specifici. Laddove possibile, fare riferimento al caso d'uso mediante nome. In generale, tutte le capacità richieste, descritte nella forma di caso d'uso o semplicemente dal testo, devono essere associate ad alcune dichiarazioni di prestazione (che descrivono come 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.
· Tempo di risposta per una transazione (medio, massimo)
· Produttività (ad esempio, transazioni per secondo)
· Capacità (ad esempio, il numero di clienti o di transazioni che il sistema può accogliere)
· Modalità di riduzione (qual è la modalità di funzionamento accettabile quando il sistema ha un calo di prestazioni)
· Utilizzo di risorse: memoria, disco, comunicazioni ecc.]
[Descrizione del requisito.]
[Questa sezione indica i requisiti che potenzieranno la supportabilità o la manutenibilità del sistema in fase di costruzione, compresi standard di codifica, convenzioni sui nomi, librerie di classe, accesso alla manutenzione, utilità di manutenzione.]
[Descrizione del requisito.]
[Questa sezione indica tutti i vincoli progettuali sul sistema in 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, l'utilizzo prescritto di tool di sviluppo, vincoli di progettazione, componenti acquistati, librerie di classe ecc.]
[Descrizione del requisito.]
[La progettazione di sistemi richiede potenzialmente altri tipi di requisiti da soddisfare]:
[Ad esempio peso, misura, potenza...]
[Ad esempio fattori di umidità, contaminanti, termici, elettrici, meccanici...]
[Ad esempio incolumità, sicurezza o altri fattori di qualità (ad esempio possibilità di sopravvivenza).]
[Descrivere i requisiti imposti al sistema in supporto alle persone che lo utilizzeranno e sosterranno: 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 riguardo alle informazioni legali ecc.]
[Questa sezione descrive i componenti acquistati 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, dovrebbe 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 dovrebbero 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, incluso le strutture logiche, indirizzi fisici, comportamenti previsti ecc.]
[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 LAN ecc.]
[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 a tali standard che si applicano al sistema in fase di descrizione. Ad esempio, ciò può includere standard legali, di qualità e regolatori, standard industriali per l'utilizzabilità, l'interoperabilità, l'internazionalizzazione, la conformità del sistema operativo e così via.]