ドキュメンテーションは、つまらない、つまらない、単調なことについて温かい気持ちを持っている人がほとんどいないということです。 それにもかかわらず、時にはその必要性に疑いの余地がない場合があります。結局のところ、誰かがそれを使用するか、さらにはそれを変更するためです。 そして、問題が発生します：ドキュメントを正しくする方法は？
「ドキュメントの書き方」というトピックに関する記事はたくさんありますが、初めて取り上げる場合は、著者がケースを書いているのか、ギャグを作っているのかがすぐにはわかりません。
記事をシャベルせずにあなたの意見を形成するために、あなたは2つの方法で行くことができます：いくつかの権威に信頼するか、基準を見ます-それは問題がすべての側面から考えられる可能性が最も高いところです。
誰かが「ああ、標準だ！ ドキュメント自体よりもさらに退屈です！」 まあ、うそをついてはいけません、ほとんどありません:)しかし、電子形式の文書を持っている場合-正しいものを見つけることは難しくありません。 それに、 標準セクションを既に吸収する必要があります。そうしないと、不快にさえなります。
私たちのもの。
最初にGOST- sに目を向けます。 彼らは開発日付にイライラしており（ただし、長年にわたってドキュメントはあまり変わっていないようです）、無料で奨励しています。
GOST R ISO 9127-94「消費者向けソフトウェアパッケージのパッケージに関するユーザーマニュアルと情報」は、当社の中で最も好まれている標準です。 かなり簡単に（ドキュメント全体は約20ページです）、ユーザードキュメントの構成とコンテンツの基本要件が示されています。
公式ページ。 PDFをダウンロードします。
GOST R ISO / IEC 15910-2002「ソフトウェアツールのユーザードキュメントを作成するプロセス」 -標準では、ドキュメントに「何」を含めるべきではなく、ドキュメントを「どのように」作成するかという質問に答えていません。 さらに、ドキュメントスタイルの詳細な説明が例を示します。テンプレートを作成するのに非常に便利です。一度テンプレートを作成し（すべてをテンプレートに配置します：画像のキャプションの配置から整列まで）、異なるフォントヘッダーではなく同じタイプのドキュメントを接着します。
公式ページ。 PDFをダウンロードします。
19.xxシリーズのGOST - ESPDシリーズ、古くからの情熱（平均して、ドキュメントは78年目に作成されました）が、多くの種類のドキュメントの要件であるGOST 9127と同じくらい簡潔です。
知り合いになる。
GOST 34.602-89「自動化システムの作成に関する参照条件」 - 技術仕様の標準。 ジャズ奏者に感謝します。
ブルジョワ。
国際基準は自由ではないことがわかったとき、私のdigりに制限はありませんでした。 交通ルールを有料にするようなものです。 しかし、原則として、それは合理的かもしれません：組織は国有ではありません。 彼らが望む-彼らは仕事のためにお金を取ることができます。 幸いなことに、多くの標準は通常の方法で、海賊版でダウンロードできます。
IEEE Std 1063-2001「ソフトウェアユーザードキュメントのIEEE標準」 -このドキュメントでは、ユーザー指示の構造、内容、および形式の要件の概要を説明しています。
公式ページ。
IEEE Std 1016-1998「ソフトウェア設計記述のためのIEEE推奨プラクティス」 - ソフトウェア のアーキテクチャーを説明する文書の推奨事項、つまり技術的な説明。
公式ページ。
私は特に、ドキュメントの主要なコンテンツのタブレット抽出物が好きでした（ここでは無料の翻訳）：
| レビューの種類 | 内容 | 属性 | プレゼンテーションの例 |
|---|---|---|---|
| 分解 | システムを構造コンポーネントに分割する | 定義、タイプ、目的、機能、依存エンティティ | 階層的な分解図、言葉による説明。 |
| 依存関係の説明 | エンティティとシステムリソース間の関係の説明。 | 定義、タイプ、目的、依存関係、リソース。 | 構造図、データフロー図、トランザクション図。 |
| インターフェースの説明 | システムの構造コンポーネントを使用するために、設計者、プログラマー、またはテスターが知っておく必要があるすべてのもののリスト。 | 定義、機能、インターフェース。 | インターフェイスファイル、パラメーターテーブル。 |
| 詳細の説明 | エンティティの一部の内部構造の説明。 | 定義、データ処理、
データ。 | フローチャート
NSチャート、PDL |
ISO / IEC FDIS 18019：2004「アプリケーションソフトウェアのユーザードキュメントの設計と準備のガイドライン」 -ユーザードキュメントの作成に関する推奨事項。 つまり、「メモの愛人」へのアドバイス。 多くの例があるかなり良いガイド（IMHO、計画自体からプロセスに徹底的にアプローチするため、ドキュメント作成の前または最初に読むのに適しています）。 また、アプリケーションには、「ドキュメントの開発プロセスで忘れてはならないこと」と「ドキュメントに含めるべきこと」のチェックリストがあります。
公式ページ。
ISO / IEC 26514：2008「ユーザー文書の設計者と開発者に対する要件」はかなり最近のものであり、内容から判断すると有用な文書です。 しかし、どうやら、明らかに、その新鮮さのために、この標準は無料で見つけることはできません。 少なくともこれはできませんでした。
公式ページ。
これらは、ドキュメントに最も密接に関連する標準でした。 これらは、最初の技術的なテックスと、たとえば「Shvets、Reaper、パイプの男」の両方であるフリーランサーの両方に役立ちます。
明確化、追加、便利なリンクは大歓迎です）
UPD ：非常に有益なコメント 、 lkochetovaに感謝
UPD1 ：私の良心は私を拷問し、自由に配布されていない標準をダウンロードするための直接リンクがこの記事に含まれなくなりました。 それらが必要な場合は、グーグルにするのは難しくありません。
UPD2 ： GOST 34 *に準拠したドキュメントも参照してください。 これは 、プロジェクトドキュメントの国内標準の詳細な分析にすぎません 。