機能要件の特定
要件は、一般に機能的または非機能的と見なされます。 機能的な要件は、ソリューションが実行する必要がある内容またはその動作を説明し、非機能要件は、一般にパフォーマンス要件などのソリューションの非動作の側面を説明します。 このトピックでは、機能的な要件に関する考慮事項について説明します。
各機能要件では、要件の担当者、内容、および理由を明確に把握する必要があります。 要件が大きすぎる場合は、より小さい要素に分割する必要があります。
機能要件の例
次のシナリオは、機能要件の簡単な例を示しています。
販売ユーザーとして、営業案件を失注としてクローズし、今後の販売戦略を改善するために失注した理由を把握できる必要がある。
販売マネージャーとして、見積もりの値引きを承認して合計価格を下げ、顧客に値引きを提供できる必要がある。
スタッフの経理担当として、後で再度開く必要がないように、保留中の品目があるバッチは閉じないようにする必要がある。
これらの状況は、要件の担当者、内容、理由を明らかにしています。
次に挙げるのは、適切に表現されていない要件の例です。
営業案件を受注できるか失注する。
価格に値引きを反映する必要がある。
バッチ品目リストで、左から 3 番目のボタンであるバッチの終了を選択すると、発生を妨げる品目が存在しない場合にバッチが終了する。
さまざまな要件を収集する場合は、機能を単に一覧表示するのではなく、プロセスにマップすると便利です。 ユーザー向けのストーリーを作成し、設計中のシステムをそれらのユーザーがうまく使用するにはどうすればよいかについて説明します。 ホワイトボードに書いたり描画したりすること、ツールを使用してプロセスを図示すること、または計画段階でチームに対して有効な方法を使用することができます。 チームは、後で各部分をより小さいアクション可能な項目に分割します。
受け入れ基準
どうすれば要件が満たされたと見なされるかを明確に理解しておくことが重要です。 多くの場合、充足度の文書化は、要件が十分に詳細かつ適切な規模であるかどうかの判断に役立ちます。 このアプローチは、要件の実装を評価する際に、チームをテストするのにも役立ちます。 最後に、関係者と共に要件の充足度をレビューして、正確であることを確認する必要があります。これはスコープが徐々に移動するのを防ぐために使用できます。 ソリューション アーキテクトは、満たすことができない受け入れ基準を探し、実現可能な妥協点に達するための交渉を行う必要があります。
例外のキャプチャ
通常、取引の成約のような単純な要件には、直線的なパスと少数の例外パスしかない可能性があります。 成功するパスを把握する際には、これらの例外を探して特定してください。 設計に進むときに、例外を主として設計する必要がなくなります。 このように処理する必要がありますが、存在することがわかっていない場合は、後で設計を修正する必要があります。 また、一部の例外は、ソフトウェアのカスタマイズではなくプロシージャやプロセスで処理するのが最適であるため、例外がどの程度頻繁に発生するかを把握しておくことを忘れないでください。
スコープの移動の回避
オフのままにすると、すべてのプロジェクトで、想定して予算を割り当てたものからスコープが追加されます。 ソリューション アーキテクトは、元の前提条件のスコープ外の要件を慎重に探す必要があります。 これらを特定した後で、プロジェクトのガバナンス プロセスを使用して、その処理方法を評価する必要があります。 多くの場合、スコープ外の要件を含めることが許容されていると、プロジェクトの契約構造によっては変更オーダーが発生することがあります。 スコープが増加しているという事実を無視すると、プロジェクトが失敗する可能性が高くなります。
演習: 機能要件の検索
Woodgrove Bank のチームをレビューし、作業を行うために必要な機能についてチーム間にある可能性のある重複を識別します。
ビジネス成長および資産管理 - 年間取引が 10 億米ドル未満の当座預金。 ここで言う成長とは、会社の再投資に使用されるローンのことを指します。 これらの顧客は、同じアカウント マネージャー グループによって管理されます。顧客ごとに管理者が割り当てられることはありません。
Fortune 500 - この部署が担当する各顧客には、すべての銀行業務の基本連絡先として、シニア アカウント マネージャーが割り当てられます。 この部署で管理されている会社は、Fortune 500 から除外された場合でも、引き続きこの部署によって管理されることになります。
グループ ポートフォリオ管理 - このチームは、複数の組織を持つ会社の、共通の傘下にある取引先企業の親会社/子会社を管理します。
新規ビジネス開発 - この部署は、主に新規ビジネスに向けたマーケティングを担当します。 取引先企業が見込みありと評価されて有効になると、その取引先企業は適切な管理チームへと受け渡されます。
公的機関/官公庁/高等教育 - Woodgrove Bank は、世界中のさまざまな国の政府機関や民間大学において、優先的に使用されている金融業者です。 このチームは、同行がサービスを提供している、一部の大口の非営利組織も担当しています。
消費者金融 - Woodgrove では企業向けの商品に重点を置いているので、このチームは最も小規模なチームとなっています。 ただし、大口の消費者向けサービスもケースバイケースで提供されています。 このチームでは、外部の見込顧客に対しては営業を打っておらず、多くの場合は、企業顧客の経営幹部向けにサービスを提供しています。
リレーションシップ マネージャー - このチームは、他の各チームのメンバーによって構成されています。これにより、取引先企業の担当チームが変更され、顧客とのやり取りの方法が変わった場合にも、一貫したエクスペリエンスが維持されるようになっています。 このチームは、ユーザーのベスト プラクティスの策定も担当しています。