Documenti IEEE SRS: versione leggera quando si lavora con appaltatori esterni?

L'opzione migliore è probabilmente quella di prendere un modello esistente o due (per l'acquisto - disponibile anche nelle appendici di Requisiti software ) o tre e personalizzarli. Rimuovi le sezioni che sono irrilevanti per le tue esigenze o aggiungi nuove sezioni che ti piacciono da un modello al resto di un altro modello. Unisci le sezioni se questo ha un senso. Se combinati, questi probabilmente coprirebbero ogni possibile tipo di domanda che potrebbe essere posta, è solo una questione di riempire i dettagli dove sono necessari.

La personalizzazione potrebbe non corrispondere ai modelli delle principali organizzazioni di standard, ma la personalizzazione è un componente chiave del miglioramento dei processi e dei programmi di implementazione. Non penso che qualcuno avrebbe un problema con un modello su misura, nella maggior parte dei casi. Per me, la rimozione esplicita delle sezioni rende un documento più gradevole e più leggibile rispetto al testo che dice "non si applica".

Per quanto riguarda la fornitura di specifiche, sarei titubante su ciò che viene fornito. Se fornirai input in un formato specificato, fornisci tale formato. Se un altro sistema consuma degli output, fornire il formato di output previsto. Questi potrebbero essere diagrammi ferroviari, schemi XML, mappe di layout di byte e qualsiasi input / output di esempio (sterilizzati, se necessario). Se stai specificando qualcosa che deve essere una sostituzione drop-in per un altro sistema, potrebbe essere anche necessario specificare l'interfaccia pubblica. Tuttavia, consiglierei di lasciare quanto più margine di manovra possibile allo sviluppatore per progettare e costruire un sistema in base alle tue esigenze.

Nelle mie esperienze, c'è spesso una separazione tra i requisiti del sistema e una descrizione dettagliata delle interfacce tra i componenti. Non penso che sia sempre necessario, però. La conformità a un'interfaccia specifica è, tecnicamente, un requisito di comunicazione o ambiente ("il sistema deve fornire output in XML conforme allo schema definito nel file di schema"). La separazione dei due è probabilmente più appropriata quando si descrive un sistema di componenti correlati piuttosto che un singolo componente, in cui direi che avere una risorsa unica e completa per quello che mi aspetto di produrre è meglio.

Suggerirei di avvicinarti a questo definendo solo ciò di cui hai bisogno da questo sistema, lasciando il più possibile allo sviluppatore. Se passi troppo tempo a fare le specifiche in modo tale che ci siano solo una o due soluzioni, allora hai svolto la maggior parte del lavoro intensivo (nella mia esperienza). Come sviluppatore, probabilmente conosci le domande che potresti porre se ti venisse presentato lo scopo generale del sistema che desideri - rispondi a quelli nel modo più chiaro e specifico possibile e speri che lo sviluppatore ti porti altre domande a cui potresti non aver pensato .

Sommario

Se è Agile, ci sono un paio di problemi da considerare. In primo luogo, SRS è un no-go in Agile, e in secondo luogo, l'IEEE non eseguirà il backup di alcun standard in quanto non si applicano qui.

User Story, non SRS

L'opzione migliore sarebbe riconsiderare la metodologia per qualcosa di simile a RUP , o per praticare correttamente Agile e beneficiare della sua soluzioni native ai problemi, ad esempio in agile, i requisiti sono specificati come User Story .

Metodologie agili

Considera Scrum , ad esempio. Tutte le storie vengono prima raggruppate in Product Backlog. Quindi, il Product Owner (tu) seleziona le storie che dovrebbero essere implementate nel prossimo sprint inserendole in Sprint Backlog. Infine, inizia l'iterazione e puoi vedere il grafico di Burndown per vedere come vengono implementate le storie.

Un'altra metodologia Agile consigliata è TDD o BDD dove è raffinato. Lo sviluppatore scrive per prima cosa test basati su user story e quindi codifica le parti interne effettive del software per superare i test.

Allo stesso modo, c'è Programmazione estrema , Crystal , DSDM e altre metodologie agili da considerare.

Processo software

Quando pratichi Agile, o qualsiasi altra metodologia, è imperativo che la particolare metodologia sia scelta bene e seguita con un certo rigore. Altrimenti, "stiamo usando Agile" diventa "stiamo usando un processo che non è riconosciuto formalmente e in realtà non siamo nemmeno sicuri del risultato, non sappiamo cosa stiamo facendo, ma iniziamo già a fare hacking"