Сформулювання вимоги щодо кодування імені файлів

Я зараз складаю специфікацію вимог, і у мене виникає дилема в тому, щоб сформулювати частину вимог.

Сценарій: ми завантажуємо файли з веб-сайту, і завантажені файли потрібно приєднати до елемента інструменту 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. Збережіть ім'я файлу в його первісному кодуванні, байт за байтом?
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, номер індексу та будь-яку частину оригінального імені файлу, яка може бути легко розміщена; вона повинна створювати таблицю, що відображає старі та нові імена файлів "або" Якщо ім'я файлу містить нерозпізнані символи, система може сформувати новий ім'я, об'єднуючи символи, які він розпізнає; якщо два імена файлів у результаті стануть однаковими через таке перетворення, будь-яке може бути довільно оголошено "переможцем" ".