Qual è il modo corretto per creare documenti dei requisiti?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/9371

Domanda

In questo momento il mio supervisore sta creando i requisiti di documentazione / specifiche per me utilizzando il software Bugtracking. Questo mi sembra una pessima idea per me, tutti i requisiti sono in questi piccoli biglietti e devo cliccare in giro su questo modulo web muto per arrivare ai requisiti. Che cosa è una soluzione software sano di mente per le specifiche esigenze / software?

Per essere chiari, sto costruendo questo grande componente software con un bel paio di caratteristiche e queste caratteristiche vengono enunciate nella presente software bugtracking.

È stato utile?

Soluzione

Io sono piuttosto sorpreso che nessuno finora è raccomandato l'uso di un wiki per i requisiti di tracciamento.

ho trovato ad essere un sistema quasi perfetto, perché:

  • Esso permette alle persone di collaborare su requisiti e rende questo aspetto altamente visibile;
  • Vi permette di tenere facilmente i requisiti aggiornati come i progressi del progetto;
  • È possibile andare a vedere la storia in qualsiasi momento, in caso di un "non è quello che abbiamo concordato" controversia;
  • La maggior parte dei wiki moderni hanno funzionalità di formattazione decenti, così sembra quasi buono come un documento Word;
  • È possibile collegamento ipertestuale direttamente dai vostri requisiti nella documentazione reale;
  • Non hai mai preoccuparsi di persone che lavorano fuori di diversi / copie obsoleti;
  • Requisiti possono iniziare a essere trattata come un processo iterativo, proprio come la progettazione / realizzazione;
  • Se i requisiti cominciano a diventare davvero grande / complicata, è facile dividerli in su attraverso pagine / argomenti.
  • La maggior parte dei wiki accetta HTML, quindi se si ha realmente bisogno di formattazione avanzate, probabilmente si può utilizzare uno strumento come di Windows live Writer .

Data la scelta, ho quasi sempre scegliere il metodo wiki in questi giorni, è davvero abbastanza indolore rispetto al vecchio stile documenti Word o cercando di stipare tutto in un bug tracker.

Altri suggerimenti

Io uso sempre IEEE Std 830-1998 (IEEE Pratica raccomandata per Requisiti software Specifcations) come modello per il mio documento SRS. Vedere http://standards.ieee.org/reading/ieee/std_public/description /se/830-1998_desc.html

I SRS finali documento stesso è di solito un singolo documento OpenOffice.org, ma ci sono di solito molte parti costituenti che entrano in esso, compresi fogli di calcolo e diagrammi.

Io di solito messo tutti questi documenti insieme in un repository che ho messo in un sistema di controllo di revisione , come SVN o CVS. Tutti gli altri analisti, progettisti, sviluppatori, tester, project manager e i clienti hanno accesso a questo repository, in modo che possano leggerlo e apportare modifiche.

Ricordate, l'SRS è un essere vivente, in continua evoluzione documento. Essa continuerà a cambiare e crescere per qualche tempo. Non solo è importante per tutte le parti interessate di avere accesso alle SRS, ma è anche importante avere una storia completa delle modifiche, e la capacità di far ritirare tali cambiamenti e, se necessario. Quindi un sistema di controllo di revisione funziona alla grande per questo scopo. Buona fortuna!

Utilizzando il bug-tracker per la gestione dei requisiti ha una tendenza a nascondere la mancanza di collaborazione e la comunicazione all'interno della società.

Senza esprimere un giudizio su un metodo particolare:

  • se avete intenzione di usare cascata, è necessario ben strutturato, precisi, documenti di più pagine (non un paragrafo che molte persone in genere di tipo come descrizione bug). Questi documenti sono anche impossibile scrivere e mantenere a un buon livello di qualità se il marketing / venditori (che hanno origine i requisiti) non funzionano bene insieme con il personale di ingegneria.
  • se avete intenzione di utilizzare uno dei metodi agili, poi un'unità di requisiti è una storia utente, rappresentato da una carta di storia. La scheda in sé non è un requisito, solo un punto di partenza della conversazione.

A (breve) esperienza di uno dei miei datori di lavoro passato con l'utilizzo di un bug-tracker per i requisiti era che ha dato molte persone come modo molto semplice per smettere di comunicare completamente. La gente avrebbe semplicemente scrivere un desiderio, discarica nel bug-tracker, e assumere che alla fine si sarebbe avverato.

Naturalmente lo hanno fatto senza tener conto:

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

Credo che i documenti "parola" sono il modo sbagliato di procedere per i requisiti, per i seguenti motivi:

  1. Non c'è modo di "diff" due documenti per vedere cosa è cambiato.
  2. I scoraggia interfaccia utente utilizzando uno stile coerente in tutto. Sì, utilizzando gli stili possono essere fatte, ma la maggior parte delle persone non può essere disturbato a causa della difficoltà.
    3. formato
  3. Documento è essenzialmente nascosto. Certo, c'è una specifica per i file OLE, che credo "parola" docs sono, ma Microsoft ha seppellito ogni cosa utile sotto tonnellate di chiacchiere, in modo che nessuno sa veramente. Prima o poi, il vostro lucido, nuova "Parola" non aprire il documento.
  4. non gioca bene con altri formati. Che è, a meno che non si utilizza Windows e IE, sei fuori di fortuna se qualcuno ha organizzato i documenti di un progetto in file HTML con link a file in formato "parola". Clicca sul link sbagliato, e si deve sedere attraverso un lungo periodo di download-and-start-Word, interrompendo il flusso del pensiero. Collegamenti ipertestuali da docs "parola" per gli altri può o potrebbe non funzionare.
  5. "Parola" è fondamentalmente per la scrittura di documenti destinati ad apparire sulla carta. Un obiettivo ammirevole, ma che lo rende meno utile per la visualizzazione on-line.

Non ho un suggerimento alternativo che ho esperienza con, ma ho pensato di testo ristrutturato di Python o Markdown come alternative.

Generalmente usiamo Word, ma in realtà come si crea loro software è meno importante di come si raccolgono i dati per creare loro e se la persona raccogliere le informazioni sa abbastanza per sapere quando un requisito è eccessivamente complicato e sarà di gran lunga più costoso di un requisito semplice ma aggiungere alcun valore reale a chiunque (come ad esempio quando vogliono i numeri ID per essere sempre assegnato in ordine con nessuno mai saltato), o quando sarà in conflitto con un requisito esistente o altra caratteristica pianificata. Spesso gli utenti effettivi non sono mai parlato e ci sono molte sorprese quando i loro dirigenti non sapevano qualcosa che doveva assolutamente essere fatto e non è inthe nuova versione del software.

Possiamo anche utilizzare vari pdf, Excel o Visio file pure. Tutti loro per il progetto sono raccolti e modificati di SharePoint, in modo che possiamo vedere le versioni precedenti se necessario.

I mantenere un prodotto backlog (uno per ogni progetto o del prodotto) che contiene User Stories . Essi possono essere memorizzati in un software di tracciamento dei bug come quello che si usa. Io personnaly uso Excel per l'arretrato e Trac per lo sprint backlog (probabilmente utilizzare uno strumento come quello strumento).

Quando richiesto solo, creo un documento di Word che descrivono la storia utente con maggiori dettagli e collegarlo alla storia dell'utente. Ma cerco di evitare questo frazionamento storia utente in quelle più piccole.

Piccoli storie degli utenti sono più facili da gestire (compresa la stima)

Mi piace il documento di Word, perché mi permette di mettere i link, formati testi, tabelle messe, screenshot e molto altro ancora, e tutti possono leggerlo.

Naturalmente, ogni Utente Story è spiegato in dettaglio nella sessione di stima, e la pianificazione sprint, e io sono sempre a disposizione per più domande quando lo sviluppatore decide di lavorare su di esso. una valutazione frequenti utilizzando recensione sprint impedire agli sviluppatori di fare qualcosa di diverso rispetto richiesto dal proprietario del prodotto.

Personalmente, in passato ho usato documenti di Word, ma hanno deciso di trovare uno strumento in futuro per gestire questo per me ... soprattutto con la capacità di insetti set a esigenze, perché un sacco di tempo, il bug è nei requisiti, non lo scostamento tra le specifiche e implementazione.

Non è mai nemmeno venuto in mente di utilizzare uno strumento di bug tracking, ma ha senso totale.

Per curiosità, che cosa è su di esso che non ti piace?

EDIT: un avvertimento; informi il direttore di rebrand il software di tracciamento dei bug. In caso contrario, tutto ciò che si presume essere un bug. Ho avuto questo problema politico al mio ultimo cliente, dove ho messo i compiti nel bug tracker. Non va bene.

ho scritto un database requisiti 6 o 7 anni fa per gestire questa situazione. Ogni record requisito ha una descrizione breve, un promemoria "definizione", e una nota "note" (sia testo ricco, con la possibilità di incorporare le schermate, ecc). Ci sono altri campi, per il progetto, prodotto, numero di sequenza (in modo che possano essere ordinati logicamente), caso d'uso / funzione è associata la stima del tempo, un campo per il maneggiarlo persona, se qualcuno ha scelto per l'attuazione, ecc.

C'è anche una "Stato" - "Inserita", perché mentre noi stiamo progettando le caratteristiche; "Approvato", impostare una volta un gruppo di requisiti sono rivisti e determinato per essere pronti ad attuare; "Implementato", fissato dal programmatore, una volta che pensano che il requisito è fatto, e "convalidato" una volta che la tecnologia QA è d'accordo con il programmatore. (Se le è d'accordo QA tecnologia, si può impostare di nuovo a "Approvato", così il programmatore ottiene indietro.) Requisiti possono anche essere "differite", "Rejected" o "Interrogato" (che significa il Consiglio Control Change ha bisogno di vedere le cose .)

Il trucco per fare questo bene è granularità ragionevole. A volte può senso avere uno esigenze frase (ad esempio "il problema descritto in numero 12345 è fisso"), ma in generale, requisiti dovrebbe descrivere tutti gli aspetti importanti di un intero caratteristica (o una grossa fetta di uno). Ad esempio, una tipica caratteristica "nuovo rapporto" avrà un requisito per un formato di report (che cosa gli sguardi di output come), e un requisito per il dialogo Opzioni (che spiega i campi, validazione, ecc) Ci potrebbe essere anche un terzo se c'è un generatore complesso sgranocchiando i dati, piuttosto che solo una query di facile o qualcosa del genere. Inoltre, creeremo un requisito "Help" per il corrispondente argomento della guida.

Ci sono enormi vantaggi di tenere questa roba nel record del database, piuttosto che un grande documento. programmatori multipli possono essere lavorando requisiti allo stesso tempo. record individuali sono bloccati in modo che solo una persona può modificare in un momento, ma possono essere aperti e letti mentre qualcun altro sta modificando. Il più grande vantaggio però è che fornisce un facile per cercare la documentazione sia di che cosa i requisiti sono stati, e le note su come sono stati implementati. Abbiamo oltre 25.000 richieste di lì adesso, e possiamo facilmente trovare tutte le esigenze con le parole specifiche in tutti i campi, o la definizione, o note, o qualsiasi altra cosa, in meno di 10 secondi. (Provate a farlo con 6+ anni di valore dei documenti di Word.)

Posso capire perché la gente potrebbe dire che è una cattiva idea di fare richieste in un "bug tracker", ma la mia ipotesi è che sia perché gli strumenti schifo, non perché mantenendo i requisiti in un database consultabile è una cattiva idea.

ho usato una volta http://www.pivotaltracker.com/ ma nella mia società attuale siamo utilizzando doc come fonte specifica core e faro come caratteristiche combinate di desideri e la gestione dei problemi. Per me è difficile fare altre persone nella squadra iniziano a utilizzare altri strumenti quando sono così tanto utilizzati per Word.

Se si riesce a seguire la metodologia Agile, i seguenti link può guidare l'utente attraverso la scelta di un buon strumento di Agile Project Management:

E sul serio, provare la metodologia Agile - che predica semplice, elegante, senza fronzoli, non-jazzy, approccio sensical comune in qualunque cosa tu faccia, in modo tale che ogni membro del team capisce e apprezza il ruolo e lo sforzo di tutti gli altri membri.

In bocca al lupo!

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top