システムの機能要件を記述するための最新の方法。 アリスター・コバーン。 本のレビューと追加

この本では、問題ステートメントの一部を記述するための XNUMX つの方法、つまりユース ケース メソッドについて説明しています。

それは何ですか？ これは、システム (またはビジネス) とのユーザー対話シナリオの説明です。 この場合、システムはブラック ボックスとして機能します (これにより、複雑な設計タスクを対話の設計とこの対話の確保に分割することが可能になります)。 同時に、表記基準が導入され、非参加者も含めて読みやすさが保証され、完全性と利害関係者の目標への準拠をある程度チェックできるようになります。

使用例

電子メールによるサイトでの認証の例を使用したシナリオは次のようになります。

(システム) Web サイトにログインして、個人アカウントにアクセスします。 ~~ (海面)

コンテクスト： 不正なクライアントがサイトにログインすると、サイトはそのクライアントを認識し、電子メールをログインとして使用して閲覧履歴、購入履歴、現在のボーナス ポイント数などの個人情報を表示します。 
レベル： ユーザーの目標
主人公： クライアント（オンラインストアの訪問者）
範囲： オンライン ストア Web サイトとのクライアント インタラクション
利害関係者と利益:

• マーケティング担当者は、個人メールをより多くカバーするために、サイト訪問者の最大数を特定したいと考えています。
• セキュリティ専門家は、XNUMX つのアカウントのパスワードを推測したり、弱いパスワードを持つアカウントを検索したりする試みなど、訪問者の個人データへの不正アクセスが発生しないようにしたいと考えています。
• 攻撃者は被害者のボーナスへのアクセスを望んでいます。
• 競合他社が製品に否定的なレビューを残したいと考えているため、
• ボットネットは、店舗の顧客ベースを取得し、攻撃を使用してサイトを動作不能にしようとしています。

前提条件: 訪問者は許可されていてはなりません。
最低保証: 訪問者は、認証の試行が成功したか失敗したかを知ることができます。
成功の保証: 訪問者は許可されています。

メインシナリオ：

1. クライアントが認可を開始します。
2. システムは、クライアントが認証されておらず、「セキュリティ ルール No. 23」に従って、特定のセッション (複数のアカウントの弱いパスワードの検索) での認証試行失敗の回数を超えていないことを確認します。
3. システムは、認証試行回数のカウンタを増加させます。
4. システムはクライアントに認証フォームを表示します。
5. クライアントは電子メールとパスワードを入力します。
6. システムは、そのような電子メールを持つクライアントがシステム内に存在すること、パスワードが一致すること、および「セキュリティ ルール No. 24」に従ってこのアカウントへのログイン試行回数が超過していないことを確認します。
7. システムはクライアントを認証し、閲覧履歴とこのセッションのバスケットをこのクライアント アカウントの最後のセッションに追加します。
8. システムは認可成功メッセージを表示し、クライアントが認可のために中断されたスクリプトステップに移動します。 この場合、ページ上のデータは、個人アカウント データを考慮して再ロードされます。

拡張子:
2.a. クライアントはすでに許可されています。
 2.a.1. システムは、以前に実行された認証の事実についてクライアントに通知し、スクリプトを中断するかステップ 4 に進むかを提案します。ステップ 6 が正常に完了すると、明確な説明とともにステップ 7 が実行されます。
 2.a.7. システムは古いアカウントでクライアントを無効化し、新しいアカウントでクライアントを認証しますが、このインタラクション セッションの閲覧履歴とカートは古いアカウントに残り、新しいアカウントに転送されません。 次に手順 8 に進みます。
2.b 認証試行回数が「セキュリティ ルール No. 23」に基づくしきい値を超えました。
 2.b.1 ステップ 4 に進み、認証フォームにキャプチャが追加で表示されます。
 2.b.6 システムは正しいキャプチャ入力を確認します
    2.b.6.1 キャプチャが間違って入力されました:
      2.b.6.1.1。 システムは、このアカウントに対する認証試行失敗のカウンターも増加させます。
      2.b.6.1.2。 システムは失敗メッセージを表示し、ステップ 2 に戻ります。
6.a. このメールアドレスのアカウントは見つかりませんでした:
 6.a.1 システムは失敗に関するメッセージを表示し、ステップ 2 に進むか、「ユーザー登録」シナリオに進んで入力した電子メールを保存するかを選択します。
6.b. このメールアドレスのアカウントのパスワードは、入力されたパスワードと一致しません:
 6.b.1 システムは、このアカウントへのログイン試行失敗のカウンターを増やします。
 6.b.2 システムは失敗に関するメッセージを表示し、「パスワード回復」シナリオに進むかステップ 2 に進むかを選択します。
6.c: このアカウントのログイン試行カウンタが「セキュリティ ルール No. 24」のしきい値を超えています。
 6.c.1 システムは、アカウント ログインのブロックに関するメッセージを X 分間表示し、ステップ 2 に進みます。

何がすごいの

完全性と目標への準拠をチェックします。つまり、検証のために要件を別のアナリストに渡すことができるため、問題策定の段階での間違いが少なくなります。

ブラック ボックス システムを使用すると、自動化する内容の開発と顧客との調整を実装方法から切り離すことができます。

これはアナリストの道の一部であり、ユーザビリティの主要な部分の XNUMX つです。 ユーザーのシナリオはユーザーの動きの主な経路を定義します。これにより、デザイナーと顧客の選択の自由が大幅に減り、デザイン開発の速度が向上します。

説明内の各インタラクション ステップの例外が特定されている箇所に非常に満足しています。 完全な IT システムは、ある種の例外処理 (上記の例のように、一部は手動で、一部は自動的に) を提供する必要があります。

経験上、例外処理を軽率に行うと、システムが非常に不便なシステムに簡単に変わってしまう可能性があることがわかっています。 ソビエト時代に、決定を得るためにさまざまなサービスからいくつかの承認を得る必要があり、最後のサービスで承認を得る必要があったときの話を思い出します。しかし、アプリケーションの名前が間違っていたり、その他の間違いがあったときは、とても苦痛でした。句読点を削除し、すべてをやり直し、すべてを再調整します。

例外を考慮して考えられていなかったシステムの動作ロジックにより、システムの大幅な作り直しが必要になる状況によく遭遇します。 このため、アナリストの作業の大部分は例外処理に費やされます。

図とは対照的に、テキスト表記を使用すると、より多くの例外を特定してカバーすることができます。

実践からのメソッドへの追加

ユーザー ストーリーとは異なり、ユース ケースはステートメントの中で独立して優先順位が付けられる部分ではありません。

上記のシナリオでは、例外「6.a.」を考慮してください。 このメールアドレスのアカウントは見つかりませんでした。」 次のステップ「6.a.1 システムは失敗メッセージを表示し、ステップ 2 に進みます。」 舞台裏にはどんなネガティブなものが残されていたのでしょうか？ クライアントにとって、何らかの利益が得られるということは、データを入力するために行ったすべての作業が埋め立て地に捨てられることと同じです。 (スクリプトに表示されないだけです!) 何ができるでしょうか? これが起こらないようにスクリプトを再構築してください。 これは可能でしょうか？ 例として、Google 認証スクリプトを見てみましょう。

シナリオの最適化

この本では形式化については述べていますが、そのようなシナリオを最適化する方法についてはほとんど述べていません。

ただし、シナリオを最適化することでこの手法を強化することは可能であり、ユースケース形式化手法によりこれが可能になります。 具体的には、発生する各例外について考え、原因を特定し、例外を取り除くかカスタマー ジャーニーを最小限に抑えるためにスクリプトを再構築する必要があります。

オンライン ストアから注文する場合は、お届けする都市を入力する必要があります。 サイズ制限、または対応する倉庫の商品不足により、店舗がクライアントが選択した都市に商品を配送できないことが判明する場合があります。

登録段階でのやり取りのシナリオを簡単に説明すると、「クライアントに配達が不可能であることを通知し、都市またはカートの内容の変更を提案する」と書くことができます（そして、多くの初心者アナリストはそこで止まります）。 ただし、そのようなケースが多数ある場合は、シナリオを最適化できます。

まず最初に、配達可能な都市のみを選択してください。 これはいつ行うべきですか? ウェブサイトで製品を選択する前に（説明付きの IP 経由で都市を自動検出）。

第二に、クライアントに提供できる商品のみを選択できるようにする必要があります。 これはいつ行うべきですか? 選択の瞬間 - 製品タイルと製品カード上。

これら XNUMX つの変更は、この例外を排除するのに大いに役立ちます。

測定と指標の要件

例外処理を最小限に抑えるタスクを検討する場合、レポート タスクを設定できます (ユースケースは説明されていません)。 例外が何件あったか、どのような場合に例外が発生したか、および正常に成功した受信シナリオの数を加えます。

しかし悲しいかな。 経験上、この形式のシナリオのレポート要件では不十分であることがわかっています。主にユースケースの形式ではなく説明されているプロセスのレポート要件を考慮する必要があります。

ユーザビリティへのアクセス

私たちの実践では、クライアントが意思決定を行えるように、エンティティとデータの特定の属性の説明を含むユースケースの説明フォームを拡張し、その後の使いやすさを向上させました。

ユーザビリティ設計のため、データの表示という入力セクションを追加しました。

承認のあるシナリオでは、これはクライアントがシステム内で承認されているという事実です。 クライアントが事前認証されている場合は、認証が成功した後にナビゲーション履歴とカートを新しいアカウントに切り替えることについての警告を表示します。

一般に、これはクライアントがシナリオに従って今後の行動を決定できるようにするために必要な情報の表示です（クライアントにとってこのデータで十分か、他に何が必要か、どのような情報が必要なのかを尋ねることができます）クライアントが決定を下す必要があります)。  
入力された情報が個別に処理され、さまざまな例外が形成される場合は、入力フィールドに入力情報を分割することも価値があります。

クライアント認証の例では、入力した情報をログインとパスワードに分離する場合、個別のログインと個別のパスワードを入力する段階を強調表示するように認証スクリプトを変更する価値があります (これは Yandex や Google で行われますが、ほとんどのオンラインストアでは行われていません）。

必要なデータ変換を達成する

データ変換アルゴリズムの要件をスクリプトから抽出することもできます。

Примеры：

• オンライン ストアで製品を購入するかどうかを決定するには、クライアントは製品カードに記載されているこの製品の可能性、コスト、自分の都市までの配達時間を知る必要があります (これらは、オンライン ストアでの製品の入手可能性に基づいてアルゴリズムによって計算されます)。倉庫とサプライチェーンパラメータ）。
• 検索行に語句を入力すると、クライアントにはアルゴリズムに従って検索候補が表示されます (アルゴリズムによって生成されます)。

合計で

一般に、残念なことに、この本を読んだ後、アナリストがビジネス上の問題を解決し、開発者向けに正式な技術仕様を作成するまでの手順は明確ではありません。 この本にはプロセスの一部しか書かれておらず、入力ステップも明確でなく、次のステップも明確ではありません。 ほとんどの場合、ユースケース自体は開発者にとって完全なステートメントではありません。

それにもかかわらず、これは、オブジェクトとサブジェクトの間の相互作用のシナリオを形式化して処理するための非常に優れた方法であり、相互作用によってサブジェクト内の何かに変化が生じる場合があります。 これは、明示的な例外検索ポイントを使用して検証可能な要件を可能にする数少ない記述方法の XNUMX つです。

この本は、アナリストがテスト可能なプレイを書き始めるために必読の書です。

出所： habr.com