目的
  • どの問題を解決すべきかについて、同意を得る
  • システムの利害関係者を明確にする
  • システムのバウンダリを定義する
  • システムの主要な機能を記述する
ステップ
入力とする成果物: 結果となる成果物:
役割: システム分析者
ツール メンター:

ワークフローの詳細:


解決すべき問題について同意を得る ページの先頭へ

問題の定義について同意を得るための最も簡単な方法の 1 つは、書面にして回覧し、皆が同意するかを確認することです。

グループに、問題は何かを尋ねます。

  • 問題をまず理解せずに、がむしゃらに解決法の定義を急ごうとする傾向がよく見られます。問題を書き出し、全員をその定義に同意させることができるかを考えます。

その後、本当の問題は何かを再びグループに尋ねます。

  • 根本原因つまり「問題の背後にある問題」を探索します。本当の問題は、しばしば問題と思われたものの背後に隠れています。

問題についての最初の記述を安易に受け入れてはなりません。「本当」の問題が何かを発見するために、「なぜ」と問いかけ続けます。

グループが実行しようとしている解決法に焦点を当てすぎると、実際の根本的な問題を系統立てて考えることが困難になる場合があります。そのような場合、解決法の利点をまず調べ、その後にそうした利点によって解決される問題を発見しようとすることは有益です。それにより、注目していた問題が組織における「本当の」問題かどうかを見極めることができます。問題の背景にある問題を発見するために使用される一般的なテクニックは、../workguid/wg_brnst.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんブレーンストーミング../workguid/wg_fish.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません要因分析図../workguid/wg_paret.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんパレート図です。

利害関係者の識別 ページの先頭へ

開発チームが専門とするドメインによって利害関係者を明確にすることは、重要なステップになったり、取るに足らないステップであったりします。しばしば、意思決定者、潜在的なユーザー、その他の関連のある人々にインタビューをする程度のことです。以下のような質問が役に立つでしょう。

  • システムのユーザーは誰ですか。
  • システムの経済的購入者は誰ですか。
  • システムが作り出す結果によってほかに誰が影響を受けますか。
  • システムが配置 / 導入された場合、誰がそれを評価し恩恵を受けますか。
  • システムの内部または外部ユーザーで、ほかにそのニーズを明らかにする必要のある人がいますか。
  • 誰が新しいシステムを保守しますか。
  • ほかに誰かいますか。
  • わかりました。ほかに誰かいますか。

システムの潜在的な (または実際の) ユーザーのプロファイルを作成することから始めます。これは、開発するシステムの人間のアクターの役割にマップします。鍵となるユーザーと環境の初期情報を、開発構想書に記述する必要があります。

システム バウンダリの定義 ページの先頭へ

システム バウンダリは、解決法とそれを取り巻く現実の世界との境界を定義します。言い換えれば、システム バウンダリは解決法システムが入っている封筒のようなものです。入力と出力の形態での情報が、システムとシステムの外にいるユーザーとの間を行ったり来たりします。システムでのすべての相互作用は、システムと外界とを結ぶインターフェイスを通じて行われます。

多くの場合、システムの境界は明らかです。たとえば、Microsoft Windows® を起動しているシュリンク包装担当管理者のような単一ユーザーの境界は、比較的うまく定義されています。単一のユーザーに単一のプラットフォームだからです。ユーザーとアプリケーション間のインターフェイスは、システムに情報を入力するためにユーザーが利用するユーザー インターフェイス ダイアログと、結果として得られる情報の記録や送信のためにシステムが使用する出力レポートとコミュニケーション パスからなっています。

システムの境界を定義し記述するには、通常、アクターを使用するのが大変有効です。「作業: ユース ケースとアクターの獲得」を参照してください。

システムに影響を与える制約の識別 ページの先頭へ

検討すべき制約には多数のソースがあります。これについての情報の多くは、成果物: と補足仕様書に文書化されています。次に示すのは、潜在的なソースのリストとそれに対して尋ねる質問のリストです。

  • 政治: 潜在的な解決法に影響する内外の政治的問題はありますか。部署間にまたがりはありますか。
  • 経済: どのような財務上または予算上の制約がありますか。販売商品のコスト、または製品の価格付け上の考慮はありますか。ライセンスに関する何らかの問題がありますか。
  • 環境: 環境上または規制上の制約はありますか。合法的ですか。ほかに制約を受ける基準はありますか。
  • 技術: 技術を選択する上で何らかの制約を受けていますか。既存プラットフォームまたは既存技術の範囲内で作業するよう制約を受けていますか。新技術は使用禁止ですか。
  • 実現可能性: スケジュールは定義されていますか。既存のリソースを使うようにという制約がありますか。外部の人の力を借りられますか。リソースを拡張できますか。一時的なものですか。永久的ですか。
  • システム: 既存システム上に解決法は構築されますか。既存の解決法と互換性を保つ必要がありますか。どのようなオペレーティング システムと環境をサポートする必要がありますか。

ここで収集した情報は、補足仕様書で定義された設計上の制約に対する初期入力となります。

問題の記述の定式化 ページの先頭へ

グループ全体で、識別された問題ごとに画架紙で作業し、次のテンプレートを埋めます。

<ここに当該問題の説明を記入> の問題は、
<ここに当該問題で影響を受ける利害関係者を記入> に影響を及ぼします。
その影響は、<ここに当該問題のインパクトを記入> となります。
成功する解決法は、<ここに成功する解決法の中心となる利点をリストアップ> となります。

このテンプレートの目的は、解決法と回答を、問題と質問から区別するのに役立てることです。

例:

問題: 顧客サービス問題のタイミングが悪い、不適切な解決
影響: 顧客、顧客サポート担当者、サービス技術者
インパクト: 顧客の不満、品質の欠如の認識、不満を抱いた従業員と収入の損失
成功する解決法:
サポート担当者がトラブルシューティング データベースにリアルタイムでアクセスし、サービス技術者を本当に必要な場所だけにタイムリーに派遣します。

システム機能の定義 ページの先頭へ

問題説明書にリストされた利点を基に、システムに含めたい機能のリストを作成します。それらは簡単に説明し、全体の状態やプロジェクトの優先順位を定義する助けとなる属性を与えます 。

結果の評価 ページの先頭へ

この段階で開発構想書をチェックし、作業が予定どおり進んでいることを確認しますが、詳細に渡ってレビューする必要はありません。開発構想書のチェックポイントについて詳しくは、「作業: 要求のレビュー」を参照してください。



Rational Unified Process   2003.06.15