「真の要求を見極めろ!」:teamB
リクワイアメント:要求定義 1)要求定義における悩み
顧客側の問題
社内規定、セキュリティ
要件変更等による方針
レベルでの変更発生
決定者/相対が不明確
クライアント多忙による
要求決定の遅れ
要求変更が多い
あまりにも期間が短い
曖昧/未確定/
設計に落とせない要求
ユーザが真に行いたいことは何か?
・いかに早く要件を定義し、納期/コスト/品質のバラ
ンスを取り、顧客が納得のいく見積りを行うか
・前例のない要件に対するリスクを如何に回避す
べきか
要求定義を行う上流SE
の人材不足
受注側の問題
CMU2005海外エンジニアリングワークショップ参加報告書
講義内容が
ヒントになる??
運用フェーズを視野に入
れた要求定義がなされ
ない
1
「真の要求を見極めろ!」:teamB
リクワイアメント:要求定義 2)要求定義に関するヒント
われわれの悩みは、システム構築プロジェクトが本質的に抱えている問題である。(アメリカでも同じこと)
⇒ 顧客要求事項は曖昧な表現が多い
⇒ プロジェクトは要件が膨らみ、納期が遅れ、予算が超過することが多い。
予め「リスクを見越して」計画を立てるべき
※ただし発生率の低そうなリスクは考慮に入れなくてもよい
「どこに要件の不確実性(リスク)があるか」
「システムを取り巻く環境や市場は今後どの様に変化するか」
<具体的な解決方法例>
【初期の段階でステークホルダ参画】
初期段階でステークホルダを関与させることにより、”サプライズ”を回避
し、ステークホルダー間の意見調整をする。
【早期情報共有】
前例のない要件については、特殊な要求である旨理解してもらい、協
業での対応を依頼する、前例のある要件に、可能な限り近づくよう変
更してもらう
【機能要求と非機能要求】
要求には機能要求と非機能要求があり、非機能要求は事前に想定
することが難しい。
*非機能要求の例:コスト削減(金額に見合った要件の削減)、
:機能追加が容易に行えるシステム構成の確保
:進捗報告、テスト範囲報告
【プロトタイプ】
不確実な要求に対するリスクを回避するには、早い段階でプロトタイプ
などを活用し、実際に動く形でユーザに見せることが有効。
【モデリング】
要求を明確化する表現方法として、ユースケースなどのモデリングが有
効である。
【メタファー】
パワーポイントなどを使用して、視覚的に顧客に訴える
CMU2005海外エンジニアリングワークショップ参加報告書
これ重要だと思うんですが、
解決方法例ではないの
で。。困り中
一問一答式で
なんだか木を見て森を見ずになって
しまっているかんじ。。。
2
「真の要求を見極めろ!」:teamB
リクワイアメント:要求定義 2)学んだこと
~具体的 HowTo
システム構築プロジェクトが本質的に抱えている問題である。(アメリカでも同じこと)
われわれの悩み
= 顧客要求事項は曖昧な表現が多い
= プロジェクトは要件が膨らみ、納期が遅れ、予算が超過することが多い。
●非機能的要求に対しては・・・
・機能的要求: ・ユーザー側要求
要求事項
・システム作成側要求
・非機能的要求:予測困難、非システム的、後続フェーズにて問題が拡大化する
<解決案>ステークホルダー(エンドユーザー/決済者/テスター/品質管理チーム等)を早期に参画させ、
要求が発生した際に即座に対応出来るよう、要求に答えるための仕掛けや仕組みを確立
●前例のない要求に対しては・・・
*ユーザーに、特殊な要求である旨理解してもらい、協業での対応を依頼する
*前例のある要件に、可能な限り近づくよう変更してもらう
*要件を細分化し、一部ずつ実現して行く
*開発するシステムに関係する者全てを登場させる関係図(MAP)を作成する
うーんこれもつまらないですね
(要求定義のセクションまとめただけですね)
●要求定義のポイントは・・・
*曖昧な要求を早期に明確にする(パワーポイントなどを使用して視覚的に顧客に訴える、プロトタイプを提供し確認依頼するなど)
*実現の厳しい要件に対する妥協点を探る
*ステークホルダー間の意見調整をする
●長期プロジェクトに対しては・・・
*常に先を見越すことが必要である。
CMU2005海外エンジニアリングワークショップ参加報告書
3
「真の要求を見極めろ!」:teamB
リクワイアメント:要求定義 2)学んだこと
~要件定義で重要な考え方
●Abstruct (抽象化)
システム構築の結果は以下のサイクルを繰り返すことにより、もたらされる。
*1
*2
*3
*4
観察(Observe)
方向性の定義(Oriented)
決定(Decide)
実行(Action)
これらの概念を取り込んで構成できると
面白いものになるのでは?
特に抽象化は設計プロセスすべてを通して
当てはめることのできる概念と思い
個人的に面白く感じた部分です。
ただ、Abstructに関して私と川上さんの理解は
共通していたのですが、神谷さんの解釈と
違っていたようです。(@菊Discuss)
レポートからの情報だけでは足りないので一度
レジュメを見直す必要があります。。
抽象化とは、重要な部分のみを引っ張り出し、そこから詳細に落とすことであり、
レイヤー構造から成立している。的を得た的確な抽象化は(RDBの概念など)はパワフルな概念となり、
コンセプトとして理解されやすい。的を得た的確な抽象化のためには、充分対象物を理解することが必要である。
●イノベーション
要件定義にもイノベーションが必要!(とおもう)
顧客価値を上げるイノベーションを行うプロセスとして、以下が重要である。
*1 人間について勉強・理解する
*2 ゴールを設定する(何ができればよいか、何をすべきか)
*3 ゴールを達成するための方法を考え、その中でどれがベストかを考える
*1 成功する(儲かる)イノベーションのためには、技術面よりもまず顧客価値を考えることが重要である。
*2 限られた情報に基づき意志決定を行う場合、ツールはあくまで意思決定の支援のために利用するものである。
*3 イノベーションのプロセスにおいて、目的を定めるためには、顧客(消費者)の観察が重要である。
「観察する」というプロセスの位置付けと重要性は、情報システム構築における要件定義においても同様である。
CMU2005海外エンジニアリングワークショップ参加報告書
4
「真の要求を見極めろ!」:teamB
リクワイアメント:要求定義 3)要求定義に関する提言
前ページの
・アブストラクト
・イノベーション
の概念を持ってくる・・・とか
<私見>
(講義から得たものではないですが)
要件定義におけるポイントは、「目的」を明確にし、早期の段階でシェアすること。
これは河合さんが、ラージケーススタディで学んだこと、としてあげていました。
CMU2005海外エンジニアリングワークショップ参加報告書
5
ダウンロード

「真の要求を見極めろ!」:teamB リクワイアメント