要求定義

「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義
われわれの悩み
ヒント
考え方・意識
組織
プロセス
ツール
提言
CMU2005海外エンジニアリングワークショップ参加報告書
1
「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義１）要求定義における悩み
われわれの悩み
顧客側の問題
社内規定、セキュリティ
要件変更等による方針
レベルでの変更発生
決定者／相対が不明確
クライアント多忙による
要求決定の遅れ
要求変更が多い
あまりにも期間が短い
⇒ 顧客要求事項は曖昧な表現が多い
曖昧／未確定／
⇒ プロジェクトは要件が膨らみ、納期が遅れ、予算が超過することが多い。
ユーザが真に行いたいことは何か？
設計に落とせない要求
・いかに早く要件を定義し、納期/ｺｽﾄ/品質のバランスを取り、
顧客が納得のいく見積りを行うか
・前例のない要件に対するリスクを如何に回避すべきか
・各ステークホルダーからの要求の変化や曖昧さに如何に対処すべきか？
・様々な利害の衝突に如何に対処すべきか？
要求定義を行う上流SE
の人材不足
受注側の問題
CMU2005海外エンジニアリングワークショップ参加報告書
運用フェーズを視野に入
れた要求定義がなされ
ない
2
「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義２）要求定義に関するヒント～考え方・意識
【機能要求と非機能要求】
要求には機能要求と非機能要求があり、非機能要求は事前に想定することが難しい。
われわれの悩み
＊非機能要求の例：コスト削減（金額に見合った要件の削減）、
：機能追加が容易に行えるシステム構成の確保
：進捗報告、テスト範囲報告
ヒント
【リスク】
考え方・意識
予め「リスクを見越して」計画を立てる
※ただし発生率の低そうなリスクは考慮に入れなくてもよい
｢どこに要件の不確実性（リスク）があるか｣組織
「システムを取り巻く環境や市場は今後どの様に変化するか」
【早期情報共有】
プロセス
前例のない要件については、特殊な要求である旨理解してもらい、協業での対応を依頼する、
前例のある要件に、可能な限り近づくよう変更してもらう
ツール
【抽象化】
抽象化とは、重要な部分のみを引っ張り出し、そこから詳細に落とすことであり、
レイヤー構造から成立している。的を得た的確な抽象化は（ＲＤＢの概念など）はパワフルな概念となり、
コンセプトとして理解されやすい。的を得た的確な抽象化のためには、充分対象物を理解することが必要である。
【イノベーション】
顧客価値を上げるイノベーションを行うプロセスとして、以下が重要である。
＊１人間について勉強・理解する
＊２ゴールを設定する（何ができればよいか、何をすべきか）
＊３ゴールを達成するための方法を考え、その中でどれがベストかを考える
CMU2005海外エンジニアリングワークショップ参加報告書
3
「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義２）要求定義に関するヒント～組織
【機能要求と非機能要求】
要求には機能要求と非機能要求があり、非機能要求は事前に想定することが難しい。
われわれの悩み
＊非機能要求の例：コスト削減（金額に見合った要件の削減）、
：機能追加が容易に行えるシステム構成の確保
：進捗報告、テスト範囲報告
ヒント
【初期の段階でステークホルダ参画】考え方・意識
初期段階でステークホルダを関与させることにより、”サプライズ”を回避し、ステークホルダー間の意見調整をする。
組織
【プロジェクトの分割】
プロジェクトを短いスパンに分割し、マイルストーンを設定する。そのマイルストーン毎に、ステークホルダーの
コミットメントを得ていく。
プロセス
【チーム編成】
メンバーの適正・スキルを把握して適切な仕事を任せる
ツール
明確なゴールとゴールまでの道のりを共有する
最終的なシステム（ゴール）のイメージを予め共有した上で、それを達成することを目的として要求定義を行う。
【ソフトウェアのサプライチェーン】
どこにどのようなステークホルダーが存在するのかを明らかにするためには、システム開発をサプライチェーンという
観点で見てみると良い。
CMU2005海外エンジニアリングワークショップ参加報告書
4
「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義２）要求定義に関するヒント～プロセス
【機能要求と非機能要求】
要求には機能要求と非機能要求があり、非機能要求は事前に想定することが難しい。
われわれの悩み
＊非機能要求の例：コスト削減（金額に見合った要件の削減）、
：機能追加が容易に行えるシステム構成の確保
：進捗報告、テスト範囲報告
ヒント
【OODAのプロセス】
考え方・意識
システム構築の結果は以下のサイクルを繰り返すことにより、もたらされる。
＊１
＊２
＊３
＊４
観察（Observe）
方向性の定義（Oriented）
決定（Decide）
実行（Action）
組織
プロセス
ツール
目的を定めるためには、顧客（消費者）の観察が重要である。
「観察する」というプロセスの位置付けと重要性は、情報システム構築における要件定義においても同様である。
マクロレベル、ミクロレベルのいずれについても、OODAのサイクルを当てはめることは出来るはずである。
PDCAが計画先行の発想であるのに対して、OODAはデータ分析による将来予測に基づいて現在の行動を
決定するという発想であり、リスクを軽減させることが出来る。
CMU2005海外エンジニアリングワークショップ参加報告書
5
「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義２）要求定義に関するヒント～ツール
【機能要求と非機能要求】
要求には機能要求と非機能要求があり、非機能要求は事前に想定することが難しい。
われわれの悩み
＊非機能要求の例：コスト削減（金額に見合った要件の削減）、
：機能追加が容易に行えるシステム構成の確保
：進捗報告、テスト範囲報告
ヒント
【プロトタイプ】
考え方・意識
不確実な要求に対するリスクを回避するには、早い段階でプロトタイプなどを活用し、実際に動く形でユーザに見
せることが有効。
組織
【モデリング】
要求を明確化する表現方法として、ユースケースなどのモデリングが有効である。
プロセス
【メタファー】
パワーポイントなどを使用して、視覚的に顧客に訴える
ツール
CMU2005海外エンジニアリングワークショップ参加報告書
6
「真の要求を見極めろ！」：teamB
リクワイアメント：要求定義３）提言
われわれの悩み
ヒント
提言
CMU2005海外エンジニアリングワークショップ参加報告書
7

Download Report