検証メッセージはどこに指定すればよいですか？
プロジェクトの機能仕様書（FSD）を作成しています。エラーメッセージをどこに指定すればよいか、かなり混乱していますか？それらはFSDに属していますか、それとも技術仕様（TSD）の一部ですか？
FSDの作成を開始するために、次の記事を読みました。
これらは優れた記事ですが、FSDに何を含めるべきかについての一般的なアイデアを提供するだけであり、より具体的な詳細をどこに配置するかについての記事はありません。
機能エラーは機能仕様書に属します。
機能エラーとは何ですか？
製品がユーザー向け（デスクトップアプリケーションやWebアプリケーションなど）の場合、機能エラーはエンドユーザーに表示されるエラーです。たとえば、ユーザーが間違ったMIMEタイプのファイルをWebアプリケーションに送信すると、そのファイルは機能仕様書に属し、次のことを説明します。
アプリケーションはこのケースを適切に処理する必要があります（クラッシュとは対照的に、ユーザーがアクションへの応答として見たいとは思わないでしょう）。
アプリケーションは、それに応じて問題についてユーザーに通知できる必要があります（例外を黙って飲み込み、送信されたファイルに対して何もしないのではなく、ファイルを送信するアクションが効果がなかった理由をユーザーに理解させる）。
製品がサービス（Webサービスや他のアプリケーションで使用することを目的としたライブラリなど）の場合、機能エラーは呼び出し元に伝播される例外です。つまり、サービスと、サービスを使用するコードとの間のインターフェイスを通過します。サービス。
製品がサーバーアプリケーションの場合、機能エラーは、システム管理者がアプリケーションが期待どおりにタスクを実行したかどうかを判断し、予期しない状況を処理するためにログに記録されるエラーです。これには、開発者向けのデバッグメッセージは含まれません。
技術エラーは技術仕様書に属します。
技術的なエラーとは何ですか？
技術的エラーは、上記のセクションで説明した、主要な対象者を対象としていないエラーです。これも：
開発者向けのロギング。
システム管理者が主要な対象者でない場合、つまりアプリケーションの直接のユーザーではない場合のシステム管理者向けのロギング。
システム内部の例外。これらの例外は、システムのさまざまなレイヤーを通過する可能性がありますが、通常は外界と相互作用しません。言い換えると、（アプリケーション、サービス、またはライブラリの）ユーザーとして、システムがそれらを処理できるため、これらの例外は表示されません（最終的には機能エラーが表示されます）。
システムの狭い範囲内の例外的なケース。すべてのクラスのすべての例外をリストすることは技術仕様書の目的ではありませんが、そのようなまたはそのような例外的な状況がコード内でどのように処理されるかを説明する、いくつかの非常に特殊なケースを文書化する必要があります。
誰かが機能的および技術的な仕様をドラフトするために十分に注意を払ったところで私が見たすべてのプロジェクトは、一貫していくつかのポイントを逃しました。
したがって、忘れないようにしてください。
グローバル例外処理。機能仕様書では、例外とエラーがグローバルレベルでどのように処理されるか、つまり、コードで具体的に処理されない場合についても説明する必要があります。たとえば、Webアプリケーションの場合、HTTP 500ページのコンテンツ（ユーザーはエラーを報告できますか？サポートに連絡すると相関IDを取得できますか？）とその背後にあるプロセスを説明する必要があります：方法とエラーはどこに記録しますか？システム管理者は、エラーが発生したことをどのように通知されますか？
非機能要件 に関連するエラー：たとえば、Webアプリケーションの容量を超える負荷をどのように処理しますか？ 1つの方法は、何が起こったかを説明するわかりやすいエラーメッセージをユーザーに表示するようにリバースプロキシを構成することです。もう1つの方法は、特定の努力を払い、最善を尽くして、リバースプロキシ（またはブラウザ）のデフォルトのエラーページが表示されるようにすることです。
別の例：アプリケーションはハードディスクがいっぱいになったときにどのように反応しますか？領域が不足していることをシステム管理者に警告しますか？それとも単にクラッシュするのでしょうか、それとも奇妙な動作を始めますか？