Quanto è necessario che le specifiche vengano scritte in caso di un nuovo progetto?

Come per tutto il software, dipende dalla complessità e dal contesto di un determinato progetto. Più sei legato ai rischi del successo del progetto, meglio ti sarà servito con chiare dichiarazioni di bisogno / intenzione e risultati ottenibili.

Sei un dipendente della gente / azienda che vuole che il progetto sia fatto? Se è così, avere un approccio iterativo senza una specifica chiara è accettabile.

Stai lavorando a un'offerta a prezzo fisso? Avere una specifica chiara è MOLTO importante qui.

Tutto il resto è nel mezzo. Nel tuo caso specifico potrebbe essere preferibile disporre almeno quello che vuoi ottenere. Se c'è una matita UI, disegna. Se ci sono interazioni, come per un gioco, definisci le regole di base. Pensa e magari prototipa alcuni dei tuoi modelli di dati. Come singolo sviluppatore puoi fare un lungo cammino senza un design formale, ma quando inizi a coinvolgere le persone, avere una chiara architettura di base e alcune linee guida di progettazione sono una buona idea. Come sta revisionando il codice fornito.

Come @ Tracker1 ha già menzionato it depends .

La cosa più importante è gestire le aspettative. Lasciami spiegare ...

In un progetto software standard segui una sorta di procedura del ciclo di vita del software . I passaggi o le fasi principali sono: raccolta dei requisiti, pianificazione, sviluppo, manutenzione e obsoleto.

In tutti questi passaggi ci sono coinvolti i portatori di interesse e sono le loro aspettative che determinano cosa devi fare e quanto dettagliato e in che misura devi documentare ogni fase del processo e quali passaggi sono necessari.

Questo include ciò che chiamate specifiche, ma ciò che è più comunemente noto come requisiti. Dai requisiti seguono l'architettura e il design del software.

È importante scoprire le aspettative dei tuoi stakeholder. Queste sono le persone che useranno il software; che pagheranno per lo sviluppo del software; che dovrà commercializzare e vendere il software; QA (Quality Assurance) sarà interessato alla sicurezza e agli aspetti normativi del tuo software; il reparto IT sarà interessato a quali hardware, pacchetti software e ambiente di sviluppo si desidera utilizzare, ecc.

Al di fuori di queste aspettative dovrebbe venire un "contratto" che registra i requisiti e come verificare che i requisiti siano stati soddisfatti. Questo può variare da un semplice documento di una pagina a un gran numero di lunghi documenti che inchiodano ogni possibile dettaglio.

Questo 'contratto' è molto importante per prevenire discussioni e discussioni in una fase successiva. Elenca ciò che è incluso e, molto importante, ciò che non è incluso e ciò che è necessario per il successo del progetto. Elenca inoltre le responsabilità di ciascuna parte coinvolta. Dovrebbe anche includere un periodo di tempo e un budget (non solo denaro ma anche risorse).

Dove lavoro, realizziamo dispositivi medici contenenti software medico, quindi abbiamo regole molto rigide su ciò che dobbiamo fare e su ciò che dobbiamo documentare.

Ad esempio, se vogliamo vendere i nostri prodotti negli Stati Uniti, dobbiamo rispettare IEC 652304 . Siamo controllati dalla FDA ogni pochi anni per assicurarci di fare effettivamente ciò che diciamo di fare; -)