Qual è il modo corretto per creare i documenti dei requisiti?

Sono piuttosto sorpreso che nessuno finora abbia raccomandato l'uso di un wiki per i requisiti di tracciamento.

Ho trovato che è un sistema quasi perfetto, perché:

• Consente alle persone di collaborare ai requisiti e rende questo aspetto altamente visibile;
• Ti consente di mantenere facilmente aggiornati i requisiti man mano che il progetto procede;
• Puoi entrare e vedere la cronologia in qualsiasi momento, in caso di controversia "non è quello che abbiamo concordato";
• La maggior parte dei wiki moderni ha capacità di formattazione decenti, quindi sembra quasi buono come un documento di Word;
• Puoi collegare ipertestuali direttamente dai tuoi requisiti alla documentazione effettiva;
• Non ti devi mai preoccupare delle persone che lavorano su copie diverse / obsolete;
• I requisiti possono iniziare a essere trattati come un processo iterativo, proprio come la progettazione / implementazione;
• Se i requisiti iniziano a diventare molto grandi / complicati, è facile dividerli tra pagine e argomenti.
• La maggior parte dei wiki accetta HTML, quindi se hai davvero bisogno di una formattazione avanzata, puoi probabilmente usare uno strumento come Windows Live Writer .

Data la scelta, quasi sempre scelgo il metodo wiki in questi giorni, è davvero piuttosto indolore se paragonato ai vecchi documenti di Word o se provo a racchiudere tutto in un bug tracker.

Uso sempre lo standard IEEE 830-1998 (Prassi raccomandata IEEE per le specifiche dei requisiti software) come modello per il mio documento SRS. Vedi link

L'ultimo documento SRS di per sé è solitamente un singolo documento di OpenOffice.org, ma di solito ci sono molte parti che lo compongono, inclusi fogli di calcolo e diagrammi.

Di solito metto tutti questi documenti insieme in un repository che ho inserito in un sistema di controllo di revisione , come SVN o CVS. Tutti gli altri analisti, progettisti, sviluppatori, tester, project manager e clienti hanno accesso a questo repository, quindi possono leggerlo e apportare modifiche.

Ricorda, l'SRS è un documento vivo e in evoluzione. Continuerà a cambiare e crescere per qualche tempo. Non solo è importante per tutti gli stakeholder avere accesso allo SRS, ma è anche importante avere una cronologia completa delle modifiche e, se necessario, anche la possibilità di eseguire il rollback di queste modifiche. Quindi un sistema di controllo di revisione funziona alla grande per questo scopo. Buona fortuna!

L'utilizzo del bug tracker per la gestione dei requisiti ha una tendenza a nascondere la mancanza di collaborazione e la comunicazione all'interno dell'azienda.

Senza giudicare alcun metodo particolare:

• se stai per usare waterfall, hai bisogno di documenti multi-pagina ben strutturati e accurati (non un paragrafo che molte persone tipicamente scrivono come descrizione di un bug). Questi documenti sono anche impossibili da scrivere e mantenere a un livello di qualità accettabile se gli addetti al marketing / alle vendite (che hanno originato i requisiti) non lavorano bene insieme allo staff tecnico.
• se utilizzerai uno dei metodi agili, allora un'unità di requisiti è una storia utente, rappresentata da una trama. La carta stessa non è un requisito, ma solo un punto di partenza della conversazione.

Un'esperienza (breve) di uno dei miei ex datori di lavoro con l'utilizzo di un bug tracker per i requisiti era che offriva a molte persone un modo molto semplice per interrompere completamente la comunicazione. Le persone semplicemente scrivono un desiderio, lo scaricano nel bug-tracker e presumono che alla fine si avvereranno.

Naturalmente lo hanno fatto senza riguardo a:

• le loro qualifiche
• la loro partecipazione nel progetto
• è in conflitto con altri requisiti
• lacune nei requisiti
• i costi
• eventuali considerazioni tecniche
• ecc.

Credo che i documenti "Word" siano la soluzione sbagliata per i requisiti, per i seguenti motivi:

1. Non c'è modo di "diff" due documenti per vedere cosa è cambiato.
2. L'interfaccia utente scoraggia l'utilizzo di uno stile coerente. Sì, è possibile utilizzare gli stili, ma la maggior parte delle persone non può essere disturbata a causa della difficoltà.
3. Il formato del documento è essenzialmente nascosto. Certo, c'è una specifica per i file OLE, che credo siano i documenti di "Word", ma Microsoft ha seppellito tutto ciò che è utile sotto tonnellate di follia, quindi nessuno lo sa davvero. Prima o poi, il tuo nuovo "Word" non aprirà il documento.
4. Non funziona bene con altri formati. Cioè, a meno che tu non usi Windows e IE, sei sfortunato se qualcuno organizzasse i documenti di un progetto in file HTML con collegamenti a file in formato "Word". Fai clic sul link sbagliato e devi passare attraverso un lungo periodo di download-and-start-Word, interrompendo il flusso del pensiero. I collegamenti ipertestuali da documenti "Word" ad altri potrebbero o potrebbero non funzionare.
5. "Parola" è fondamentalmente per la scrittura di documenti destinati ad apparire sulla carta. Un obiettivo ammirevole, ma che lo rende poco utile per la visualizzazione online.

Non ho un suggerimento alternativo di cui abbia esperienza, ma ho pensato a come convertire il testo di ReStructured Text o Markdown in alternative.

Generalmente usiamo Word, ma in realtà il modo in cui li crei nel software è meno importante di come raccogli i dati per crearli e se la persona che raccoglie le informazioni sa abbastanza per sapere quando un requisito è eccessivamente complicato e sarà lontano più costoso di un requisito più semplice, ma non aggiunge alcun valore reale a nessuno (ad esempio quando desidera che i numeri di ID vengano sempre assegnati in ordine con nessuno mai saltato) o quando entrerà in conflitto con un requisito esistente o altre funzionalità pianificate. Spesso gli utenti reali non vengono mai contattati e ci sono molte sorprese quando i loro manager non sapevano qualcosa che doveva essere fatto assolutamente e non è nella nuova versione del software.

Potremmo anche usare vari file pdf, Excel o Visio. Tutti loro per il progetto sono raccolti e modificati da SharePoint, quindi possiamo vedere le versioni precedenti se necessario.

Gestisco un backlog di prodotto (uno per progetto o prodotto) che contiene User Story . Possono essere archiviati in software di tracciamento dei bug come quello che usi. Personalmente utilizzo Excel per il backlog e Trac per il backlog sprint (probabilmente utilizzi uno strumento come quello).

Solo quando richiesto, creo un documento di Word che descrive la User Story con maggiori dettagli e lo allega alla user story. Ma cerco di evitarlo suddividendo la storia dell'utente in quelle più piccole.

Small user stories are easier to manage (including estimation)

Mi piace il documento Word perché mi permette di mettere link, formattare testi, mettere tabelle, screenshot e altro, e tutti possono leggerlo.

Naturalmente, ogni User Story è spiegata nei dettagli nella sessione di stima e nella pianificazione dello sprint, e sono sempre disponibile per ulteriori domande quando lo sviluppatore decide di lavorarci sopra. I feedback frequenti che utilizzano la revisione sprint impediscono agli sviluppatori di fare qualcosa di diverso da quello richiesto dal proprietario del prodotto.

Personalmente, in passato ho usato documenti di Word, ma ho deciso di trovare uno strumento in futuro per gestirlo per me ... specialmente con la possibilità di impostare bug ai requisiti, perché molto tempo, il bug è nei requisiti, non nella deviazione tra specifiche e amp; implementazione.

Non mi è mai nemmeno venuto in mente di usare uno strumento di tracciamento dei bug, ma ha perfettamente senso.

Per curiosità, che cos'è che non ti piace?

EDIT: un avvertimento; dire al proprio manager di rinominare il software di tracciamento dei bug. Altrimenti si presume che tutto ciò che contiene sia un bug. Ho avuto questo problema politico nel mio ultimo cliente, dove ho messo compiti nel bug tracker. Non va bene.

Ho scritto un database dei requisiti 6 o 7 anni fa per gestirlo. Ogni record di requisito ha una breve descrizione, un memo di "definizione" e un promemoria "note" (sia rich text, con possibilità di incorporare schermate, ecc.). Ci sono anche altri campi, per progetto, deliverable, numero di sequenza (in modo che possano essere ordinati logicamente), use-case / feature a cui è correlato, stima del tempo, un campo per la persona che lo gestisce, se qualcuno lo ha selezionato per l'implementazione, ecc.

C'è anche uno "Stato" - "Inserito", perché mentre stiamo progettando le funzionalità; "Approvato", imposta una volta che un gruppo di requisiti viene esaminato e determinato per essere pronto per essere implementato; "Implementato", impostato dal programmatore una volta che ritengono che il requisito sia stato eseguito, e "Convalidato" una volta che la tecnologia QA è d'accordo con il programmatore. (Se il tecnico QA non è d'accordo, può riportarlo su "Approvato" in modo che il programmatore lo riprenda.) I requisiti possono anche essere "Differiti", "Rifiutati" o "Interrogati" (il che significa che il Pannello di Controllo del Cambiamento deve guardarlo .)

Il trucco per farlo bene è una granularità ragionevole. A volte può essere logico avere un requisito di frase (ad esempio "il problema descritto nel problema 12345 è risolto"), ma in generale i requisiti dovrebbero descrivere tutti gli aspetti importanti di un'intera funzione (o una grande parte di uno). Ad esempio, una caratteristica tipica del "nuovo report" avrà un requisito per un formato del report (come appare l'output) e un requisito per la finestra di dialogo delle opzioni (spiegando i campi, la convalida, ecc.). Potrebbe esserci anche un terzo se c'è un generatore complesso che scricchiola i dati, piuttosto che una semplice query o qualcosa del genere. Inoltre, creeremo un requisito di "Guida" per l'argomento della guida corrispondente.

Ci sono enormi vantaggi nel mantenere questa roba nei record del database piuttosto che in un grande documento. Più programmatori possono lavorare sui requisiti allo stesso tempo. I singoli record sono bloccati in modo che solo una persona possa modificare alla volta, ma possono essere aperti e letti mentre qualcun altro sta modificando. Il più grande vantaggio è che fornisce una documentazione di ricerca facile sia per quanto riguarda i requisiti, sia per le note su come sono stati implementati. Abbiamo oltre 25.000 requisiti in questo momento e possiamo facilmente trovare tutti i requisiti con parole specifiche in tutti i campi, o la definizione, o note, o qualsiasi altra cosa, in meno di 10 secondi. (Provalo con più di 6 anni di documenti Word.)

Posso capire perché la gente potrebbe dire che è una cattiva idea fare i requisiti in un "bug tracker", ma la mia ipotesi è perché gli strumenti fanno schifo, non perché mantenere i requisiti in un database ricercabile è una cattiva idea.

Ho usato una volta link ma nella mia attuale compagnia utilizziamo .doc come fonte di specifiche del core e Lighthouse come wishlist e ampli ; problema di tracciamento. Per me è difficile fare in modo che altre persone del team inizino a utilizzare altri strumenti quando sono così abituati a Word.

Se puoi seguire la metodologia Agile, i seguenti link ti guideranno nella scelta di un buon strumento di gestione dei progetti Agile:

• Strumenti di gestione del progetto Agile
• Confronto tra diversi strumenti di gestione del progetto Agile

E seriamente, prova la metodologia Agile - predica un approccio sensoriale semplice, elegante, senza fronzoli, non jazzistico, comune a qualsiasi cosa tu faccia, in modo tale che ogni membro della squadra capisca e apprezzi il ruolo e lo sforzo di ogni altro membro.

Buona fortuna!