Określanie wymagań dotyczących kodowania nazw plików

Jestem w trakcie pisania specyfikacji wymagań i mam dylemat w sformułowaniu fragmentu wymagań.

Scenariusz: pobieramy pliki ze strony internetowej, a pobrane pliki należy dołączyć do elementu w posiadanym przez nas narzędziu CM. Pobrane pliki zawierają nazwy, które mogą być ASCII, ISO-8859-1, japoński itp.

Czy w sformułowaniu poniżej „nie-ASCII” obejmuje wszystkie sytuacje?

Pobrana nazwa pliku może zawierać znaki spoza ASCII, a przetwarzanie tego nie spowoduje awarii aplikacji

Wymóg, jak stwierdzono, jest dla mnie niewyraźny.

Moje pierwsze pytanie brzmiałoby: ile kodowań znaków wymaga obsługi? Możliwe interpretacje obejmują:

1. Każde kodowanie, jakie kiedykolwiek opracowano, w tym jednobajtowe (np. ISO-8859-15 ), wielobajtowe (np. Big5 , Shift-JIS , HZ ) i rzadkie / dziwne (np. UTF-7 , Punycode , EBCDIC ).
2. To oczywiście ekstremalne. Co powiesz na minimalne wsparcie, a mianowicie ISO-8859-1?
3. Tylko ISO-8859-1 wydaje się łasica. A może po prostu wesprzeć nowoczesne najlepsze praktyki, a mianowicie Unicode jako UTF-8 ?

Jeśli nie określisz, jakie kodowanie masz na myśli, wtedy, gdy wystąpi błąd specyficzny dla kodowania, ty i implementator moglibyście walczyć i oboje mielibyście rację. Jest to z definicji konsekwencja rozmytej specyfikacji.

Idąc dalej, co oprogramowanie musi zrobić z nazwą pliku, oprócz awarii? Czy to…

4. Czy zachować nazwę pliku w oryginalnym kodowaniu, bajt po bajcie?
5. Znormalizować wszystko do Unicode? Jeśli tak, to czy musi automatycznie wykrywać kodowanie źródłowe? Według jakiego mechanizmu?
6. Przechowywać zarówno formularz Unicode, jak i oryginał, na wypadek niepowodzenia normalizacji?

Lepsza wersja twojego wymagania byłaby

Program pobierający musi obsługiwać nazwy plików w różnych kodowaniach, w tym co najmniej ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 i Big5. Jeśli odpowiedź serwera WWW określa kodowanie, należy go przestrzegać. (Jeśli kodowanie jest nieokreślone, można założyć ISO-8859-1 lub można lepiej zgadywać.) Nazwy plików należy znormalizować do reprezentacji Unicode w systemie zarządzania treścią.

Konkretne przykłady wymaganych kodowań są niezbędne do opracowania kryteriów akceptacji. Dodane zdania określają, co oprogramowanie musi zrobić, nie powodując awarii.

Wymóg, który napisałeś, nie ma cech dobrego wymagania . W szczególności nie jest spójny, nie jest atomowy i nie jest jednoznaczny. Z powodu braku tych cech nie jest to również łatwe do zweryfikowania.

Wymagany stan początkowy to:

Pobrana nazwa pliku może zawierać znaki spoza ASCII, a przetwarzanie tego nie spowoduje awarii aplikacji

Polecam usunięcie „... a przetwarzanie tego nie spowoduje awarii aplikacji”. Jeśli masz wymaganie, że oprogramowanie musi coś zrobić, myślę, że można założyć, że powinno to robić bez awarii oprogramowania.

Przekształca to wymaganie w:

Pobrana nazwa pliku może zawierać znaki inne niż ASCII

Teraz masz spójny i atomowy wymóg. Nie jestem jednak pewien, czy jest to jednoznaczne. W swoim pytaniu wymieniasz wiele różnych formatów. Istnieje kilka opcji.

Niektórzy zalecają osobne i unikalne wymagania dla każdego kodowania nazw plików, które muszą być obsługiwane. To najlepiej wspiera spójne, atomowe, identyfikowalne, jednoznaczne i weryfikowalne wymagania. Ułatwiłoby to również określenie znaczenia każdego wymagania - być może obsługa niektórych kodowań jest ważniejsza lub potrzebna wcześniej.

Inni mogą zalecić tabelę obsługiwanych formatów, a wymaganie to prowadzi do tabeli. Byłoby to mniej kompletne (masz zdanie tekstowe i tabelę do utrzymania), ale byłyby w tym samym dokumencie lub bazie danych. Jeśli jednak zamierzasz wykonać łączenie w narzędziu do zarządzania wymaganiami, można je połączyć ze sobą, aby zmiany w jednym z nich uwypukliły powiązane wymaganie. Pozwoliłoby to również na przepływ tekstu do innych pakietów oprogramowania, ale jest z inną tabelą dla różnych kodowań.

Sposób dokumentowania wymagań zależy jednak od konkretnych potrzeb.

Istnieje kilka problemów z twoim sformułowaniem, które osłabiają wymóg:

1) Powinieneś wyrazić wymóg w kategoriach pozytywnych , a nie w kategoriach tego, czego nie powinien robić . Jak sprawdza się test „nie upaść”.

2) Wyrażenie „Nazwa pobranego pliku może zawierać ...” jest niejasne.

Sugerowane alternatywne sformułowanie (oczywiście subiektywne) może być:

Aplikacja obsługuje pobrane nazwy plików zawierające znaki spoza ASCII.

(Słowo „wsparcie” jest wciąż nieco niejasne i można je zmienić, aby było bardziej konkretne, jeśli zostanie ono uwzględnione w połączeniu z innymi wymaganiami dotyczącymi aplikacji.)

Problem z zapisaną specyfikacją polega na tym, że nie mówi ona, co aplikacja powinna zrobić z „interesującymi” nazwami plików. Zetknąłem się z jednym programem, który zastąpiłby dowolne znaki nazwy pliku, których nie rozumiał _, z takim skutkiem, że gdy poproszono o skopiowanie katalogu zawierającego dwa znaki o identycznych nazwach, z wyjątkiem znaków, których narzędzie nie rozumiało, drugi plik zapisany w katalogu zastąpiłby pierwszy. Takie zachowanie kwalifikowałoby się jako „nie upaść”, ale nie powinno to oznaczać, że jest to dopuszczalne bez wyraźnej specyfikacji.

Sugerowałbym, że dobra specyfikacja powinna twierdząco określać, co powinno się stać, lub też zauważyć, jakie działania są dopuszczalne, np. „Jeśli nazwa pliku zawiera nierozpoznane znaki, system powinien wygenerować nowy identyfikator GUID dla całej operacji i wygenerować nazwę pliku który łączy ten identyfikator GUID, numer indeksu i dowolną część oryginalnej nazwy pliku, którą można łatwo pomieścić; powinien utworzyć tabelę odwzorowującą stare i nowe nazwy plików ”lub„ Jeśli nazwa pliku zawiera nierozpoznane znaki, system może utworzyć nowy nazwa poprzez połączenie rozpoznawanych znaków; jeśli dwie nazwy plików w wyniku takiej transformacji staną się identyczne, każdą z nich można dowolnie uznać za „zwycięzcę”.