作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
役割: システム分析者 | |
ツール メンター: |
ワークフローの詳細: |
問題の定義について同意を得るための最も簡単な方法の 1 つは、書面にして回覧し、皆が同意するかを確認することです。
グループに、問題は何かを尋ねます。
その後、本当の問題は何かを再びグループに尋ねます。
問題についての最初の記述を安易に受け入れてはなりません。「本当」の問題が何かを発見するために、「なぜ」と問いかけ続けます。
グループが実行しようとしている解決法に焦点を当てすぎると、実際の根本的な問題を系統立てて考えることが困難になる場合があります。そのような場合、解決法の利点をまず調べ、その後にそうした利点によって解決される問題を発見しようとすることは有益です。それにより、注目していた問題が組織における「本当の」問題かどうかを見極めることができます。問題の背景にある問題を発見するために使用される一般的なテクニックは、ブレーンストーミング、
要因分析図、
パレート図です。
開発チームが専門とするドメインによって利害関係者を明確にすることは、重要なステップになったり、取るに足らないステップであったりします。しばしば、意思決定者、潜在的なユーザー、その他の関連のある人々にインタビューをする程度のことです。以下のような質問が役に立つでしょう。
システムの潜在的な (または実際の) ユーザーのプロファイルを作成することから始めます。これは、開発するシステムの人間のアクターの役割にマップします。鍵となるユーザーと環境の初期情報を、開発構想書に記述する必要があります。
システム バウンダリは、解決法とそれを取り巻く現実の世界との境界を定義します。言い換えれば、システム バウンダリは解決法システムが入っている封筒のようなものです。入力と出力の形態での情報が、システムとシステムの外にいるユーザーとの間を行ったり来たりします。システムでのすべての相互作用は、システムと外界とを結ぶインターフェイスを通じて行われます。
多くの場合、システムの境界は明らかです。たとえば、Microsoft Windows® を起動しているシュリンク包装担当管理者のような単一ユーザーの境界は、比較的うまく定義されています。単一のユーザーに単一のプラットフォームだからです。ユーザーとアプリケーション間のインターフェイスは、システムに情報を入力するためにユーザーが利用するユーザー インターフェイス ダイアログと、結果として得られる情報の記録や送信のためにシステムが使用する出力レポートとコミュニケーション パスからなっています。
システムの境界を定義し記述するには、通常、アクターを使用するのが大変有効です。「作業: ユース ケースとアクターの獲得」を参照してください。
検討すべき制約には多数のソースがあります。これについての情報の多くは、成果物: と補足仕様書に文書化されています。次に示すのは、潜在的なソースのリストとそれに対して尋ねる質問のリストです。
ここで収集した情報は、補足仕様書で定義された設計上の制約に対する初期入力となります。
グループ全体で、識別された問題ごとに画架紙で作業し、次のテンプレートを埋めます。
<ここに当該問題の説明を記入> の問題は、
<ここに当該問題で影響を受ける利害関係者を記入> に影響を及ぼします。
その影響は、<ここに当該問題のインパクトを記入> となります。
成功する解決法は、<ここに成功する解決法の中心となる利点をリストアップ> となります。
このテンプレートの目的は、解決法と回答を、問題と質問から区別するのに役立てることです。
問題: 顧客サービス問題のタイミングが悪い、不適切な解決
影響: 顧客、顧客サポート担当者、サービス技術者
インパクト: 顧客の不満、品質の欠如の認識、不満を抱いた従業員と収入の損失
成功する解決法: サポート担当者がトラブルシューティング データベースにリアルタイムでアクセスし、サービス技術者を本当に必要な場所だけにタイムリーに派遣します。
問題説明書にリストされた利点を基に、システムに含めたい機能のリストを作成します。それらは簡単に説明し、全体の状態やプロジェクトの優先順位を定義する助けとなる属性を与えます 。
この段階で開発構想書をチェックし、作業が予定どおり進んでいることを確認しますが、詳細に渡ってレビューする必要はありません。開発構想書のチェックポイントについて詳しくは、「作業: 要求のレビュー」を参照してください。
Rational Unified Process
|