ファイル名のエンコーディングに関する要件のフレージング

私は要件の仕様を作成していますが、要件の一部をフレージングすることにはジレンマがあります。

シナリオ：Webサイトからファイルをダウンロードし、ダウンロードしたファイルを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を含むさまざまなエンコーディングのファイル名をサポートする必要があります。Webサーバーの応答でエンコードが指定されている場合は、それを尊重する必要があります。（エンコードが指定されていない場合、ISO-8859-1が想定されるか、より適切な推測が行われる可能性があります。）ファイル名は、コンテンツ管理システムでUnicode表現に正規化されます。

必要なエンコーディングの特定の例は、受け入れ基準を考案するために不可欠です。追加された文は、クラッシュしないことを超えて、ソフトウェアが何をする必要があるかを述べています。

あなたが書いた要件には良い要件の特徴がありません。具体的には、それはまとまりがなく、アトミックでもなく、明確でもありません。これらの特性がないため、簡単に検証することもできません。

初期状態の要件は次のとおりです。

ダウンロードしたファイル名には非ASCII文字が含まれている可能性があり、これを処理してもアプリケーションがクラッシュすることはありません

「...そしてこの処理はアプリケーションをクラッシュさせない」を削除することをお勧めします。あるソフトウェアが何かをする必要があるという要件がある場合、ソフトウェアをクラッシュさせることなくそれを行うべきであるという仮定を立てることは問題ないと思います。

これにより、要件は次のように変換されます。

ダウンロードしたファイル名に非ASCII文字が含まれている可能性があります

さて、あなたはまとまりがありアトミックな要件を持っています。しかし、それが明確であることは確かではありません。あなたの質問では、いくつかの異なる形式に言及しています。いくつかのオプションがあります。

一部の人は、サポートする必要のある各ファイル名エンコーディングに対して個別の固有の要件を推奨します。これは、まとまりのある、アトミックな、追跡可能な、明確な、検証可能な要件を最もよくサポートします。また、各要件の重要性を指定しやすくなります。おそらく、一部のエンコーディングのサポートはより重要であるか、より早く必要になります。

他の人は、サポートされている形式の表を推奨する場合があり、この要件は表にリンクします。完成度は低くなりますが（テキスト文とメンテナンスするテーブルがあります）、それらは同じドキュメントまたはデータベースにあります。ただし、要件管理ツールでリンクを実行する場合は、それらをリンクして、1つの変更がリンクされた要件を強調するようにすることができます。また、テキストを他のソフトウェアパッケージにそのまま流し込むこともできますが、エンコーディングが異なるとテーブルも異なります。

ただし、要件を文書化する方法は、特定のニーズによって異なります。

文言には、要件を弱める問題がいくつかあります。

1）してはならないことではなく、肯定的な言葉で要件を表現する必要があります。「クラッシュしない」ことをどのようにテストしますか。

2）「ダウンロードしたファイル名に... が含まれている可能性があります」というフレーズはあいまいです。

推奨される代替の文言（もちろん主観的なもの）は次のとおりです。

アプリケーションは、非ASCII文字を含むダウンロードされたファイル名をサポートするものとします。

（「サポート」という言葉はまだ少しあいまいであり、アプリケーションの他の要件と合わせてより具体的になるように変更することができます。）

書かれた仕様の問題は、アプリケーションが「興味深い」ファイル名で何をすべきかを言っていないことです。私は理解できないファイル名文字を置き換える_ユーティリティに遭遇しました。ユーティリティが理解できない文字を除いて同じ名前の2文字を含むディレクトリをコピーするように求められたときに、2番目のファイルディレクトリに書き込まれると、最初のものが上書きされます。そのような振る舞いは「クラッシュしない」とみなされますが、そういう明示的な仕様がなければ受け入れられるという意味ではありません。

良い仕様では、何が起こるかを肯定的に指定するか、たとえば、「認識できない文字がファイル名に含まれている場合、システムは操作全体の新しいGUIDを生成し、ファイル名を生成する必要があります」そのGUID、インデックス番号、および容易に対応できる元のファイル名の一部を組み合わせます。古いファイル名と新しいファイル名をマッピングするテーブルを作成する必要があります」または「ファイル名に認識できない文字が含まれている場合、システムは新しい認識される文字を連結することで名前を付けます。2つのファイル名がそのような変換によって最終的に同一になった場合、どちらか一方が勝者と宣言される可能性があります。