回答:
ビジネスルールについては、@ Joppeが私たち全員が考えていたUMLを指摘したと思います。
ユースケース図は、アクター/ロールがシステムとどのように相互作用するか、およびシステムが何をするかの優れた概要を示します。COMPLEXEユースケースの場合、追加の情報は大いに役立つだろうテキストで説明した（事前条件、事後条件、以前のUCの実行への依存、など）
さまざまなレベルでのビジネスの概要も示す図があります。
アドバイスとして、各ユースケースにコードを割り当てます（例：UC-1、UC-n）。これらは後でUIのドキュメント化の際に役立ちます。
UIドキュメントの一般的な方法（最近）は、ワイヤーフレームを使用することです。見た目がすっきりとシンプルなので、スクリーンショットよりもはるかに優れています。たとえば、WireframeSketcherを見てください。
ワイヤーフレームは十分なドキュメントではない可能性があるため、各画面について簡単な紹介を行い、すべてのボタンについて説明します。さらに、画面に含まれるUCへの参照を行います（UCコードが役立つ理由をご覧ください）。これにより、ドキュメントに一貫性が生まれます。
Wireframesketcherなどのツールのポイントは、インタラクティブなモックアップを行うことです。あなたがまだ設計または開発している間に、顧客にインタラクティブな何かを与えるのに最適です。
ナビゲーション計画を文書化することを忘れないでください。ナビ プランにはUMLダイアグラムがありませんが、代わりにステートマシンダイアグラムを使用できます。それはそれが作られたもののためではなく、まだです。
最後に、あなたが誰に宛てているのかを覚えておいてください。
技術者：詳細に行き、技術を使用することができます。
技術者ではない：技術を回避する（languajeにもコードにも関連しない）。明確でシンプルなものにし、お客様が使用しているのと同じ用語/単語を使用するようにします。あなたがプログラミングの考えを持っていなかったように考えてください。
文書化はユースケースやその他の散文形式で行われることがよくあります。さらに、より高いレベルで概要を示し、ページやページを読むよりも短時間で簡単に理解できるUMLダイアグラムやその他のグラフィックフォームを用意すると非常に便利です。
そして最後に、最も重要なドキュメントは、ビジネスルールを実行するテストケースです。これにより、コードを変更して、ビジネスルールに違反していることがわかります。それ以外の場合、ドキュメントは常に古くなって古くなるという危険にさらされています。
どの方法を使用する場合でも、アクティブに維持できることを確認してください。彼らは生きた文書でなければなりません。ドキュメントをバージョン管理システムまたはSharepointのようなある種のドキュメント管理システムに収容することで、ドキュメントを維持し続けることができます。電子メールに添付されたワードドキュメントを通じてビジネスルールを追跡することは、複数のバージョンが浮かんでしまうため、この問題に対処する恐ろしい方法です。
ビジネスルールをユースケースやUIデザインから参照するだけで、ビジネスルールをシステム仕様から厳密に分離することを強くお勧めします。私の好きなテクニックは次のとおりです。-識別されたビジネスルールのリストをスプレッドシートに入れます。-システム設計、ユースケース仕様、ユーザーストーリーなどで、「ユーザーがビジネスルールBR012で指定された情報を入力する」、「システムがビジネスルールBR510で指定された合計金額を計算する」と指定するだけです。この記事をお勧めしますhttp://www.allaboutrequirements.com/business-rules/