ここ数年、アナリストとして、要件を文書化するために、仕事でユースケース（SI）とSI図を非常に広く使用してきました。 一般に、ユースケースの名前は異なります。 それらはユースケース、ユースケース、さらにはユースケースと呼ばれます。 2000年代半ばに、いくつかの分析リソースで、ユースケースという用語をロシア語に翻訳する方法についての激しい議論があったことを覚えています。 その後、この恐ろしい「前例」という言葉が登場し、さらにそれ以上に、ロシア語には欠陥があり、ユースケースの概念のすべての微妙さを伝えることができないと主張する仲間もいました。 しかし、時間が示しているように、ユースケース（またはユースケース）の概念は、それ自体に非常に適しており、耳に心地よいものです。
SIで良い経験しかなかったので、他の会社の同僚とコミュニケーションをとるときに、彼らが彼らを使用していないことに気づき、さらに、彼らの間には小さな男性、楕円形、スティックを描くことは空であると確信させようとしたとき、私は非常に驚きました時間の無駄。 そのため、私は自分の経験を共有し、SIダイアグラムが仕事にどのように役立つかを示すことにしました。
まず、ユースケースとは何ですか？ 使用シナリオは、外部環境の誰か（または何か）と対話するときのシステムの動作に関する一貫したストーリーです。 誰かまたは何かがシステムのユーザーになる可能性があり、何らかの情報システムまたはデバイスになる可能性があります。 そして、この誰かまたは何かは、演技者（DL）と呼ばれます。 ユースケース自体は、DLのアクションとそれらに対するシステムの反応を説明する一連のステップです。
たとえば、Webサイトに登録するためのスクリプトは次のようになります。
- ユーザーが登録するコマンドを与えます。
- サイトに登録フォームが表示されます。
- ユーザーはフォームフィールドに入力し、登録を確認します。
- サイトは、フォームへの記入の正確さを確認します。
- サイトは、登録を確認するためのリクエストを含む電子メールを送信します。
- ユーザーが登録を確認します。
- サイトはユーザーを登録します。
ご覧のように、ユーザーとシステムのアクションは互いに交互に行われ、ボールをプレーしているように見えます。 SIの詳細については、 ru.wikipedia.org / wiki / User scriptをご覧ください。
しかし、腐食性の読者は、そのようなシナリオを開発に与えてはならないことに当然反対することができます。 そして彼は正しいでしょう！ 結局のところ、一般的な動作がすでに明確になっているが、詳細な要件はまだないときに、おそらく5階建ての建物の高さからシステムを調べました。 したがって、ユースケースは、最低限、代替の実行スレッドで補完する必要があります（上記で説明したものはメインスレッドと呼ばれ、すべてが正常に動作する場合のシステムのアクションを説明します）。 代替ストリームは、誤ったユーザーアクションまたは例外的な状況に対するシステムの反応、またはユーザーがソーシャルネットワーク上のアカウントを使用して登録する場合など、ユーザーアクションの代替ケースを記述するストリームです。 また、ユースケースを含むドキュメントには、ユーザーインターフェイスの詳細、データ検証ルール、さまざまなビジネスルール、エラーメッセージを追加できます。 ただし、非機能要件は通常、特定のSIではなくシステム全体に適用されるため、通常は個別のドキュメントで説明されます。
さらに高くして、より高い「高さ」からシステムを見ると、システムからユーザーに提供されるサービスのセットのように見えます（ユースケースはシステムの高レベルの要件と考えることもできます）。 ここで、これらの要件を視覚化するのがいいと思います。このためには、適切なUMLダイアグラムが適しています：ユースケースのダイアグラム。 チャートの一部を以下に示します。 アクター、使用シナリオ、およびそれらの間のさまざまな関係で構成されます。
開発者とテスターにとって、一見したところ、ユースケース自体よりもメリットが少ないです。 しかし、それは別のものを対象としています！
SIチャートは通常、プロジェクトの最初の段階でアナリストによって描かれ、プロジェクトの計画された機能全体を広いストロークでカバーし、顧客と調整します。 その後、各SIは手順と詳細な要件を使用してすでに詳細になっています。 SIは、システムを提供するサービスの観点からシステムを見るのに役立ち、特に掘り下げることを助けません。
私は通常、SIチャートを使用して次の問題を解決します。
- プロジェクトの複雑さの評価。
- 勤務スケジュールの計画。
- 満たされていない要件の特定;
- プロジェクトドキュメントの「コンテンツ」。
SIがこれらの問題の解決にどのように役立つかを見てみましょう。
プロジェクトの複雑さの評価
経験と実践が示すように、評価はより正確に取得され、今後の作品のリストがより詳細に強調されます。 実際、「記事を書く」タスクは、「イラスト用の5つの写真を見つける」タスクよりも評価がはるかに困難です。 したがって、ユースケースは、システムを個々の要素に分解する最初の反復です。 さらに、これらの要素は良好な接続性（この場合は機能的）を持ち、互いに別々に評価できます。 これで十分でない場合は、各SIをメイン/代替ストリームに分解するか、プログラマーが個別のシナリオを実装するために実行する必要があるタスクに分解することもできます。
ここでは、以前に作成されたアーティファクトを再利用する可能性も明らかになります。 たとえば、システムがユーザー登録機能を必要とする場合、プラス/マイナスは多くのシステムで同じように機能し、評価中の不確実性の度合いを即座に低減します。
SI ユースケースポイントに基づいた特別な評価方法もあります。 この場合、特定のルールに従って、アクターとシナリオが区別され、複雑さを決定し、チームのプロ意識と対象領域の複雑さを考慮したいくつかの修正要因を設定し、すぐに評価が出力に表示されます。 つまり、理想的には、開発者とテスターを評価に関与させる必要さえありません。
勤務スケジュール計画
予算が固定されたプロジェクトでは、設計、開発、テストの連続した段階（ウォーターフォールモデルなど）が通常明確に区別されます。 しかし実際には、テスターは開発された要件のレビューに接続し、テスト設計の作成を開始するため、テストは設計段階が完了する前でもすでに部分的に開始されます。 また、アナリストや建築家がスケジュールを立てるのが難しくない場合、これらの役割の活動はプロジェクトの開始から始まるため、テスターと開発者をつなぐ価値のある時期とタスクを判断するのが難しくなります。 実際、それらの入力データは準備され、要件を備えた文書に同意されているためです。 そして、この問題を解決するために、SIは再び適しています。 各シナリオにはプロセスの完全な説明が含まれているため、それらを顧客と調整しやすくなり、それに応じて、スケジュール内の要件ドキュメントを調整するための重要なポイントを非常に正確に設定できます。 そして、すでにこれらの点から、チームの残りの作業を計画します。
満たされていない要件を特定する
顧客が将来のシステムの要件を何らかの形で表明するとき、彼の説明では有用な機能に焦点を当てており、たとえばシステム構成機能やユーザーアカウント管理機能について言及していないことは驚くことではありませんが、それらがなければシステムは完全にはなりません働く。 多くの場合、このような要件を受け取った後、チームは評価を実行し始めます。 実際には、チームがすぐに戦闘に突入し、顧客が説明した内容を評価し、システムの無言の、しかしそれにもかかわらず必須の機能を残した場合がありました。
また、システムの説明に作業の過程でユーザーが何らかの種類のエンティティを作成する必要がある要件が含まれる場合もあります。 ほとんどの場合、忘れられることもあるすべてのCRUD（作成、読み取り（または取得）、更新、削除）操作は、そのようなエンティティに適用できます。 ここでのSIモデルの使用は何ですか？ そして、要件をグラフィカルに表現したものです。 目が全体像を覆っている場合、要件がプレーンテキストで定式化されている場合よりも、欠落している要素に気付くのがはるかに簡単です。
プロジェクト文書の内容
多くの場合、顧客は一連のプロジェクト文書の転送をシステムに依頼します。 当社では、使用シナリオの形式でプロジェクト文書を作成します。 顧客がGOSTに従って文書を必要とする場合、使用シナリオが最初に記述され、次にGOST文書がそれらに基づいて形成されます。
ドキュメンテーションには、少なくとも2つのアプローチを使用します。各SIが個別のドキュメントで記述される場合と、1つのサブシステムに関連する複数のSIが1つのドキュメントで同時に記述される場合です。 多くの場合、採用されたプロセスまたは顧客の習慣に基づいて、1つまたは別のアプローチが決定されます。
ユースケースのリストの最初のバージョンは、作業スケジュールの評価と計画の段階ですでに形成されていると上記で述べました。 将来、このリストは補足および調整できますが、ある程度の正確さで、プロジェクトチームが提供するドキュメントについて顧客と合意することはすでに可能です。
おわりに
これらの説明の後、SIダイアグラムを使用する利点が明らかになることを願っています。 開発者にとって直接的なシンプルさや冗長性にも関わらず、あらゆるプロジェクトの開始を促進します。 そして、まずこの流れでそれを考慮する必要があります。 アリスター・コバーンの著書「システムの機能要件を説明するための現代の方法」では、スティックや楕円形を描くことには意味がないと書いています。 しかし、彼もまた、一連のシナリオを定義した後に続く要件の詳細な詳細化の段階についてすでに話している。