Esposizione di un requisito relativo alle codifiche dei nomi dei file

Il requisito, come detto, è confuso per me.

La prima domanda che vorrei è: quante codifiche di caratteri devono essere supportate? Le possibili interpretazioni includono:

1. Ogni codifica mai ideata, incluso single-byte (ad esempio ISO-8859-15 ), multibyte (ad es. Big5 , Shift-JIS , HZ ) e rari / strani (ad esempio UTF-7 , Punycode , EBCDIC ).
2. Questo è ovviamente estremo. Che ne dici di solo il supporto minimo, vale a dire ISO-8859-1?
3. Solo ISO-8859-1 sembra assurdo. Che ne dici di solo il supporto delle moderne best practice, vale a dire Unicode come UTF-8 ?

Se non specifichi quali codifiche intendi, allora quando si verifica un bug specifico per la codifica, tu e l'implementatore potresti litigare e avresti entrambi ragione. Cioè, per definizione, la conseguenza di una specifica fuzzy.

Andando oltre, cosa deve fare il software con il nome del file, oltre a non bloccarsi? Dovrebbe ...

4. Mantieni il nome del file nella sua codifica originale, byte per byte?
5. Normalizza tutto su Unicode? In tal caso, è necessario rilevare automaticamente la codifica sorgente? Con quale meccanismo?
6. Memorizza sia il modulo Unicode che l'originale, nel caso in cui la normalizzazione fallisca?

Una versione migliore del tuo requisito sarebbe

The downloader must support filenames in various encodings, including at least ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312, and Big5. If the web server response specifies an encoding, it must be respected. (If the encoding is unspecified, ISO-8859-1 may be assumed, or a better guess may be made.) Filenames shall be normalized to a Unicode representation in the content management system.

Gli esempi specifici di codifiche richieste sono essenziali per definire i criteri di accettazione. Le frasi aggiunte indicano ciò che il software deve fare, oltre a non bloccarsi.

Il requisito che hai scritto non ha le caratteristiche di un buon requisito . In particolare, non è coeso, non è atomico e non è univoco. A causa della mancanza di queste caratteristiche, non è nemmeno facilmente verificabile.

Il tuo requisito di stato iniziale è:

The downloaded file name may contain non-ASCII characters and processing of this shall not crash the application

Suggerirei di rimuovere "... e l'elaborazione di questo non causerà il crash dell'applicazione". Se si ha la necessità che un pezzo di software debba fare qualcosa, penso che sia corretto supporre che dovrebbe farlo senza arrestare il software.

Questo trasforma il requisito in:

The downloaded file name may contain non-ASCII characters

Ora hai un requisito coesivo e atomico. Tuttavia, non sono sicuro che sia univoco. Nella tua domanda, menzioni un certo numero di formati diversi. Ci sono alcune opzioni.

Alcuni consiglierebbero un requisito separato e univoco per ogni codifica del nome di file che deve essere supportata. Ciò potrebbe meglio supportare requisiti coesi, atomici, tracciabili, non ambigui e verificabili. Inoltre, sarebbe più semplice specificare l'importanza di ciascun requisito: forse il supporto per alcune codifiche è più importante o necessario prima.

Altri potrebbero raccomandare una tabella di formati supportati e questo requisito si collegherebbe a una tabella. Sarebbe meno completo (hai una frase testuale e una tabella da mantenere), ma sarebbero nello stesso documento o database. Tuttavia, se si desidera eseguire il collegamento in uno strumento di gestione dei requisiti, potrebbero essere collegati tra loro in modo che le modifiche apportate a uno evidenzieranno il requisito collegato. Permetterebbe anche il flusso del testo verso altri pacchetti software così com'è, ma con una tabella diversa per le diverse codifiche.

Tuttavia, il modo in cui documenti i requisiti dipende dalle tue esigenze specifiche.

Ci sono un paio di problemi con la tua formulazione che indeboliscono il requisito:

1) Dovresti esprimere il requisito nei termini positivi , piuttosto che in termini di ciò che dovrebbe non fare . Come funziona un test per "non andare in crash".

2) La frase "Il nome del file scaricato può contenere ..." è vaga.

Una formulazione alternativa suggerita (puramente soggettiva, ovviamente) potrebbe essere:

L'applicazione deve supportare i nomi di file scaricati contenenti caratteri non ASCII.

(La parola "supporto" è ancora un po 'vaga e potrebbe essere modificata per essere più concreta se presa in concomitanza con altri requisiti della tua applicazione.)

Il problema con le specifiche come scritto è che non dice cosa l'applicazione dovrebbe fare con i nomi di file "interessanti". Ho incontrato un programma che sostituisce tutti i caratteri del nome del file che non ha capito con _ , con l'effetto che quando è stato chiesto di copiare una directory che conteneva due caratteri i cui nomi erano identici tranne nei caratteri che l'utilità non comprendeva, il secondo file scritto nella directory sovrascriverebbe il primo. Un comportamento del genere si qualifica come "non in crash", ma ciò non dovrebbe implicare che sia accettabile in assenza di una specifica esplicita che lo dica.

Suggerirei che una buona spec dovrebbe specificare in modo affermativo che cosa dovrebbe accadere, oppure annotare quali sono le linee d'azione accettabili, ad es. "Se il nome di un file contiene caratteri non riconosciuti, il sistema dovrebbe generare un nuovo GUID per l'operazione complessiva e generare un nome file che combini il GUID, un numero di indice e qualsiasi porzione del nome file originale che possa essere facilmente adattata; una tabella che mappa i nomi dei file vecchi e nuovi "o" Se un nome di file contiene caratteri non riconosciuti, il sistema può formare un nuovo nome concatenando i caratteri che riconosce, se due nomi di file finiscono per diventare identici attraverso tale trasformazione, uno può arbitrariamente essere dichiarato il "vincitore".