基本的にPHPで開発されたWebアプリケーションを完成させましたが、これはもう1つの通常のWebアプリケーションです。通常、最終製品リリースを配信するときは、コードド​​キュメントとアーキテクチャ情報をクライアントに引き渡すだけです。ただし、この特定のプロジェクトでは、クライアントはプロジェクトに関する完全な入出力データを保持することを強く求めています。

だから私はただ疑問に思っています...コードとアーキテクチャのドキュメントとは別にクライアントに提供できる必須の技術的および非技術的ドキュメントは何ですか？

（また、プロジェクトに関するさまざまな統計情報やデータについてクライアントにヒットして、関連する作業量と製品が実際にどれだけクールであるかを実際に知ることもできます。）

リストには以下を含めるべきだと思います：

• 非技術的な要件（そのような文書がありましたか？）
• 技術的要件
• 一部の決定が他の決定よりも下された理由を説明する「決定」ドキュメント（ある場合）。これは、すでに別の要件またはアーキテクチャドキュメントに含まれている可能性がありますが、通常は、Big Decisionsに対して個別に行います。
• コードとその他のリソース（画像ファイル、CSSなど）
• データベースモデル（図、ドキュメントなど）
• データベースを作成するDDL。
• データベースをシードするDML。
• アプリケーションのセットアップと基本的なトラブルシューティングを説明するドキュメント。
• 重要なユーザー名とそのパスワード（管理者アカウント用）のリスト、およびパスワードの変更方法の説明。理想的には、Webサイトを初めてセットアップするときに、新しい管理者パスワードを入力するように求められますが、これはアーキテクチャの問題です。
• システム要件、およびWebアプリの場合、最小ホスティング要件も同様です（アプリにはMySQLまたはPostgreSQLが必要ですか？RAMはどれくらいですか？など）

これらのすべてがすべてのプロジェクトで利用可能（または必要）であるとは限りませんが、これは良い一般的なガイドだと思います。

FrustratedWithFormsDesignerの本当に良い答えに加えて、非技術文書に含まれるものを（私たちがやったように）言いたいと思います。

• 分析データ：最初に要件について話したとき、顧客は何を伝えましたか？

• あなたがした申し出：

  • 製品要件ドキュメント
  • 機能仕様書

  これらは一緒になって、あなたがしなければならないことと、
  開発中に顧客が何を提供することを期待するかについての一種の契約として、また推定時間とコストとして機能します。

• レビュープロトコル、ユースケースとテスト計画、テスト結果を含む仕様

• UMLの設計および対応するすべてのドキュメント

• ソースコードのドキュメント（doxygenなど）

• マニュアルとインストールのガイドライン

• プロジェクトに使用されるリソースの実際の最終的な量（時間とお金）。請求書を書くことができます。

• 一部の顧客は、会議プロトコルも必要としています。これは、上記の「決定文書」の拡張版です

それがあなたが探していたことを願っています。

以下から、プロジェクトに該当するドキュメントに従ってください。すでにいくつかのドキュメントが用意されている場合があります。

技術文書：

• PHPの詳細とプロジェクトでのPHPの有用性に関する情報
• バックエンドの詳細と、それがプロジェクトにどのように役立つかに関する情報
• データベースの接続に関する情報と、データの流れを描いた適切な写真
• XML、HTMLなど、プロジェクトに関係する他のプログラミング言語またはアプリケーションに関する情報
• FAQヘルプファイル

スクリーンショット付きのドキュメントを準備し、以下の関連コード（必要な場合）を強調表示します。

• オブジェクトやコントロール、オブジェクトプロパティなどのフロントエンドアプリケーションに関する情報
• データベースクエリに関する情報（まだ存在しない場合）
• 主キー、外部キーなどのデータベースプロパティに関する情報と、それらがデータの一貫性と正確性を保証する方法。
• サンプルデータを実行した後、フロントエンドとバックエンドの両方を使用して、あらゆる種類の画面のスクリーンショットを使用して、類似の種類のデータまたは画面を論理的な順序で繰り返すことなく、プロジェクト全体の詳細なガイド。

• 無効なデータを入力し、フロントエンドとバックエンドでデータ検証を行ったため、不可能であることを示します。
  /* This step is not applicable if you have not used any object for getting direct input from the user like Text Field as it is obvious that you cannot get invalid data through indirect input. */

• 関連するコードを説明することにより、サーバーまたはクライアントシステムで突然の障害が発生した場合に、プログラムにエラーやデータの不整合がないことを示します。

• サンプルデータをフロントエンドから提供した後、サーバーからデータを直接取得するためのサンプルクエリをバックエンドに含め、データの重要な統計を準備するのに役立つサンプルDMLクエリを含めることができます。

ドキュメントを作成する前にこれらを確認して、クライアントがサンプルデータを含むデモを要求した場合に、プロジェクトが実際にどのように機能するかを示すことができます。また、フロントエンドコードに適切なコメント行があることを確認してください。

• 最後に、コードの総行数、プロジェクトに費やされた総日数、プロジェクトをチェックした総回数、使用されたすべてのアプリケーションのリスト、その他の技術的および非技術的情報などの統計で終わります。

  
  非技術文書：

• 該当する場合、プロジェクトのライセンスの詳細。
• 該当する場合、プロジェクトの商業的側面。

心配する

クライアントに提供できる潜在的なドキュメントは、事実上無限です。まだ持っていないドキュメントを生成するのに必要な追加の時間は無料です。

クライアントがこのドキュメント（ソースコード以上）を必要とするのはなぜですか？それで何が行われますか？誰のためですか？

これらの質問に対する答えは、提供するものの範囲を狭めるのに役立ちます。

あなたとクライアントが提供する文書を正確に同意し、追加の労力が補償されるかどうかに同意することが重要です。

推測ゲームをプレイしないでください。ほとんどの技術文書は、一般的な（非技術的な）クライアントにとっては役に立ちません。

おそらく、これをいくつかのドキュメントカテゴリに分割します。

ガイド：

• インストールガイド、サーバーでこれを設定する方法。
• 最適なパフォーマンスのためにアプリケーションを構成および実行する方法については、管理者ガイド。セキュリティは、このアプリケーションがどのパスワードを持ち、実行に使用するかを知るために、ここでカバーするものでもあります。

サポート：

• 問題がある場合、どのような手順を提案しますか？一定期間サポートを提供していますか？他の誰かがサービスの再起動やサーバーの再起動などを試してみるのがもっと簡単なことを知っているように、おそらくこのエリアでガイドを1つか2つあげるでしょう。

統合ポイント：

• このアプリケーションには、コード以外のベンダーに依存するサードパーティの統合ポイントがありますか？