<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.       Introduzione         

1.1     Scopo     

1.2     Ambito     

1.3     Definizioni, acronimi e abbreviazioni     

1.4     Riferimenti     

1.5     Panoramica     

2.       Funzionalità     

2.1     <Requisito funzionale uno>     

3.       Utilizzabilità

3.1     <Requisito di utilizzabilità uno>     

4.       Affidabilità

4.1     <Requisito di affidabilità uno>     

5.       Prestazione       

5.1     <Requisito di prestazione uno>     

6.       Supportabilità    

6.1     <Requisito di supportabilità>     

7.       Vincoli di progettazione   

7.1     <Vincolo di progettazione uno>     

8.        Considerazioni aggiuntive di progettazione di sistemi               

8.1     Requisiti fisici     

8.2     Requisiti ambientali     

8.3     Requisiti di assicurazione di altri prodotti     

8..3.x   <Categoria> 

8.4     Requisiti attinenti alle persone 

8.5     Requisiti logistici  

9.       Requisiti di guida di sistema e di documentazione online dell'utente

10.       Componenti acquistati 

11.            Interfacce               

11.1     Interfacce utente     

11.2     Interfacce hardware     

11.3     Interfacce software     

11.4     Interfacce di comunicazioni     

12.            Requisiti di licenza               

13.            Note legali, di copyright e altre               

14.            Standard applicabili               


Specifiche supplementari

1.                  Introduzione

[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.]

1.1               Scopo

[Definire lo scopo di queste Specifiche supplementari.]

1.2               Ambito

[Breve descrizione dell'ambito di queste Specifiche supplementari, dei progetti con i quali è associato e di qualunque cosa sia influenzata da questo documento.]

1.3               Definizioni, acronimi e abbreviazioni

[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.]

1.4               Riferimenti

[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.]

1.5               Panoramica

[Questa sezione secondaria descrive ciò che contiene il resto delle Specifiche supplementari e spiega come è organizzato il documento.]

2.                  Funzionalità

[Questa sezione descrive ogni requisito funzionale aggiuntivo del sistema espresso in linguaggio naturale.]

2.1               <Requisito funzionale uno>

[Descrizione del requisito.]

3.                  Utilizzabilità

[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]

3.1               <Requisito di utilizzabilità uno>

Descrizione del requisito.

4.                  Affidabilità

[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).]

4.1               <Requisito di affidabilità uno>

[Descrizione del requisito.]

5.                  Prestazione

[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.]

5.1               <Requisito di prestazione uno>

[Descrizione del requisito.]

6.                  Supportabilità

[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.]

6.1               <Requisito di supportabilità>

[Descrizione del requisito.]

7.                  Vincoli di progettazione

[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.]

7.1               <Vincolo di progettazione uno>

[Descrizione del requisito.]

8.        Considerazioni aggiuntive di progettazione di sistemi

[La progettazione di sistemi richiede potenzialmente altri tipi di requisiti da soddisfare]:

8.1      Requisiti fisici

[Ad esempio peso, misura, potenza...]

8.2      Requisiti ambientali

[Ad esempio fattori di umidità, contaminanti, termici, elettrici, meccanici...]

8.3      Requisiti di assicurazione di altri prodotti

8.3.x     <Categoria>

[Ad esempio incolumità, sicurezza o altri fattori di qualità (ad esempio possibilità di sopravvivenza).]

8.4      Requisiti attinenti alle persone

[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.]

8.5      Requisiti logistici

[Descrivere i requisiti imposti al sistema per via di considerazioni logistiche - inclusi manutenzione, supporto, trasporto, fornitura e installazione dei sistemi attuali.]

9.                  Requisiti di guida di sistema e di documentazione online dell'utente

[Descrive i requisiti, se presenti, relativi alla documentazione online dell'utente, i sistemi guida, la guida riguardo alle informazioni legali ecc.]

10.              Componenti acquistati

[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.]

11.             Interfacce

[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.]

11.1            Interfacce utente

[Descrivere le interfacce utente che devono essere implementate dal sistema.]

11.2            Interfacce hardware

[Questa sezione definisce tutte le interfacce hardware che devono essere supportate dal sistema, incluso le strutture logiche, indirizzi fisici, comportamenti previsti ecc.]

11.3            Interfacce software

[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.]

11.4            Interfacce di comunicazioni

[Descrivere le interfacce di comunicazione ad altri sistemi o periferiche come LAN ecc.]

12.             Requisiti di licenza

[Definisce tutti i requisiti di applicazione della licenza o altri requisiti di limitazione dell'utilizzo che devono essere presentati dal sistema.]

13.             Note legali, di copyright e altre

[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.]

14.             Standard applicabili

[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.]