In una specifica, dovrei descrivere cosa fa un prodotto (idealmente) o cosa dovrebbe / deve fare?

Questo flusso di eventi è molto simile a quello con cui lavoro. Tuttavia, ci sono differenze nella terminologia che ritengo possano causare alcuni problemi.

Ciò che fornisce il cliente non è un documento dei requisiti. È probabile che sia un documento di visione o un concetto di operazioni (CONOPS) . Questi documenti potrebbero richiamare le principali caratteristiche del sistema, ma sono scritti dal punto di vista del cliente o dell'utente, però, e tendono a non essere come tecnici (anche se potrebbero essere se provengono da un cliente o utente tecnico) o inequivocabile come un ingegnere progettista o un ingegnere dell'assicurazione della qualità deve svolgere il proprio lavoro.

Spesso, questi documenti tendono a descrivere gli obiettivi del cliente per il sistema - come intendono usarlo, cosa vogliono realizzare, e così via, ma nel loro linguaggio commerciale, usando terminologia e concetti di business. È probabile che questo tipo di contenuto non sia adatto agli ingegneri che costruiscono e progettano il sistema, quindi è necessario trasformarlo.

Gli ingegneri prenderanno gli input del cliente di un documento di visione o CONOPS (quello che stai chiamando un documento dei requisiti) e creeranno una specifica dei requisiti . Si tratta di una dichiarazione formale dei requisiti funzionali e non funzionali, degli standard di qualità, di eventuali vincoli di progettazione e dei casi d'uso in un modo che possa essere compreso dal resto del progetto. implementazione e test team. Indipendentemente dalla struttura e dal formato dell'input del cliente, i requisiti documentati nella specifica devono avere le caratteristiche di un buon requisito:

• Ogni requisito riguarda una cosa (coesiva)
• Ogni requisito è dichiarato in una posizione (completa)
• Non ci sono contraddizioni tra i requisiti o tra un requisito e un documento esterno (coerente)
• Ogni requisito non contiene congiunzioni, come "e" (atomico)
• Ogni requisito può essere collegato a un'esigenza aziendale di uno o più stakeholder (tracciabile)
• Ogni requisito non è obsoleto (corrente)
• Ogni requisito è chiaro, gli acronimi sono definiti, è oggettivo, evita dichiarazioni negative (non ambigue)
• Ogni requisito chiarisce la sua importanza
• L'implementazione di ciascun requisito può essere determinata mediante ispezione, dimostrazione, test e / o analisi (verificabile)

Questo documento è la specifica dei requisiti per il prodotto. Indica esattamente cosa deve essere in grado di fare il prodotto, quando è finito. Se si dispone di requisiti opzionali, questi sono chiaramente identificati come facoltativi e indicano cosa dovrebbe o potrebbe fare il progetto. Qui è dove nasce l'idea di scrivere requisiti come "deve". I requisiti facoltativi sostituiscono "devono" con "può" o "possono", e il significato di "deve", "può" e "può" deve essere definito nel documento in modo che i progettisti, gli esecutori e i tester conoscano il parente importanza di ciascun requisito.

Definendo esattamente come deve comportarsi il prodotto, stai essenzialmente fornendo istruzioni per i progettisti, i tester e (in parte) gli implementatori. Stanno iniziando con un sistema che non ha ancora raggiunto tutte le cose e viene detto loro che cosa farà quando verrà completato. La progettazione e l'implementazione possono essere confrontate (in vari modi) con queste specifiche per garantire che siano pienamente conformi a ciò che il cliente intende.

Ognuno ha il proprio stile e, alla fine, è meglio "ballare con quello che ti ha portato", (fai quello che la persona che ti paga dice di fare).

Detto questo, penso che sia tutta una questione di livelli di astrazione e di pubblico. Supponiamo che questo sia un progetto di chip. La risposta che segue si applicherà ugualmente bene al software con gli esempi specifici modificati per soddisfare il vocabolario e il contesto del giorno. OK, torna ai livelli di astrazione.

È necessario utilizzare dichiarazioni "must" quando si specifica un vincolo per i progettisti del sistema e i tecnici di verifica / prova. Di conseguenza, potresti vedere quanto segue in una specifica:

The SRAM buffer will have a throughput of at least 8 Mbits per second, and must be implemented using 9 nm CMOS technology compatible with the TSMC fab.

Tradotto, lo scrittore delle specifiche ha scritto sulla parte del progetto in cui ci si aspetta che il progettista eserciti la sua creatività / mestiere (il rendimento del buffer), in termini più rilassati di quelli usati per il processo di fabbricazione in cui non c'è Wiggle Room.