Формулировка требования о кодировке имени файла

Я нахожусь в процессе написания спецификации требований, и у меня возникла дилемма в формулировке части требований.

Сценарий: мы загружаем файлы с веб-сайта, и загруженные файлы необходимо прикрепить к элементу в имеющемся у нас инструменте CM. Загруженные файлы содержат имена, которые могут быть ASCII, ISO-8859-1, японский и т. Д.

В приведенной ниже фразе «не ASCII» охватывает все ситуации?

Загруженное имя файла может содержать не-ASCII-символы, и его обработка не должна приводить к сбою приложения.

Требование, как указано, для меня нечетко.

Первый вопрос, который у меня возникнет: сколько кодировок необходимо поддерживать? Возможные интерпретации включают в себя:

1. Все когда-либо разработанные кодировки, включая однобайтовые (например, ISO-8859-15 ), многобайтовые (например, Big5 , Shift-JIS , HZ ) и редкие / странные (например, UTF-7 , Punycode , EBCDIC ).
2. Это явно экстрим. Как насчет минимальной поддержки, а именно ISO-8859-1?
3. Просто ISO-8859-1 кажется ласковым. Как насчет поддержки современных лучших практик, а именно Unicode как UTF-8 ?

Если вы не укажете, какую кодировку вы имеете в виду, то при возникновении ошибки, связанной с кодировкой, вы и разработчик можете сразиться, и вы оба будете правы. Это, по определению, следствие нечеткой спецификации.

В дальнейшем, что программное обеспечение должно делать с именем файла, кроме того, чтобы не зависать? Если это ...

4. Сохранить имя файла в исходной кодировке, byte-by-byte?
5. Нормализовать все для Unicode? Если да, нужно ли автоматически определять кодировку источника? По какому механизму?
6. Сохранить как форму Unicode, так и оригинал, на случай, если нормализация не удалась?

Лучшая версия вашего требования будет

Загрузчик должен поддерживать имена файлов в различных кодировках, включая, по крайней мере, ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 и Big5. Если в ответе веб-сервера указана кодировка, его необходимо соблюдать. (Если кодировка не указана, можно предположить ISO-8859-1 или сделать более правильное предположение.) Имена файлов должны быть нормализованы к представлению Unicode в системе управления контентом.

Конкретные примеры требуемых кодировок необходимы для разработки критериев приемлемости. В добавленных предложениях указывается, что нужно сделать программному обеспечению, кроме того, чтобы не дать сбой.

Написанное вами требование не имеет характеристик хорошего требования . В частности, это не связно, не атомарно и не однозначно. Из-за отсутствия этих характеристик это также нелегко проверить.

Ваше начальное требование к состоянию:

Загруженное имя файла может содержать не-ASCII-символы, и его обработка не должна приводить к сбою приложения.

Я бы порекомендовал удалить «... и обработка этого не приведет к сбою приложения». Если у вас есть требование, чтобы какое-то программное обеспечение должно было что-то делать, я думаю, можно предположить, что оно должно делать это без сбоя программного обеспечения.

Это преобразует требование в:

Имя загруженного файла может содержать символы не ASCII

Теперь у вас есть связное и атомарное требование. Однако я не уверен, что это однозначно. В своем вопросе вы упоминаете ряд различных форматов. Есть несколько вариантов.

Некоторые рекомендуют отдельное и уникальное требование для каждой кодировки имени файла, которая должна поддерживаться. Это наилучшим образом соответствует связным, атомарным, прослеживаемым, однозначным и проверяемым требованиям. Это также облегчило бы определение важности каждого требования - возможно, поддержка некоторых кодировок более важна или необходима раньше.

Другие могут рекомендовать таблицу поддерживаемых форматов, и это требование будет ссылаться на таблицу. Он будет менее полным (у вас есть текстовое предложение и таблица, которую нужно сохранить), но они будут в одном документе или базе данных. Однако, если вы собираетесь выполнить связывание в инструменте управления требованиями, их можно связать вместе, чтобы изменения в одном из них выдвинули на первый план связанное требование. Это также позволило бы передавать текст другим пакетам программного обеспечения, как есть, но с другой таблицей для разных кодировок.

Однако то, как вы документируете требования, зависит от ваших конкретных потребностей.

Есть несколько проблем с вашей формулировкой, которые ослабляют требование:

1) Вы должны выразить требование в положительном выражении, а не в терминах того, что оно не должно делать . Как сделать один тест на «не сбой».

2) Фраза «Имя загруженного файла может содержать ...» расплывчата.

Предлагаемая альтернативная формулировка (сугубо субъективная, конечно) может быть:

Приложение должно поддерживать загруженные имена файлов, содержащие не-ASCII символы.

(Слово «поддержка» все еще немного расплывчато и может быть изменено, чтобы быть более конкретным, если принимать его вместе с другими требованиями для вашего приложения.)

Проблема со спецификацией в том виде, в котором она написана, в том, что она не говорит, что приложение должно делать с «интересными» именами файлов. Я столкнулся с одной программой, которая заменила бы любые символы имени файла, которые он не понимал _, с тем эффектом, что когда его попросили скопировать каталог, который содержал два символа, имена которых были идентичны, за исключением символов, которые утилита не понимала, второй файл записанный в каталог перезаписал бы первый. Такое поведение будет квалифицироваться как «не сбой», но это не должно означать, что это допустимо при отсутствии явной спецификации, в которой говорится об этом.

Я хотел бы предложить, чтобы в хорошей спецификации было указано, что должно произойти, или отметьте, какие действия допустимы, например: «Если имя файла содержит нераспознанные символы, система должна сгенерировать новый GUID для всей операции и сгенерировать имя файла который объединяет этот GUID, порядковый номер и любую часть исходного имени файла, которую можно легко разместить; он должен создать таблицу, отображающую старые и новые имена файлов »или« Если имя файла содержит нераспознанные символы, система может сформировать новый имя путем объединения символов, которые он распознает; если в результате такого преобразования два имени файла оказываются идентичными, любое из них может быть произвольно объявлено «победителем» ».