Formulation d'une exigence concernant les encodages de nom de fichier

Je suis en train de rédiger une spécification des exigences et j'ai un dilemme à formuler une partie des exigences.

Scénario: Nous téléchargeons des fichiers à partir d'un site Web et les fichiers téléchargés doivent être joints à un élément dans l'outil CM que nous avons. Les fichiers téléchargés contiennent des noms qui peuvent être ASCII, ISO-8859-1, japonais, etc.

Dans le libellé ci-dessous, "non-ASCII" couvre-t-il toutes les situations?

Le nom du fichier téléchargé peut contenir des caractères non ASCII et le traitement de celui-ci ne fera pas planter l'application

Comme je l'ai dit, l'exigence est floue pour moi.

Ma première question est la suivante: combien de codages de caractères doivent être pris en charge? Les interprétations possibles incluent:

1. Chaque encodage jamais conçu, y compris un octet (par exemple ISO-8859-15 ), multi-octets (par exemple Big5 , Shift-JIS , HZ ) et rares / étranges (par exemple UTF-7 , Punycode , EBCDIC ).
2. C'est évidemment extrême. Que diriez -vous du support minimum, à savoir ISO-8859-1?
3. La norme ISO-8859-1 semble vraiment difficile. Que diriez-vous de simplement prendre en charge les meilleures pratiques modernes, à savoir Unicode en UTF-8 ?

Si vous ne spécifiez pas les encodages que vous voulez dire, alors lorsqu'un bogue spécifique à l'encodage se produit, vous et l'implémentateur pourriez vous battre et vous auriez tous les deux raison. C'est, par définition, la conséquence d'une spécification floue.

Pour aller plus loin, qu'est-ce que le logiciel doit faire avec le nom de fichier, en plus de ne pas planter? Devrait-il…

4. Conserver le nom de fichier dans son encodage d'origine, octet par octet?
5. Normaliser tout en Unicode? Si oui, doit-il détecter automatiquement l'encodage source? Par quel mécanisme?
6. Stockez à la fois le formulaire Unicode et l'original, juste au cas où la normalisation échouerait?

Une meilleure version de votre exigence serait

Le téléchargeur doit prendre en charge les noms de fichiers dans divers encodages, y compris au moins ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 et Big5. Si la réponse du serveur Web spécifie un encodage, il doit être respecté. (Si le codage n'est pas spécifié, ISO-8859-1 peut être supposé, ou une meilleure estimation peut être faite.) Les noms de fichiers doivent être normalisés en une représentation Unicode dans le système de gestion de contenu.

Les exemples spécifiques de codages requis sont essentiels pour élaborer des critères d'acceptation. Les phrases ajoutées indiquent ce que le logiciel doit faire, au-delà de ne pas planter.

L'exigence que vous avez écrite n'a pas les caractéristiques d'une bonne exigence . Plus précisément, ce n'est pas cohérent, ce n'est pas atomique et ce n'est pas sans ambiguïté. En raison de l'absence de ces caractéristiques, ce n'est pas non plus facilement vérifiable.

Votre condition d'état initiale est:

Le nom du fichier téléchargé peut contenir des caractères non ASCII et le traitement de celui-ci ne fera pas planter l'application

Je recommanderais de supprimer le "... et le traitement de cela ne plantera pas l'application". Si vous avez besoin qu'un logiciel doive faire quelque chose, je pense que c'est OK de faire l'hypothèse qu'il devrait le faire sans planter le logiciel.

Cela transforme l'exigence en:

Le nom du fichier téléchargé peut contenir des caractères non ASCII

Maintenant, vous avez une exigence cohérente et atomique. Cependant, je ne suis pas sûr que ce soit sans ambiguïté. Dans votre question, vous mentionnez un certain nombre de formats différents. Il y a quelques options.

Certains recommanderaient une exigence distincte et unique pour chaque codage de nom de fichier qui doit être pris en charge. Cela prendrait le mieux en charge des exigences cohésives, atomiques, traçables, non ambiguës et vérifiables. Il serait également plus facile de spécifier l'importance de chaque exigence - peut-être que la prise en charge de certains encodages est plus importante ou nécessaire plus tôt.

D'autres peuvent recommander un tableau des formats pris en charge et cette exigence serait liée à un tableau. Ce serait moins complet (vous avez une phrase textuelle et un tableau à maintenir), mais ils seraient dans le même document ou la même base de données. Toutefois, si vous deviez effectuer une liaison dans un outil de gestion des exigences, elles pourraient être liées entre elles afin que les modifications apportées à l'une mettent en évidence l'exigence liée. Cela permettrait également au texte de circuler vers d'autres progiciels tels quels, mais avec un tableau différent pour différents encodages.

Cependant, la façon dont vous documentez les exigences dépend de vos besoins spécifiques.

Il y a quelques problèmes avec votre formulation qui affaiblissent l'exigence:

1) Vous devez exprimer l'exigence en termes positifs plutôt qu'en termes de ce qu'elle ne devrait pas faire . Comment peut-on tester pour "ne pas planter".

2) L'expression "Le nom du fichier téléchargé peut contenir ..." est vague.

Une formulation alternative suggérée (purement subjective, bien sûr) pourrait être:

L'application doit prendre en charge les noms de fichiers téléchargés contenant des caractères non ASCII.

(Le mot «support» est encore un peu vague et pourrait être modifié pour être plus concret lorsqu'il est utilisé de concert avec d'autres exigences pour votre application.)

Le problème avec la spécification telle qu'elle est écrite est qu'elle ne dit pas ce que l'application doit faire avec les noms de fichiers "intéressants". J'ai rencontré un programme qui remplacerait tous les caractères de nom de fichier avec lesquels il ne comprenait pas _, avec pour effet que lorsqu'on lui a demandé de copier un répertoire contenant deux caractères dont les noms étaient identiques, sauf dans les caractères que l'utilitaire ne comprenait pas, le deuxième fichier écrit dans le répertoire écraserait le premier. Un tel comportement serait qualifié de "ne pas planter", mais cela ne devrait pas impliquer qu'il est acceptable en l'absence d'une spécification explicite le disant.

Je suggérerais qu'une bonne spécification devrait spécifier de manière affirmative ce qui devrait se produire, ou bien noter quels plans d'action sont acceptables, par exemple "Si un nom de fichier contient des caractères non reconnus, le système devrait générer un nouveau GUID pour l'opération globale, et générer un nom de fichier qui combine ce GUID, un numéro d'index et toute partie du nom de fichier d'origine qui peut être facilement hébergée; il doit produire un tableau mappant les anciens et les nouveaux noms de fichiers "ou" Si un nom de fichier contient des caractères non reconnus, le système peut former un nouveau nom en concaténant les caractères qu'il reconnaît; si deux noms de fichiers finissent par devenir identiques par une telle transformation, l'un ou l'autre peut être arbitrairement déclaré "gagnant" ".