Devo usare il tempo futuro o presente quando scrivo un documento di progettazione?

Dipende da cosa stai scrivendo.

Se stai scrivendo dei requisiti, la risposta è "nessuno dei due". Un'altra domanda qui su Ingegneria del software si rivolge al uso di "deve" e "deve" quando si scrivono i requisiti . La guida che uso al lavoro è che "deve" è utilizzato per indicare eventuali requisiti che devono essere soddisfatti affinché il software sia accettabile per il cliente, "dovrebbe" contrassegnare le caratteristiche desiderate, "può" essere utilizzato per identificare qualsiasi cosa che sia facoltativo, e "will" è tutto ciò su cui si può fare affidamento dopo l'implementazione delle caratteristiche obbligatorie e di quelle desiderate o facoltative. Se non stai scrivendo i tuoi requisiti come dichiarazioni, ma utilizzando casi d'uso o storie utente , ti consigliamo di seguire le convenzioni di quel formato.

Se stai scrivendo sul software che esiste già, dovresti usare il tempo presente. Il software esiste già, quindi "è" qualcosa o "fa" qualcosa.

Se stai cercando di definire i requisiti e documentare un approccio progettuale allo stesso tempo, ti consiglio di non farlo e di capire il valore della separazione tra le funzioni che il software deve esporre e gli attributi non funzionali del software rispetto alla documentazione come si decompone il software o come utilizzare il software. La separazione dei requisiti, la progettazione tecnica e l'utilizzo (manuali dell'utente) è molto importante.

Per rispondere alle tue esigenze specifiche, penso che la cosa migliore da fare sia chiedere al tuo istruttore di corso o a qualcun altro che capisca cosa stanno cercando. Nelle mie esperienze, questo tipo di documento non esiste in nessuna forma di moderno sviluppo del software, quindi chiedere ai tecnici del software professionisti come produrre un documento che è accettabile per il proprio cliente particolare (in questo caso, il tuo professore o selezionatore) non ottenere le risposte migliori, soprattutto perché non penso che la risposta di "non farlo, non è una buona pratica, guarda invece la tua metodologia di sviluppo e l'approccio" ti porterà molto lontano nel corso.

A detailed ‘design specification’ based on the requirements specification. The completed design specification should be comprehensive and should allow a third party to use your design specification as the basis for implementation. It therefore should be clear, concise and detailed. It may contain: a navigation map to clearly show how you propose how to link various pages or screens; a series of detailed storyboards to illustrate page layout, colour schemes, typography (fonts, sizes, styling, alignment), use of media elements (eg icons, graphics, sound, video, animation) or interaction styles. Justification of design decisions should also be present.

La specifica dei requisiti è la base per l'implementazione del software, da parte di un team interno o esterno. Non dovrebbe avere solo le caratteristiche funzionali, ma i vincoli di progettazione, le prestazioni e altri attributi di qualità, le caratteristiche dell'utente, le interfacce richieste e così via. La specifica dei requisiti è l'accordo tra il cliente e il fornitore del software.

Ciò che ti viene detto di inserire nel documento è in effetti una informazione di progettazione. Tuttavia, è coerente con gli "grandi progetti in anticipo" approcci allo sviluppo del software in cui non scrivi il codice finché non hai "finito" "il tuo design. Tuttavia, non sono a conoscenza di molte organizzazioni che adottano questo approccio.

Non importa

È il contenuto della specifica che è importante, non la presentazione - e la "presentazione" include cose come il linguaggio. L'eccezione qui è che se la presentazione è così cattiva i lettori sono ostacolati in modo significativo nella loro comprensione del contenuto, ma il presente o il tempo futuro non causerà questo tipo di problema.

Tieni in considerazione se il documento verrà letto dopo che il software è stato completato!

Se stai scrivendo una proposta che descrive cosa vuoi costruire, allora il tempo futuro è Ok.

Se vuoi scrivere una documentazione di progettazione che verrà mantenuta durante la vita del tuo software, allora il tempo futuro non ha senso e dovresti usare il tempo presente. Dopo tutto, il documento descriverà come è progettato il tuo software .

La coerenza è probabilmente la preoccupazione principale.

Per motivi di accuratezza, se la documentazione riguarda un sistema esistente, eventualmente uno potenziato, il tempo presente. Se il sistema non esiste ancora, allora il tempo futuro, dal momento che stai descrivendo qualcosa che accadrà (si spera), ma non lo ha ancora fatto.

Una cosa da considerare è che questi documenti spesso portano alla generazione di alcuni dei casi di test. In questo senso è meglio usare il tempo futuro, che verrà poi confermato nei test. Ogni "volontà" o "deve" nei requisiti è qualcosa che può essere testato e confermato. "fa" o "è" implica il completamento precedente e quindi qualcosa che non ha bisogno di essere testato.

Modifica, per coloro che non amano la prospettiva di coerenza:

In un mondo di sviluppo che si allontana sempre più dalla progettazione rigorosa, dai requisiti e dai documenti di test, la coerenza e la leggibilità del documento sono importanti. E poiché questi documenti hanno meno probabilità di essere l'unico riferimento per il completamento / correttezza, la scelta tra tempo presente e futuro è molto meno importante.

Per un progetto che continuerà ad utilizzare un rigoroso processo di documentazione, la precisione e l'accuratezza del testo (e la relativa applicazione coerente) sono fondamentali.