Visione

Quando qualcuno si unisce al progetto è utile poter dire "Benvenuti! Siete pregati di andare a leggere il documento di Visione (è lungo solo 7 pagine) sul sito web del progetto". Inoltre è utile avere un "sommario esecutivo" che descrive brevemente il progetto, come contesto per i partecipanti principali, al fine di stabilire una visione comune del progetto.

La Visione non deve essere lunga né deve tentare di descrivere i requisiti stabili nel dettaglio, ma deve riassumere alcune informazioni contenuti nel Modello dei casi d'uso e nelle Specifiche supplementari.

Obiettivi e problemi fondamentali ad alto livello delle parti interessate
...

Questo paragrafo della Visione riassume gli obiettivi e i problemi ad alto livello (spesso più alto che non i casi d'uso specifici) e rivela importanti obiettivi non funzionali e di qualità che possono essere relativi a uno solo o a più casi d'uso, come i seguenti:

  • C'è bisogno di un'elaborazione delle vendite tollerante ai guasti
  • C'è bisogno della capacità di personalizzare le regole di business

Riepilogo delle caratteristiche del sistema
...

Nella Visione, per cogliere le caratteristiche principali, non è sufficiente elencare semplicemente i nomi dei casi d'uso. Perché?

  • Dettagli eccessivi o a livello basso. Di solito è preferibile una breve sintesi delle idee principali. Potrebbero invece essere pronti 30 o 50 casi d'uso.
  • I nomi dei casi d'uso potrebbero nascondere delle caratteristiche fondamentali sulle quali le parti interessare desiderano effettivamente avere informazioni. Per esempio, si supponga che la decrizione di una funzionalità di pagamento automatizzato sia incorporata nel caso d'uso Process Sale. Chi legge l'elenco dei nomi dei casi d'uso non è in grado di capire se il sistema gestisce le autorizzazioni ai pagamenti.
  • Alcune caratteristiche significative si estendono su più casi d'uso o sono ortogonali agli stessi. Per esempio, durante il primo Worksop dei requisiti per NextGen, qualcuno potrebbe dire: "il sistema deve essere in grado di interagire con dei sistema esistenti di contabilità, inventario e calcolo delle imposte prodotti da terze parti".

Pertanto un metodo alternativo e complementare per esprimere le funzioni del sistema è attraverso le feature o caratteristiche, o più precisamente in questo contesto, le caratteristiche del sistema, che sono affermazioni concise e di alto livello che riassumono funzioni di sistema. In modo più formale, in UP, una caratteristica di sistema è "un servizio osservabile dall'esterno fornito dal sistema, che soddisfa direttamente una necessità di una parte interessata".

Le caratteristiche sono funzioni o comportamento che un sistema può fare, eseguire, gestire. Esempio:

Il sistema gestisce le autorizzazioni ai pagamenti

Le caratteristiche funzionali di sistema devono essere contrapposte ai vari tipi di requisiti e vincoli non funzionali, come:

Il sistema deve essere eseguito su Linux, deve essere disponibile 24 ore al giorno 7 giorni su 7 e deve avere un'interfaccia touch-screen.

Segue un esempio di caratteristiche ad alto livello, per un grosso progetto multi-sistema di cui POS è solo un elemento:

Le caratteristiche principali comprendono:

  • Servizi POS
  • Gestione inventario
  • Vendita sul web
  • ...

Comunemente è prassi organizzare le caratteristiche di sistema secondo una gerarchia a due livelli. Nel documento di Visione, più di due livelli comporterebbero un eccesso di dettagli; lo scopo delle caratteristiche di sistema nella Visione è riassumere le funzionalità, non decomporle in un lungo elenco di elementi a grana fine. Ecco un esempio ragionevole di dettagli:

Le caratteristiche principali comprendono: (livello 1)
Servizi POS: (livello 2)

  • acquisizione vendite
  • autorizzazione pagamenti
  • ...

Gestione inventario:

  • riordinamento automatico
  • ...