Ci sono diversi documenti che definiscono un progetto:
-
Product Vision: questo documento viene utilizzato per comunicare ciò che il prodotto dovrebbe fare e ciò che non dovrebbe fare. In genere ha sezioni che mettono a confronto il prodotto con i concorrenti e mostrano i suoi vantaggi. Elenca inoltre le parti interessate coinvolte nella produzione e implementazione e i loro ruoli. Una sezione molto importante elenca anche i tipi di utenti (ruoli) e in che modo il sistema aggiungerà valore a loro e migliorerà il loro lavoro.
-
Documenti relativi ai requisiti: devono contenere requisiti funzionali e non funzionali. A volte sono separati in Use Cases per i requisiti funzionali e Specifiche supplementari per i requisiti non funzionali. Alcune organizzazioni combinano tutto il documento SRS (Specifiche dei requisiti del software) e altri inseriscono gli Use Case nello SRS e utilizzano un documento separato per le Specifiche supplementari.
La Product Vision viene solitamente preparata nella fase iniziale del progetto in cui sono definite solo specifiche di alto livello ed è inteso principalmente per ottenere un accordo con il cliente. Un documento sulla Carta dei progetti viene preparato nella stessa fase e parte dei documenti di gestione del progetto. Contiene una descrizione di livello ancora più elevato delle funzioni del prodotto e ha lo scopo di definire l'ambito del progetto. Alcune organizzazioni lo usano come documento interno per concordare l'ambito tra il PM e l'alta dirigenza. Tuttavia, alcune organizzazioni utilizzano la carta del progetto anziché la visione del progetto e la usano anche per l'accordo con il cliente.
Quando il progetto prende il via, soprattutto quelli di grandi dimensioni, due documenti sono preparati da Business Analysts (esperto di dominio): il Come è documento e Essere documento. As As descrive l'ambiente corrente e il flusso di lavoro nel dominio aziendale (alcuni elementi vengono eseguiti manualmente, ad esempio utilizzando documenti). The To Be descrive ciò che il cliente desidera che le cose siano (come verrà utilizzato il software invece del lavoro cartaceo).
Dopo aver preparato l'As is and To Be, l' analista di sistema inizia a creare casi d'uso e specifiche supplementari.
Questa è la scala più grande che ho visto nelle organizzazioni per cui ho lavorato. È possibile combinare o rimuovere i documenti come desiderato / necessario per la suite del progetto. I progetti più piccoli non hanno bisogno di così tanti documenti e non coinvolgono molti ruoli. I progetti di grandi dimensioni necessitano di tale separazione perché diversi documenti parlano a persone diverse. Specialmente se vuoi comunicare con alte posizioni manageriali non dovresti dare loro documenti con contenuti che non sono interessati a leggere.