Qual è il modo corretto di creare documenti dei requisiti?

In questo momento il mio supervisore sta creando requisiti documentazione / specifiche per me utilizzando il software di bugtracking. Questa mi sembra un'idea terribile, tutti questi requisiti sono su questi piccoli biglietti e devo fare clic su questo stupido modulo web per ottenere i requisiti. Che cos'è una soluzione software sana per requisiti / specifiche software?

Per essere chiari, sto costruendo questo grande componente software con alcune funzionalità e queste funzionalità sono state esposte in questo software di bugtracking.

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

Ho trovato un sistema quasi perfetto, perché:

• Permette 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 avanza;
• 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 discrete capacità di formattazione, quindi sembra quasi buona come un documento Word;
• È possibile collegare ipertestuali direttamente dalle proprie esigenze nella documentazione effettiva;
• Non devi mai preoccuparti di 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 suddividerli in pagine / 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, ho quasi sempre scelto il metodo wiki in questi giorni, è davvero abbastanza indolore rispetto ai documenti di Word vecchio stile o cercando di stipare tutto in un tracker di bug.

Uso sempre IEEE Std 830-1998 (IEEE Recommended Practice for Software Specifments Specifcations) come modello per il mio documento SRS. Vedi http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Lo stesso documento SRS finale è di solito un singolo documento OpenOffice.org, ma di solito ci sono molte parti costitutive che lo compongono, inclusi fogli di calcolo e diagrammi.

Di solito metto insieme tutti questi documenti in un repository che inserisco in un sistema di controllo di revisione , come SVN o CVS. Tutti gli altri analisti aziendali, designer, sviluppatori, tester, project manager e clienti hanno accesso a questo repository, in modo che possano leggerlo e apportare modifiche.

Ricorda, l'SRS è un documento vivo e in evoluzione. Continuerà a cambiare e crescere per qualche tempo. Non solo è importante che tutte le parti interessate abbiano accesso all'SRS, ma è anche importante avere una cronologia completa delle modifiche e la possibilità di annullare anche queste modifiche, se necessario. Quindi un sistema di controllo di revisione funziona perfettamente a questo scopo. In bocca al lupo!

L'uso del bug tracker per la gestione dei requisiti tende a nascondere la mancanza di collaborazione e comunicazione all'interno dell'azienda.

Senza giudicare alcun metodo particolare:

• se hai intenzione di usare la cascata, hai bisogno di documenti ben strutturati, precisi e multi-pagina (non un paragrafo che molte persone tipicamente digitano come descrizione di un bug). Questi documenti sono anche impossibili da scrivere e mantenere a un livello decente di qualità se il marketing / i venditori (che originano i requisiti) non lavorano bene insieme allo staff tecnico.
• se hai intenzione di utilizzare uno dei metodi agili, un'unità di requisiti è una user story, rappresentata da una story card. La carta stessa non è un requisito, solo un punto di partenza della conversazione.

Una (breve) esperienza di uno dei miei precedenti datori di lavoro con l'uso di un bug-tracker per i requisiti è stata che ha fornito a molte persone un modo molto semplice per interrompere completamente la comunicazione. Le persone semplicemente scrivevano un desiderio, lo scaricavano nel bug-tracker e presumevano che alla fine sarebbe diventato realtà.

Naturalmente lo hanno fatto senza considerare:

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

Credo che i documenti "Word" siano la strada 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 in tutto. Sì, è possibile utilizzare gli stili, ma la maggior parte delle persone non può essere disturbata a causa della difficoltà.
3. Il formato del documento è sostanzialmente nascosto. Certo, c'è una specifica per i file OLE, che immagino siano i documenti "Word", ma Microsoft ha seppellito tutto ciò che è utile sotto tonnellate di letame, quindi nessuno lo sa davvero. Prima o poi, la tua nuova e brillante "Parola" 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 organizza i documenti di un progetto in file HTML con collegamenti a file di formato "Word". Fai clic sul link sbagliato e devi passare un lungo periodo di download e avvio di Word, interrompendo il flusso di pensiero. I collegamenti ipertestuali da documenti "Word" ad altri potrebbero non funzionare.
5. "Word" è essenzialmente per scrivere documenti destinati ad apparire su carta. Un obiettivo ammirevole, ma che lo rende poco utile per la visualizzazione online.

Non ho un suggerimento alternativo con cui ho esperienza, ma ho pensato al testo ricostruito di Python o Markdown come alternative.

Generalmente utilizziamo 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à molto più costoso di un requisito più semplice ma non aggiunge alcun valore reale a nessuno (come quando vogliono che i numeri ID vengano sempre assegnati in ordine senza che nessuno venga mai ignorato) o quando entrerà in conflitto con un requisito esistente o altra caratteristica pianificata. Spesso gli utenti reali non vengono mai contattati e ci sono molte sorprese quando i loro manager non sapevano qualcosa che doveva assolutamente essere fatto e non è nella nuova versione del software.

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

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

Solo quando richiesto, creo un documento di Word che descrive la User Story con maggiori dettagli e lo allego alla User story. Ma provo a evitarlo dividendo la user story in più piccole.

Le storie di piccoli utenti sono più facili da gestire (compresa la stima)

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

Naturalmente, ogni User Story è spiegata in dettaglio nella sessione di stima e nella pianificazione dello sprint e sono sempre disponibile per ulteriori domande quando lo sviluppatore decide di lavorarci. I feedback frequenti che utilizzano lo sprint review impediscono agli sviluppatori di fare qualcosa di diverso rispetto a quanto richiesto dal proprietario del prodotto.

Personalmente, in passato ho usato Word Documents, ma in futuro ho deciso di trovare uno strumento per gestirlo ... soprattutto con la possibilità di impostare i bug in base ai requisiti, perché il più delle volte il bug è nei requisiti, non la deviazione tra specifiche e implementazione.

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

Per curiosità, che cosa non ti piace?

EDIT: un avvertimento; dì al tuo 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 inserito compiti nel tracker dei bug. Non bene.

Ho scritto un database di requisiti 6 o 7 anni fa per gestirlo. Ogni record di requisiti ha una breve descrizione, un memo "definizione" e un memo "note" (entrambi rich text, con possibilità di incorporare schermate, ecc.). Esistono anche altri campi, per progetto, deliverable, numero progressivo (in modo che possano essere ordinati logicamente), caso d'uso / funzionalità a cui è correlato, stima del tempo, un campo per la persona che lo gestisce, se qualcuno lo ha selezionato per l'implementazione, eccetera.

C'è anche uno "Stato" - "Inserito", mentre mentre stiamo progettando le funzionalità; "Approvato", impostato una volta che un gruppo di requisiti viene esaminato e determinato per essere pronto per l'implementazione; "Implementato", impostato dal programmatore quando ritengono che il requisito sia stato eseguito, e "Convalidato" una volta che la tecnologia QA è d'accordo con il programmatore. (Se la tecnologia QA non è d'accordo, può riportarlo su "Approvato" in modo che il programmatore lo ritorni.) I requisiti possono anche essere "Rinviato", "Rifiutato" o "Interrogato" (ciò significa che la commissione di controllo delle modifiche deve esaminarla .)

Il trucco per farlo bene è una granularità ragionevole. A volte può avere senso avere requisiti di una frase (ad esempio "il problema descritto nel problema 12345 è risolto"), ma in generale, i requisiti dovrebbero descrivere tutti gli aspetti importanti di un'intera funzionalità (o una grande parte di uno). Ad esempio, una tipica funzione "nuovo report" avrà un requisito per un formato di report (come appare l'output) e un requisito per la finestra di dialogo delle opzioni (che spiega i campi, la convalida, ecc.) Potrebbe anche esserci 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 contemporaneamente. I singoli record sono bloccati, quindi solo una persona alla volta può modificare, ma possono essere aperti e letti mentre qualcun altro sta modificando. Il più grande vantaggio però è che fornisce una facile ricerca della documentazione di entrambi i requisiti e delle note su come sono stati implementati. Ora abbiamo oltre 25.000 requisiti e possiamo facilmente trovare tutti i requisiti con parole specifiche in tutti i campi, o la definizione, o le note, o qualsiasi altra cosa, in meno di 10 secondi. (Prova con documenti Word di almeno 6 anni).

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

Ho usato una volta http://www.pivotaltracker.com/ ma nella mia attuale azienda stiamo usando .doc come fonte delle specifiche di base e Lighthouse come lista delle funzionalità combinate e tracciamento dei problemi. Per me è difficile far sì che altre persone nel team inizino a usare qualsiasi altro strumento quando sono così abituati a Word.

Se riesci a seguire la metodologia Agile, i seguenti link ti guideranno nella scelta di un buon strumento di Project Management Agile:

• Strumenti di gestione dei progetti agili
• Confronto tra diversi strumenti di gestione dei progetti Agile

E seriamente, prova la metodologia Agile: predica un approccio sensuale semplice, elegante, senza fronzoli, non jazzistico, comune in qualsiasi cosa tu faccia, in modo tale che ogni membro del team comprenda e apprezzi il ruolo e lo sforzo di ogni altro membro.

In bocca al lupo!