<Nome del progetto>

Vista

 

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     Referenze      

1.5     Panoramica      

2.       Posizionamento          

2.1     Opportunità economiche      

2.1.1     Posizione attuale 

2.1.2     Giustificazioni delle modifiche

2.2     Definizione del problema      

2.3     Definizione della posizione del prodotto     

3.       Descrizioni di stakeholder e utente  

3.1     Demografia di mercato     

3.2     Riepilogo dello stakeholder     

3.3     Riepilogo dell'utente     

3.4     Ambiente dell'utente     

3.5     Profili dello stakeholder     

3.5.1     <Nome dello stakeholder>           

3.6     Profili dell'utente     

3.6.1     <Nome dell'utente>           

3.7     Esigenze principali dello stakeholder o dell'utente     

3.8     Alternative e competizione     

3.8.1     <Un concorrente>           

3.8.2     <Un altro concorrente>           

3.9      Alternative di sviluppo considerate

4.       Panoramica del prodotto      

4.1     Prospettiva del prodotto     

4.2     Riepilogo delle capacità     

4.3     Presupposti e dipendenze     

4.4     Costo e prezzo     

4.5     Licenza e installazione     

5.       Funzioni del prodotto         

5.1     Funzioni     

5.1.1       <Una funzione>

5.1.2       <Un'altra funzione>

5.2     Scenari operativi

5.3       Fornitura di supporto    

6.       Vincoli         

7.       Intervalli di qualità

8.       Precedenza e priorità

9.       Requisiti di altri prodotti

9.1     Standard applicabili     

9.2     Requisiti di sistema     

9.3     Requisiti di prestazione     

9.4     Requisiti ambientali   

9.5       Requisiti fisici  

10.            Requisiti di documentazione               

10.1     Manuale dell'utente     

10.2     Guida online     

10.3     Guide di installazione, configurazione e file Read Me     

10.4     Etichettatura e imballaggio     

A.                Attributi di funzioni               

   


Vista

1.                   Introduzione

[Lo scopo di questo documento è raccogliere, analizzare e definire le esigenze e le funzioni ad alto livello del <<Nome del sistema>>. Si concentra sulle capacità necessarie agli stakeholder e agli utenti di destinazione e sul perché vi sono queste esigenze. I dettagli di come il <<Nome del sistema>> adempie a questi bisogni sono precisati nelle specifiche supplementari e di caso d'uso.Nota: questo modello di Visione tenta di coprire tutti i tipi di sviluppo, dai prodotti confezionati, sviluppati in modo speculativo per un'esigenza di mercato percepita, ai sistemi one-off, sviluppati sotto contratto, ad una richiesta specifica del cliente. Di conseguenza, le parole "prodotto" e "sistema" possono essere utilizzate senza differenziazione, col significato di "cosa da sviluppare". Ci si aspetta che la personalizzazione dia un'applicazione specifica.]

 [L'introduzione del documento Visione fornisce una panoramica dell'intero documento e includere obbiettivo, ambito, acronimi, abbreviazioni, referenze e panoramica di questo documento Visione.]

1.1               Scopo

[Specificazione dello scopo di questo documento Visione.]

1.2               Ambito

[Breve descrizione dell'ambito di questo documento Visione, 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 il documento Visione. 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 nel documento Visione. Identificare ogni documento 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 un altro documento.]

1.5               Panoramica

[Questa sezione secondaria descrive ciò che contiene il resto del documento Visione e spiega come è organizzato il documento.]

2.                  Posizione

2.1               Opportunità economiche

[Descrivere brevemente le opportunità economiche da soddisfare con questo progetto.]

2.1.1     Posizione attuale

[In questa sezione secondaria descrivere il background, lo scopo e l'ambito del sistema attuale o delle circostanze economiche, comprese, se possibile, le politiche applicate, le capacità dell'attuale sistema, gli stakeholder coinvolti e le questioni di supporto.]

2.1.2     Giustificazioni delle modifiche

[In questa sezione secondaria descrivere le nuove circostanze o le esigenze che sono derivate, in senso operativo o economico, che giustificano una modifica. Identificare brevemente le modifiche proposte e rifiutate e il fondamento logico associato. Se sono state svolte delle analisi di commercio (su esigenze di modifica) devono essere riportate.]

2.2               Constatazione di problemi

[Fornire una constatazione che riassume il problema da risolvere in questo progetto. Possono essere utilizzati i seguenti formati:]

Il problema di

[descrivere il problema]

influenza

[indicare gli stakeholder influenzati dal problema]

il cui impatto è

[descrivere l'impatto del problema]

una soluzione valida potrebbe essere

[elencare alcuni vantaggi chiave di una soluzione ottimale]

2.3               Constatazione della posizione del prodotto

[Fornire una constatazione generale che riassuma, al livello più alto, la posizione unica che il prodotto intende occupare nel mercato. Possono essere utilizzati i seguenti formati:]

Per

[cliente di destinazione]

Cosa

[definizione dell'esigenza o dell'opportunità]

(Nome del prodotto)

[categoria di prodotto]

Vantaggi

[definizione dei benefici chiave ovvero il motivo determinante l'acquisto]

A differenza di

[alternativa concorrente diretta]

Il prodotto

[constatazione della differenziazione primaria]

[Una constatazione della posizione di un prodotto o di un sistema comunica l'intenzione del sistema e l'importanza del progetto a tutto il personale attinente.]

3.                  Descrizioni dello stakeholder e dell'utente

[Per fornire con efficienza i prodotti e i servizi che soddisfino le esigenze reali degli stakeholder e degli utenti, è necessario coinvolgere tutti gli stakeholder come parte del processo di modellazione dei requisiti. È anche necessario identificare tutti gli utenti del sistema e assicurarsi che la comunità di stakeholder li rappresenti in modo adeguato. Questa sezione fornisce un profilo degli stakeholder e degli utenti coinvolti nel progetto e i problemi principali che questi ritengono debbano essere risolti dalle soluzioni proposte. Non descrivere richieste o requisiti specifici che non siano catturati in un artefatto di richeiste degli stakeholder separato. Fornisce invece il background e la giustificazione del perché questi requisiti sono necessari.]

3.1               Demografia di mercato

[Riassumere la demografia di mercato principale che motiva le decisioni del prodotto. Descrivere e posizionare i segmenti target di mercato. Fare una stima della misura e della crescita del mercato utilizzando numerosi potenziali utenti o del denaro speso dai clienti nel cercare di soddisfare i bisogni che il prodotto o il potenziamento potrebbero adempiere. Revisionare le maggiori tecnologie e tendenze industriali. Rispondere alle seguenti domande strategiche:

?          Qual è la reputazione della propria organizzazione in questi mercati?

?          Come dovrebbe essere?

?          Come questo prodotto o servizio supporta gli obiettivi?

3.2               Riepilogo dello stakeholder

[Molti stakeholder hanno un interesse per lo sviluppo e non tutti sono utenti. Presentare un elenco di riepilogo di questi stakeholder non utenti. (Gli utenti sono riassunti in questa sezione3.3.)]

Nome

Descrizione

Responsabilità

[Stabilire il tipo di stakeholder.]

[Descrivere brevemente lo stakeholder.]

[Fare un riepilogo delle responsabilità principali dello stakeholder rispetto al sistema da sviluppare, ovvero l'interesse come stakeholder. Ad esempio, questo stakeholder:

- assicura che il sistema sarà gestibile

- assicura che ci sarà una richiesta di mercato per le funzioni del prodotto

- fa un monitoraggio del progresso del processo

- approva il finanziamento.]

3.3               Riepilogo dell'utente

[Presentare un elenco di riepilogo di tutti gli utenti identificati.]

Nome

Descrizione

Responsabilità

Stakeholder

[Stabilire il tipo di utente.]

[Descrivere brevemente cosa rappresentano gli utenti per il sistema.]

[Fare un elenco delle responsabilità principali dell'utente rispetto al sistema da sviluppare, ad esempio

- cattura dettagli

- produce report

- coordina il lavoro

[Se l'utente non è direttamente rappresentato, identificare quale stakeholder è responsabile della rappresentazione degli interessi dell'utente.]

 

3.4               Ambiente dell'utente

[Descrivere nel dettaglio l'ambiente di lavoro dell'utente di destinazione. Ecco alcuni suggerimenti:

In questo punto possono essere inclusi estratti dal modello economico per delineare il compito, i lavoratori coinvolti ecc.]

3.5               Profili dello stakeholder 

[Descrivere ciascuno stakeholder nel sistema compilando la seguente tabella per ogni stakeholder. Ricordarsi che i tipi di stakeholder possono essere divergenti come gli utenti, i dipartimenti e gli sviluppatori tecnici. Un profilo completo riguarderebbe le seguenti sezioni per ogni tipo di stakeholder.]

3.5.1          <Nome dello stakeholder>

Rappresentante

[Chi è lo stakeholder rappresentante del progetto?  (Facoltativo se descritto altrove.)  Qui sono richiesti nomi.]

Descrizione

[Breve descrizione del tipo di stakeholder.]

Tipo

[Qualificare la competenza dello stakeholder, background tecnico e grado di sofisticatezza, cioè ideatore, professionista, esperto, utente occasionale ecc.]

Responsabilità

[Fare un elenco delle responsabilità principali dello stakeholder rispetto al sistema da sviluppare, cioè l'interesse come stakeholder.]

Criteri di successo

[Come definisce il successo lo stakeholder?

Come viene ricompensato lo stakeholder?]

Coinvolgimento

[Come viene coinvolto nel progetto lo stakeholder? Dove possibile, correlarsi con i ruoli di RUP? ovvero Revisore dei requisiti ecc.]

Componenti distribuibili

[Vi sono dei componenti distribuibili aggiuntivi richiesti dallo stakeholder? Questi potrebbero essere componenti distribuibili del progetto o output dal sistema in sviluppo.]

Commenti / questioni

[Inserire qui i problemi che interferiscono con il successo ed ogni altra informazione rilevante.]

 

3.6               Profili dell'utente 

[Descrivere ciascuno utente unico del sistema compilando la seguente tabella per ogni tipo d'utente. Ricordarsi che i tipi d'utente possono essere divergenti come i maestri e i principianti. Ad esempio, un ideatore potrebbe richiedere un tool flessibile e sofisticato con un supporto a piattaforma incrociata, mentre un principiante potrebbe aver bisogno di uno strumento semplice da utilizzare e adatto per l'utente. Un profilo completo riguarderebbe le seguenti sezioni per ogni tipo di utente.]

3.6.1          <Nome dell'utente>

Rappresentante

[Chi è l'utente rappresentante del progetto?  (Facoltativo  se descritto altrove.)  Spesso si riferisce allo stakeholder che rappresenta il gruppo di utenti, ad esempio, Stakeholder: Stakeholder1.]

Descrizione

[Breve descrizione del tipo d'utente.]

Tipo

[Qualificare la competenza dell'utente, il background tecnico e il grado di sofisticatezza, cioè ideatore, utente occasionale ecc.]

Responsabilità

[Fare un elenco delle responsabilità principali dell'utente rispetto al sistema da sviluppare, ad esempio catturare dettagli, produrre report, coordinare il lavoro ecc.]

Criteri di successo

[Come definisce il successo l'utente?

Come viene ricompensato l'utente?]

Coinvolgimento

[Come viene coinvolto nel progetto l'utente? Dove possibile, correlarsi con i ruoli di RUP?cioè Revisore dei requisiti e simili.]

Componenti distribuibili

[Vi sono componenti distribuibili che l'utente produce e, se si, per chi?]

Commenti / questioni

[I problemi che interferiscono con il successo ed ogni altra informazione rilevante vanno inseriti qui. Ciò comprende le tendenze che rendono il lavoro dell'utente più semplice o più difficile.]

 

3.7               Esigenze principali dello stakeholder o dell'utente

[Elencare i problemi principali e le soluzioni esistenti come percepite dallo stakeholder. Chiarire le seguenti questioni per ogni problema:

?          Quali sono i motivi di questo problema?

?          Come dovrebbe essere risolto?

?          Quali soluzioni preferiscono lo stakeholder o l'utente?]

[È importante capire l'importanza relativa che lo stakeholder o l'utente danno alla risoluzione di ogni problema. Le tecniche di elezione cumulative e di classificazione indicano i problemi che devono essere risolti contro le questioni che si vorrebbero affrontare.

Compilare la seguente tabella. Quando si utilizza Rational RequisitePro per catturare i bisogni, ciò potrebbe essere un estratto o un report di quel tool.]

Esigenze

Priorità

Problematiche

Soluzione attuale

Soluzioni proposte

Messaggi di diffusione

 

 

 

 

 

3.8               Alternative e competizione

[Identificare le alternative che lo stakeholder percepisce come disponibili. Ciò può includere l'acquisto del prodotto di un concorrente, creare una soluzione interna o semplicemente mantenere lo status quo. Elencare ogni scelta competitiva conosciuta che esiste o che può diventare disponibile. Includere le maggiori debolezze e forze di ogni concorrente come vengono percepite dallo stakeholder o dall'utente.]

3.8.1          <Un concorrente>

3.8.2          <Un altro concorrente>

3.9       Alternative di sviluppo considerate

[In questa sezione secondaria, descrivere ogni alternativa al prodotto proposto che era stata considerata e ogni studio di mercato associato.]

4.                  Panoramica del prodotto

[Questa sezione fornisce una vista ad alto livello delle capacità del prodotto, delle interfacce con altri sistemi e delle configurazione di sistemi.] 

4.1               Prospettive di prodotto

[Questa sezione secondaria del documento Visione mette il prodotto in prospettiva con altri prodotti correlati e con l'ambiente dell'utente. Se il prodotto è indipendente e totalmente auto contenuto, lo stato viene inserito qui. Se il prodotto è un componente di un sistema più ampio, questa sezione riporta come questi sistemi interagiscono e identifica le interfacce rilevanti tra i sistemi. Un modo semplice per visualizzare i componenti maggiori del sistema più ampio, le interconnessioni e le interfacce esterne è utilizzare un diagramma a blocchi. 

Identificare gli impatti operativi, organizzativi e di sviluppo sugli stakeholders e sugli altri sistemi.]

4.2               Riepilogo delle capacità

[Fare un riepilogo dei maggiori benefici e funzioni che il prodotto fornirà. Ad esempio, un documento Visione relativo al sistema di supporto al cliente può utilizzare questa parte per risolvere problemi di documentazione, di instradamento e report dello stato senza menzionare la quantità di dettagli richiesto da ciascuna di queste funzioni.

Organizzare le funzioni per rendere l'elenco comprensibile al cliente o a chiunque legga il documento per la prima volta. Potrebbe essere sufficiente una semplice tabella che elenca i benefici principali e relative funzioni. Ad esempio:]

Tabella 4-1   Sistema di supporto al cliente

Beneficio del cliente

Funzioni di supporto

Un nuovo staff di supporto può aumentare la velocità rapidamente.

Una conoscenza di base aiuta il personale di supporto nell'identificare velocemente le correzioni e le soluzioni conosciute.

La soddisfazione del cliente migliora poiché non si verificano imprevisti sfavorevoli.

I problemi vengono specificati, classificati e tracciati attraverso il processo di risoluzione. Per ogni questione dell'epoca avviene una notifica automatica.

La gestione può identificare le aree di problemi e il calibro del carico di lavoro del personale.

I report di tendenza e di distribuzione consentono una revisione ad alto livello dello stato del problema.

I team di supporto distribuiti possono lavorare insieme per risolvere i problemi.

Il server di replica consente di condividere con l'impresa le informazioni sull'attuale database.

I clienti possono essere autosufficienti, diminuendo i costi di supporto e migliorando il tempo di risposta.

Una conoscenza di base può essere resa disponibile in Internet. Include capacità di ricerca ipertestuale e motore grafico di query.

4.3               Supposizioni e dipendenze

[Elencare ogni fattore che influenza le funzioni esposte nel documento Visione. Elencare le supposizioni che, se modificate, potrebbero alterare il documento Visione. Ad esempio, la Visione è costruita nel contesto di un'impresa più ampia e se qualcosa cambia in quel contesto la Visione potrebbe aver bisogno di cambiare. Ciò può comprendere, ad esempio, fattori economici, politici, legali o ambientali. La Visione può anche dipendere dalla disponibilità dell'attrezzatura, dai componenti software o di altri sistemi o dalla disponibilità di particolari capacità o skill.]

4.4               Costi e prezzi

[Per i prodotti venduti a clienti esterni e per altri sistemi in-house, le questioni attinenti al costo e al prezzo possono avere impatto diretto sull'implementazione e definizione del sistema. In questa sezione, registrare ogni vincolo rilevante di costo e prezzo. Ad esempio, costi di distribuzione (# di dischetti, # di CD-ROM, masterizzazione di CD) o altri costi di vincoli di beni venduti (manuali, imballaggio) possono essere di aiuto al successo del progetto o irrilevanti a seconda della natura del sistema.]

4.5               Licenza ed installazione

[Le questioni attinenti alla licenza e installazione possono anche avere un impatto diretto sullo sforzo di sviluppo. Ad esempio, l'esigenza di supportare i controlli d'accesso, la serializzazione, la sicurezza di password o la licenza di rete creerà ulteriori requisiti del sistema da considerare nello sforzo di sviluppo.

I requisiti d'installazione possono anche influire sulla costruzione del software o creare l'esigenza di un software d'installazione separato. I sistemi fisici possono imporre requisiti d'installazione speciali, se soggetti a particolari vincoli di sicurezza e di possibilità di sopravvivenza ad esempio.]

5.                  Funzioni del prodotto

[Elencare e descrivere brevemente le funzioni del prodotto. Per funzioni si intende le capacità primarie del sistema che apportano benefici agli utenti. Descrivere anche le caratteristiche di prestazione associate ad ogni singola funzione, evidenziando specifici vantaggi in relazione a diversi fattori, quali tempo, tempo di risposta o frequenza di transazione. Al termine "funzione" non è stato assegnato un significato specifico e gli si potrebbe preferire "capacità" o "caratteristica", per indicare qualcosa che il sistema o il prodotto deve essere in grado di fare. Ogni funzione è un servizio esterno desiderato che in genere richiede una serie di input per raggiungere il risultato voluto. Ad esempio, una funzione di un sistema di traccia del problema potrebbe essere l'abilità di fornire report di tendenza. Mentre il modello di caso d'uso prende forma, aggiornare la descrizione da riferire ai casi d'uso.

Poiché il documento Visione viene revisionato da un'ampia varietà di personale coinvolto, il livello di dettagli deve essere abbastanza generale per essere compreso da chiunque. Ad ogni modo, devono essere disponibili abbastanza dettagli per fornire al team le informazioni necessarie al fine di creare un modello di caso d'uso.

Per gestire in modo efficace la complessità, si raccomanda per ogni nuovo sistema, o per ogni incremento ad un sistema esistente, che le capacità siano astratte ad un livello tanto alto da far risultare 25-99 funzioni. Tali funzioni forniscono le basi fondamentali per la definizione del prodotto, la gestione dell'ambito e del progetto. Ogni funzione sarà ampliata in dettagli maggiori nel modello di caso d'uso o in linguaggio naturale, se il progetto decide di non produrre casi d'uso.

Nel corso di questa sezione, ogni funzione sarà percepibile esternamente dagli utenti, dagli operatori o da altri sistemi esterni. Tali funzioni dovrebbero includere una descrizione della funzionalità e ogni questione di utilizzabilità rilevante che deve essere risolta. Rispettare le seguenti linee guida:

?          Evitare la progettazione. Mantenere le descrizioni della funzione ad un livello generale. Focalizzarsi sulle capacità necessarie e sul perché (non sul come) debbano essere implementate.

?          Se si sta utilizzando il toolkit Rational RequisitePro, tutto deve essere selezionato come requisiti di tipo per un riferimento e una tracciabilità semplici.

5.1               Funzioni

5.1.1     <Una funzione>

5.1.2     <Un'altra funzione>

5.2               Scenari operativi

[Descrivere pochi utilizzi del prodotto o del sistema che illustrino alcune interazioni interessanti o importanti tra il sistema e gli utenti, l'ambiente e/o altri sistemi.]

5.3               Fornitura di supporto

[In questa sezione secondaria descrivere, in breve, come deve essere fornito il supporto, comprese le descrizioni dell'organizzazione di supporto, l'attrezzatura, i cicli di manutenzione e fornire accordi.]

6.                  Vincoli

[Annotare ogni vincolo esterno, di progettazione o altre dipendenze.]

7.                  Intervalli di qualità

[Definire gli intervalli di qualità relativi alla prestazione, robustezza, tolleranza agli errori, utilizzabilità e altre caratteristiche non catturate nell'Insieme di funzioni.]

8.                  Precedenza e priorità

[Definire la priorità delle diverse funzioni di sistema.]

9.                  Requisiti di altri prodotti

[Ad alto livello, fare un elenco degli standard applicabili, dei requisiti hardware o di piattaforma e ambientali.]

9.1               Standard applicabili

[Elencare tutti gli standard con cui il prodotto deve essere conforme. Ciò può includere standard di comunicazioni (TCP/IP, ISDN) legali e regolatori (FDA, UCC), standard di conformità alla piattaforma (Windows, UNIX, e così via) e standard di sicurezza e qualità (UL, ISO, CMM).]

9.2               Requisiti di sistema

[Per lo sviluppo di sistema software, definire ogni requisito di sistema necessario a supportare l'applicazione. Ciò può comprendere i sistemi operativi host e le piatteforme di rete, le configurazioni, la memoria, le periferiche e software di accompagnamento.]

9.3               Requisiti di prestazione

[Utilizzare questa sezione per specificare i requisiti di prestazione. Le questioni di prestazione possono comprendere elementi come fattori di caricamento, larghezza di banda o capacità di comunicazione, produttività, accuratezza e affidabilità o tempi di risposta sotto varie condizioni di caricamento.]

9.4               Requisiti ambientali

[Specificare i requisiti ambientali come necessario. Per i sistemi fisici, i problemi ambientali possono comprendere la temperatura, shock, umidità, radiazioni e così via. Per i sistemi software, i fattori ambientali possono comprendere condizioni d'utilizzo, ambiente dell'utente, disponibilità di risorse, problemi di manutenzione e recupero e gestione di errori.]

9.5        Requisiti fisici

[Se vi sono requisiti fisici come peso o limiti di massa o di misura, descriverli in questa sezione secondaria.]

10.             Requisiti di documentazione

[Questa sezione descrive la documentazione che deve essere sviluppata per supportare una distribuzione del sistema di successo.]

10.1            Manuale dell'utente

[Descrivere lo scopo e i contenuti del Manuale dell'utente. Discutere sulla lunghezza, livello di dettagli, esigenza di indice, glossario di termini, strategia didattica contro quella manuale di riferimento e così via. Anche i vincoli di formattazione e di stampa devono essere identificati.]

10.2            Guida online

[Molti sistemi forniscono una guida online per assistere l'utente. La natura di questi sistemi è inusuale, poiché combina aspetti di programmazione (collegamenti ipertestuali ecc.) con aspetti di scrittura tecnica come l'organizzazione e la presentazione. Molti hanno riscontrato che lo sviluppo di un sistema di guida online è un progetto dentro un progetto che beneficia di un ambito di anticipo e di attività di pianificazione.]

10.3            Guide di installazione, configurazione e file Read Me

[Un documento che comprende istruzioni di installazione e linee guida di configurazione è importante per offrire una piena soluzione. In genere è incluso anche un file Read Me come componente standard. Il file Read Me può includere una sezione "Cosa c'è di nuovo in questo rilascio? e una discussione sulle questioni di compatibilità con precedenti rilasci. Molti utenti apprezzano anche una documentazione che definisce i problemi e le soluzioni nel file Read Me.]

10.4            Etichettatura e imballaggio

[I sistemi moderni tentano di fornire un aspetto coerente che inizia con l'imballaggio del prodotto e si concretizza in menu d'installazione, schermate iniziali, guide di sistema, finestre di dialogo GUI e così via. Questa sezione definisce le esigenze e i tipi di etichettatura da incorporare nel sistema. Gli esempi includono avvisi di copyright e di brevetto, loghi aziendali, icone standardizzate e altri elementi grafici e così via.]

A.         Attributi di funzioni

[Alle funzioni vengono assegnati degli attributi che possono essere utilizzati per valutare, tracciare, dare priorità e gestire gli elementi del prodotto proposti per l'implementazione. Tutti i tipi di requisiti e gli attributi vengono strutturati nel Piano di gestione requisiti, si potrebbe comunque desiderare di elencare e descrivere brevemente gli attributi relativi alle funzioni che sono stati scelti. Le seguenti sezioni secondarie presentano una serie di attributi di funzione suggeriti.]

A.1            Stato

[Impostato dopo la negoziazione e rivisto dal team di gestione del progetto. Tiene traccia dell'avanzamento durante la definizione della linea di base del progetto.]

Proposto

[Utilizzato per descrivere le funzioni in discussione ma che non sono state ancora riviste e accettate dal "canale ufficiale," come un gruppo di lavoro costituito da rappresentanti del team del progetto, di gestione del prodotto e comunità di utenti o clienti.]

Approvato

[Capacità ritenute utili e realizzabili e che sono state approvate per l'implementazione dal canale ufficiale.]

Incorporato

[Funzioni incorporate nella linea di base del prodotto in uno specifico momento.]

A.2            Beneficio

[Impostato dal Marketing, dal Responsabile del prodotto o dall'Analista di settore. I requisiti non sono tutti uguali. La classificazione dei requisiti a seconda del relativo beneficio all'utente apre un dialogo con i clienti, gli analisti e i membri del team di sviluppo. Utilizzato nell'ambito della gestione e nella determinazione delle priorità di sviluppo.]

Critico

[Funzioni essenziali. Il fallimento dell'implementazione significa che il sistema non soddisferà le esigenze del cliente. Tutte le funzioni critiche devono essere implementate nel rilascio o la pianificazione slitterà.]

Importante

[Funzioni importanti per l'efficacia e l'efficienza del sistema nella maggior parte degli utilizzi. La funzionalità non può essere facilmente fornita in altri modi. La mancanza dell'inclusione di una funzione importante può influenzare la soddisfazione del cliente o dell'utente, ma il rilascio non sarà posticipato a causa di questa mancanza.]

Utile

[Funzioni che supportano utilizzi meno tipici e di conseguenza saranno utilizzati meno frequentemente o per cui possono essere trovate soluzioni ragionevolmente efficaci. Non è possibile aspettarsi profitti significativi o impatti di soddisfazione del cliente se questo elemento non viene inserito nel rilascio.]

 

A.3            Impegno

[Impostato dal team di sviluppo. Poiché alcune funzioni richiedono più tempo e risorse di altre, fare una stima delle risorse umane necessarie e ogni altra valutazione relativa all'impegno (come le righe di codice richieste o i punti di funzione relativi al software), è il modo migliore per misurare la complessità e stabilire le aspettative di cosa può o non può essere realizzato in un dato lasso di tempo. Utilizzato nell'ambito della gestione e nella determinazione delle priorità di sviluppo.]

A.4            Rischio

[Impostato dal team di sviluppo sulla base della probabilità che nel progetto vi siano eventi indesiderati, come lo sforamento dei costi, ritardi nella pianificazione o addirittura la cancellazione. La maggior parte dei Responsabili di progetto ritengono sufficiente catalogare i rischi come alto, medio e basso, sebbene sia possibile dare altre gradazioni. I rischi spesso possono essere valutati misurando l'imprecisione della stima di pianificazione del team dei progetti.]

A.5            Stabilità

[Impostata dall'analista e dal team di sviluppo sulla base della probabilità che la funzione cambi o sulla coscienza del team che ciò possa accadere. Utilizzata per stabilire le priorità di sviluppo e determinare quegli elementi per cui una deduzione aggiuntiva è l'azione successiva appropriata.]

A.6            Rilascio previsto

[Registra la versione del prodotto desiderata in cui la funzione apparirà per prima. Questo campo può essere utilizzato per assegnare funzioni da un documento Visione in un particolare rilascio di linee base. Se combinato con il campo di stato, il team può proporre, registrare e discutere varie funzioni del rilascio senza impegnarle allo sviluppo. Solo quelle funzioni il cui Stato è impostato su Incorporato e il cui Rilascio previsto è definito saranno realizzate. Quando avviene la gestione dell'ambito, il Numero di versione del rilascio previsto può essere incrementato così l'elemento resterà nel documento di Visione ma sarà pianificato per un rilascio successivo.]

A.7            Assegnato a

[In molti progetti, le funzioni saranno assegnate ai "team di funzione" responsabili di ulteriori deduzioni, della cattura e perfezionamento dei requisiti e dell'implementazione. Questo semplice elenco a discesa aiuterà il team di progetto a comprendere meglio le responsabilità.]

A.8            Motivo

[Questo campo di testo viene utilizzato per tracciare la fonte della funzione richiesta. I requisiti esistono per ragioni specifiche. Questo campo registra una spiegazione o un riferimento ad una spiegazione. Ad esempio, il riferimento potrebbe essere ad un numero di pagina o di rigo della specifica del requisito di un prodotto o ad un indicatore di minuti in un video di un'importante revisione del cliente.]