なぜそれが必要なのか-リクエストが届いたときにビジネス分析が何をしているのかをよりよく理解するために-リンクがあるので、ウェブサイトが欲しい。
ロシア語の翻訳では、彼らが何について話しているのかよくわからないことが多かったので、おそらくこの本はまだ原本で読むべきでしょう。
主な概念：
ユースケース -特定の目標を達成するために、通常、ロール/機能（UMLでは「アクター」と呼ばれる）とシステムの間のすべての相互作用を定義する一連のステップ。
この場合、 アクターとは、システムと対話する人、またはシステムで何らかのアクションをトリガーできる外部システムのいずれかです。 簡単に言えば、ユースケースはすべて、ページで発生するすべてのスクリプトのバリアントです。
目標 -目標、 目標の失敗 -それぞれ、未到達の目標。
優れたユースケースは、他の人が情報を簡単かつ簡単に理解できるように、シンプルで理解可能な言語で作成する必要があります。
主な特徴は次のとおりです。
スコープ -プロジェクトまたはプロジェクトの一部とは、
主要なアクター （メインゴールのフレームワーク内でシステムとの対話を開始するメインキャラクターまたはシステム要素）誰（ユーザー/管理者）またはこのページで何が機能するかの説明
レベル -すべてが発生するレベル。
前提条件と保証 -ユースケースを実行する前後の状態。
主な成功シナリオ -正常に完了する必要がある主なシナリオ。
拡張 -システムがメインシナリオから逸脱する場合のさまざまなオプション。
私自身に代わって、スティーブ・エドルフへのリンクがとても気に入りました。「<immerse and float>メソッドを使用してください。 新しいシステムがどのように機能するかについての理解を説明する基本的な高レベルモデルを作成します。 これは未開の領域であるため、単純化に努めてください。 メインシナリオがどのように見えるかを考え、古いシステムの専門家と一緒にプレイします。 次に、新しいユースケースの1つに飛び込みます。 正式な要件に入らずに、実際には何が起こるのかを自問してください<..>最後に、表面に戻って、詳細に突入した後に何が変わったのですか？ モデルをセットアップし、次のユースケースに向けてダイブを繰り返します... "
一般規則
おそらくそれらを完全に引用する価値があります：
1.システムの説明は読みやすいものでなければなりません。
2.常に共通の概念から始めて、サブレベルに移動する必要があります。
各ステップについて：
最初に、プロセスを構成するものを（ステップで）記述して、目標を達成し、アクターの意図を記述できるようにします。ユーザーインターフェースの詳細には触れません。 （アクターは、ロシア語の翻訳で書くのが好きなので、アクターではありません。特定のアプリケーションレベルまたはこのページで計算、アクション、および操作の合計を生成する人、またはシステムの場合があります）。
次に、アクターが特定する情報を、どの基準に従って、またはどのように更新のステータスを確認する必要があるかを示す必要があります。 これに続いて、さまざまなステップ間で起こること、またはこれらのステップが欠落している場合についてコメントを書く必要があります。
その後、このステップを使用して次の上位レベルでどのような目標が達成されているのか疑問に思う価値があります。
データの説明：
説明ユースケースに対応する詳細レベルのみを入力します。
詳細レベル1：データ名
詳細レベル2：名前に関連付けられたデータフィールド
詳細レベル3：フィールドタイプ、フィールド長、入力されたデータの検証の正確性。
ユースケースに含まれていないものは常に何らかの形で接続されており、データ形式、入力/出力プロトコル、パフォーマンス要件、ユーザーインターフェイスの要件、ユーザーインターフェイス設計、ビジネスルールを考慮する必要があります。
精度にはいくつかの段階があります。
1.アクターと目標：アクターと、システムが追求する各目標をリストします。 このリストの正確性と完全性を確認してください。 優先順位を設定し、開発チームとバージョン間で目標を分配します。 これで、第1レベルの精度の機能要件があります。
2.ユースケースまたはメインシナリオの概要：ユースケースでは、一般的な用語でメインシナリオに従うことを選択しました。 アウトライン形式で表示して、関心のある参加者の要件をシステムが本当に満たしていることを確認してください。 これは、機能要件の精度の第2レベルです。 この資料は、次の2つのレベルとは異なり、かなり簡単に入力できます。
3.障害条件：メインシナリオを完了し、どのような障害が発生する可能性があるかを検討します。 システムがそれらを処理する方法を決定する前に、それらをリストします。 フェイルオーバープロセスの記述は、障害のリストよりも時間がかかります。 <...>
4.フェイルオーバー：各障害に対するシステムの対応方法を記述します。 これは、多くの場合、システムが達成しなければならない新しいアクターまたは新しい目標を明らかにする可能性があるため、困難で退屈で予測不可能なプロセスです。
継続する。